Web and Mobile Backend Services Patterns

Web and Mobile Backend Services Patterns

Suppose for a moment that we need to design an application with support for Mobile and Web clients. We also need the solution to be scalable, elastic according to the demand for resources, high service availability, resilience to failures, and the ability to recover its services in specific tolerance times. Besides, it is so flexible to integrate extra services.

We can turn to cloud services to design solutions to meet these types of requirements. We have large cloud service providers such as Google or Amazon. This article is dedicated to the services provided by Google through Google Cloud Platform.

The first thing is to know what; Google Cloud Platform has an extensive catalog of services, and therefore there are multiple alternatives when designing a system based on these services. It will depend on these services' correct choice to provide mobile and web clients with a backend of services that meets the requirements.

Some common patterns can be taken as a reference to start the design of the solution backend services.

This article aims to provide a guide to common patterns that might be considered when planning a solution design. This article references a highly recommended article published by Google and known as Mobile app backend services.

Pattern 1: With Firebase and Client Library/SDKs

In this pattern, Firebase is the platform used for Cloud Services integration. Storage services, database, analytics, Artificial Intelligence (AI), operations, among others.

Why integrate services through Firebase? The first thing is to know that Firebase is an extension of GCP that allows them to adhere in an agile and flexible way to mobile or web solutions capabilities such as Push notifications, Testing, and Real-time. Can quickly integrate common capabilities in mobile solutions such as authentication and authorization through social networks and even AI services through Firebase.

Integration to Firebase is done through Client Libraries and SDKs provided by Google for each operating system, that is, for Android, iOS, and Web.

As an improvement, an Rx wrapper capable of bringing operations to the Reactive world could be implemented in each of the clients. In such a way, the client application's data layer would use the advantages of Functional and Reactive Programming. Could build the wrappers with RxJava for Android clients, RxSwift for iOS clients, and RxJS for Web clients. Could obtain a good design in the data layer by applying good practices in the implementation with Rx (The Clean Way to Use Rx). There are other alternatives such as Coroutines for Android or Combine for iOS side; however, this article refers to the Rx extensions.

The reader will notice that the implementation of this pattern brings its advantages and disadvantages. The main advantage of applying this pattern is to provide mobile and web clients with a backend of services in an agile and flexible way. An appropriate design for rapid implementation of a service backend for prototype, product validation, or quick product development purposes.

Perhaps one of the most prominent disadvantages is that it requires integrating logic in each of the clients without the opportunity to share the implementation. Let's remember that, Firebase does not apply any logic at the server backend level.

For the cases in which Firebase is required to execute specific processes in the backend scope, the following Pattern 2 is proposed.

Pattern 2: With Firebase and Extended Capabilities

This pattern is similar to Pattern 1, with a variant that allows Firebase functionality to be extended across compute and container services.

In GCP, we find Compute Engine, App Engine, or Cloud Functions within the family of computing services. And in the container family, we find Kubernetes Engine, Cloud Run, among others. Through these two families of services, the solution can be enriched with capabilities to process, transform, monitor, or execute any necessary task in the server area.

Create good designs imply to know each of the services. Each service has its specific qualities; for example, if Compute Engine is chosen, it could perform software updates on-demand with greater control over the instances; however, their auto-scaling and load balancing capability would not be automatic; it would have to be configured. The opposite case would be when choosing App Engine, for example, where these capabilities are automated because, among other things, they are a service on the Cloud Computing PaaS model.

Also, according to the nature of the task, one could choose Cloud Run or Cloud Function for those cases where microservices are required in a highly manageable model such as FaaS or CaaS. These services are also suitable for those on-demand tasks that require only short execution times in a decoupled and asynchronous manner in an Event-driven or Serverless design.

Client-side integration remains similar to that presented in Pattern 1, through Client Libraries, SDKs, and Rx Wrappers.

This proposal then offers the same advantages as Pattern 1, with the additional benefit of adding server capabilities for task operation. Similarly, it maintains the same disadvantage of delegating part of the integration logic to clients in non-shared layers.

Pattern 3: With REST or gRPC API published on Server Side

This pattern, compared to the previous two, has as a variant the absence of Firebase. In this case, the publication of the APIs and the backend services is delegated to the different computing options and containers provided by the Google Cloud Platform.

Can also integrate these backend services with other database services such as Firestore, Cloud SQL, and Cloud Spanner. Storage services such as Cloud Storage, Filestore, among others. Analytics services, such as BigQuery, among others. Operations services such as Cloud Monitoring, Cloud Logging, Error Reporting, among others.

REST or gRPC is used as the protocol for API integration. It is important to analyze that the chosen services support the desired protocol and consider the programming languages ​​that each service can support. For example, App Engine provides two options, Standard and Flexible. Each option supports a specific set of programming languages.

On the client integration side, one could use the different REST client options that also support Rx. For example, on the Android side, you could use Retrofit, and on the iOS side, you could use RxAlamofire, which are REST Client Libraries that include Rx support. In the case of Web clients, Angular, for example, comes with RxJS support by default.

One of the advantages of this pattern is to allow the solution design to conform to the most appropriate Cloud Computing Model. That will depend on the type of service chosen, which, as we know, could be IaaS, CaaS, PaaS, or FaaS, depending on whether Compute Engine, Kubernetes Engine, App Engine, Cloud Functions are chosen, for example.

Another advantage is sharing application or business logic across the different clients because it is now located on the server-side.

As a disadvantage, it could be mentioned that by not having Firebase, would omit these platforms' great capabilities.

Pattern 4: With REST or gRPC API published on Server Side

This pattern is similar to Pattern 4, with a variant that adds an API manager. That addition represents an improvement since the APIs administration is delegated to another component. Also, the ability to monitor these APIs is extended. Additionally, you could add a layer of security to the requests you make to the API. Google Cloud Platform provides the following options to manage the APIs are Cloud Endpoints, Apigee, or API Gateway.

The client-side integration remains similar to that presented in Pattern 3, through Client Libraries that include Rx support.

Conclusion

Of course, this is just a scratch of the possible alternatives that could be considered when designing a Mobile or Web application. 

At the time of design, functional and technical requirements will significantly influence. The important thing to highlight is the great variety of cloud service providers such as Google Cloud Platform offers and makes available. It is vital to know each service very well, its advantages and disadvantages, how far they are appropriate to choose them, and their cost rates.


References

Previous
Next Post »
Thanks for your comment