How to design a server-less backend that evolves with the success of your applications?
The development of a small mobile application can be done very easily – although it is difficult to change the underlying architecture once the application is operational. Before launch, take the time to prepare your mobile application with resilient backend services that will adapt to your success. Your mobile application’s architecture must be designed so that each backend component evolves independently and resists failure, even at the cloud provider level.
If possible, implement serverless technologies. This will allow your backend services to scale efficiently and automatically to meet demand, and reduce your costs as your customers grow.
To prepare for the success of your mobile application, your design must include each of these six key components of a well-architected server-less backend:
Number 1: Event Driven Calculation
As developers moved away from monolithic applications to create microservices built inside the containers, it was possible to deploy modules individually. This approach also allowed each team of developers to choose the framework and the programming language of their choice.
With the emergence of AWS Lambda-less features, an even more efficient model of event-driven computing is now available to developers.
With no server, the application client creates an event that triggers an on-demand function. For example, the event of a client downloading an image will trigger a function to execute an image processing routine.
- You do not have to worry about scaling calculation – only your application.
- You can decouple backend implementations from frontend deployments.
- Service-level issues, such as caching, monitoring, and logging, are maintained at the API gateway.
- Authentication is handled at the API gateway and passed on to individual Lambda functions.
- Individual teams may be responsible for deploying their own code, including selecting the programming language.
- The API Gateway can support versioning so that new versions or test versions of the API are easily implemented.
Number 2: Serverless data storage
The data is probably one of the first problems experienced by developers when scaling a mobile backend. Regardless of what data storage you decide to implement, you must isolate the backend to ensure a better mobile experience.
Most modern applications are written to take advantage of RESTful web services to access data. For applications that use REST, it is recommended that you place a set of Lambda functions behind an API gateway to access the data.
The smartest applications take advantage of GraphQL to minimize the transfer of data between the client and the server. For GraphQL, use a managed service such as AWS AppSync to provide the GraphQL service and isolate the data.
Regarding the backend database, there are so many questions to answer before starting:
- Do you need relational databases or NoSQL?
- Do you need unstructured data like images and videos?
- What are the models and types of requests?
- Do you need offline data access?
- What real-time collaborative scenarios do you need to support?
- What failover scenarios should you support?
- What is your plan for the global scale?
AWS offers a range of serverless storage options that support each usage scenario, each with its own advantages and disadvantages.
- Amazon DynamoDB is a completely server-free NoSQL option with auto-replication and failover, and integrated multi-availability zone replication. It also supports global tables to ensure truly global reach. However, it does not provide standard relational operations such as joins between tables.
- Aurora Serverless is a new preview service for Amazon Aurora – a scalable database option with MySQL and PostgreSQL modes. The database will automatically increase or decrease capacity based on the needs of your application, while providing SQL connectivity for relational needs. 6-way replication is built-in, allowing for global fault tolerance.
- Sometimes the database does not have the capabilities your queries need. This usually occurs with full-text search, fuzzy matching, log analysis, and geospatial analysis requirements. In this case, complete your database with Amazon Elasticsearch Service . You can populate the Elasticsearch service directly from the database using an AWS Lambda trigger.
- Amazon S3 storage can be used for unstructured data such as audio, video, and images. It is easy to use with a simple web service to store and retrieve any amount of data. Pair it with an Amazon CloudFront service to provide CDN functionality around the world.
Number 3: Management and User Identity
It seems that every developer wants to use their own identity solution to support authentication schemes such as “username + password”.
The goal of a user management and identity solution is to secure resources on the backend, minimize disagreements with your users, and adapt to the evolution of your application.
This indicates the use of a service. On AWS, it’s Amazon Cognito.
In addition to solving the basic problem of the user directory, Cognito also supports OpenID Connect, SAML, OAuth 2.0, Facebook and Google social login mechanisms. Simply choose the appropriate social service provider for your application and use it for authentication. Your users will thank you.
There are two parts of Amazon Cognito that are worth understanding:
- Identity Pool : It stores the identities of your users and uses them to provide resource access tokens within the application. It supports both unauthenticated and authenticated usage.
- User Pool : This is a user directory that can optionally be used next to an identity pool to provide username / password functionality.
One of the characteristics that can be confusing is that identity pools and user pools both support Facebook and Google authentication. The main difference is that the user pool allows you to retrieve profile information from Facebook or Google.
If your application requires access to profile data, it can get it directly from the authentication provider – so use an identity pool. If the backend code needs to access profile data, use a user pool.
One last tip – implement access control at the cloud gateway. For most applications, this will be AWS AppSync or Amazon API Gateway. Slave functions just need to trust the gateway to reduce computing costs.