Firebase vs. Amplify for Mobile Development

Introduction

In my consulting work helping companies design and deploy their mobile applications, most clients (especially startups) need to provision and deploy a mobile back-end service along with their application. My go-to platforms to accelerate time-to-market for mobile apps are?AWS Amplify?and?Google Firebase. This article is a high-level comparison of these two excellent mobile back-end as a service (MBaaS) platforms.?

Purpose of this Article

The purpose of this article is to provide a high-level, architectural understanding of?AWS Amplify?and?Google Firebase. I won't be making a deep dive into either platform--they're way too broad and deep to cover in a blog post. This is intended as a starter for your thinking about whether to use either of these platforms in your next mobile project.

By the end of the article I hope to provide a glimpse of what to expect when using either service, where each platform has some differentiation and a general idea of which might be more appropriate for your situation. Do keep in mind the analysis and advice int his article is from my own field experience, and others may have formed different opinions--that's perfectly OK.

Is one of these always the best?

I'll just state up front that I won't be declaring either Google Firebase or AWS Amplify as the absolute best choice for all mobile application deployments.?Both MBaaS platforms are built and maintained by outstanding companies, and both are very reliable. I've been happy using both of them.

That said, I believe each platform was designed and built from a different perspective and with different priorities at the top of the list, which I'll discuss below. These different approaches definitely can make one better than the other for a specific circumstance, and I have pushed some clients toward one or the other, and pushed some clients away from one or the other depending on their situation.

What is an MBaaS?

It's important to understand what an?MBaaS?is, so if this is a new term for you don't skip this section.

Mobile apps can have multiple tiers (similar to modern web applications), but in practice they?have more in common with the traditional client/server architecture. I'll use client/server interchangeably with front-end/back-end in this article.

Client (i.e. front-end)

For mobile applications, the?client?is the code that runs on the mobile device.

• User Interface (UI). The code that draws the elements users actually interact with.
• Device hardware/sensor control. Code that detects GPS location, interacts with Bluetooth peripherals, integrates with payment systems (e.g. Google Pay/Apple Pay) and so on.
• Local Data Replicas. Apps may allow users to use centralized application data when Internet connectivity is unavailable. To do so, the back-end needs to support replication, and possibly offline data updates.

Server (i.e. back-end)

Some mobile apps are 100% client code--for example a to-do list that isn't shared with anyone else. But the majority of mobile apps leverage back-end code to support their features.

