DEV Community: Derek Bingham ☘️

How I Built My First App with Kiro

Derek Bingham ☘️ — Fri, 12 Dec 2025 06:08:52 +0000

Introduction

A few months back my son and I built a game using QCLI. This took me on a journey to understand agentic coding and prompt engineering, I then shared this journey with others in a talk The continued developer evolution.

I've been creating applications using agentic coding tools ever since. However, recently I decided that instead of mindlessly prompting my way through another prototype that would work once and confuse me forever, I tried something called spec-driven development with Kiro another new tool in the crowded agentic IDE market.

Spoiler: I didnt build a game this time ( as my son was at school :) ) I actually built a task manager app, to help me keep on top of all the things I havent done so far this year. The application needed: priorities, due dates and filtering. To build this application I turned to an immerging process called Specification Driven Development ( SDD ) and the tool to support this process is called KIRO

Here’s how it went down.

The Problem with My Old Workflow

I’ll be honest with you - I’ve been riding the AI coding wave hard. Type what I want, watch code appear, test it, call it a day. However when I revisited these projects, a week or even a month later, I'd think “wait, why did I build it this way?”

Well I could go through the chat history and find all the nuggets of my lost thought process, or look at the git history log - but this wasnt a reliable process. Also my architecture was a mystery and my requirements - lost in time.

All I could think of was if I had a team working with me, how could I explain the code to them ? The answer was I couldnt... and to me this wasnt acceptable when building real working software. This was “vibe coding” at its 'finest' - and it was starting to annoy me - there's got to be a better way ?

Enter Kiro

I started trialing Kiro during one of these “there has to be a better way” moments . Instead of jumping straight into code generation, it made me think through three levels: requirements, design, and implementation. This process formalised a new approach called Specification Driven Developent or SDD. Each level creating actual markdown files that get version-controlled with your code and so giving some structure to the previous chaos of vibe coding. So what is Kiro and how do we get started ?

Getting started with KIRO

This was super easy, I downloaded KIRO from here and signed in with my BuilderID and I was presented with a window much like this

I then read a few articles on KIRO best practices and finished this workshop, just to get familiar with everything around KIRO and the SDD process that it supports.

Lets start building...

Building My Task Manager

I decided to test my new found understanding of SSD and Kiro by building my new task manager application with priorities, due dates, and filtering. Nothing groundbreaking, but complex enough to see if this spec-driven thing actually worked. With SDD its important that I have an idea of what I want before starting so here is my initial sketches.

As you can see I'm not much of an artist :)

Phase 0: Steering and Architecture

Before we can start building we need to define the guardrails and rules that govern our application. These will help guide the AI as it generates the code. To do this I first created some steering files.

I choose workspace only as the location for these steering files and filled in the details I wanted from the resulting blank file that was created. Here is some of my steering rules.

When creating Python code, use the following guidance:

- Use Flask as the web framework
- Follow Flask's application factory pattern
- Use Pydantic for data validation
- Use environment variables for configuration
- Implement Flask-SQLAlchemy for database operations

I also could have added in some MCP servers in Phase0 to add additional context for Kiro to understand what I'm trying to build. MCP servers like the AWS Docs Knowledgebase MCP Server to provide the latest AWS docs, and the AWS Pricing MCP Server to provide me with Pricing information.

Phase 1: Requirements - Lets gooo !

Next its time to tell Kiro what to build, from the "Lets Build" panel, I made sure that "Spec" is selected and typed: “Build a task manager with priorities and due dates.”

Kiro then generated detailed user stories in something called EARS notation in a requirements.md file. Now to some EARS might be a new thing, but to me it was something from my past( it actually came out in 2009 !! ) , as a technique I had used extensively on some larger projects I worked on. Think of it as a standard way of stating requirements.

So an EARS statement would typically be like:

'While optional pre-condition, when optional trigger, the system name shall system response>'

So Kiro generated extensive requirements like:

[WHEN] the user creates a task without a due date [THEN] the system [SHALL] set the default due date to 7 days from creation
[WHEN] the user attempts to save a task with an empty title [THEN] the system [SHALL] display an error message

These weren’t things I asked for. They were edge cases I would’ve discovered through production bugs at 2am. The AI was thinking ahead, documenting assumptions that would’ve otherwise lived only in my head. Pretty cool

I reviewed the requirements, and wanted to add some specifics about filtering and sorting. So to do this I could either use the chat interface again OR ( and this is what I did ) add the new requirements manually. Once that was done I saved the file and make sure that Kiro was aware of these changes I put a prompt into the chat interface:
'I have updated the requirements - please reload and review', and moved on to the next Phase.

Phase 2: Design - The “Aha!” Moment

This is where Kiro really changed my perspective. It took my requirements and proposed a complete technical design: data models, API endpoints, component structure, database schemas. Everything laid out in a document I could review, modify, and reference later.

For my task manager, it suggested: the following

A React frontend with clear component hierarchy
REST API with specific endpoints
SQLite for local storage
State management patterns

The design phase forced me to think about architecture before writing a single line of code. In my old workflow, I’d be three prompts deep into implementation before realizing my data model was completely wrong.

Here, I was able to catch issues early. As I had clearly articulated inside the steering files what the rules of this project were. So Kiro knew already what tech stack I wanted (if you have used other agentic coding assitants like claude code, you might call these rules ) So now every piece of generated code aligned with how I actually work.

Phase 3: Implementation - Breaking It Down

Once I had reviewed, iterated and finally was happy with the design, Kiro broke everything into discrete implementation tasks. It also gave me two options - to create some tasks as optional ( for a quicker MVP ), or to make all tasks mandatory. I chose the former

Each task was trackable. I could execute them one at a time or let Kiro’s Autopilot mode handle multiple tasks at once.\

The tasks weren’t vague like “create the frontend” - they were specific - here are some examples:

Set up project structure and dependencies
Implement Task data model with validation
Create TaskList component with filtering
Build API endpoints for CRUD operations
Add error handling and edge cases

I could review each task’s implementation, see exactly what code was generated, and understand how it connected to my original requirements. This traceability was exactly what I was after as show below

What if things go wrong ?

So in the implementation phase there was a number of times that task would not complete. However when this happened I could re-run these tasks and Kiro would open a new chat window, so clearing the context, before reloading the steering and design files. This allows it to easily pick up were it left off - a very handy feature when building complex applications with AI tools.

The Real Test: Adding Features Later

A week later, I wanted to add tags to tasks. In my old workflow, this would mean:
Searching through code history, logs and prompt history trying to figure out where things live.

Prompting the AI with incomplete context
Hoping I didn’t break anything( never successfully )

However now with Kiro, I just updated my requirements document with two lines about tagging functionality. Kiro automatically updated the design, created new implementation tasks, and modified the existing code to support tags. Everything was version-controlled, documented, and traceable.
It felt like having old skool pair programming and having another engineer to vounce ideas off, who actually remembers what you decided last week.

A word on testing

I think its important to also point out that some of the tasks Kiro generated to satisfy my requirements and design tasks, was to create unit test suits to verify everything. However, unit tests are not the only way developers verify their code is fit for purpose. We also had techniques like Business Driven Developement(BDD) and Test Driven Development (TDD) ( test first ) . The good new is, a similar techniques Property Based Testing(PBT) is included in Kiro's workflow out of the box!!

So at the end of an hour or so of furious Kiro-ing I ended up with this thanks to SDD and it worked !

Given more time

If I had more time ( hopefully I will ) my next stage would be to use this process to create a build and deployment pipeline so I can deploy the Task Manager website into the cloud.

Other things I would love to investigate is another feature of Kiro called Kiro Powers. These specialized modules / plugins for Kiro, add expertise in specific tech stacks like AWS, Stripe, or Figma, by providing tools and workflows that support building with that stack. So by bundling tools, best practices, and code into easy-to-install packages, Kiro can then produce better outcomes and accelerate development tasks. I've linked a nice article about Powers above and its definatley on my todo list to implement.

What I Actually Learned

So what did I actually learn by building this..
Your specs become super prompts. Your requirements and design documents stick around. Unlike chat history that disappears into the void, these are durable context the AI remembers across your entire project.
Slowing down speeds you up. Taking time to review requirements and design actually makes development faster. You catch architectural issues before they become technical debt that haunts you at 3am.
AI needs structure. Kiro’s approach keeps the AI focused and aligned with what you actually want. It’s true collaboration, not just “generate code and pray.”
Documentation is free. Your specs double as project documentation. When your teammate asks “why does it work this way?” you have an actual answer, not “uh, the AI did that I guess?”

When Should You Actually Use This?

Spec-driven development isn’t for everything. Building a quick proof-of-concept / or architectural spike to test an API or experimenting with something you’ll throw away in an hour? ? Just vibe code it with prompts and get a quick feedback cycle happening

But for anything you’ll maintain, expand, or collaborate on, SDD provides the structure that prevents your codebase from becoming a mystery novel where you’re both the author and confused reader.

Kiro gives you the best of both worlds: the speed of AI-assisted development with the clarity of actually knowing what my code does.

