Building and Managing your Cloud Backend with Amplify Admin UI

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'

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 authorisation, which I will cover later in this post.

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:

1. 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.
2. 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.