• Centralized data storage.?Many applications use data stored in centralized databases (i.e. Google/Apple Maps, or your phone's mail app).
• Replicated data storage.?Applications that allow users to continue using them when offline require a back-end that supports one or two-way data replication.
• Push Notifications. A server back-end is needed to enable sending personalized messages to users based on external events.
• Authentication. A server back-end is required to support authentication and user authorization for cloud-hosted data and services.

Before MBaaS

Before cloud services were common, all mobile back-end services were purpose built for an application on dedicated server hardware or shared VMs in an Infrastructure as a Service (IaaS) model, such as Amazon EC2 instances.?As you probably imagine, building and operating these services securely for a complex application is very expensive and requires many skill sets to be on-hand for development and operation.

MBaaS?

As public cloud services have matured, mobile backend services can now be purchased without dedicated resources. Modern MBaaS systems are server-less and are billed on a usage-based model, a/k/a Platform as a Service (PaaS).?

When back-end services supporting mobile apps are well integrated and packaged specifically to support mobile apps, we?refer to the offering as a mobile back-end as a service (MBaaS).?

Firebase and Amplify both fall into this category, providing pre-packaged offerings that support mobile applications. Both also support web-based applications (that have no mobile components), so they go beyond MBaaS in their execution.

Relationship to core AWS/GCP

It's probably obvious that?AWS Amplify?is built on top of?Amazon Web Services (AWS), while?Firebase?is built on top of?Google Cloud Platform (GCP).?

In both cases, the company recognized that providing more approachable, easier to use mobile app/web app services would attract developers that may be?intimidated by the complexity and learning curve presented when directly using a full cloud computing stack.

For both Firebase and Amplify, developers can get up and running without the support of skilled AWS/GCP professionals. How they provide their respective abstraction layers over their core cloud platforms is different, which I'll discuss more below.

Core?Modules

AWS Amplify and Google Firebase both support what I believe are the core MBaaS offerings that almost every MVP Mobile Application will need:

1. User Authentication
2. Social Media Login (e.g.?Sign in with Apple,?Facebook Login)
3. A NoSQL database supporting queries and client-side updates
4. BLOB storage for images, text and other unstructured data
5. Serverless cloud functions easily callable from client-side code
6. Managed hosting of an application admin web site

All of these features should be server-less and auto-scaling.

Of course, each service has differentiated and unique features. For example Firebase supports?attestation, which provides an enhanced layer of security for API access, whereas (at this writing) Amplify does not.?Conversely, Amplify has a robust?environment solution?(e.g. dev/stage/prod), where Firebase (at this writing) does not.?

Almost always, unique extra features?can?be implemented on the other platform. But the raison d'être for an MBaaS is to remove the need to implement platform features "by hand", instead freeing developers to focus on implementing application features rather than platform features.?

When evaluating MBaaS platforms, it's critical to understand what features you need, and select the platform that provides those features directly whenever possible.

Here's how Amplify and Firebase support these core requirements:

User Authentication

• Google Firebase uses its own?Firebase Authentication?feature, which is specifically built for Firebase.?This offering is separate from?Google Cloud Platform (GCP) IAM?offering. What I like the most about Firebase Auth is how simple it is to configure and use, and how well integrated its mobile features are. For example?Native Sign in with Apple?(i.e. without using a web view) is dead simple to add to Firebase Authentication, but is actually not supported by Amplify (at the time of this writing).
• Amplify Authentication?is a thin abstraction over the?AWS Cognito?identity management system.?Cognito is a full-fledged identity system. When Auth is created in Amplify, AWS uses?CloudFormation?to create a Cognito instance underneath. What I like about this approach is that the full Cognito system is underneath if it's ever needed. However, I've found that this is a dual-edged sword, since Amplify can't necessarily use all these features without using "escape hatches", and without developers really learning the intricacies of how Cognito works under the covers.?

Overall?

Firebase Auth has fewer features available compared with Amplify, but also has a lower learning curve and many of its mobile-specific tasks are better integrated than Amplify.

Amplify Auth potentially has more features since it's a thin abstraction over Cognito, but to access those features requires core AWS platform skills most developers will need to learn first.

Social Media & Federated Authentication

Federated authentication?refers to trusting an external authentication source to confirm a user's identity. For example, your app may use your company's Active Directory or other SAML provider for authentication.

Social Media authentication?is really a subset of Federated Auth, where the trusted external source is a social media property, such as Twitter or Facebook.

Overall, both Firebase and Amplify have excellent features for social media sign-in, and both support Federated login schemes. Between the two it's hard to recommend one over the other, except that I'd recommend Firebase if social media sign-in is a critical requirement. I find Firebase's implementation more complete (see above Sign in with Apple discussion), and generally it's easier to configure social sign in options.?

NoSQL Database

The data offering is the area where I think there's the most amount of difference between these two offerings.

Most developers and database pros at this point have a good understanding of the difference between a SQL database and a?NoSQL?database.

As NoSQL relates to mobile app development:

• NoSQL is most characterized by the lack of a predefined SQL Schema, and not using SQL as the data access language--though sometimes SQL is used for query, for example with?Microsoft CosmosDB.
• NoSQL Databases are oriented toward making application development easier.
• NoSQL repositories can store deeply nested?JSON data structures?as a document referenced by some string key.
• A NoSQL database should allow fetching documents by key, updating or deleting document by key, and some way to query for a subset of JSON documents using a non-trivial predicate.

Both Amplify and Firebase have NoSQL database services and both provide all these requirements, but with different strengths:

• Firebase actually has two options:?Cloud Firestore?and?Realtime Database. Cloud Firestore is most commonly used for application data. It supports all the characteristics above. I like Firestore because it's drop-dead simple to use. Its lack of defined schema makes very flexible, but also means the discipline of data schema is entirely shifted to the development team(s). There's no pre-configuration or setup necessary before using Cloud Firestore.
• Amplify DataStore?is designed very differently than Firestore. Fundamentally it's a wrapper over the?AWS AppSync?service, which is a managed?GraphQL?data source that stores data in?AWS DynamoDB?tables. Amplify storage entities must be explicitly defined (using GraphQL) and deployed via a CLI before storing data in collections. Much like Amplify Authentication, the abstraction over highly tunable underlying services can potentially provide more capabilities. However using those capabilities requires developers to learn how to use all the underlying services effectively, which many teams may not have the bandwidth or desire to take on.

Overall, both Amplify and Firebase have highly capable and scalable NoSQL offerings. Firebase is definitely the one that's easier to get started with compared to Amplify. However, Amplify has defined schema, relationships, GraphQL flexibility, a model generator and more knobs and switches to use to create more complex solutions. Where Firebase is a "code first" database, Amplify is a "data structure first" database.

BLOB Storage

BLOB stands for?Binary?Large?OBjects.?Typically in a mobile app context, this means images, firmware upgrade files, large pieces of text, PDF files, etc. While it would be possible to UUEncode this type of data and store it in a database, it's not efficient and would increase operational costs.

• Firebase Cloud Storage?is the Firebase offering for storing BLOBs accessible by a string index key. The offering works very well, and apps can access files in Cloud Storage through APIs or by public URLs.
• Amplify Storage?is the comparable Amplify offering for storing BLOBs. It also stores files (in S3 buckets) accessed by key and has APIs and URL support, including temporary, expiring URLs.

Overall the Firebase and Amplify BLOB storage features are very similar, and either will meet the needs of most mobile developers.

Server-side Functions

In recent years all top-tier cloud providers have implemented some form of back-end functions.?Briefly, a backend (or cloud) function is an API endpoint that is available to a front-end application to call.?

In practice a cloud function is not different than, say, a Node.js POST endpoint installed on a load-balanced mid-tier server.?The difference is more in?how?that endpoint is deployed.?With cloud functions, the provider (AWS, GCP, Azure) spins up the function (endpoint) on demand, billing for the number of calls, rather than for the physical hardware used to run the function.

Using functions will often be less expensive than paying for reserved backend server instances. But almost certainly it will be more flexible and reliable in small to medium scale deployments.

The combination of easy deployment and hands-off administration/scaling makes functions perfect for mobile app back-end server-side code.

• Firebase offers?Cloud Functions?for deployment of server-side code within the MBaaS project.?These functions are developed using JavaScript or TypeScript (only).?Cloud Functions are easy to implement, and anyone familiar with JavaScript will feel right at home. Functions can easily access non-Firebase GCP resources, such as Google BigQuery.
• Amplify offers?Amplify Functions.?When deployed, these functions are?AWS Lambda?functions, and can be managed in the AWS Lambda Console if desired. Like Firebase functions, AWS Lambda functions can be used to bridge to other AWS services. Amplify Functions can be written in NodeJS, Java, Go, .NET or Python.

Like BLOB Storage, the cloud function features provided by Firebase and Amplify are very similar, with neither providing a significant differentiation over the other. Both will meet the needs of most mobile projects.

Managed Hosting

Although the focus of this article is Mobile Applications (e.g. Android and iOS), when a back-end platform is implemented we usually need to add some type of web-based administrative application. This web-based application may be needed for any or all of the following use cases:

• Maintaining content displayed in the app (e.g. text or price lists)
• Upload images
• Authorize users to specific resources
• Process payments, refunds, and make transaction adjustments

Both Amplify and Firebase have excellent support for web applications as well as mobile apps.?All features we would need to use to update the same data, BLOB resources or call into functions are available via JavaScript APIs on both platforms.

Both Firebase and Amplify also support publishing web applications to a managed hosting environment. For example AWS will publish a SPA Web App to S3 and configure a CloudFront CDN endpoint without requiring a developer to have the skills to make those configurations manually. Firebase provides equivalent functionality to support managed hosting of an admin web app.

Which is the better choice for you?

The above summary of features discusses what I consider the "core" features an MBaaS offering.?Both Amplify and Firebase offer unique features the other doesn't. If your project has a very specific requirement met by either platform--it would be difficult to recommend the other, as they're both excellent.

In the remainder of this section, I'm going to assume that your needs are the 90% of mobile app needs covered by the basic features discussed above.

What's your organizations larger technical landscape?

Very few applications are developed on an island.?A startup building its first product is an exception--but if your company is already deployed on AWS for other projects, and has teams trained and ready to help configure and support an AWS Amplify deployment--that may well be a deciding factor--and that's OK.?The same for Firebase--if your company has adopted GCP already and has trained resources to help, Firebase would be hard to beat in that scenario.

Desired Level of Abstraction

This is a subjective criteria--but how much abstraction from the back-end services do you want while developing your app??Conversely, do you want it to be as easy as possible to jump past the MBaaS abstraction layer and turn the knobs and dials in AWS or GCP yourself?

• If you definitely want to focus on application and stay out of the platform as much as possible, you probably want Firebase.?It makes most things easier than Amplify, at the cost of making access to the physical resources underlying your mobile back-end a bit harder.
• If you definitely want to modify and tweak the underlying platform resources yourself--and are willing to learn how to do that, then Amplify may be a better fit. Amplify creates AWS resources, and there are few restrictions to keep you from jumping right into AWS to access the resources it creates for you. But be careful--AWS won't prevent you from breaking the design Amplify deployed for you!

Team Size

The next dimension to consider when choosing between these products is team size. In a small team, complexity can become a significant bottleneck to progress. If avoiding complexity and keeping the team focused on the application is a priority, Firebase is the less complex offering of the two.

On the other hand, if the team is larger, it may have the bandwidth and willingness to dedicate resources to learn and use the more complex feature set offered by AWS Amplify.

Team Composition

For a team that won't have dedicated Back-End developers/system administrators, AWS Amplify will be more challenging.?Amplify is a thin layer over AWS Resources such as S3, AppSync, and Cognito (among others).?Mid-way through most projects, the team will likely need to begin learning how to directly manipulate AWS's JSON-based authorization rules, CloudFormation configuration files and start writing GraphQL queries.?If learning these underlying technologies will be too disruptive, Firebase may be the better option.

Conversely, if the team will have dedicated Back-End developers and administrators, they may prefer adopting AWS to provision more complex and sophisticated services themselves as part of the platform. Google Cloud also would allow a larger team to deploy GCP resources "underneath" Firebase, so this approach isn't specific to AWS--but Amplify arguably has more transparency in its abstraction layers.

Summary

I hope this gave you a good, high-level view of how Amplify and Firebase compare, and at least some idea of how to evaluate whether to adopt either one. As I said in the beginning, I don't think every project will arrive at the same answer. Both services are competing for the same customers, but they've come at it from a different starting point and have created services that have different strengths.

AWS Amplify

• AWS Amplify is a thin veneer around AWS services, intended to make the on-ramp to AWS easier for developers.
• The services Amplify offers are more configurable than Firebase alternatives, which can be a positive.
• But the learning curve is steeper and the startup of a project on Amplify is more complex than Firebase.
• Amplify's data offering (AppSync), is more structured and more difficult to configure, but also more powerful and provides more centralized schema control.
• AWS services are available for integration when needed

Google Firebase

• A service that's build from the ground up as an MBaaS, with ease-of-use as its top priority.
• Backed by GCP resources, which are available for integration as needed
• Fewer fine-grained configurations are available in core Firebase than in Amplify...
• But the features provided are easier to learn and harder to break (e.g. through misconfiguration or misuse)
• Firebase has somewhat broader and more refined mobile infrastructure features at the time of this writing.

This article was originally published at www.cuvenx.com.