Getting Started

With Kiro and SDD, if you can write a prompt, you can create a spec. The SDD Workshop by my esteemed colleage @094459 has hands-on tutorials that walk you through building complete features.

The shift from vibe coding to spec-driven development felt like going from scribbling notes on napkins to using a proper notebook. Both work, but one of them lets you find your notes later.

Now its your go

Get started just like me by doing this SDD Workshop on GitHub ( thx @094459 ) for hands-on tutorials, or download Kiro from kiro.dev and see how spec-driven development changes your workflow.*

How a 12 year old built a game with Amazon Q Developer CLI.

Derek Bingham ☘️ — Tue, 15 Apr 2025 03:38:52 +0000

Introduction

Last weekend, my 12-year-old son and I embarked on a game development adventure that transformed our usual Sunday afternoon gaming session into something a bit different. Armed with Pygame, the new Amazon Q Developer CLI, and an experimental approach we called "child coding" we decided rather than play games, lets build one. So thats what we did ! - but in the end we managed to create not one but two simple games in a single day.

Here's how it went down.

Setting Up Our Environment

This was easy, all we had to do was install the Amazon Q Developer CLI. We would then use the capabilities of this tool to work out what else to install and how to install it, including any of the other software we needed on our quest.

The easiest way to get started, we found was to use THIS LINK, this excellent blog by Ricardo is a one stop shop on how to set everything up. Q Developer CLI is a coding assistant that brings generative AI capabilities directly to the command line. While not specifically designed for game development, we discovered it's remarkably effective when paired with Pygame.

We knew we had everything running by executing from a standard shell env.

q doctor

Using a game engine

For this we decided on Pygame which is a a free and open-source cross-platform library for the development of multimedia applications like video games using Python. I had previously been shown what Pygame could do and thought it would be a great fit. Its python so pretty easy to pick up and my son had very limited coding experience to begin with and installation was easy.

pip install pygame

Our First Game: "PacNibbles"

For our first creation we reused an idea I had heard about previously, that is, creating a game that is a mashup of two other games. So we created PacNibbles - a mashup of Pacman and Snake(nibbles). Instead of meticulously planning every detail, we embraced "child coding" - a term loosely based on "vibe coding", coined for our approach of starting with a core game play feeling and iteratively building toward it, using AI to fill in the technical gaps. Once we had our idea we then started to prompt the AI Assistant.

q /chat "write a pygame game which combines the ideas of pacman and nibbles"

This is were Q Developer CLI started doing all the heavy lifting for us. It created a code repo, created a ReadMe.md and started to fill out the python file pacnibbles.py with code. Once complete all assertions and mechanics were outputted to the console

So this was the end of our first iteration and guess what ? When we started the game it worked !! BUT it was very 'blocky' and not fun to play. So we started some "child coding" iterations. Our next prompt was:

> I now want power pills that let me east the ghost added to the game

and then we added better graphics

>Great - I now want the game to look really nice with enhanced graphics

Our "vibe coding" technique followed these principles:

Focus on the game feel first
Build the minimum viable prototype
Use AI to overcome technical roadblocks
Test frequently with our target audience (Kiddo's friends)
Iterate based on immediate feedback

This approach proved perfect for our father-son project. Kiddo could focus on the creative aspects while I handled the technical, with Amazon Q Developer bridging our knowledge gaps.
In the end we had this game looking quite nice and playing well

Our Second Game: "Clowns Adventure"

Encouraged by our success with PacNibbles, we moved on to a more ambitious project: a simple 2D platformer called "PlumberPlatformer." This time, we needed more complex mechanics like jumping, platforms, and gravity. Rather than writing everything from scratch, we leveraged Amazon Q's ability to generate boilerplate code:

q "create a pygame thats a platformer with a character with gravity, jumping and platform collision

The CLI output gave us a solid starting point that we could then customize to fit our game's vibe and this is how the first iteration turned out.

We will work on that next weekend :)

Lessons Learned

Our weekend project taught us several valuable lessons:

AI coding assistants can dramatically accelerate development, especially for educational projects
"Vibe / child coding" - focusing on the feel and iterating rapidly - works well for game development
Parent-child coding is more engaging when both contribute to the creative direction
Pygame remains an excellent entry point for young game developers

Conclusion

One day, two games, and a whole lot of fun, we had created something we were mostly proud of. Our games weren't perfect, but they were fun, and more importantly, they were ours. For parents looking to connect with their children through coding, I highly recommend this combination of Pygame and Amazon Q Developer AI CLI coding assistance. The barrier to entry has never been lower, and the creative possibilities have never been greater.

If you want to get started too ??

Download and install Amazon Q Developer CLI

Thanks for reading, if you manage to build some games better than ours - please comment below :)

Using the Flutter BLoC Pattern with AWS Amplify Datastore

Derek Bingham ☘️ — Mon, 30 Aug 2021 07:11:44 +0000

Introduction

Last year I began really looking into Flutter development as AWS released the beta version of the AWS Amplify Flutter client libraries. These Amplify Flutter libraries are now GA
and I have started building out applications that show the offline sync functionality of AWS Amplify's DataStore category.

So as I built out various UI's that used DataStore, I quickly ran into the old problem of how to handle state and emit/consume events as states changed. This is where I came across the BLoC pattern and its simplified sibling the Cubit. So I thought I would write a quick post about it as I loved its simplicity and elegance in wrapping the AWS Amplify DataStore calls.

In this post I will walk you through an example of the BLoC pattern, how you can use it to improve your use of AWS Amplify Datastore API calls, to be a lot cleaner and so easier to maintain.

Abstract Data Access

For those who do not know about Amplify DataStore, it provides a programming model for leveraging shared and distributed data without writing additional code for offline and online scenarios, which makes working with distributed, cross-user data just as simple as working with local-only data. If we boil this down, it simply means that working with a single set of DataStore API calls means that data will not only be persisted locally, but also synced with a connected cloud back end.

The Datastore API calls, like any traditional data persistence mechanism are best wrapped in a repository pattern - I have been wrapping these calls in a repository so that I can abstract them away from the application logic and make them testable.

Understanding BloC

First lets have a quick overview of state and in particular the use of the BLoC pattern in Flutter. The pattern itself is very much in the reactive style, and stands for Business Logic Components. The gist of BLoC is that everything in the app should be represented as stream of events: widgets submit events; other widgets will respond. BLoC sits in the middle, managing the conversation. An added benefit is that Dart comes with syntax for working with streams that is baked into the language. Lets see how a typical program would flow using the Bloc and Repository patterns with the UI Layer

As you can seem, data flows from the UI layer, via the BLoC layer into the repository. The example shows the repository wrapping a Amplify.DataStore.save() call.

Understanding the Cubit

As explained the BLoC uses a stream of events and in its natural form isn't that easy to then wire into UI widgets. To listen and take action on events generated by widgets in Flutter we can use the Cubit, a simplified way of implementing BLoC in your application. The main difference between BloC and Cubit is that Cubit is suitable for simple state management where you just have one kind of event to bind to the state. While Bloc is for complex state management where you can have many events to map to states. This is what I have been using when interacting with the my repository that wraps Amplify DataStore calls. I often find keeping things simple is the way forward.

Putting together a simple example

So to demonstrate this I will walk you through the steps required to implement a simple 'update' action using Cubit. The first thing we need to do is install the dependencies we need in pubspec.yml

Here we can see the dependencies I need to run AWS Amplify along with the Flutter BLoC libraries. Once they are pulled down, next we create our repository class to wrap our DataStore API calls.

import 'package:amplify_flutter/amplify.dart';
import 'package:flutter_droidcon/models/ShoppingListItem.dart';

class ShoppingListItemRepository {
  Future<List<ShoppingListItem>> getListItems() async {
    List<ShoppingListItem> items = new List.empty();
    try {
      items = await Amplify.DataStore.query(ShoppingListItem.classType);
    } catch (e) {
      print("Could not query DataStore: ");
    }
    return items;
  }

  Future<void> createListItems(String itemName) async {
    final item = ShoppingListItem(itemName: itemName, isComplete: false);
    try {
      await Amplify.DataStore.save(item);
    } catch (e) {
      throw e;
    }
  }

  Future<void> updateListItem(ShoppingListItem item, bool isComplete) async {
    final updatedItem = item.copyWith(isComplete: isComplete);
    try {
      await Amplify.DataStore.save(updatedItem);
    } catch (e) {
      throw e;
    }
  }

  Stream observeTodos() {
    return Amplify.DataStore.observe(ShoppingListItem.classType);
  }
}

This code has a number of data operations get/create/update that take the passed in args that are then used to construct the Amplify DataStore API calls.

The next stage is to create the Cubit that wraps these calls. The Cubit for the above repository class looks like this:

class ShoppingListItemCubit extends Cubit<ShoppingListState> {
  final _shoppingListRepo = ShoppingListItemRepository();

  ShoppingListItemCubit() : super(LoadingShoppingList());

  void getListItems() async {
    if (state is ShoppingListSuccess == false) {
      emit(LoadingShoppingList());
    }

    try {
      final items = await _shoppingListRepo.getListItems();
      emit(ShoppingListSuccess(listItems: items));
    } catch (e) {}
  }

  void createListItems(String itemName) async {
    await _shoppingListRepo.createListItems(itemName);
  }

  void updateListItem(ShoppingListItem item, bool isComplete) async {
    await _shoppingListRepo.updateListItem(item, isComplete);
  }

  void observeItems() {
    final itemStream = _shoppingListRepo.observeTodos();
    itemStream.listen((_) => getListItems());
  }
}

Notice that inside some of the methods in this class we can also emit() state changes. Finally, lets see how to use the Cubit defined above. Using the updateListItem action as an example, what does that look like inside a UI widget.

Widget _shoppingItemListView(List<ShoppingListItem> items) {
    return ListView.builder(
      itemCount: items.length,
      itemBuilder: (context, index) {
        final item = items[index];
        return Card(
          child: CheckboxListTile(
              title: Text(item.itemName),
              value: item.isComplete,
              onChanged: (newValue) {
                BlocProvider.of<ShoppingListItemCubit>(context)
                    .updateListItem(item, newValue!);
              }),
        );
      },
    );
  }

As you can see implementation of the pattern inside the widgets onChanged property is trivial and we simply look up the Type of object we want the BlocProvider for, the send the value down to the BloC class's method - which in turn delegates to the repository. Very simple but extremely effective.

Summing up

As you can see, building with Flutter and Amplify lends itself really well to baking in best practice application architecture into your solution. In this article I showed you how to use Repository and BLoC patterns and how well they can facade the Amplify DataStore API calls. This then makes it very easy to build out a data persistence mechanism for your application that will function in online and offline modes with little code.

This was a very short example, if you want to see a more involved examples using multiple repositories and cubits - see My Github Repo. I have also written a Series of Amplify and Flutter posts detailing how to build out an application.

As always, please help me with future articles by providing feedback.

Until next time...

10 Things I've learnt being an AWS Developer Advocate

Derek Bingham ☘️ — Mon, 30 Aug 2021 04:15:49 +0000

Intro

So exactly 12 months ago I landed a job as a Developer Advocate at AWS. A job title, that when I left school with a rudimentary knowledge of Java v1 didn't exist. Now this isn't unusual in the technology industry today, where new job roles and titles are popping up almost daily. The role of Developer Advocate(DA), is becoming more and more popular, so I want to share my experiences and the advice that I would give to anyone who wants to be a DA or indeed wants to work at AWS. As inevitably most of this blog is also about working at AWS, as well as, being in Developer Relations as a Developer Advocate.

Background

My career has been primarily in technology as a software developer/engineer who is at their happiest in front of a screen building software. After 15 or so years of this I decided to try something different and joined AWS as a Solutions Architect (SA). Luckily enough a role came up in the most remote and beautiful of cities, Perth Western Australia where I live (see top of post for a pic). Three years into AWS I managed to land a role as a DA, due mostly to dumb luck and an understanding hiring manager.

This role I have found at times to be very challenging, however I have enjoyed it immensely. Mostly due to the fact that I am able to influence and help developers on a far greater scale than I could have previously hoped for as a software engineer. So here are the things I have learned and techniques I have adopted to help me be a better Developer Advocate at AWS, but still stay true to my software engineering roots. As being a DA does mean that you work in marketing, a fact that on first glance would seem a bit strange.

Tip 1: Internal Vs External Advocacy

AWS is a large company and ships lots of code in the form of services and features to the platform. To be effective as a DA you need to be known within the organisation as a thought leader and someone who can deliver great content on a service or feature. This requires Internal Advocacy. At the same time you also are employed to advocate on behalf of developers who are using AWS services and features to build cool products. This requires External Advocacy.

Its easy to over index on one over the other, the most effective DA's always find the perfect balance of the two. They are well known by teams within AWS but also by the external developers they advocate on behalf of. They have built this balance up over time, and have spent many hours building the relationships required to be successful, there is no short cut. Put simply, you cant advocate for developers unless you intimately know / can influence the services they are building with, so take the time to find that balance.

Tip 2: Take notes

Writing things down is important, inside AWS writing takes on a whole new level of importance. Being a developer advocate inside AWS, good writing skills are essential. You are always writing; blogs, code, internal documents etc. The skill I would like to highlight, is the art of taking actionable notes. Notes that not only make sense as you write them, but also will make sense to future self and can be turned into actions.

Take this scenario - you are thinking about your next great piece of content. An idea comes to you while walking for your morning coffee, you sketch out the idea in you head, it sounds awesome !!. You get home and start to write the idea down, only to find you have forgotten half the content you thought of on your walk, you end up not doing the content. DO NOT LET THIS HAPPEN!* Always have a way of writing your ideas down. Even if they simply act as a catalyst for other ideas, don't waste them - take your phone out WRITE IT DOWN, but always take the time to write a coherent structured sentence. A sentence that you in four weeks time can read and take action from.

Tip 3: Execute

Thoughts and ideas are good, writing them down is a great step but actions and results are better. You can have 10 great ideas but unless they lead into 10 pieces of great content (blogs, streams, videos) they are meaningless. You need to execute on an idea - make it a reality, as that reality is what you will be ultimately judged on.

Tip 4: Prioritise , Prioritise and Re-Prioritse

Now there is no way you have time to execute 10 ideas - in fact you will be lucky to execute on a very small number. This is due many things, life, distractions, life and even distractions ;) - so make prioritising what you are going to execute on a constant. Ask yourself, is this the right thing to be concentrating on right now? Will this have a better impact on the thing that is next on my list? Will it be worth the x number of days of focus to create it? There is no worse feeling than spending a week creating a blog post that no-one reads or gets little impact. This skill of prioritising and re-prioritising is also a non negotiable when working inside AWS, as work is always infinite, you need to keep prioritising!

Tip 5: Become your own producer

The modern DA needs to produce content in a number of formats. No longer is it a case of showing up at a conference or meetup - speaking and conveying a message to a group who are physically in the same room as you. Now it is a case of preparing and talking to a camera and conveying your message to a group of people you cant see, who might be on the other side of the globe. You could be streaming a live coding session or recording a video showing how to build x - but you need to be as engaging as if you where on stage in front of your audience.

In this arena production quality and setup is important, very important. You need to cut through and engage people, your session needs to stand out and engage people quickly, so make sure you learn how to build up a YouTube or Twitch channel. Read about how others are doing it, find out what camera, mic, editing software is being used. Learn from others like: (in no particular order)

Marcia
Nader
Kyle

Now recording is not something I had much experience with at all, and building a good set up is not easy, you constantly underestimate the time involved. But that time needs to be invested so that the content you have does not get lost in the ever increasing amount of digital content available.

That all being said, remember, good content is everything Being a good producer just makes your content more accessible to a wider audience and makes it more likely that people will actually find and watch it.

Tip 6: Time and Timezone mismanagement

I live on the GMT +8 timezone and work for a US based company that for the most part operates 12 hours behind me. There are always meetings on at any time of the day or night. Do not feel obliged to turn up, give yourself a break from the 24 hour development cycle. Set your own time and set your own time boundaries, you are the best qualified to know when these are. Yes there will be times when you need to present at midnight to a group 8 hours time difference away. Make this an exception, if you do not, you will not last, you will burnout and miss the opportunities that you are presented with, due simply to being over tired. Learn the 'art of saying no'

Tip 7: Be Authentic

Be your true self, by that I mean, if you are a software developer, build content that is focused on code. If you love architectural principals, build content that is focused on architectural patterns and practices. I find the best content is that which you, the creator, would like to watch. So try and keep coding, and always be your authentic self with your audience.

Tip 8:Have fun

If you don't enjoy what you are doing, it comes through in the final product, so play to your strengths. If you find yourself writing an article or recording a video and your heart is not in it, because you find the content boring and uninspiring, then STOP, DON'T GO ANY FURTHER. I have made this mistake many times, and what ultimately results is content that you are not proud of and ultimately you end up dumping anyway. Save yourself some time and anguish :)

Tip 9: Reuse and Recycle

Don't be afraid to take someone else's idea and content and put your own perspective on it, make it your own. At first I was guilty of trying to think of unique content for everything, this quickly doesn't scale as how many truly unique things are left to do? Instead, I was given great advice "its OK to reuse" and recycle - but put your own perspective and take on things".

You may see an excellent you tube series that you think would make a great blog series or is missing an important addition. There are a few caveats of course - don't copy and plagiarize, instead, add something to existing content and always acknowledge the "shoulders of giants" you are standing on.

Tip 10: Always seek feedback/review

How can you ever hope to improve if you DONT ask for feedback? the short answer is - you can't.

In Summary

Working at AWS is a unique and humbling experience in and of itself. The culture , peculiarities and people, all make it different every single day. Working as a Developer Advocate within the organisation, gives you the reach and the ability to really influence and affect change in the software solutions that developers are creating today. Its a real privilege to help developers around the world, and in a very small way, build the software solutions of the future.

And we are always hiring

Thanks for reading, as as always feedback always welcome - see Tip 10

Building Android with Flutter and AWS Amplify — Part 3

Derek Bingham ☘️ — Tue, 10 Aug 2021 02:16:54 +0000

Building Android with Flutter and AWS Amplify — Part 3

Introduction

This is final part of a three part series on using Flutter with AWS Amplify to build an Android mobile application. In Part One we scaffolded out our shopping list application using Flutter to build our UI, before adding offline datasync capabilities to the application with Amplify Datastore. Then in Part Two we built a login / signup UI in Flutter and implemented the backend auth flow with Amazon Cognito using the Amplify Auth Category.

In this the final part of the series we will complete the application by adding two additional features from our backlog:

Add the ability to store the users profile image in the cloud
Add the ability to track user behaviour with analytics.

What are we going to build ?

In this post we will start to build a screen flow that allows us to add an image to the user profile UI. Clicking ‘Change Avatar’ will launch the Android Gallery and allow us to choose an image, once an image is chosen we will be returned to the profile screen, with the chosen images displayed. As well as being displayed the image will be uploaded to the application back end, so that a user can maintain their profile image across devices.

Building the UI in Flutter

As ever, the first step in the process is to build out the UI in Flutter. To build the ‘ profile image widget ’ we will need two widgets, 1 / a circular profile widget to view the image in and, 2 / a button to launch the android gallery view so we can choose a new image. The UI code will look something like this

profile_view.dart

So here are the two widgets inside profile view — as you can see, we are using a BLoC to pass a state object into the UI. In this case the state object will store our image once we have grabbed it from the phones gallery. If we also look at the button code we can see that the call to open the gallery goes to the ChangeAvatarRequest() method — lets have a look at that next.

profile_bloc.dart

So inside the Profile BloC’s mapEventToState() method, if the ChangeAvatarRequest event comes in we are doing a number of things.

using an _imagePicker to set the selectedImage
passing that image to a storageRepository for uploading
updating the user object with the imageKey to the image
updating the user profile and grabbing the URL for the uploaded image.

For this to work we are missing a few things that we need to setup, namely the _imagepicker and a storageRepository. So lets do these next.

Adding an Image Picker

So the image picker is the package that will open the Android Gallery app and allow us to pick an image. This functionality we can get from Flutter’s repository of packages pub.dev , with the one we want being called image_picker. If we navigate to the image_picker package on pub.dev we are given installation instructions for Android.

image_picker Android install instructions

So all we need to do then to install image_picker for use in our Android device is add it into pubspec.yml.

Creating a Storage Repository

As in previous posts, we are using the repository pattern to wrap and abstract API calls for the underlying storage mechanism. In the Storage Repository’s case we are abstracting away the AWS Amplify Storage feature/category. So lets install that category before proceeding.

To do this we run the following command from a terminal within our project.

amplify add storage

It is then prompting us to fill in some values, we are choosing mostly defaults apart from the ‘Who should have access’ question where we select Auth users only and give them full CRUD privileges.

Once we are happy with this, we call

amplify push

to push all of these changes into the AWS account and provision an S3 bucket for our uploaded files to live in with the correct access controls built in.

Adding dependencies and API calls

The next thing we need to do is change ‘pubspec.yml’ to add the amplify_storage_s3 plugin before updating the_configureAmplify() method in main.dart. This should now look like this with the added call to AmplifyStorageS3

After adding the new libraries of image_picker and amplify_storage_s3 , our pubspec.yml should now look like this:

Once the libraries are added and our backend is provisioned, the final part is to wrap the storage API calls in a repository.

storage_repository.dart

As you can see this is similar to all the other repository’s in the application, for this storage repository was are wrapping the Storage.uploadFile() and Storage.getURL() methods in Amplify.Storage api calls — Also notice that we are not re-downloading the file to view the Image, but rather using the Flutter NetworkImage widget (see profile_view.dart above)

Adding Analytics

Now in the final part of our journey we will add some analytics into our application so we can track how our users actually use the application in the wild. To do this we are going to implement a quick set of analytics to track user behaviour using Amplify’s Analytics category. We first need to add this to our project by following the usual steps, namely

In the terminal run ‘ amplify add analytics ’ — and fill out the prompts as below

In the terminal run ‘ amplify push -y ’ — to deploy the changes to the back end. Like all other Amplify categories the Analytics category abstracts away a service from the developer, to reduce the complexity of provisioning. In the case of Analytics the service is Amazon Pinpoint that we are provisioning as the back end Analytics service. You can also stream the Analytics events into an Amazon Kenesisstream and then implement another provider to act on these events in the stream.
Next, add the ‘ amplify_analytics_pinpoint ’ dependency to pubspec.yml

pubspec.yaml snippet

Finally, update amplify configure code in main.dart, to include the new category of Analytics

| Note: If everything is done correctly then re-launching the app should work — if this doesn't work as expected, check the contents of amplifyconfiguration.dart in this file are all the configuration details for the Amplify categories. If configuration values are not there for categories that are added to your project then the app will throw an exception on startup with details of what is missing.

Assuming everything is working and the application is starting the next step is to decide on what event to capture. For the purposes of this app, we are going to be interested in shopping items as they are added to the Shopping List by each user. A great feature of Amplify Analytics is that it can introspect the user details and easily add them to the event we want to track. So lets set that event up now

shoppinglistItem_view.dart

Here we are intercepting the UI call by the user to create the new item in their shopping list. The recordNewEvent method will then decorate the event and send it to Pinpoint.

shoppinglistItem_view.dart

This does some minor decoration before registering the event which by default will be flushed every 30 seconds to the Pinpoint servuce. This default can be changed inside amplifyconfiguration.dart if desired. See here for more information and details on the information we can capture using the Amplify Analytics category.

Summing Up

So that is it for our journey building out our Android Flutter application to store our shopping list data, in this final part we added functionality to upload our profile images and to track our user behaviour with analytics. We talked about the ability to pull in existing components from flutter pub.get to interact with native controls. Then we added the Storage category from Amplify to the project which provisioned an Amazon S3 bucket with the correct permission to store our applications images. Finally we added the Analytics category to provision an Amazon Pinpoint instance to store any events we want to track of user interaction on the device.

During the course of this series we have seen how well Flutter and AWS Amplify can be used in tandem to really accelerate the application development and delivery lifecycle. So that ultimately you can deliver applications with great features into the hands of users quicker than ever.

If you want to follow along with this blog and build this application yourself, remember the finished code can be cloned from https://github.com/deekob/flutter_droidcon and you can also follow along with Kyle (aka Kilo Loco) in his excellent #30daysofflutter you-tube playlist

Thanks for reading, please reach out on twitter if you have any questions.

Until next time…

Building Android with Flutter and AWS Amplify — Part 2

Derek Bingham ☘️ — Thu, 05 Aug 2021 14:26:04 +0000

Building Android with Flutter and AWS Amplify — Part 2

Introduction

This is Part two in a series of three articles describing how to build out an Android mobile application using Flutter and AWS Amplify. In Part One we scaffolded out our shopping list application using Flutter to build our UI. We then, added our initial offline first datamodel usingAWS Amplify AdminUI sandbox and tested that it worked with our UI. Then we deployed our changes and provisioned the AWS services that control our application’s backend ( AWS Appsync and Amazon DynamoDB ) and finally we made sure that all clients were correctly seeing the most up to date version of our shopping list data as it synchronized between them.

In Part two we are going add extra features to our application by creating a user login screen, this will add the ability to login, signup and verify signup for our application.

What are we going to build ?

First Screen — “Login”

Enter Email
Enter Password ( hidden)
Submit
Link to Signup

Second Screen — “SignUp”

Enter UserName
Enter Email
Enter Password
Submit
Link to Login

Third Screen — “Confirm Signup”

Enter email verification code
Submit

So you can see what is a very standard login flow, prompting the user to login if they have an account. If they don't have an account then prompting the user to signup, with an additional step in signup to verify a code that has been sent to their signup email address.

Building the UI in Flutter

So the first step as always is to flesh out the UI and how that will behave using dart. Again as with the previous article all the code for this demo you can find here https://github.com/deekob/flutter_droidcon . Now we know from the last post that in Flutter everything is a widget so in this post I want to introduce another Flutter concept and that is that of Cubit and BloC patterns.

In basic terms the BLoC ( Business Logic Components ) is a pattern that has come from the Flutter community, so if you haven't built anything in Dart, its unlikely you would have come across it. However if you have used patterns like Redux, MVVM and MVC it will be very familiar to you. In a nutshell what BLoC does is take a stream of Events ( from the UI ) and transforms them to a stream of States — with Cubit being a subset of BloC and relies on methods as opposed to events to emit state change events. As there are a few state changes in a normal authentication flow, it means handling these changes and updating your UI accordingly can get fiddly, but using Cubit with a repository pattern is a nice way of decoupling these state changes.

So lets start by looking at the main login screen.

login_view.dart

So if we look at login view for example, we can see in the build method we now introduce a context , inside of which we have an AuthRepository and an AuthCubit ( more on those later ). This context is then passed to the UI if elements need access to it. We then also have our widgets defined and they can be wrapped in a BlocListener which will be invoked when any state changes, so we can in effect update the UI based on state — which is exactly what we want for the auth flow. So lets now have a look at the LoginBloc that is taking the events from the UI and updating the state accordingly.

login_bloc.dart

The main method in a Bloc is always the mapEventToState method — which does exactly what you think it would do. As you can see we are listening for events from the UI and depending on their type we are updating the state. Depending on the event we may also want to make a call to the Auth repository ( as we do here with LoginSubmitted ). The repository is how we are abstracting our auth store from our application. In Part One we also used a repository pattern to do the same for our data store holding our shoppinglist data. Next lets see what our auth repository looks like.

auth_repository.dart

As you can see the repository is wrapping calls to the Amplify.Auth library, much the same way as in the previous post our repository was wrapping calls to the Amplify.Datastore library. So the next step is to update our application to add the Amplify Auth libraries and associated backend.

Adding Amplify Auth

The first thing we need to do is update pubspec.yml and add the new Amplify Auth dependancy — after that has been done the dependancies section in the file should look something like this:

pubspec.yml

Notice we also have the other plugins we have been using, flutter_bloc , amplify_datastore and a mplify_flutter already there from Part One. Once ‘pub get’ has been run we can now go ahead and change our amplify configure code in main.dart to configure the new Amplify feature.

main.dart

This will complete the code changes we need to do to configure the Amplify libraries, the final part is to configure and deploy the supporting backend. Just like the Amplify Datastore feature/category abstracted AWS AppSync and Amazon DynamoDBin Part One of this series, the Amplify Auth category abstracts Amazon Cognito as our identity provider (IDP) where our users are held. To provision this we can either use the Amplify CLI and call ‘amplify add auth’ or once again we can use the Amplify Admin UI. In this example we will use the Admin UI, we do that by selecting ‘User Management’ in the Admin UI.

In our example we will be using username as a login mechanism — so remove the default of email and replace it with Username.

Once happy with our choices, selecting ‘Save and deploy’ will create a Amazon Cognito instance for our user store and add it into our backend. This also enables us to create users for our app via the Admin UI. Once that is complete and the backend has been deployed we then re-pull the configuration down locally like before — as shown below:

In the terminal in our local dev environment we simply run the ‘amplify pull’ command shown above to pull down all the backend configuration that we just created using thhe Amplify AdminUI.

Rinse and Repeat

This is the login UI, states and actions all connected into our repository, the next stage is to do the same for sign-up, and confirm. This involves writing the view , BloC and states for those actions, much the same way we just did for the login action. Below is an excerpt from the confirm view

confirm_view.dart

As you can see its exactly the same pattern. Once we have completed these classes for sign-up and confirm — we simply make sure that the repository has the necessary Amplify.Auth API calls and that should now be our functionality complete — you can see the calls in the Auth Repository snippet below

auth_repository.dart

Summing Up

So that is Part 2 of our Android Flutter application built, in this part we created the UI for login, signup and confirm screen flow. We talked about the BLoC / Cubit pattern in Flutter and how we can manage state changes with it. Then we added the Auth category from Amplify to the project which provisioned Amazon Cognito and gave us a consistent Auth API which we wrapped in a repository on the client.

In the next and final part of the series we will build out another screen in our application — this will hold the user profile information and we will learn how to implement image upload capabilities from our Android device so we can store our users picture as part of their profile in AWS.

Until next time…

Building Android with Flutter and AWS Amplify — Part 1

Derek Bingham ☘️ — Tue, 03 Aug 2021 09:54:25 +0000

Building Android with Flutter and AWS Amplify — Part 1

Introduction

This is the first part of a three part series on using Flutter with AWS Amplify. In this series we will learn how to setup a Flutter project with Amplify, to make the most of the Amplify provided categories/features like auth, storage and API. In Part 1 we will go through how to scaffold a project and build out an initial UI, before creating our application’s data storage model and provisioning out the AWS cloud backend. In part two and part three of this series we will build on this application and add additional features available in AWS Amplify, such as Auth, cloud storage and analytics.

What is Flutter ?

Flutter was introduced by Google as an open source cross platform development environment for IOS and Android that uses Dart as its programming language. Flutter itself is relatively new( v1.0 was released December 2018 ). Since that time is has expanded beyond native mobile into web and desktop applications. At the time of writing, Flutter is gaining greater popularity than React Native on both GitHub and Stack Overflow due in part to its fantastic developer experience.

Whats is AWS Amplify ?

First launched in late 2017, AWS Amplify is a package of tools and services designed to make it easy for developers to create and launch apps in AWS, including code libraries, ready-to-use components, and a built-in CLI.

For those who have not come across AWS Amplify before It is an opinionated framework that makes assumptions on the developer’s behalf, so less time on scaffolding boiler plate code and more time building features. In 2020 Amplify released a beta set of open source client librariesthat support Flutter, these subsequently went GA in Feb 2021.

What are we going to build ?

In part 1 of this series we are going to build out an application that helps users to store the ‘humble’ shopping list. This shopping list application should store a list of items that a household would like to buy, and as members visit the shops they can tick off items from the list. The ultimate aim of ‘smart shopping list’ is that the chore of shopping can be shared ! . So lets look at the typical screen flow of our application.

First Screen

Mark Item as complete (purchased)
Add New Item

Second Screen

Add new Item to List

Third Screen

View List

A pretty straight forward flow, so let’s get started …

Configuring your Developer Environment

Before we start building out the UI, we need to install and configure our development environment to run Flutter — this is beyond the scope of this blog, however just follow these steps to set up your local Flutter environment.

For my IDE of choice I will be using VSCode, however Android Studio is also supported with setup instructions here. Once you have configured the editor, test your configuration and then finally write a quick hello world application.

| Note: There are also some great tips and tricks for Android Developers in the flutter documentation here.

Building out the UI in Flutter

Once we are all setup lets jump in and build our UI. All the code for this demo you can find here https://github.com/deekob/flutter_droidcon — The first thing to do is create a new Flutter Project — you can either do this at the command line using ‘flutter create’ or by using your IDE of choice.

The entry point to any flutter project is main.dart — lets change that first to include our theme and styling.

main.dart

This is nothing more than the entry point to the application, where we can setup the UI theme before then calling our first View — In this case I have called the first view ShoppingListItemsView — which I will define in a new class file.

shoppinglist_view.dart

This is the main part of our UI, its broken up into a number of Widgets, as everything in Flutter is a widget — In this case we are using a StatefulWidget to hold the state (Shopping List Item) that we are creating. The StatefulWidget has a state that has one @override method called build(BuildContext context) — and this is where we create our UI.

The UI itself we have a _navbar that simply holds the apps title ‘My Shopping List’, a _floatingActionButton that when pressed, will push a modal from the bottom containing the widget called _newItemView. Finally in this widget we have a TextEditingController that holds the value of our new item and a button to save the item. Notice that the onPressed() event in the ElevatedButton isnt doing anything yet. Before we can persist anything however we first need to define our application data model.

Building our DataModel

Now with the UI done we want to start thinking about persisting the application’s data. To do this we will use the Amplify Admin UI to model what the data objects will be, what fields and types they contain, which fields are optional and which are mandatory. So, lets start by opening the Admin UI sandbox web page found at AdminUI sandbox.

From here we get to choose what we are building, either:

Application Backend
Hosting a Web Site

Ultimately, we want to build out an application backend for this application, so we choose the first option ‘Create an app backend ’.

We can either start modelling the data layer, set up an auth layer or configure file storage for our application. In this case we are focusing on data, so lets choose ‘Data >>’

Modelling our data

Next, we start to think about our data model, its relationships and how to test it locally. This can all be done when we select the ‘Data’ feature and then selecting the ‘Blank Schema’ option, as we want to start from scratch, finally hitting ‘Create New Schema’ to get going.

With the Admin UI data modelling feature we can do things like choose the names and types for our data. For individual types we can decide if they are simple types like ‘String’ or more complex scalar types like AWSDateTime. Along with model / field names and types we can also mark the fields as mandatory by ticking the ‘isRequired’ checkbox, or mark them as being a collection by ticking the ‘is array’ checkbox.

We can easily define relationships between model elements, currently I can define a 1:1, 1:M and M:M relationships inside the AdminUI.

The model we want to define is a ShoppingListItem must have a name ( itemName ) and a flag( isComplete ) to let the user know if the item has been bought. This model will look something like this

For more in depth instructions on how to get started with data modelling, check out Amplify Docs. Next we can test this locally to see if it fits our understanding and the existing front-end code. Selecting ‘Test this Locally’ brings up a set of steps we need to perform to integrate this new model into the application.

Adding Amplify to our app

The steps on how to build and test our newly created schema are nicely laid out for us as a series of steps in the AdminUI, so let’s step through these. The first one looks like this :

Choose the type of App we are building — we can choose either a Web, IOS / Android or cross- platform and then make the appropriate framework/language selection based on our platform selection. For this example, we are choosing a cross platform ( even though we will be targeting Android ) with Flutter as the framework.

Step 2 (Optional)

This step will contain the commands needed if you are creating an app from scratch. As we are using an existing frontend UI, we will skip this step.

Step 3

The next step contains the commands needed to install the Amplify CLI, which we then use to pull down the data model we have created in the AdminUI Sandbox. This ‘amplify pull’ command will also in our case generate the correct types that we can use to access our data model in our Dart code.

Step 4

This step shows us how to install the Amplify Flutter libraries that we can use to interact with the types pulled down and generated in Step 3. It also shows us how to configure our application to start implementing Amplify client libraries in our frontend code and finally how to configure the native projects for IOS and Android. In summary what we will do is:

Add the dependencies to pubspec.yaml :
Click Pub Get in the “Flutter commands” bar to install Amplify Libraries
(iOS only) Open ios/Podfile and update the platform target:

Go to main.dart and add the following lines to initialize the Amplify Libraries:

main.dart

Step 5

Finally, this step shows us how to build CRUD operations into our application by supplying code snippets for Amplify Datastore. Datastore is an Amplify category/feature that enables applications to be built with a client first programming model. The beauty of the datastore category is that once we deploy a backend for our app into an AWS account, the data persistence mechanisms we have defined in datastore will mean all application data will automatically be synced to all connected clients. This is due to the service that underpins datastore, AWS Appsync.

For a more in-depth view of what datastore can do -> check this out

So, for the ShoppingListItem model, if I want to persist items into our local datastore we would use the datastore API and code something like:

The datastore API is pretty elegant, in that with this line of code we are storing the result in your local sqllite DB. But before we check to see if this is working, lets explore how we would code the other CRUD operations. To do this we create a data repository class to abstract all of the data operations in our app. This class look like this

shoppinglist_repo.dart

Note that the args for the updateListItem function have a bool? — this is because the isComplete field is non-mandatory and Dart is inherently null safe as are theAmplify client libs. — To find out more about Dart null safety

Testing Locally

So now we have modelled our data in AdminUI, installed the Amplify CLI, pulled down the required libraries and model schema from the AdminUI sandbox, generated types in Dart for our model AND changed our application to call the datastore API for these types. We have done a lot in a short time, the last thing we need to do is test it all works. So we can simply run our application and excercise the creating of shopping list items. As mentioned previously all the items created will be stored only on the device

Whats Next ?

If we are not happy with our model, we can go back to our sandbox and re-model our data again. We can re-run the ‘amplify pull ’ command to retrieve any changes to our model and re-generate the types accordingly inside our codebase. This way we can quickly iterate on our model until it is fit for purpose.

When we are finally happy with the application and the data that it is persisting, we can move on to connecting our AWS account up and start to think about adding other features like datasync, authentication, content management and user management.

Deploying to an AWS Account

Deploying the app into a AWS account is the final step of the Sandbox Admin UI process and can be kicked off by selecting ‘Deploy to AWS’.

We are then prompted to either deploy into a new AWS account or deploy to an existing account. If we choose a new account, we will be taken to the account creation wizard and stepped through the process of creating a brand-new AWS account. However, in this case, lets assume we will use an existing AWS account and so we are subsequently prompted to login to that account in the browser.

Once successfully logged in on the browser, the next step takes us to the AWS console where we give our new backend a name.

Once the app has been given a name and region click on ‘ Confirm Deployment ’ will begin the deployment process of the backend into our AWS account. This may take a few minutes to execute…

Once the deployment has completed, the next step is to open the Admin UI page for our app and start adding additional features to the backend. To do this simply click on ‘Open Admin UI’

Once the AdminUI is open, you will see that it looks very different than it did as a Sandbox, this is because now with the addition of an AWS account there is a large array of features we can add that were not available in the sandbox like authorization and storage, that I will cover in later posts.

Updating local dev

Before we can do anything, we need to connect our local development environment to our newly deployed backend. To do this we need to find the ‘amplify pull’ command to run locally. To find out what it is, click on the ‘Local Setup Instructions’ link as shown.

So now running:

amplify pull -appId [xxxxxxxx] -envName staging

will then kick off an authentication challenge, once that successfully completes we will then be prompted to set up our local amplify project so it is ‘in-sync’ with our backend. The main things it will synchronise are the cloudformation templates that describe the backend services and generate any types from the objects created in the data model.

Adding Application Content

Next thing we will do is to test that our data model is deployed correctly and that syncing updates to our app works as expected. To do this we can use a feature of AdminUI called ‘App Content Management’.

App Content Management allows us to create data in our back-end for testing but also it allows us to create markdown content. For our purposes we will create some test ShoppingListItems using the built-in editor that we will then use to test data sync. We will create two items for our Shopping List [Cheese , Crackers ]

Once the items are created, we can start up our app in the local dev environment and ❗ boom ❗ without any code changes at all we have both of these ShoppingListItems displaying in the app.

Summing Up

So that's it for Part 1 in this series on Amplify and Flutter on Android — In this post we have explored how to set up our initial project, we have built our UI using Flutter, installed the Amplify tools and data modeled and tested our application data using Amplify Admin UI Sandbox. We did all this without having an AWS account, as we used one of Amplify’s categories/features called Datastore which allows us to store application data locally on the device.

We then deployed our solution to an AWS account, this enabled us to test the persistence of the data in the cloud. With Amplify provisioning the backend of AWS Appsync and Amazon DynamoDB which was abstracted from the developer by the Amplify Datastore category. Another real advantage of using Datastore is that we were then able to sync data to the cloud and other connected clients without changing any of the api calls, as Amplify Datastore takes care of all of this heavy lifting for us.

As you can see using Amplify and Flutter together are a great way to accelerate your application development cycle on Android, in Part 2 of this series we will add login and signup to our application and start building the concept of a user profile.

See you then …

Adding image upload to a React Native app with AWS Amplify

Derek Bingham ☘️ — Tue, 04 May 2021 05:12:56 +0000

Intro

In this blog post I will detail how to leverage AWS Amplify, AWS Appsync and Amazon S3 to provide an image upload capability into a react native app.

This blog assumes that the reader is familiar with AWS Amplify and its feature categories, however if you are not familiar then please have a read of this great intro by @ajonp one of our AWS community members.

I will also be working off an existing AWS backend application that has already been created with the AWS Amplify CLI and has had both the 'auth' and 'api' feature categories added. You can follow along with this creation by going to the official Amplify react-native docs. Or ;tldr it and simply clone this repo

Note - if you do end up cloning the repo, remember to run 'amplify configure' and 'amplify init' to re-configure the project to a new cloud back end in your own AWS account.

What are we building ?

The base application we will be adding photo/image storage to should look something like the below image.

There are two views in this app

A list of Todo's that have already been created.
A form to create a new Todo

Clicking on 'New To Do' button on the 'list view' will bring you to the 'create view' and once a new todo has been created the app will navigate back to the 'list view' from the 'create view'

So, nothing too tricky here, what we are going to add to this app is the ability to save images to our cloud backend when in the 'create view' and the ability to see those images in the 'list view'.

Adding the image concept to backend resources.

First thing is confirming what amplify feature categories we have installed - to find this out we simply run the amplify status command which gives the following output

As you can see, we have both auth and api feature categories installed - so that means that there is an Amazon Cognito instance handling users and auth, an AWS Appsync instance handling the GraphQL API and an Amazon DynamoDB instance handling data persistence.

Adding an S3 storage bucket.

First thing is to add the new Storage feature category to this existing backend. This is super easy to do by running the amplify add storage command in the terminal and selecting the following options

Note - most of these are defaults apart from the 'Who should have access' question where I have selected Auth users only and given them full CRUD privilege.

Adding an 'image' to our API definition

The next step is to add the concept of an image to our GraphQL schema definition. You can find the schema definition under ./amplify/backend/api/myapi/schema.graphql

We simply add a new String type called image - which will hold our image name when we persist an image and an image pre-signedURL when we retrieve an image. The schema should now look like this

Note: if we want to add FGAC to any of the fields in the schema we could use the '@auth' transformer directive - for more detail on access control, transformer directives and @auth [read this article] https://aws.amazon.com/blogs/mobile/graphql-security-appsync-amplify/ - by Brice Pelle.

Once that has been updated, we go back to our terminal and run amplify update api command to regenerate the api definition. The output from this command should look similar to the below:

Once complete we finally need to call amplify push --y to push all of our local changes into our cloud back end. This means that out back-end services will now look like the following architectural diagram with the addition of the S3 bucket that the Amplify CLI Storage category has provisioned.

Updating the react native client application

So that is enough messing around in the terminal, now it’s time to write some code. We will be making all the changes in a single file App.js and the first thing we will do is add in some additional state to store the image name and the imageURI we want to add to each todo. So, something like

const initialTodoState = { name: '', description: '', image: '' }
const initialAppState = {showForm: false, imageURI: '' }

Note - All of the code for the finished app can be found here

Selecting Images

Once we have that we need to write a function that locates images on the device and displays them for the user to select. Luckily there is a third-party library called React Native Image Picker that will do most of this for us. So, let’s create a function to call this library, it should look something like this.

handleChoosePhoto = async () =>
   {
    try {
      launchImageLibrary({
        mediaType: 'photo',
        includeBase64: false,
        maxHeight: 200,
        maxWidth: 200,
      }, (response) => {
        if (response.uri) {
          updateAppState( 'imageURI', response.uri )
          const filename = uuid.v4() + '_todoPhoto.jpg'
          updateTodoState('image', filename)
        }
      })
    } catch (error) {
      console.log(error)
    }
  }

The handleChoosePhoto function is calling the launchImageLibrary function, that is part of react-native-image-picker's api. We are simply passing in some options like, image type , image height and image width and from the response we get the imageURI ( the location on the image on the device ) and we save this and a unique image name in the state fields we created earlier.

Note: We a using the react-native-uuid library to make sure all images have unique names - this makes it easier when we store these names in DynamoDB.

When implemented the 'handleChoosePhoto' UI looks like this:

Uploading Images

Once we select the image, we can now create a Todo in the 'create view' that contains the image we have selected by simply adding the following tag in the App.js 'render' function

  <Image source={{uri: todo.image}} style={styles.image}/>

which should look something like this after adding in the appropriate tag.

We next need to implement the function that is called by the 'Create Todo' button. This addTodo() function is where we add the image upload code to the existing GraphQL api call as shown below

async function addTodo() {
    try {
      // new code for images
      const photo = await fetch(appstate.imageURI)
      const photoBlob = await photo.blob();
      await Storage.put(todoState.image, photoBlob, {
        level: 'private',
        contentType: 'image/jpg'
      })

      //existing api code
      const todo = { ...todoState }
      setTodos([...todos, todo])
      await API.graphql(graphqlOperation(createTodo, { input: todo }))
      setTodoState(initialTodoState)
      setAppState(initialAppState)

    } catch (err) {
      console.log('error creating todo:', err)
    }
  }

Here we are fetching the blob of the photo we have selected using the stored imageURI and then passing the result along with the unique image name to the Amplify Storage.put() call. Not forgetting as we are using a new Amplify category of 'Storage' we need to import the relevant libraries at the top of App.js in the imports section

import { API, graphqlOperation, Storage} from 'aws-amplify'

Once we have stored the blob in S3 using Storage.put() the last part of the function persists the image name along with all the other todo data in DynamoDB via the AppSync GraphQL api call, before finally re-setting any state.

Downloading Images

So now we have our image uploaded as part of the ‘create view’, the final step is to view the images when our initial 'list view' displays. It is currently looking very empty

To implement this, we first of all add in an image tag to the UI that renders the list.

        <Image source={{uri: todo.image}} style={styles.image}/>

Then we update the fetchTodos function to retrieve the relevant image for every Todo we have in our list.

async function fetchTodos() {
    try {
      //fetch the recipes from the server
      const todoData = await API.graphql(graphqlOperation(listTodos));
      let todos = todoData.data.listTodos.items
      // for all todos get the pre-signURL and store in images field
      todos = await Promise.all(todos.map(async (todo) =>{
        const imageKey = await Storage.get(todo.image, { level: 'private' })
        console.log(imageKey)
        todo.image = imageKey;
        return todo;
      }));
      setTodos(todos)
      setTodoState(initialTodoState)
      setAppState(initialAppState)
    } catch (err) { console.log('error fetching todos ') + err }
  }

And that is it!! your app should now look like this, where the image is downloaded into the app from the S3 bucket using the pre-signed URL that Storage.get() so conveniently generates.

Conclusion

So that is it, in a few minutes we have added an image upload and download feature into our existing react native application.

All we needed to do is update our backend using the Amplify CLI to provision our S3 bucket and change the schemas of our DynamoDB table and Appsync API. Then using the Amplify client libraries write a Storage.put() function and a Storage.get() function to add and retrieve the images. The result was not only fast to achieve, but also came with security built in.

Thanks for reading, hopefully this makes adding this kind of feature to your react native application a breeze - if you would like me to go into more detail on any of the features of AWS Amplify or indeed anything AWS related in a future post - just post in the comments below.

Likewise, any feedback is always welcome either here or catch me on the socials.

Building and Managing your Cloud Backend with Amplify Admin UI

Derek Bingham ☘️ — Thu, 25 Feb 2021 08:54:48 +0000

Intro

This is the second post in a series on the AWS Amplify Admin UI. In the first post we explored how to use Admin UI to build and test a data model for a react app without needing to sign up for an AWS Account.

In this second post we will look at how Admin UI can be used as a 'single pane of glass' into your application's backend, to help speed up development, management and deployment of an application on AWS. We will see how to connect our application into an account, enabling us to add more advanced features like AuthN/AuthZ and datasync/client side notifications. Also learning how you can delegate access to develop application backends without having AWS accounts themselves.

;tldr

I've created a video going over all the steps in both blog articles. If you want to follow a step by step guide or just dont want to read, then check it out

YouTube:

Deploying to an Account

From the first post you'll remember that we left our application as local only, following the Amplify Admin UI wizard we were then able to build and test locally. Deploying the app into a AWS account is the final step of this process and can be kicked off by selecting 'Deploy to AWS'.

We are then prompted to either deploy into a new AWS account or deploy to an existing account. If we choose a new account, we will be taken to the account creation wizard and stepped through the process of creating a brand-new AWS account. However, in this case we will use an existing AWS account and so we are subsequently prompted to login to that account in the browser.

Once successfully logged in on the browser, the next step takes us to the AWS console where we give our new backend a name.

❗ all screen shots that are in 'dark mode' are taken from the AWS Console, to help differentiate them from AWS Admin UI screens which will still be in 'light mode'❗

Once the app has been given a name and region click on 'Confirm Deployment' will begin the deployment process of the backend into our AWS account. This may take a few minutes to execute.

Note - under the region text box you will see 'Service Categories being Deploy' and AWS AppSync and DynamoDB mentioned. This is because we are using the Datastore category for CRUD operations in our app and these services underpin the Datastore category.

Once the deployment has completed, the next step is to open the Admin UI page for our app and start adding additional features to the backend. To do this simply click on 'Open Admin UI'

Connecting to local dev

Before we can do anything, we need to connect our local development environment to our newly deployed backend. To do this we need to find the 'amplify pull' command to run locally. To find out what it is, click on the 'Local Setup Instructions' link as shown.

So now running

amplify pull --appId [xxxxxxxx] --envName staging

will then kick off an authentication challenge, once that successfully completes we will then be prompted to set up our local amplify project so it is 'in-sync' with our backend. The main things it will synchronise are the cloudformation templates that describe the backend services and generate any types from the objects created in the datamodel.

Running the command will look something like this:

We have selected defaults for most of the questions, however it is worth noting the last question : "Do you plan on modifying this backend ( Y/n )" - selecting Y will mean that you can use the Amplify CLI locally to also add features to this backend. For more information on adding features using the CLI see [here].(https://docs.amplify.aws/cli)

We have now connected our backend environment with our local developer environment so let's start building.

Adding Application Content

Next thing we will do is to test that our data model is deployed correctly and that syncing updates to our app works as expected. To do this we can use a feature of AdminUI called 'App Content Management'.

App Content Management allows us to create data in our back-end for testing but also it allows us to create markdown content. This is particularly useful to allow app admins to manage content (e.g., update a product price or add a new blog post). You can work with basic data types (strings, integers, Booleans, etc..) as well as rich text using the built-in rich text editor for editing content for websites and blogs.

For our purposes we will create some test ShoppingListItems using the built-in editor that we will then use to test data sync. We will create two items for our Shopping List [Cheese, Crackers ]

Once the items are created, we can start up our app in the local dev environment and ❗ boom ❗ without any code changes at all we have both of these ShoppingListItems displaying in the app. Now it is time to add an observer to our lists to make sure that any updates to the ShoppingList or ShoppingListItems in the list are correctly synched to all clients.

This again we can do very simply by using the DataStore api:

DataStore.observe(ShoppingListItems).subscribe(() => {
      fetchData()
    });

The beauty of Datastore is its ability to abstract away the complexity of data persistence and synchronisation. With Datastore we can not only persist data and register observers on that data, we can also be selective in what data we would like synced back to clients. This is because Datastore is built as a client first programming model, in that, developers only need to code for local persistence. With the GraphQL schema and client subscriptions provided by AWS Appsync abstracted away from you by the Datastore API’s handling the rest. So that when the app becomes connected to a backend, the code you wrote will quite happily sync data with all connected clients without it being changed.

More info on this operation and others available can be found in the excellent [Amplify Datastore Docs].(https://docs.amplify.aws/lib/datastore/getting-started/q/platform/js)

Adding Auth

We have now implemented a full data sync engine between all of our application clients, the next stage is to secure this API and add Sign In / Sign Up capabilities to our UI. We do that by selecting 'User Management' in the Admin UI.

User Management allows us to choose which login mechanism we would like to use (email, username, etc.), if we would like to add MFA and how that would behave (SMS, Authenticator app). We can choose what attributes users must provide when signing up as well as configuring our password policy. Once happy with our choices, selecting 'Save and deploy' will create a Amazon Cognito instance for our user store and add it into our backend. This also enables us to create users for our app via the Admin UI.

Now the backend is complete with can go perform the changes to our UI. These changes are all described in detail here - however, in a nutshell we will use one of the Higher Order Components(HOC) that comes with the AWS Amplify JS React library and wrap our app with that.

export default withAuthenticator(App);

Now users will have to Authenticate before being allowed to navigate to the main page of our app and call the backend API.

Admin UI Management

The next set of functionality I will go through is accessed through the AWS Amplify console for the application. On the left hand menu there is a new option called 'Admin UI Management'

Under this heading you can enable/disable Admin UI for the app, see a list of all backend environments and the final thing we will go through in this post, controlling access to Admin UI.

Controlling Team Access

The next thing we will do to our app backend is decide what members of our team can work on which aspect of the applications backend.

Note - the following process is done vis the Amplify Console for our app and not the Admin UI.

We have two types of scope that we can grant access to:

Full Access - this will give access to all features of the Admin UI and will allow developers to create and update features within the application backend.
Manage Only - this will give access to a subset of features of the Admin UI , namely Content and User Management.

Depending on the scope granted to each user will mean changes to visibility of the following items.

Conclusion

In the first part of this series we explored how we can use Amplify Admin UI without an AWS account to quickly iterate through a data model design and test it locally. We then extended this concept in this post and showed how we can quickly and easily build out backend functionality for our application and even grant access for developers without an AWS account. This in itself onlocks a whole new world of possibilty of how you build out your application within an organisation, by removing this account bottleneck the teams agility should only increase.

The single pane of glass over the entire application backend is a very powerful feature of the Amplify Admin UI. To be able to have one single point where you can add/remove developers, change what features you have available inside your app, like authentication and authorisation and even change the content displayed. In my opinion makes it well worth checking out.

Thanks for reading, if you would like me to go into more detail on any of the features of Amplify Admin UI or indeed anything AWS related in a future post - just post in the comments below.

Likewise, any feedback is always welcome.

Datamodel your React app with AWS Amplify Admin UI

Derek Bingham ☘️ — Wed, 17 Feb 2021 12:44:29 +0000

AWS Amplify Admin UI was announced just prior to AWS re:invent 2020, the killer feature for me was the ability to start building out the data persistence model for an application without needing access to an AWS Account. So in this blog post I will take you through how to add a data model and a persistence store to an existing React application and how you can go about testing it locally.

For those who have not come across AWS Amplify before it is a great way to start dipping your toe into the full stack cloud development experience if you have not already. It is an opinionated framework that makes assumptions on the developer's behalf, so less time on scaffolding boiler plate code and more time building features. Also, the Amplify documentation is (in my opinion) the best documentation you'll find for an AWS service. Don't take my word for it - see for yourself.

This is the first in a two part series, if your more of a visual learner then check out part 2 where I have included a video detailing all the steps I took for the demo.

What are we building?

For this blog we will work with an app that already has had the bones of the UI built in. The apps purpose is to collect information about shopping lists, allowing a user to Create Read Update and Delete items in a shopping list. Now with the existing UI done we want to start thinking about persisting the application's data. To do this we will use the Amplify Admin UI to model what the data objects will be, what fields and types they contain, which fields are optional and which are mandatory.

Getting Started

So lets go ahead and open the AdminUI sandbox.

From here we get to choose what we are building, either:

Application Backend
Hosting a Web Site

Ultimately, we want to build out an application backend for this application, so we choose the first option 'Create an app backend'. You will then be presented with the following options:

We can either start modelling the data layer, set up an auth layer or configure file storage for our application. In this case we are focusing on data, so lets choose 'Data >>'

Modelling our data

Next, we start to think about our data model, its relationships and how to test it locally. This can all be done when we select the 'Data' feature and then selecting the 'Blank Schema' option, as we want to start from scratch, finally hitting 'Create New Schema' to get going.

With the Admin UI data modelling feature we can do things like choose the names and types for my data. For individual types we can decide if they are simple types like 'String' or more complex scalar types like AWSDateTime. Along with model / field names and types we can also mark the fields as mandatory by ticking the 'isRequired' checkbox, or mark them as being a collection by ticking the 'is array' checkbox. Finally we can easily define relationships between model elements, currently I can define a 1:1, 1:M and M:M relationships inside the AdminUI.

The model we want to define is, a ShoppingList which can have 1:M ShoppingListItems -> so, modelling that in the AdminUI looks something like this.

For more in depth instructions on how to get started with data modelling, check out Amplify Docs

Next we can test this locally to see if it fits our understanding and the existing front-end code. Selecting 'Test this Locally' brings up a set of steps we need to perform to integrate this new model into the application.

Note - We can also share this model with other developers in the team as well as make it a template to base other models on. The model will exist in this sandbox until it is deployed into an AWS account, at which stage it will be locked down.

Adding Amplify to our app

The steps on how to build and test our newly created schema are nicely laid out for us as a series of steps in the AdminUI, so let's step through these

Step 1

Choose the type of App we are building - we can choose either a Web, IOS or Android platform and then make the appropriate framework/language selection based on our platform selection. For this example, we are choosing a Web platform with React as the framework.

Step 2 (Optional)

This step will contain the commands needed if you are creating an app from scratch. As we are using an existing frontend UI, we will skip this step.

Step 3

The next step contains the commands needed to install the Amplify CLI, which we then use to pull down the data model we have created in the AdminUI Sandbox. This 'amplify pull' command will also in our case generate the correct types that we can use to access our data model in our React code.

Step 4

This step shows us how to install the Amplify typescript library that we can use to interact with the types pulled down and generated in Step 3. It also shows us how to configure our application to start implementing Amplify libraries in our frontend code.

Step 5

Finally, this step shows how to build CRUD operations into our application by supplying code snippets for dataStore. Datastore is an Amplify category/feature that enables applications to be built with a client first programming model. The beauty of the datastore category is that once we deploy a backend for our app into an AWS account, the data persistence mechanisms we have defined in datastore will mean all application data will automatically be synced to all connected clients. This is due to the service that underpins datastore, AWS Appsync.

For a more in-depth view of what datastore can do -> check this out

So, for the ShoppingListItem model, if I want to persist items into our local datastore we would use the datastore API and code something like:

DataStore.save(new ShoppingListItems({"itemName": itemName})

The datastore API is pretty elegant, in that with this line of code we are storing the result in indexedDB in your local browser. But before we check to see if this is working, lets explore how we would code the other CRUD operations.

//READ
export async function getUserItems() {
 return await DataStore.query(ShoppingListItems)
}

//CREATE
export async function addItem(itemName) {
  return await DataStore.save(new ShoppingListItems({
        "itemName": itemName
    })
); 
}

//DELETE
export async function deleteItem(itemId) {
 const modelToDelete = await DataStore.query(ShoppingListItems, itemId);
 return DataStore.delete(modelToDelete);
}

Testing Locally

So now we have modelled our data in AdminUI, installed the Amplify CLI, pulled down the required libraries and model schema from the AdminUI sandbox, generated types in typescript for our model AND changed our application to call the datastore API for these types. We have done a lot in a short time, the last thing we need to do is test it all works.

As mentioned before, when calling datastore API's we actually persist the data in IndexedDB in the browser, which makes it super easy to test. We can simply spin up the application, create some test data by executing the app's functionality. Then, if we want to make sure the data is persisting in the format expected, we can inspect it using the development tools of the browser and query indexedDB as shown below

Note - If, we are building an Android our IOS application, datastore would instead persist the data in SQLite database on the device as opposed to indexedDB in a browser.

Whats Next

If we are not happy with our model, we can go back to our sandbox and re-model our data again.

amplify pull --sandboxId

Running this command once more will retrieve any changes to our model and re-generate the types accordingly inside our codebase. This way we can quickly iterate on our model until it is fit for purpose.

I will cover how this is done in a later blog.

Conclusion

As you can see Amplify AdminUI is a great way to start modeling and iterating on our datamodel that we want to use within our application. As there is no AWS account involved its very easy to just dive in and get started and the feedback cycle is really fast. This enables a faster application development cycle and and helps aid faster delivery of our application into the hands of real users.

So dont put it off any longer, dive in to the Amplify AdminUI and start building that next killer app.

In the next post I will describe how we take this application to the next phase of development by deploying it to an AWS account and adding more advanced features like auth and datasync/notifications. I'll also show you how you can delegate access to developers who dont have AWS accounts themselves.

Also, If there is specific content you want to see around this or other AWS topics, please get in touch.