How does 🔥 Firebase compare to ⚡Amplify? Review Google Cloud Platform and Amazon Web Services in terms of pricing, features, and the developer experience 🤔. https://fireship.io

- Firebase https://firebase.google.com/
- Amplify https://aws-amplify.github.io/
- Source Code https://github.com/fireship-io/188-firebase-vs-amplify

#firebase #aws #amplify

Get the Fireship Quiz App 🤓

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment.

Tools I use...

Editor: VS Code with Atom One Dark + VS Code Icons
Video: Adobe Premiere + AfterEffects
Design: Figma
2024-02-04T06:44:43.552Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
6e72f00c-32c0-499a-8453-173d670a87be
da09b0f68451ca466044e5cf931891edb4b8eb99e52c8d769a0ee5fd84d529d9
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
Today, we're going to compare Firebase to AWS Amplify, both of which are platforms that make it easy for app developers to manage and scale their cloud infrastructure.
In In this video, we'll build a mini JavaScript app on both platforms so we can compare feature parity, the developer experience, and pricing.
It's Showtime.
If you're new here, like and subscribe, and check out the full write up on Fireship IO.
Now for full disclosure, I am a huge fan of Firebase, and I've been using it for many years, while AWS Amplify was only released in 2018.
The first major difference to point out is that Amplify will run on Amazon's cloud infrastructure, while Firebase will run on Google's.
So there will be some degree of vendor lock in there, but that's just the trade off you make if you want a dramatically simplified back end.
You are mine now.
You belong to me.
You're not gonna have your mommy slam Let's start by looking at some of the core features offered by both platforms.
And I should point out that this isn't a one is better than the other type of Harrison, it's more about using the right tool for the job.
And the first thing you'll need to know is whether or not your front end framework is supported.
You'll find official support for iOS, Android, and the web.
And with Amplify, you'll also find official support for React Native as well as React Web, Angular, and Vue.
At the time of this video, it does not support Flutter or bundling with Rollup.
But there are open issues for those, so they may be supported in the future.
With Firebase, you do have official support for Flutter, and Angular and Vue both have official libraries under their mono repos for Firebase, and there are some really good community maintained projects for React and React Native.
Now let's take a look at the core features of these platforms starting with the things that they share in common.
They both provide user authentication, analytics, a way to manage real time data, push notifications, file storage, serverless functions and web hosting.
We'll look at all these 1 by 1 throughout the video, but what does Amplify offer that Firebase does not?
Come with me if you want to live.
One of the first things I noticed was the ability to set up dedicated environments for development and production.
You can do this in Firebase as well by just setting up multiple projects, but it's a little more streamlined And another thing that's more streamlined is setting up your continuous deployment.
Amplify takes a very similar approach to Netlify where you connect your hosting account to a GitHub Though, then when you commit your code, it just automatically deploys that code to the hosting account.
Now in all fairness, you can do this with Google Cloud Build and Firebase as well.
There's just a few more configuration steps to get it set up.
Another unique feature of Amplify is its integration with GraphQL, which we'll look at closely in a few minutes.
And the last thing I'll point out is its integration with Sumerian, which might be useful if you're building an augmented or virtual reality app.
So that's pretty cool, but what does Firebase have that Amplify does not?
Case of the chopper.
The first and most interesting thing is a dedicated database, and we'll compare that in detail to Amplify's GraphQL setup.
And another feature in Firebase that I find to be very powerful is callable functions.
These are serverless functions that you can call with the auth context from your front end, so you can easily tell in your back end code if a user is logged in or not.
And that's a lot easier than setting up an API gateway or just writing the back end authorization logic from scratch.
In Firebase, you also have a few tools for quality control, things like Crashlytics, performance and test lab.
And then you have quite a few more features that are built on top of your analytics, things like predictions and remote config, just to name a few.
And you also have ML Kit, which makes it really easy to implement machine learning features both in the Cloud and on device.
Now, let's go ahead and switch gears to pricing.
If you've ever shopped on Amazon.com, you'll know that they push prices to the absolute bottom.
That's just built into Amazon's DNA and culture and we can see that with AWS Pricing going back 10 years in the past.
We'll find a price of 15¢ per gigabyte in an s three storage bucket.
And if we fast forward to the present day, it's It's only 2.3¢ per gigabyte.
That's a price reduction of 85% over the course of 10 years.
Remember, we are not undersold.
We will not be undersold.
We cannot be undersold.
The home appliance But it's a little more complex than that.
Both platforms have extremely generous pricing models and they both start out on a free tier, so you don't really pay for anything until you have a decent number of active users.
And what you'll find on most services is that AWS is just slightly cheaper than GCP.
For example, a gigabyte of storage is 2.3¢ on AWS and 2.6 on Firebase.
But Firebase has a couple of services that are always free, such as user authentication and push notifications.
On AWS, you pay about Half a penny for each monthly active user beyond 50,000 monthly active users.
But the most interesting pricing comes into play when we start talking about databases and real time listeners to that data.
With Firestore, you're billed for your reads and writes to the database.
And all the real time syncing just happens automatically, so you don't really have to worry much about that as far as pricing is concerned.
On On AWS, you have a service called AppSync, which will connect automatically to a Dynamo DB instance.
And with AppSync, you pay $4 per 1,000,000 query or write operations.
But with Firestore, that would only be 60¢ if they're read operations or a dollar 80 if they were write operations.
In addition, with AppSync, you have additional costs associated with the actual back end database itself, and they also calculate billing in chunks of 5 kilobytes.
So if you have a document that's a 100 kilobytes, That would equal 50 document read units.
It is hard to compare these things side by side, but this appears to be an area where Firestore would be significantly less expensive as an app scales up.
And the last thing I'll mention on pricing is that AWS does have a solid edge when it comes to serverless, costing 20¢ per 1,000,000 function invocations versus 40¢ on Firebase.
Now pricing is an important thing to consider, but the whole reason you would use a framework like Amplify or Firebase in the first place is to increase the speed and flexibility of development.
So what I've done here is built a little to do app that has user authentication and a real time to do list.
It's built with Svelte 3, and we'll just use it to compare the developer experience between both platforms.
We'll go ahead and start with Amplify.
So at this point, you need to have an AWS developer account and also the Amplify CLI installed on your system.
From there, we'll run amplify init, which will set up a project in our working directory.
That'll ask us a series of basic questions, and it also gives us the option to set up amplify with a popular JavaScript framework.
But we'll just go ahead and select none for vanilla JS.
That'll take a minute to complete, and then when it's done, it will create this Amplify directory in the root of the project.
And that just contains a reference to all of the AWS resources that we're using in this project.
Now we can connect authentication to this app by running amplify add auth.
That'll give us a few different options here, but we'll go with the most simple use case of just email password authentication.
And once we selected those options, we can go ahead and run amplify push.
This will take all the resources that we have staged locally for AWS and then actually allocate them in the cloud.
In this case, user authentication is handled by an AWS service called Cognito.
If we go to the AWS console, you'll see a user pool based on the app that you just created.
And inside of here, you'll find all kinds of different configuration options.
And this is an area where AWS has a big advantage over Firebase in terms of flexibility and customization.
It allows you to do things like multifactor auth by sending a text message or email to the user with a special code that they need to verify.
And you can also set up custom attributes on the user authentication record.
And you also have additional triggers that you can use for serverless code.
In Firebase, you can only trigger when a user is created or deleted, but with Cognito, you have additional places that you can hook in serverless code.
Now if we switch over to the Firebase dashboard, you'll find that things are a lot more simplified.
Things are generally faster and easier to set up, but they are less flexible by comparison.
For example, if we wanted to set up passwordless authentication, we can just do that by clicking a button, whereas on AWS we can do that as well, but we'd have to set up several Lambda functions to make it happen.
Now Now once we have the initial configuration done, the code for both platforms looks very similar.
On my AWS Amplify branch, I had to switch over to webpack back and Svelte because apparently it doesn't work with roll up currently.
And just a quick side note here, both Amplify and Firebase will add quite a bit of JavaScript to your final bundle size.
For Firebase with user authentication and Firestore, you'll be looking at around 500 kilobytes, and AWS with AppSync and GraphQL is close to a full megabyte.
In the main JS file in Svelte, I'm going to import Amplify from Amplify Core and then I'm going to call configure on it with our configuration details that were automatically generated by the DLI.
From there, I'll just go into the app component, and then when this component is mounted, I'll go ahead and call auth current user to see if the current user is logged in.
So just one line of code to check if the user's logged in.
And then if we want to log in with email and password, we can call auth sign in with the username and password.
And that's all it takes to get a user signed in, and then we can set that user as the user property on this component.
Now if we click the login button, it's going to log us in with AWS Cognito, and then it'll show our username here in the UI.
And I don't think it gets any easier than that as far as user authentication goes.
Now if we switch over to our Firebase branch, we have the same basic setup Here, we initialize the SDK with our credentials from the Firebase console.
And then from there, we'll go into the main app component.
And you'll notice that the code is almost identical to AWS Amplify.
We're simply calling auth current user to get the current user, and then we say sign in with email and password to sign the user in.
Now the point I'm trying to make here is that both SDKs provide well organized JavaScript libraries that help you get things done with very few lines of code.
But now I wanna switch gears here to real time data, and that's where things really start to get interesting.
I'll go ahead and start by showing you the Firebase example.
We're here in the Firestore database, and we're creating a document in a to dos collection.
The user needs to be able to view this data and update the data and also stay up to date with any changes that happen to it in real time across all clients.
And that's a very challenging requirement to not only implement, but also to do at scale.
If we look at the app itself, the user should be able to tap the smart complete button and then see the data updated in the UI and then also in the back end as well.
To implement this code, we'll go ahead and import Firestore, and then we'll make a reference to that to do's collection in the database.
To query the collection, we just call on snapshot, and that will give us a callback function that will listen to any changes to that collection in real time.
It's going to give us a snapshot that contains an array of the document data, And then we can map that snapshot down to an actual JavaScript object that we can show here in our front end application.
And that's actually all it takes to listen to a real time stream of data.
Now if we want to mutate or update a specific to do item, we just make a reference to its location in the database and then we call update on that reference with the new data that we want to send.
In our case, we want to update a to do item to complete, which we can do with a single line of code.
So with Firestore, you get simplicity without any boilerplate code.
That makes it really easy to work with, especially if you're building complex real time features because all of the difficult real time stuff is done for you automatically under the hood.
But the major drawback is that you're stuck working with a single NoSQL database that may present challenges for data modeling and can also be hard to migrate into or migrate out of.
Let's go ahead and switch back to Amplify to see how this looks with GraphQL and AppSync.
We're going to first run amplify add API to provision these resources in the project.
We'll choose GraphQL so we can use real time features, then make sure to choose API for the authentication type.
Now with GraphQL, there's a lot of boilerplate code, But the nice thing about the Amplify CLI is that it's going to walk you through that code and generate most of it for you.
Conveniently, the default Schema matches the data type that we already have set up in our front end app.
I'm just going to add a Boolean property called complete.
From there, you can run amplify push, and then it will ask you if you want to automatically generate the GraphQL API.
Select yes.
And in this demo, I'll select JavaScript as the language.
Go ahead and select yes to everything else, and it's going to finish up by giving you a GraphQL API endpoint as well as an API key.
Then head over to the AppSync console, and you'll find a Schema has been generated and uploaded to the cloud for you.
This is really cool because you now have a GraphQL API deployed that can be accessed by any client that has that API key.
And it took almost no effort on our part, but the API itself is pretty useless unless there's a back end data source attached to it.
Amplify will automatically set up an instance of DynamoDB, which is a NoSQL database that is roughly equivalent to MongoDB or Firestore.
Now we can go into the database, and we'll go ahead and create a new item that matches the schema that we have set up in GraphQL.
Now if we go back to our source code, you'll see that there's an automatically generated GraphQL folder in the source directory.
This contains all the boilerplate code that you need for GraphQL for things like mutations, queries, and subscriptions.
Now there's a few different ways we could query this data with GraphQL, QL.
But the gold standard way is to use the Apollo client.
So we'll go ahead and install AWS AppSync and GraphQL tag in this project.
And then I'm creating a new JavaScript file called client dot JS that is just here to initialize AWS AppSync.
From there, we'll go into our app component and then we'll import that client, as well as the list to do's query from the GraphQL directory.
Now we can make a query for the actual data in the database by saying GraphQL list to do's, and that will return a promise that resolves into the actual data from the database which will be an array of the to do items.
So that provides a relatively easy way to fetch the data, but at this Point, it's not real time.
If the user clicks mark complete, it's going to update the item in the database, but it's not going to actually notify us of that change.
We'll go ahead and run the mutation as well as the subscription to real time updates in this to do component.
We'll need the update to do mutation as well as the on update to do subscription.
And And then to update the data, we'll call client mutate and then pass in an object that contains the data that we wanna change on that database record in DynamoDB.
Now that's going to take care of the update, but we still want to listen to real time changes.
To make that happen, we'll go ahead and set up a subscription here that listens to the update on this to do item.
We'll go ahead and call client subscribe and then point it to a query of the on update to do subscription.
And then we'll call subscribe on that, which will give us access to the data whenever it changes.
Once we have access to that new data, we can just go ahead and update the property on this component.
So now when this mutation runs on the back end, it's going to update the UI on the front end.
Now Now I probably would not build an app like this in the real world, but I just want to give you an idea of what it takes to get things set up with real time data in AWS AppSync.
GraphQL is a really amazing tool, but in a lot of cases, it might just be overkill.
We have a lot of complexity in this app, both in automatically generated code and our own implementation details for something that was implemented relatively easily with Firestore.
But, again, the big trade out there is we now have a lot more flexibility to make the code behave exactly the way we want it to.
I want to finish things off by saying that both platforms are awesome in their own ways, and it's hard for me to imagine going back to building a back end from scratch.
These services will save you time and money and help you get your product in front of customers faster.
Now to sum up the comparison, I would say that pricing is almost equivalent.
One might be cheaper than the other depending on how you use it.
I would say Firebase is generally easier to use, and there are fewer decisions to make when getting things configured.
And that's especially true when you compare GraphQL and Dynamo DB to Firestore.
But on the other hand, AWS is superior when it comes to flexibility.
There are more knobs to turn that you can use to customize the experience specific to your needs.
I'm gonna go ahead and wrap things up there.
And if you've experience with both Amplify and Firebase?
I'd really like to hear your thoughts in the comments.
Thanks for watching, and I will talk to you soon.
It might be a tumor.
It's not A tumor.
Not a tumor at all.

Speaker 0: Today, we're going to compare Firebase to AWS Amplify, both of which are platforms that make it easy for app developers to manage and scale their cloud infrastructure. In In this video, we'll build a mini JavaScript app on both platforms so we can compare feature parity, the developer experience, and pricing. It's Showtime. If you're new here, like and subscribe, and check out the full write up on Fireship IO. Now for full disclosure, I am a huge fan of Firebase, and I've been using it for many years, while AWS Amplify was only released in 2018.

The first major difference to point out is that Amplify will run on Amazon's cloud infrastructure, while Firebase will run on Google's. So there will be some degree of vendor lock in there, but that's just the trade off you make if you want a dramatically simplified back end. You are mine now. You belong to me. You're not gonna have your mommy slam Let's start by looking at some of the core features offered by both platforms.

And I should point out that this isn't a one is better than the other type of Harrison, it's more about using the right tool for the job. And the first thing you'll need to know is whether or not your front end framework is supported. You'll find official support for iOS, Android, and the web. And with Amplify, you'll also find official support for React Native as well as React Web, Angular, and Vue. At the time of this video, it does not support Flutter or bundling with Rollup.

But there are open issues for those, so they may be supported in the future. With Firebase, you do have official support for Flutter, and Angular and Vue both have official libraries under their mono repos for Firebase, and there are some really good community maintained projects for React and React Native. Now let's take a look at the core features of these platforms starting with the things that they share in common. They both provide user authentication, analytics, a way to manage real time data, push notifications, file storage, serverless functions and web hosting. We'll look at all these 1 by 1 throughout the video, but what does Amplify offer that Firebase does not?

Come with me if you want to live. One of the first things I noticed was the ability to set up dedicated environments for development and production. You can do this in Firebase as well by just setting up multiple projects, but it's a little more streamlined And another thing that's more streamlined is setting up your continuous deployment. Amplify takes a very similar approach to Netlify where you connect your hosting account to a GitHub Though, then when you commit your code, it just automatically deploys that code to the hosting account. Now in all fairness, you can do this with Google Cloud Build and Firebase as well.

There's just a few more configuration steps to get it set up. Another unique feature of Amplify is its integration with GraphQL, which we'll look at closely in a few minutes. And the last thing I'll point out is its integration with Sumerian, which might be useful if you're building an augmented or virtual reality app. So that's pretty cool, but what does Firebase have that Amplify does not? Case of the chopper.

The first and most interesting thing is a dedicated database, and we'll compare that in detail to Amplify's GraphQL setup. And another feature in Firebase that I find to be very powerful is callable functions. These are serverless functions that you can call with the auth context from your front end, so you can easily tell in your back end code if a user is logged in or not. And that's a lot easier than setting up an API gateway or just writing the back end authorization logic from scratch. In Firebase, you also have a few tools for quality control, things like Crashlytics, performance and test lab.

And then you have quite a few more features that are built on top of your analytics, things like predictions and remote config, just to name a few. And you also have ML Kit, which makes it really easy to implement machine learning features both in the Cloud and on device. Now, let's go ahead and switch gears to pricing. If you've ever shopped on Amazon.com, you'll know that they push prices to the absolute bottom. That's just built into Amazon's DNA and culture and we can see that with AWS Pricing going back 10 years in the past.

We'll find a price of 15¢ per gigabyte in an s three storage bucket. And if we fast forward to the present day, it's It's only 2.3¢ per gigabyte. That's a price reduction of 85% over the course of 10 years. Remember, we are not undersold. We will not be undersold.

We cannot be undersold. The home appliance But it's a little more complex than that. Both platforms have extremely generous pricing models and they both start out on a free tier, so you don't really pay for anything until you have a decent number of active users. And what you'll find on most services is that AWS is just slightly cheaper than GCP. For example, a gigabyte of storage is 2.3¢ on AWS and 2.6 on Firebase.

But Firebase has a couple of services that are always free, such as user authentication and push notifications. On AWS, you pay about Half a penny for each monthly active user beyond 50,000 monthly active users. But the most interesting pricing comes into play when we start talking about databases and real time listeners to that data. With Firestore, you're billed for your reads and writes to the database. And all the real time syncing just happens automatically, so you don't really have to worry much about that as far as pricing is concerned.

On On AWS, you have a service called AppSync, which will connect automatically to a Dynamo DB instance. And with AppSync, you pay $4 per 1,000,000 query or write operations. But with Firestore, that would only be 60¢ if they're read operations or a dollar 80 if they were write operations. In addition, with AppSync, you have additional costs associated with the actual back end database itself, and they also calculate billing in chunks of 5 kilobytes. So if you have a document that's a 100 kilobytes, That would equal 50 document read units.

It is hard to compare these things side by side, but this appears to be an area where Firestore would be significantly less expensive as an app scales up. And the last thing I'll mention on pricing is that AWS does have a solid edge when it comes to serverless, costing 20¢ per 1,000,000 function invocations versus 40¢ on Firebase. Now pricing is an important thing to consider, but the whole reason you would use a framework like Amplify or Firebase in the first place is to increase the speed and flexibility of development. So what I've done here is built a little to do app that has user authentication and a real time to do list. It's built with Svelte 3, and we'll just use it to compare the developer experience between both platforms.

We'll go ahead and start with Amplify. So at this point, you need to have an AWS developer account and also the Amplify CLI installed on your system. From there, we'll run amplify init, which will set up a project in our working directory. That'll ask us a series of basic questions, and it also gives us the option to set up amplify with a popular JavaScript framework. But we'll just go ahead and select none for vanilla JS.

That'll take a minute to complete, and then when it's done, it will create this Amplify directory in the root of the project. And that just contains a reference to all of the AWS resources that we're using in this project. Now we can connect authentication to this app by running amplify add auth. That'll give us a few different options here, but we'll go with the most simple use case of just email password authentication. And once we selected those options, we can go ahead and run amplify push.

This will take all the resources that we have staged locally for AWS and then actually allocate them in the cloud. In this case, user authentication is handled by an AWS service called Cognito. If we go to the AWS console, you'll see a user pool based on the app that you just created. And inside of here, you'll find all kinds of different configuration options. And this is an area where AWS has a big advantage over Firebase in terms of flexibility and customization.

It allows you to do things like multifactor auth by sending a text message or email to the user with a special code that they need to verify. And you can also set up custom attributes on the user authentication record. And you also have additional triggers that you can use for serverless code. In Firebase, you can only trigger when a user is created or deleted, but with Cognito, you have additional places that you can hook in serverless code. Now if we switch over to the Firebase dashboard, you'll find that things are a lot more simplified.

Things are generally faster and easier to set up, but they are less flexible by comparison. For example, if we wanted to set up passwordless authentication, we can just do that by clicking a button, whereas on AWS we can do that as well, but we'd have to set up several Lambda functions to make it happen. Now Now once we have the initial configuration done, the code for both platforms looks very similar. On my AWS Amplify branch, I had to switch over to webpack back and Svelte because apparently it doesn't work with roll up currently. And just a quick side note here, both Amplify and Firebase will add quite a bit of JavaScript to your final bundle size.

For Firebase with user authentication and Firestore, you'll be looking at around 500 kilobytes, and AWS with AppSync and GraphQL is close to a full megabyte. In the main JS file in Svelte, I'm going to import Amplify from Amplify Core and then I'm going to call configure on it with our configuration details that were automatically generated by the DLI. From there, I'll just go into the app component, and then when this component is mounted, I'll go ahead and call auth current user to see if the current user is logged in. So just one line of code to check if the user's logged in. And then if we want to log in with email and password, we can call auth sign in with the username and password.

And that's all it takes to get a user signed in, and then we can set that user as the user property on this component. Now if we click the login button, it's going to log us in with AWS Cognito, and then it'll show our username here in the UI. And I don't think it gets any easier than that as far as user authentication goes. Now if we switch over to our Firebase branch, we have the same basic setup Here, we initialize the SDK with our credentials from the Firebase console. And then from there, we'll go into the main app component.

And you'll notice that the code is almost identical to AWS Amplify. We're simply calling auth current user to get the current user, and then we say sign in with email and password to sign the user in. Now the point I'm trying to make here is that both SDKs provide well organized JavaScript libraries that help you get things done with very few lines of code. But now I wanna switch gears here to real time data, and that's where things really start to get interesting. I'll go ahead and start by showing you the Firebase example.

We're here in the Firestore database, and we're creating a document in a to dos collection. The user needs to be able to view this data and update the data and also stay up to date with any changes that happen to it in real time across all clients. And that's a very challenging requirement to not only implement, but also to do at scale. If we look at the app itself, the user should be able to tap the smart complete button and then see the data updated in the UI and then also in the back end as well. To implement this code, we'll go ahead and import Firestore, and then we'll make a reference to that to do's collection in the database.

To query the collection, we just call on snapshot, and that will give us a callback function that will listen to any changes to that collection in real time. It's going to give us a snapshot that contains an array of the document data, And then we can map that snapshot down to an actual JavaScript object that we can show here in our front end application. And that's actually all it takes to listen to a real time stream of data. Now if we want to mutate or update a specific to do item, we just make a reference to its location in the database and then we call update on that reference with the new data that we want to send. In our case, we want to update a to do item to complete, which we can do with a single line of code.

So with Firestore, you get simplicity without any boilerplate code. That makes it really easy to work with, especially if you're building complex real time features because all of the difficult real time stuff is done for you automatically under the hood. But the major drawback is that you're stuck working with a single NoSQL database that may present challenges for data modeling and can also be hard to migrate into or migrate out of. Let's go ahead and switch back to Amplify to see how this looks with GraphQL and AppSync. We're going to first run amplify add API to provision these resources in the project.

We'll choose GraphQL so we can use real time features, then make sure to choose API for the authentication type. Now with GraphQL, there's a lot of boilerplate code, But the nice thing about the Amplify CLI is that it's going to walk you through that code and generate most of it for you. Conveniently, the default Schema matches the data type that we already have set up in our front end app. I'm just going to add a Boolean property called complete. From there, you can run amplify push, and then it will ask you if you want to automatically generate the GraphQL API.

Select yes. And in this demo, I'll select JavaScript as the language. Go ahead and select yes to everything else, and it's going to finish up by giving you a GraphQL API endpoint as well as an API key. Then head over to the AppSync console, and you'll find a Schema has been generated and uploaded to the cloud for you. This is really cool because you now have a GraphQL API deployed that can be accessed by any client that has that API key.

And it took almost no effort on our part, but the API itself is pretty useless unless there's a back end data source attached to it. Amplify will automatically set up an instance of DynamoDB, which is a NoSQL database that is roughly equivalent to MongoDB or Firestore. Now we can go into the database, and we'll go ahead and create a new item that matches the schema that we have set up in GraphQL. Now if we go back to our source code, you'll see that there's an automatically generated GraphQL folder in the source directory. This contains all the boilerplate code that you need for GraphQL for things like mutations, queries, and subscriptions.

Now there's a few different ways we could query this data with GraphQL, QL. But the gold standard way is to use the Apollo client. So we'll go ahead and install AWS AppSync and GraphQL tag in this project. And then I'm creating a new JavaScript file called client dot JS that is just here to initialize AWS AppSync. From there, we'll go into our app component and then we'll import that client, as well as the list to do's query from the GraphQL directory.

Now we can make a query for the actual data in the database by saying GraphQL list to do's, and that will return a promise that resolves into the actual data from the database which will be an array of the to do items. So that provides a relatively easy way to fetch the data, but at this Point, it's not real time. If the user clicks mark complete, it's going to update the item in the database, but it's not going to actually notify us of that change. We'll go ahead and run the mutation as well as the subscription to real time updates in this to do component. We'll need the update to do mutation as well as the on update to do subscription.

And And then to update the data, we'll call client mutate and then pass in an object that contains the data that we wanna change on that database record in DynamoDB. Now that's going to take care of the update, but we still want to listen to real time changes. To make that happen, we'll go ahead and set up a subscription here that listens to the update on this to do item. We'll go ahead and call client subscribe and then point it to a query of the on update to do subscription. And then we'll call subscribe on that, which will give us access to the data whenever it changes.

Once we have access to that new data, we can just go ahead and update the property on this component. So now when this mutation runs on the back end, it's going to update the UI on the front end. Now Now I probably would not build an app like this in the real world, but I just want to give you an idea of what it takes to get things set up with real time data in AWS AppSync. GraphQL is a really amazing tool, but in a lot of cases, it might just be overkill. We have a lot of complexity in this app, both in automatically generated code and our own implementation details for something that was implemented relatively easily with Firestore.

But, again, the big trade out there is we now have a lot more flexibility to make the code behave exactly the way we want it to. I want to finish things off by saying that both platforms are awesome in their own ways, and it's hard for me to imagine going back to building a back end from scratch. These services will save you time and money and help you get your product in front of customers faster. Now to sum up the comparison, I would say that pricing is almost equivalent. One might be cheaper than the other depending on how you use it.

I would say Firebase is generally easier to use, and there are fewer decisions to make when getting things configured. And that's especially true when you compare GraphQL and Dynamo DB to Firestore. But on the other hand, AWS is superior when it comes to flexibility. There are more knobs to turn that you can use to customize the experience specific to your needs. I'm gonna go ahead and wrap things up there.

And if you've experience with both Amplify and Firebase? I'd really like to hear your thoughts in the comments. Thanks for watching, and I will talk to you soon. It might be a tumor. It's not A tumor.

Not a tumor at all.
Today, we're going to compare Firebase to AWS Amplify, both of which are platforms that make it easy for app developers to manage and scale their cloud infrastructure. In In this video, we'll build a mini JavaScript app on both platforms so we can compare feature parity, the developer experience, and pricing. It's Showtime. If you're new here, like and subscribe, and check out the full write up on Fireship IO. Now for full disclosure, I am a huge fan of Firebase, and I've been using it for many years, while AWS Amplify was only released in 2018. The first major difference to point out is that Amplify will run on Amazon's cloud infrastructure, while Firebase will run on Google's. So there will be some degree of vendor lock in there, but that's just the trade off you make if you want a dramatically simplified back end. You are mine now.
amazon
streaming
video gaming
youtube
software
software development
You belong to me. You're not gonna have your mommy slam Let's start by looking at some of the core features offered by both platforms. And I should point out that this isn't a one is better than the other type of Harrison, it's more about using the right tool for the job. And the first thing you'll need to know is whether or not your front end framework is supported. You'll find official support for iOS, Android, and the web. And with Amplify, you'll also find official support for React Native as well as React Web, Angular, and Vue. At the time of this video, it does not support Flutter or bundling with Rollup. But there are open issues for those, so they may be supported in the future. With Firebase, you do have official support for Flutter, and Angular and Vue both have official libraries under their mono repos for Firebase, and there are some really good community maintained projects for React and React Native. Now let's take a look at the core features of these platforms starting with the things that they share in common. They both provide user authentication, analytics, a way to manage real time data, push notifications, file storage, serverless functions and web hosting. We'll look at all these 1 by 1 throughout the video, but what does Amplify offer that Firebase does not? Come with me if you want to live.
One of the first things I noticed was the ability to set up dedicated environments for development and production. You can do this in Firebase as well by just setting up multiple projects, but it's a little more streamlined And another thing that's more streamlined is setting up your continuous deployment.
infrastructure
software development
Amplify takes a very similar approach to Netlify where you connect your hosting account to a GitHub Though, then when you commit your code, it just automatically deploys that code to the hosting account. Now in all fairness, you can do this with Google Cloud Build and Firebase as well. There's just a few more configuration steps to get it set up. Another unique feature of Amplify is its integration with GraphQL, which we'll look at closely in a few minutes. And the last thing I'll point out is its integration with Sumerian, which might be useful if you're building an augmented or virtual reality app. So that's pretty cool, but what does Firebase have that Amplify does not? Case of the chopper. The first and most interesting thing is a dedicated database, and we'll compare that in detail to Amplify's GraphQL setup. And another feature in Firebase that I find to be very powerful is callable functions. These are serverless functions that you can call with the auth context from your front end, so you can easily tell in your back end code if a user is logged in or not. And that's a lot easier than setting up an API gateway or just writing the back end authorization logic from scratch. In Firebase, you also have a few tools for quality control, things like Crashlytics, performance and test lab.
And then you have quite a few more features that are built on top of your analytics, things like predictions and remote config, just to name a few. And you also have ML Kit, which makes it really easy to implement machine learning features both in the Cloud and on device. Now, let's go ahead and switch gears to pricing. If you've ever shopped on Amazon.com, you'll know that they push prices to the absolute bottom. That's just built into Amazon's DNA and culture and we can see that with AWS Pricing going back 10 years in the past. We'll find a price of 15¢ per gigabyte in an s three storage bucket.
amazon
machine learning
artificial intelligence
deep learning
neural networks
purchasing
And if we fast forward to the present day, it's It's only 2.3¢ per gigabyte. That's a price reduction of 85% over the course of 10 years. Remember, we are not undersold. We will not be undersold. We cannot be undersold. The home appliance But it's a little more complex than that. Both platforms have extremely generous pricing models and they both start out on a free tier, so you don't really pay for anything until you have a decent number of active users. And what you'll find on most services is that AWS is just slightly cheaper than GCP. For example, a gigabyte of storage is 2.3¢ on AWS and 2.6 on Firebase.
But Firebase has a couple of services that are always free, such as user authentication and push notifications. On AWS, you pay about Half a penny for each monthly active user beyond 50,000 monthly active users. But the most interesting pricing comes into play when we start talking about databases and real time listeners to that data. With Firestore, you're billed for your reads and writes to the database. And all the real time syncing just happens automatically, so you don't really have to worry much about that as far as pricing is concerned.
billing
commerce
customers
databases
amazon
data management
On On AWS, you have a service called AppSync, which will connect automatically to a Dynamo DB instance. And with AppSync, you pay $4 per 1,000,000 query or write operations.
But with Firestore, that would only be 60¢ if they're read operations or a dollar 80 if they were write operations. In addition, with AppSync, you have additional costs associated with the actual back end database itself, and they also calculate billing in chunks of 5 kilobytes. So if you have a document that's a 100 kilobytes, That would equal 50 document read units.
billing
It is hard to compare these things side by side, but this appears to be an area where Firestore would be significantly less expensive as an app scales up. And the last thing I'll mention on pricing is that AWS does have a solid edge when it comes to serverless, costing 20¢ per 1,000,000 function invocations versus 40¢ on Firebase.
Now pricing is an important thing to consider, but the whole reason you would use a framework like Amplify or Firebase in the first place is to increase the speed and flexibility of development. So what I've done here is built a little to do app that has user authentication and a real time to do list. It's built with Svelte 3, and we'll just use it to compare the developer experience between both platforms. We'll go ahead and start with Amplify. So at this point, you need to have an AWS developer account and also the Amplify CLI installed on your system. From there, we'll run amplify init, which will set up a project in our working directory. That'll ask us a series of basic questions, and it also gives us the option to set up amplify with a popular JavaScript framework.
software development
software
microsoft
But we'll just go ahead and select none for vanilla JS. That'll take a minute to complete, and then when it's done, it will create this Amplify directory in the root of the project.
And that just contains a reference to all of the AWS resources that we're using in this project. Now we can connect authentication to this app by running amplify add auth. That'll give us a few different options here, but we'll go with the most simple use case of just email password authentication. And once we selected those options, we can go ahead and run amplify push. This will take all the resources that we have staged locally for AWS and then actually allocate them in the cloud.
email
In this case, user authentication is handled by an AWS service called Cognito. If we go to the AWS console, you'll see a user pool based on the app that you just created. And inside of here, you'll find all kinds of different configuration options. And this is an area where AWS has a big advantage over Firebase in terms of flexibility and customization. It allows you to do things like multifactor auth by sending a text message or email to the user with a special code that they need to verify. And you can also set up custom attributes on the user authentication record. And you also have additional triggers that you can use for serverless code. In Firebase, you can only trigger when a user is created or deleted, but with Cognito, you have additional places that you can hook in serverless code. Now if we switch over to the Firebase dashboard, you'll find that things are a lot more simplified. Things are generally faster and easier to set up, but they are less flexible by comparison. For example, if we wanted to set up passwordless authentication, we can just do that by clicking a button, whereas on AWS we can do that as well, but we'd have to set up several Lambda functions to make it happen. Now Now once we have the initial configuration done, the code for both platforms looks very similar. On my AWS Amplify branch, I had to switch over to webpack back and Svelte because apparently it doesn't work with roll up currently. And just a quick side note here, both Amplify and Firebase will add quite a bit of JavaScript to your final bundle size. For Firebase with user authentication and Firestore, you'll be looking at around 500 kilobytes, and AWS with AppSync and GraphQL is close to a full megabyte. In the main JS file in Svelte, I'm going to import Amplify from Amplify Core and then I'm going to call configure on it with our configuration details that were automatically generated by the DLI. From there, I'll just go into the app component, and then when this component is mounted, I'll go ahead and call auth current user to see if the current user is logged in.
So just one line of code to check if the user's logged in. And then if we want to log in with email and password, we can call auth sign in with the username and password. And that's all it takes to get a user signed in, and then we can set that user as the user property on this component.
email
Now if we click the login button, it's going to log us in with AWS Cognito, and then it'll show our username here in the UI. And I don't think it gets any easier than that as far as user authentication goes. Now if we switch over to our Firebase branch, we have the same basic setup Here, we initialize the SDK with our credentials from the Firebase console. And then from there, we'll go into the main app component. And you'll notice that the code is almost identical to AWS Amplify. We're simply calling auth current user to get the current user, and then we say sign in with email and password to sign the user in. Now the point I'm trying to make here is that both SDKs provide well organized JavaScript libraries that help you get things done with very few lines of code.
But now I wanna switch gears here to real time data, and that's where things really start to get interesting. I'll go ahead and start by showing you the Firebase example. We're here in the Firestore database, and we're creating a document in a to dos collection. The user needs to be able to view this data and update the data and also stay up to date with any changes that happen to it in real time across all clients. And that's a very challenging requirement to not only implement, but also to do at scale.
databases
data management
data
If we look at the app itself, the user should be able to tap the smart complete button and then see the data updated in the UI and then also in the back end as well.
To implement this code, we'll go ahead and import Firestore, and then we'll make a reference to that to do's collection in the database. To query the collection, we just call on snapshot, and that will give us a callback function that will listen to any changes to that collection in real time. It's going to give us a snapshot that contains an array of the document data, And then we can map that snapshot down to an actual JavaScript object that we can show here in our front end application. And that's actually all it takes to listen to a real time stream of data. Now if we want to mutate or update a specific to do item, we just make a reference to its location in the database and then we call update on that reference with the new data that we want to send.
data management
data
databases
photography
In our case, we want to update a to do item to complete, which we can do with a single line of code. So with Firestore, you get simplicity without any boilerplate code.
That makes it really easy to work with, especially if you're building complex real time features because all of the difficult real time stuff is done for you automatically under the hood. But the major drawback is that you're stuck working with a single NoSQL database that may present challenges for data modeling and can also be hard to migrate into or migrate out of. Let's go ahead and switch back to Amplify to see how this looks with GraphQL and AppSync.
databases
data management
We're going to first run amplify add API to provision these resources in the project.
We'll choose GraphQL so we can use real time features, then make sure to choose API for the authentication type. Now with GraphQL, there's a lot of boilerplate code, But the nice thing about the Amplify CLI is that it's going to walk you through that code and generate most of it for you. Conveniently, the default Schema matches the data type that we already have set up in our front end app. I'm just going to add a Boolean property called complete. From there, you can run amplify push, and then it will ask you if you want to automatically generate the GraphQL API.
databases
programming
Select yes. And in this demo, I'll select JavaScript as the language.
Go ahead and select yes to everything else, and it's going to finish up by giving you a GraphQL API endpoint as well as an API key. Then head over to the AppSync console, and you'll find a Schema has been generated and uploaded to the cloud for you. This is really cool because you now have a GraphQL API deployed that can be accessed by any client that has that API key. And it took almost no effort on our part, but the API itself is pretty useless unless there's a back end data source attached to it. Amplify will automatically set up an instance of DynamoDB, which is a NoSQL database that is roughly equivalent to MongoDB or Firestore. Now we can go into the database, and we'll go ahead and create a new item that matches the schema that we have set up in GraphQL. Now if we go back to our source code, you'll see that there's an automatically generated GraphQL folder in the source directory. This contains all the boilerplate code that you need for GraphQL for things like mutations, queries, and subscriptions. Now there's a few different ways we could query this data with GraphQL, QL.
databases
But the gold standard way is to use the Apollo client. So we'll go ahead and install AWS AppSync and GraphQL tag in this project. And then I'm creating a new JavaScript file called client dot JS that is just here to initialize AWS AppSync.
From there, we'll go into our app component and then we'll import that client, as well as the list to do's query from the GraphQL directory. Now we can make a query for the actual data in the database by saying GraphQL list to do's, and that will return a promise that resolves into the actual data from the database which will be an array of the to do items. So that provides a relatively easy way to fetch the data, but at this Point, it's not real time.
databases
data management
data
If the user clicks mark complete, it's going to update the item in the database, but it's not going to actually notify us of that change. We'll go ahead and run the mutation as well as the subscription to real time updates in this to do component. We'll need the update to do mutation as well as the on update to do subscription.
And And then to update the data, we'll call client mutate and then pass in an object that contains the data that we wanna change on that database record in DynamoDB. Now that's going to take care of the update, but we still want to listen to real time changes.
data management
To make that happen, we'll go ahead and set up a subscription here that listens to the update on this to do item. We'll go ahead and call client subscribe and then point it to a query of the on update to do subscription. And then we'll call subscribe on that, which will give us access to the data whenever it changes. Once we have access to that new data, we can just go ahead and update the property on this component. So now when this mutation runs on the back end, it's going to update the UI on the front end.
Now Now I probably would not build an app like this in the real world, but I just want to give you an idea of what it takes to get things set up with real time data in AWS AppSync. GraphQL is a really amazing tool, but in a lot of cases, it might just be overkill. We have a lot of complexity in this app, both in automatically generated code and our own implementation details for something that was implemented relatively easily with Firestore. But, again, the big trade out there is we now have a lot more flexibility to make the code behave exactly the way we want it to.
databases
programming
data management
I want to finish things off by saying that both platforms are awesome in their own ways, and it's hard for me to imagine going back to building a back end from scratch. These services will save you time and money and help you get your product in front of customers faster. Now to sum up the comparison, I would say that pricing is almost equivalent. One might be cheaper than the other depending on how you use it. I would say Firebase is generally easier to use, and there are fewer decisions to make when getting things configured.
computers
technology
customer support
And that's especially true when you compare GraphQL and Dynamo DB to Firestore. But on the other hand, AWS is superior when it comes to flexibility. There are more knobs to turn that you can use to customize the experience specific to your needs. I'm gonna go ahead and wrap things up there.
data management
And if you've experience with both Amplify and Firebase? I'd really like to hear your thoughts in the comments. Thanks for watching, and I will talk to you soon. It might be a tumor. It's not A tumor. Not a tumor at all.
cancer
Today, we're going to compare Firebase to AWS Amplify, both of which are platforms that make it easy for app developers to manage and scale their cloud infrastructure. In In this video, we'll build a mini JavaScript app on both platforms so we can compare feature parity, the developer experience, and pricing. It's Showtime. If you're new here, like and subscribe, and check out the full write up on Fireship IO. Now for full disclosure, I am a huge fan of Firebase, and I've been using it for many years, while AWS Amplify was only released in 2018. The first major difference to point out is that Amplify will run on Amazon's cloud infrastructure, while Firebase will run on Google's. So there will be some degree of vendor lock in there, but that's just the trade off you make if you want a dramatically simplified back end. You are mine now. You belong to me. You're not gonna have your mommy slam Let's start by looking at some of the core features offered by both platforms. And I should point out that this isn't a one is better than the other type of Harrison, it's more about using the right tool for the job. And the first thing you'll need to know is whether or not your front end framework is supported. You'll find official support for iOS, Android, and the web. And with Amplify, you'll also find official support for React Native as well as React Web, Angular, and Vue. At the time of this video, it does not support Flutter or bundling with Rollup. But there are open issues for those, so they may be supported in the future. With Firebase, you do have official support for Flutter, and Angular and Vue both have official libraries under their mono repos for Firebase, and there are some really good community maintained projects for React and React Native. Now let's take a look at the core features of these platforms starting with the things that they share in common. They both provide user authentication, analytics, a way to manage real time data, push notifications, file storage, serverless functions and web hosting. We'll look at all these 1 by 1 throughout the video, but what does Amplify offer that Firebase does not? Come with me if you want to live. One of the first things I noticed was the ability to set up dedicated environments for development and production. You can do this in Firebase as well by just setting up multiple projects, but it's a little more streamlined And another thing that's more streamlined is setting up your continuous deployment. Amplify takes a very similar approach to Netlify where you connect your hosting account to a GitHub Though, then when you commit your code, it just automatically deploys that code to the hosting account. Now in all fairness, you can do this with Google Cloud Build and Firebase as well. There's just a few more configuration steps to get it set up. Another unique feature of Amplify is its integration with GraphQL, which we'll look at closely in a few minutes. And the last thing I'll point out is its integration with Sumerian, which might be useful if you're building an augmented or virtual reality app. So that's pretty cool, but what does Firebase have that Amplify does not? Case of the chopper. The first and most interesting thing is a dedicated database, and we'll compare that in detail to Amplify's GraphQL setup. And another feature in Firebase that I find to be very powerful is callable functions. These are serverless functions that you can call with the auth context from your front end, so you can easily tell in your back end code if a user is logged in or not. And that's a lot easier than setting up an API gateway or just writing the back end authorization logic from scratch. In Firebase, you also have a few tools for quality control, things like Crashlytics, performance and test lab. And then you have quite a few more features that are built on top of your analytics, things like predictions and remote config, just to name a few. And you also have ML Kit, which makes it really easy to implement machine learning features both in the Cloud and on device. Now, let's go ahead and switch gears to pricing. If you've ever shopped on Amazon.com, you'll know that they push prices to the absolute bottom. That's just built into Amazon's DNA and culture and we can see that with AWS Pricing going back 10 years in the past. We'll find a price of 15¢ per gigabyte in an s three storage bucket. And if we fast forward to the present day, it's It's only 2.3¢ per gigabyte. That's a price reduction of 85% over the course of 10 years. Remember, we are not undersold. We will not be undersold. We cannot be undersold. The home appliance But it's a little more complex than that. Both platforms have extremely generous pricing models and they both start out on a free tier, so you don't really pay for anything until you have a decent number of active users. And what you'll find on most services is that AWS is just slightly cheaper than GCP. For example, a gigabyte of storage is 2.3¢ on AWS and 2.6 on Firebase. But Firebase has a couple of services that are always free, such as user authentication and push notifications. On AWS, you pay about Half a penny for each monthly active user beyond 50,000 monthly active users. But the most interesting pricing comes into play when we start talking about databases and real time listeners to that data. With Firestore, you're billed for your reads and writes to the database. And all the real time syncing just happens automatically, so you don't really have to worry much about that as far as pricing is concerned. On On AWS, you have a service called AppSync, which will connect automatically to a Dynamo DB instance. And with AppSync, you pay $4 per 1,000,000 query or write operations. But with Firestore, that would only be 60¢ if they're read operations or a dollar 80 if they were write operations. In addition, with AppSync, you have additional costs associated with the actual back end database itself, and they also calculate billing in chunks of 5 kilobytes. So if you have a document that's a 100 kilobytes, That would equal 50 document read units. It is hard to compare these things side by side, but this appears to be an area where Firestore would be significantly less expensive as an app scales up. And the last thing I'll mention on pricing is that AWS does have a solid edge when it comes to serverless, costing 20¢ per 1,000,000 function invocations versus 40¢ on Firebase. Now pricing is an important thing to consider, but the whole reason you would use a framework like Amplify or Firebase in the first place is to increase the speed and flexibility of development. So what I've done here is built a little to do app that has user authentication and a real time to do list. It's built with Svelte 3, and we'll just use it to compare the developer experience between both platforms. We'll go ahead and start with Amplify. So at this point, you need to have an AWS developer account and also the Amplify CLI installed on your system. From there, we'll run amplify init, which will set up a project in our working directory. That'll ask us a series of basic questions, and it also gives us the option to set up amplify with a popular JavaScript framework. But we'll just go ahead and select none for vanilla JS. That'll take a minute to complete, and then when it's done, it will create this Amplify directory in the root of the project. And that just contains a reference to all of the AWS resources that we're using in this project. Now we can connect authentication to this app by running amplify add auth. That'll give us a few different options here, but we'll go with the most simple use case of just email password authentication. And once we selected those options, we can go ahead and run amplify push. This will take all the resources that we have staged locally for AWS and then actually allocate them in the cloud. In this case, user authentication is handled by an AWS service called Cognito. If we go to the AWS console, you'll see a user pool based on the app that you just created. And inside of here, you'll find all kinds of different configuration options. And this is an area where AWS has a big advantage over Firebase in terms of flexibility and customization. It allows you to do things like multifactor auth by sending a text message or email to the user with a special code that they need to verify. And you can also set up custom attributes on the user authentication record. And you also have additional triggers that you can use for serverless code. In Firebase, you can only trigger when a user is created or deleted, but with Cognito, you have additional places that you can hook in serverless code. Now if we switch over to the Firebase dashboard, you'll find that things are a lot more simplified. Things are generally faster and easier to set up, but they are less flexible by comparison. For example, if we wanted to set up passwordless authentication, we can just do that by clicking a button, whereas on AWS we can do that as well, but we'd have to set up several Lambda functions to make it happen. Now Now once we have the initial configuration done, the code for both platforms looks very similar. On my AWS Amplify branch, I had to switch over to webpack back and Svelte because apparently it doesn't work with roll up currently. And just a quick side note here, both Amplify and Firebase will add quite a bit of JavaScript to your final bundle size. For Firebase with user authentication and Firestore, you'll be looking at around 500 kilobytes, and AWS with AppSync and GraphQL is close to a full megabyte. In the main JS file in Svelte, I'm going to import Amplify from Amplify Core and then I'm going to call configure on it with our configuration details that were automatically generated by the DLI. From there, I'll just go into the app component, and then when this component is mounted, I'll go ahead and call auth current user to see if the current user is logged in. So just one line of code to check if the user's logged in. And then if we want to log in with email and password, we can call auth sign in with the username and password. And that's all it takes to get a user signed in, and then we can set that user as the user property on this component. Now if we click the login button, it's going to log us in with AWS Cognito, and then it'll show our username here in the UI. And I don't think it gets any easier than that as far as user authentication goes. Now if we switch over to our Firebase branch, we have the same basic setup Here, we initialize the SDK with our credentials from the Firebase console. And then from there, we'll go into the main app component. And you'll notice that the code is almost identical to AWS Amplify. We're simply calling auth current user to get the current user, and then we say sign in with email and password to sign the user in. Now the point I'm trying to make here is that both SDKs provide well organized JavaScript libraries that help you get things done with very few lines of code. But now I wanna switch gears here to real time data, and that's where things really start to get interesting. I'll go ahead and start by showing you the Firebase example. We're here in the Firestore database, and we're creating a document in a to dos collection. The user needs to be able to view this data and update the data and also stay up to date with any changes that happen to it in real time across all clients. And that's a very challenging requirement to not only implement, but also to do at scale. If we look at the app itself, the user should be able to tap the smart complete button and then see the data updated in the UI and then also in the back end as well. To implement this code, we'll go ahead and import Firestore, and then we'll make a reference to that to do's collection in the database. To query the collection, we just call on snapshot, and that will give us a callback function that will listen to any changes to that collection in real time. It's going to give us a snapshot that contains an array of the document data, And then we can map that snapshot down to an actual JavaScript object that we can show here in our front end application. And that's actually all it takes to listen to a real time stream of data. Now if we want to mutate or update a specific to do item, we just make a reference to its location in the database and then we call update on that reference with the new data that we want to send. In our case, we want to update a to do item to complete, which we can do with a single line of code. So with Firestore, you get simplicity without any boilerplate code. That makes it really easy to work with, especially if you're building complex real time features because all of the difficult real time stuff is done for you automatically under the hood. But the major drawback is that you're stuck working with a single NoSQL database that may present challenges for data modeling and can also be hard to migrate into or migrate out of. Let's go ahead and switch back to Amplify to see how this looks with GraphQL and AppSync. We're going to first run amplify add API to provision these resources in the project. We'll choose GraphQL so we can use real time features, then make sure to choose API for the authentication type. Now with GraphQL, there's a lot of boilerplate code, But the nice thing about the Amplify CLI is that it's going to walk you through that code and generate most of it for you. Conveniently, the default Schema matches the data type that we already have set up in our front end app. I'm just going to add a Boolean property called complete. From there, you can run amplify push, and then it will ask you if you want to automatically generate the GraphQL API. Select yes. And in this demo, I'll select JavaScript as the language. Go ahead and select yes to everything else, and it's going to finish up by giving you a GraphQL API endpoint as well as an API key. Then head over to the AppSync console, and you'll find a Schema has been generated and uploaded to the cloud for you. This is really cool because you now have a GraphQL API deployed that can be accessed by any client that has that API key. And it took almost no effort on our part, but the API itself is pretty useless unless there's a back end data source attached to it. Amplify will automatically set up an instance of DynamoDB, which is a NoSQL database that is roughly equivalent to MongoDB or Firestore. Now we can go into the database, and we'll go ahead and create a new item that matches the schema that we have set up in GraphQL. Now if we go back to our source code, you'll see that there's an automatically generated GraphQL folder in the source directory. This contains all the boilerplate code that you need for GraphQL for things like mutations, queries, and subscriptions. Now there's a few different ways we could query this data with GraphQL, QL. But the gold standard way is to use the Apollo client. So we'll go ahead and install AWS AppSync and GraphQL tag in this project. And then I'm creating a new JavaScript file called client dot JS that is just here to initialize AWS AppSync. From there, we'll go into our app component and then we'll import that client, as well as the list to do's query from the GraphQL directory. Now we can make a query for the actual data in the database by saying GraphQL list to do's, and that will return a promise that resolves into the actual data from the database which will be an array of the to do items. So that provides a relatively easy way to fetch the data, but at this Point, it's not real time. If the user clicks mark complete, it's going to update the item in the database, but it's not going to actually notify us of that change. We'll go ahead and run the mutation as well as the subscription to real time updates in this to do component. We'll need the update to do mutation as well as the on update to do subscription. And And then to update the data, we'll call client mutate and then pass in an object that contains the data that we wanna change on that database record in DynamoDB. Now that's going to take care of the update, but we still want to listen to real time changes. To make that happen, we'll go ahead and set up a subscription here that listens to the update on this to do item. We'll go ahead and call client subscribe and then point it to a query of the on update to do subscription. And then we'll call subscribe on that, which will give us access to the data whenever it changes. Once we have access to that new data, we can just go ahead and update the property on this component. So now when this mutation runs on the back end, it's going to update the UI on the front end. Now Now I probably would not build an app like this in the real world, but I just want to give you an idea of what it takes to get things set up with real time data in AWS AppSync. GraphQL is a really amazing tool, but in a lot of cases, it might just be overkill. We have a lot of complexity in this app, both in automatically generated code and our own implementation details for something that was implemented relatively easily with Firestore. But, again, the big trade out there is we now have a lot more flexibility to make the code behave exactly the way we want it to. I want to finish things off by saying that both platforms are awesome in their own ways, and it's hard for me to imagine going back to building a back end from scratch. These services will save you time and money and help you get your product in front of customers faster. Now to sum up the comparison, I would say that pricing is almost equivalent. One might be cheaper than the other depending on how you use it. I would say Firebase is generally easier to use, and there are fewer decisions to make when getting things configured. And that's especially true when you compare GraphQL and Dynamo DB to Firestore. But on the other hand, AWS is superior when it comes to flexibility. There are more knobs to turn that you can use to customize the experience specific to your needs. I'm gonna go ahead and wrap things up there. And if you've experience with both Amplify and Firebase? I'd really like to hear your thoughts in the comments. Thanks for watching, and I will talk to you soon. It might be a tumor. It's not A tumor. Not a tumor at all.
Today,
today
we're
we're
going
going
to
to
compare
compare
Firebase
firebase
to
to
AWS
aws
Amplify,
amplify
both
both
of
of
which
which
are
are
platforms
platforms
that
that
make
make
it
it
easy
easy
for
for
app
app
developers
developers
to
to
manage
manage
and
and
scale
scale
their
their
cloud
cloud
infrastructure.
infrastructure
In
in
In
in
this
this
video,
video
we'll
we'll
build
build
a
a
mini
mini
JavaScript
javascript
app
app
on
on
both
both
platforms
platforms
so
so
we
we
can
can
compare
compare
feature
feature
parity,
parity
the
the
developer
developer
experience,
experience
and
and
pricing.
pricing
It's
it's
Showtime.
showtime
If
if
you're
you're
new
new
here,
here
like
like
and
and
subscribe,
subscribe
and
and
check
check
out
out
the
the
full
full
write
write
up
up
on
on
Fireship
fireship
IO.
io
Now
now
for
for
full
full
disclosure,
disclosure
I
i
am
am
a
a
huge
huge
fan
fan
of
of
Firebase,
firebase
and
and
I've
i've
been
been
using
using
it
it
for
for
many
many
years,
years
while
while
AWS
aws
Amplify
amplify
was
was
only
only
released
released
in
in
2018.
2018
The
the
first
first
major
major
difference
difference
to
to
point
point
out
out
is
is
that
that
Amplify
amplify
will
will
run
run
on
on
Amazon's
amazon's
cloud
cloud
infrastructure,
infrastructure
while
while
Firebase
firebase
will
will
run
run
on
on
Google's.
google's
So
so
there
there
will
will
be
be
some
some
degree
degree
of
of
vendor
vendor
lock
lock
in
in
there,
there
but
but
that's
that's
just
just
the
the
trade
trade
off
off
you
you
make
make
if
if
you
you
want
want
a
a
dramatically
dramatically
simplified
simplified
back
back
end.
end
You
you
are
are
mine
mine
now.
now
You
you
belong
belong
to
to
me.
me
You're
you're
not
not
gonna
gonna
have
have
your
your
mommy
mommy
slam
slam
Let's
let's
start
start
by
by
looking
looking
at
at
some
some
of
of
the
the
core
core
features
features
offered
offered
by
by
both
both
platforms.
platforms
And
and
I
i
should
should
point
point
out
out
that
that
this
this
isn't
isn't
a
a
one
one
is
is
better
better
than
than
the
the
other
other
type
type
of
of
Harrison,
harrison
it's
it's
more
more
about
about
using
using
the
the
right
right
tool
tool
for
for
the
the
job.
job
And
and
the
the
first
first
thing
thing
you'll
you'll
need
need
to
to
know
know
is
is
whether
whether
or
or
not
not
your
your
front
front
end
end
framework
framework
is
is
supported.
supported
You'll
you'll
find
find
official
official
support
support
for
for
iOS,
ios
Android,
android
and
and
the
the
web.
web
And
and
with
with
Amplify,
amplify
you'll
you'll
also
also
find
find
official
official
support
support
for
for
React
react
Native
native
as
as
well
well
as
as
React
react
Web,
web
Angular,
angular
and
and
Vue.
vue
At
at
the
the
time
time
of
of
this
this
video,
video
it
it
does
does
not
not
support
support
Flutter
flutter
or
or
bundling
bundling
with
with
Rollup.
rollup
But
but
there
there
are
are
open
open
issues
issues
for
for
those,
those
so
so
they
they
may
may
be
be
supported
supported
in
in
the
the
future.
future
With
with
Firebase,
firebase
you
you
do
do
have
have
official
official
support
support
for
for
Flutter,
flutter
and
and
Angular
angular
and
and
Vue
vue
both
both
have
have
official
official
libraries
libraries
under
under
their
their
mono
mono
repos
repos
for
for
Firebase,
firebase
and
and
there
there
are
are
some
some
really
really
good
good
community
community
maintained
maintained
projects
projects
for
for
React
react
and
and
React
react
Native.
native
Now
now
let's
let's
take
take
a
a
look
look
at
at
the
the
core
core
features
features
of
of
these
these
platforms
platforms
starting
starting
with
with
the
the
things
things
that
that
they
they
share
share
in
in
common.
common
They
they
both
both
provide
provide
user
user
authentication,
authentication
analytics,
analytics
a
a
way
way
to
to
manage
manage
real
real
time
time
data,
data
push
push
notifications,
notifications
file
file
storage,
storage
serverless
serverless
functions
functions
and
and
web
web
hosting.
hosting
We'll
we'll
look
look
at
at
all
all
these
these
1
1
by
by
1
1
throughout
throughout
the
the
video,
video
but
but
what
what
does
does
Amplify
amplify
offer
offer
that
that
Firebase
firebase
does
does
not?
not
Come
come
with
with
me
me
if
if
you
you
want
want
to
to
live.
live
One
one
of
of
the
the
first
first
things
things
I
i
noticed
noticed
was
was
the
the
ability
ability
to
to
set
set
up
up
dedicated
dedicated
environments
environments
for
for
development
development
and
and
production.
production
You
you
can
can
do
do
this
this
in
in
Firebase
firebase
as
as
well
well
by
by
just
just
setting
setting
up
up
multiple
multiple
projects,
projects
but
but
it's
it's
a
a
little
little
more
more
streamlined
streamlined
And
and
another
another
thing
thing
that's
that's
more
more
streamlined
streamlined
is
is
setting
setting
up
up
your
your
continuous
continuous
deployment.
deployment
Amplify
amplify
takes
takes
a
a
very
very
similar
similar
approach
approach
to
to
Netlify
netlify
where
where
you
you
connect
connect
your
your
hosting
hosting
account
account
to
to
a
a
GitHub
github
Though,
though
then
then
when
when
you
you
commit
commit
your
your
code,
code
it
it
just
just
automatically
automatically
deploys
deploys
that
that
code
code
to
to
the
the
hosting
hosting
account.
account
Now
now
in
in
all
all
fairness,
fairness
you
you
can
can
do
do
this
this
with
with
Google
google
Cloud
cloud
Build
build
and
and
Firebase
firebase
as
as
well.
well
There's
there's
just
just
a
a
few
few
more
more
configuration
configuration
steps
steps
to
to
get
get
it
it
set
set
up.
up
Another
another
unique
unique
feature
feature
of
of
Amplify
amplify
is
is
its
its
integration
integration
with
with
GraphQL,
graphql
which
which
we'll
we'll
look
look
at
at
closely
closely
in
in
a
a
few
few
minutes.
minutes
And
and
the
the
last
last
thing
thing
I'll
i'll
point
point
out
out
is
is
its
its
integration
integration
with
with
Sumerian,
sumerian
which
which
might
might
be
be
useful
useful
if
if
you're
you're
building
building
an
an
augmented
augmented
or
or
virtual
virtual
reality
reality
app.
app
So
so
that's
that's
pretty
pretty
cool,
cool
but
but
what
what
does
does
Firebase
firebase
have
have
that
that
Amplify
amplify
does
does
not?
not
Case
case
of
of
the
the
chopper.
chopper
The
the
first
first
and
and
most
most
interesting
interesting
thing
thing
is
is
a
a
dedicated
dedicated
database,
database
and
and
we'll
we'll
compare
compare
that
that
in
in
detail
detail
to
to
Amplify's
amplify's
GraphQL
graphql
setup.
setup
And
and
another
another
feature
feature
in
in
Firebase
firebase
that
that
I
i
find
find
to
to
be
be
very
very
powerful
powerful
is
is
callable
callable
functions.
functions
These
these
are
are
serverless
serverless
functions
functions
that
that
you
you
can
can
call
call
with
with
the
the
auth
auth
context
context
from
from
your
your
front
front
end,
end
so
so
you
you
can
can
easily
easily
tell
tell
in
in
your
your
back
back
end
end
code
code
if
if
a
a
user
user
is
is
logged
logged
in
in
or
or
not.
not
And
and
that's
that's
a
a
lot
lot
easier
easier
than
than
setting
setting
up
up
an
an
API
api
gateway
gateway
or
or
just
just
writing
writing
the
the
back
back
end
end
authorization
authorization
logic
logic
from
from
scratch.
scratch
In
in
Firebase,
firebase
you
you
also
also
have
have
a
a
few
few
tools
tools
for
for
quality
quality
control,
control
things
things
like
like
Crashlytics,
crashlytics
performance
performance
and
and
test
test
lab.
lab
And
and
then
then
you
you
have
have
quite
quite
a
a
few
few
more
more
features
features
that
that
are
are
built
built
on
on
top
top
of
of
your
your
analytics,
analytics
things
things
like
like
predictions
predictions
and
and
remote
remote
config,
config
just
just
to
to
name
name
a
a
few.
few
And
and
you
you
also
also
have
have
ML
ml
Kit,
kit
which
which
makes
makes
it
it
really
really
easy
easy
to
to
implement
implement
machine
machine
learning
learning
features
features
both
both
in
in
the
the
Cloud
cloud
and
and
on
on
device.
device
Now,
now
let's
let's
go
go
ahead
ahead
and
and
switch
switch
gears
gears
to
to
pricing.
pricing
If
if
you've
you've
ever
ever
shopped
shopped
on
on
Amazon.com,
amazon.com
you'll
you'll
know
know
that
that
they
they
push
push
prices
prices
to
to
the
the
absolute
absolute
bottom.
bottom
That's
that's
just
just
built
built
into
into
Amazon's
amazon's
DNA
dna
and
and
culture
culture
and
and
we
we
can
can
see
see
that
that
with
with
AWS
aws
Pricing
pricing
going
going
back
back
10
10
years
years
in
in
the
the
past.
past
We'll
we'll
find
find
a
a
price
price
of
of
15¢
15¢
per
per
gigabyte
gigabyte
in
in
an
an
s
s
three
three
storage
storage
bucket.
bucket
And
and
if
if
we
we
fast
fast
forward
forward
to
to
the
the
present
present
day,
day
it's
it's
It's
it's
only
only
2.3¢
2.3¢
per
per
gigabyte.
gigabyte
That's
that's
a
a
price
price
reduction
reduction
of
of
85%
85%
over
over
the
the
course
course
of
of
10
10
years.
years
Remember,
remember
we
we
are
are
not
not
undersold.
undersold
We
we
will
will
not
not
be
be
undersold.
undersold
We
we
cannot
cannot
be
be
undersold.
undersold
The
the
home
home
appliance
appliance
But
but
it's
it's
a
a
little
little
more
more
complex
complex
than
than
that.
that
Both
both
platforms
platforms
have
have
extremely
extremely
generous
generous
pricing
pricing
models
models
and
and
they
they
both
both
start
start
out
out
on
on
a
a
free
free
tier,
tier
so
so
you
you
don't
don't
really
really
pay
pay
for
for
anything
anything
until
until
you
you
have
have
a
a
decent
decent
number
number
of
of
active
active
users.
users
And
and
what
what
you'll
you'll
find
find
on
on
most
most
services
services
is
is
that
that
AWS
aws
is
is
just
just
slightly
slightly
cheaper
cheaper
than
than
GCP.
gcp
For
for
example,
example
a
a
gigabyte
gigabyte
of
of
storage
storage
is
is
2.3¢
2.3¢
on
on
AWS
aws
and
and
2.6
2.6
on
on
Firebase.
firebase
But
but
Firebase
firebase
has
has
a
a
couple
couple
of
of
services
services
that
that
are
are
always
always
free,
free
such
such
as
as
user
user
authentication
authentication
and
and
push
push
notifications.
notifications
On
on
AWS,
aws
you
you
pay
pay
about
about
Half
half
a
a
penny
penny
for
for
each
each
monthly
monthly
active
active
user
user
beyond
beyond
50,000
50,000
monthly
monthly
active
active
users.
users
But
but
the
the
most
most
interesting
interesting
pricing
pricing
comes
comes
into
into
play
play
when
when
we
we
start
start
talking
talking
about
about
databases
databases
and
and
real
real
time
time
listeners
listeners
to
to
that
that
data.
data
With
with
Firestore,
firestore
you're
you're
billed
billed
for
for
your
your
reads
reads
and
and
writes
writes
to
to
the
the
database.
database
And
and
all
all
the
the
real
real
time
time
syncing
syncing
just
just
happens
happens
automatically,
automatically
so
so
you
you
don't
don't
really
really
have
have
to
to
worry
worry
much
much
about
about
that
that
as
as
far
far
as
as
pricing
pricing
is
is
concerned.
concerned
On
on
On
on
AWS,
aws
you
you
have
have
a
a
service
service
called
called
AppSync,
appsync
which
which
will
will
connect
connect
automatically
automatically
to
to
a
a
Dynamo
dynamo
DB
db
instance.
instance
And
and
with
with
AppSync,
appsync
you
you
pay
pay
$4
$4
per
per
1,000,000
1,000,000
query
query
or
or
write
write
operations.
operations
But
but
with
with
Firestore,
firestore
that
that
would
would
only
only
be
be
60¢
60¢
if
if
they're
they're
read
read
operations
operations
or
or
a
a
dollar
dollar
80
80
if
if
they
they
were
were
write
write
operations.
operations
In
in
addition,
addition
with
with
AppSync,
appsync
you
you
have
have
additional
additional
costs
costs
associated
associated
with
with
the
the
actual
actual
back
back
end
end
database
database
itself,
itself
and
and
they
they
also
also
calculate
calculate
billing
billing
in
in
chunks
chunks
of
of
5
5
kilobytes.
kilobytes
So
so
if
if
you
you
have
have
a
a
document
document
that's
that's
a
a
100
100
kilobytes,
kilobytes
That
that
would
would
equal
equal
50
50
document
document
read
read
units.
units
It
it
is
is
hard
hard
to
to
compare
compare
these
these
things
things
side
side
by
by
side,
side
but
but
this
this
appears
appears
to
to
be
be
an
an
area
area
where
where
Firestore
firestore
would
would
be
be
significantly
significantly
less
less
expensive
expensive
as
as
an
an
app
app
scales
scales
up.
up
And
and
the
the
last
last
thing
thing
I'll
i'll
mention
mention
on
on
pricing
pricing
is
is
that
that
AWS
aws
does
does
have
have
a
a
solid
solid
edge
edge
when
when
it
it
comes
comes
to
to
serverless,
serverless
costing
costing
20¢
20¢
per
per
1,000,000
1,000,000
function
function
invocations
invocations
versus
versus
40¢
40¢
on
on
Firebase.
firebase
Now
now
pricing
pricing
is
is
an
an
important
important
thing
thing
to
to
consider,
consider
but
but
the
the
whole
whole
reason
reason
you
you
would
would
use
use
a
a
framework
framework
like
like
Amplify
amplify
or
or
Firebase
firebase
in
in
the
the
first
first
place
place
is
is
to
to
increase
increase
the
the
speed
speed
and
and
flexibility
flexibility
of
of
development.
development
So
so
what
what
I've
i've
done
done
here
here
is
is
built
built
a
a
little
little
to
to
do
do
app
app
that
that
has
has
user
user
authentication
authentication
and
and
a
a
real
real
time
time
to
to
do
do
list.
list
It's
it's
built
built
with
with
Svelte
svelte
3,
3
and
and
we'll
we'll
just
just
use
use
it
it
to
to
compare
compare
the
the
developer
developer
experience
experience
between
between
both
both
platforms.
platforms
We'll
we'll
go
go
ahead
ahead
and
and
start
start
with
with
Amplify.
amplify
So
so
at
at
this
this
point,
point
you
you
need
need
to
to
have
have
an
an
AWS
aws
developer
developer
account
account
and
and
also
also
the
the
Amplify
amplify
CLI
cli
installed
installed
on
on
your
your
system.
system
From
from
there,
there
we'll
we'll
run
run
amplify
amplify
init,
init
which
which
will
will
set
set
up
up
a
a
project
project
in
in
our
our
working
working
directory.
directory
That'll
that'll
ask
ask
us
us
a
a
series
series
of
of
basic
basic
questions,
questions
and
and
it
it
also
also
gives
gives
us
us
the
the
option
option
to
to
set
set
up
up
amplify
amplify
with
with
a
a
popular
popular
JavaScript
javascript
framework.
framework
But
but
we'll
we'll
just
just
go
go
ahead
ahead
and
and
select
select
none
none
for
for
vanilla
vanilla
JS.
js
That'll
that'll
take
take
a
a
minute
minute
to
to
complete,
complete
and
and
then
then
when
when
it's
it's
done,
done
it
it
will
will
create
create
this
this
Amplify
amplify
directory
directory
in
in
the
the
root
root
of
of
the
the
project.
project
And
and
that
that
just
just
contains
contains
a
a
reference
reference
to
to
all
all
of
of
the
the
AWS
aws
resources
resources
that
that
we're
we're
using
using
in
in
this
this
project.
project
Now
now
we
we
can
can
connect
connect
authentication
authentication
to
to
this
this
app
app
by
by
running
running
amplify
amplify
add
add
auth.
auth
That'll
that'll
give
give
us
us
a
a
few
few
different
different
options
options
here,
here
but
but
we'll
we'll
go
go
with
with
the
the
most
most
simple
simple
use
use
case
case
of
of
just
just
email
email
password
password
authentication.
authentication
And
and
once
once
we
we
selected
selected
those
those
options,
options
we
we
can
can
go
go
ahead
ahead
and
and
run
run
amplify
amplify
push.
push
This
this
will
will
take
take
all
all
the
the
resources
resources
that
that
we
we
have
have
staged
staged
locally
locally
for
for
AWS
aws
and
and
then
then
actually
actually
allocate
allocate
them
them
in
in
the
the
cloud.
cloud
In
in
this
this
case,
case
user
user
authentication
authentication
is
is
handled
handled
by
by
an
an
AWS
aws
service
service
called
called
Cognito.
cognito
If
if
we
we
go
go
to
to
the
the
AWS
aws
console,
console
you'll
you'll
see
see
a
a
user
user
pool
pool
based
based
on
on
the
the
app
app
that
that
you
you
just
just
created.
created
And
and
inside
inside
of
of
here,
here
you'll
you'll
find
find
all
all
kinds
kinds
of
of
different
different
configuration
configuration
options.
options
And
and
this
this
is
is
an
an
area
area
where
where
AWS
aws
has
has
a
a
big
big
advantage
advantage
over
over
Firebase
firebase
in
in
terms
terms
of
of
flexibility
flexibility
and
and
customization.
customization
It
it
allows
allows
you
you
to
to
do
do
things
things
like
like
multifactor
multifactor
auth
auth
by
by
sending
sending
a
a
text
text
message
message
or
or
email
email
to
to
the
the
user
user
with
with
a
a
special
special
code
code
that
that
they
they
need
need
to
to
verify.
verify
And
and
you
you
can
can
also
also
set
set
up
up
custom
custom
attributes
attributes
on
on
the
the
user
user
authentication
authentication
record.
record
And
and
you
you
also
also
have
have
additional
additional
triggers
triggers
that
that
you
you
can
can
use
use
for
for
serverless
serverless
code.
code
In
in
Firebase,
firebase
you
you
can
can
only
only
trigger
trigger
when
when
a
a
user
user
is
is
created
created
or
or
deleted,
deleted
but
but
with
with
Cognito,
cognito
you
you
have
have
additional
additional
places
places
that
that
you
you
can
can
hook
hook
in
in
serverless
serverless
code.
code
Now
now
if
if
we
we
switch
switch
over
over
to
to
the
the
Firebase
firebase
dashboard,
dashboard
you'll
you'll
find
find
that
that
things
things
are
are
a
a
lot
lot
more
more
simplified.
simplified
Things
things
are
are
generally
generally
faster
faster
and
and
easier
easier
to
to
set
set
up,
up
but
but
they
they
are
are
less
less
flexible
flexible
by
by
comparison.
comparison
For
for
example,
example
if
if
we
we
wanted
wanted
to
to
set
set
up
up
passwordless
passwordless
authentication,
authentication
we
we
can
can
just
just
do
do
that
that
by
by
clicking
clicking
a
a
button,
button
whereas
whereas
on
on
AWS
aws
we
we
can
can
do
do
that
that
as
as
well,
well
but
but
we'd
we'd
have
have
to
to
set
set
up
up
several
several
Lambda
lambda
functions
functions
to
to
make
make
it
it
happen.
happen
Now
now
Now
now
once
once
we
we
have
have
the
the
initial
initial
configuration
configuration
done,
done
the
the
code
code
for
for
both
both
platforms
platforms
looks
looks
very
very
similar.
similar
On
on
my
my
AWS
aws
Amplify
amplify
branch,
branch
I
i
had
had
to
to
switch
switch
over
over
to
to
webpack
webpack
back
back
and
and
Svelte
svelte
because
because
apparently
apparently
it
it
doesn't
doesn't
work
work
with
with
roll
roll
up
up
currently.
currently
And
and
just
just
a
a
quick
quick
side
side
note
note
here,
here
both
both
Amplify
amplify
and
and
Firebase
firebase
will
will
add
add
quite
quite
a
a
bit
bit
of
of
JavaScript
javascript
to
to
your
your
final
final
bundle
bundle
size.
size
For
for
Firebase
firebase
with
with
user
user
authentication
authentication
and
and
Firestore,
firestore
you'll
you'll
be
be
looking
looking
at
at
around
around
500
500
kilobytes,
kilobytes
and
and
AWS
aws
with
with
AppSync
appsync
and
and
GraphQL
graphql
is
is
close
close
to
to
a
a
full
full
megabyte.
megabyte
In
in
the
the
main
main
JS
js
file
file
in
in
Svelte,
svelte
I'm
i'm
going
going
to
to
import
import
Amplify
amplify
from
from
Amplify
amplify
Core
core
and
and
then
then
I'm
i'm
going
going
to
to
call
call
configure
configure
on
on
it
it
with
with
our
our
configuration
configuration
details
details
that
that
were
were
automatically
automatically
generated
generated
by
by
the
the
DLI.
dli
From
from
there,
there
I'll
i'll
just
just
go
go
into
into
the
the
app
app
component,
component
and
and
then
then
when
when
this
this
component
component
is
is
mounted,
mounted
I'll
i'll
go
go
ahead
ahead
and
and
call
call
auth
auth
current
current
user
user
to
to
see
see
if
if
the
the
current
current
user
user
is
is
logged
logged
in.
in
So
so
just
just
one
one
line
line
of
of
code
code
to
to
check
check
if
if
the
the
user's
user's
logged
logged
in.
in
And
and
then
then
if
if
we
we
want
want
to
to
log
log
in
in
with
with
email
email
and
and
password,
password
we
we
can
can
call
call
auth
auth
sign
sign
in
in
with
with
the
the
username
username
and
and
password.
password
And
and
that's
that's
all
all
it
it
takes
takes
to
to
get
get
a
a
user
user
signed
signed
in,
in
and
and
then
then
we
we
can
can
set
set
that
that
user
user
as
as
the
the
user
user
property
property
on
on
this
this
component.
component
Now
now
if
if
we
we
click
click
the
the
login
login
button,
button
it's
it's
going
going
to
to
log
log
us
us
in
in
with
with
AWS
aws
Cognito,
cognito
and
and
then
then
it'll
it'll
show
show
our
our
username
username
here
here
in
in
the
the
UI.
ui
And
and
I
i
don't
don't
think
think
it
it
gets
gets
any
any
easier
easier
than
than
that
that
as
as
far
far
as
as
user
user
authentication
authentication
goes.
goes
Now
now
if
if
we
we
switch
switch
over
over
to
to
our
our
Firebase
firebase
branch,
branch
we
we
have
have
the
the
same
same
basic
basic
setup
setup
Here,
here
we
we
initialize
initialize
the
the
SDK
sdk
with
with
our
our
credentials
credentials
from
from
the
the
Firebase
firebase
console.
console
And
and
then
then
from
from
there,
there
we'll
we'll
go
go
into
into
the
the
main
main
app
app
component.
component
And
and
you'll
you'll
notice
notice
that
that
the
the
code
code
is
is
almost
almost
identical
identical
to
to
AWS
aws
Amplify.
amplify
We're
we're
simply
simply
calling
calling
auth
auth
current
current
user
user
to
to
get
get
the
the
current
current
user,
user
and
and
then
then
we
we
say
say
sign
sign
in
in
with
with
email
email
and
and
password
password
to
to
sign
sign
the
the
user
user
in.
in
Now
now
the
the
point
point
I'm
i'm
trying
trying
to
to
make
make
here
here
is
is
that
that
both
both
SDKs
sdks
provide
provide
well
well
organized
organized
JavaScript
javascript
libraries
libraries
that
that
help
help
you
you
get
get
things
things
done
done
with
with
very
very
few
few
lines
lines
of
of
code.
code
But
but
now
now
I
i
wanna
wanna
switch
switch
gears
gears
here
here
to
to
real
real
time
time
data,
data
and
and
that's
that's
where
where
things
things
really
really
start
start
to
to
get
get
interesting.
interesting
I'll
i'll
go
go
ahead
ahead
and
and
start
start
by
by
showing
showing
you
you
the
the
Firebase
firebase
example.
example
We're
we're
here
here
in
in
the
the
Firestore
firestore
database,
database
and
and
we're
we're
creating
creating
a
a
document
document
in
in
a
a
to
to
dos
dos
collection.
collection
The
the
user
user
needs
needs
to
to
be
be
able
able
to
to
view
view
this
this
data
data
and
and
update
update
the
the
data
data
and
and
also
also
stay
stay
up
up
to
to
date
date
with
with
any
any
changes
changes
that
that
happen
happen
to
to
it
it
in
in
real
real
time
time
across
across
all
all
clients.
clients
And
and
that's
that's
a
a
very
very
challenging
challenging
requirement
requirement
to
to
not
not
only
only
implement,
implement
but
but
also
also
to
to
do
do
at
at
scale.
scale
If
if
we
we
look
look
at
at
the
the
app
app
itself,
itself
the
the
user
user
should
should
be
be
able
able
to
to
tap
tap
the
the
smart
smart
complete
complete
button
button
and
and
then
then
see
see
the
the
data
data
updated
updated
in
in
the
the
UI
ui
and
and
then
then
also
also
in
in
the
the
back
back
end
end
as
as
well.
well
To
to
implement
implement
this
this
code,
code
we'll
we'll
go
go
ahead
ahead
and
and
import
import
Firestore,
firestore
and
and
then
then
we'll
we'll
make
make
a
a
reference
reference
to
to
that
that
to
to
do's
do's
collection
collection
in
in
the
the
database.
database
To
to
query
query
the
the
collection,
collection
we
we
just
just
call
call
on
on
snapshot,
snapshot
and
and
that
that
will
will
give
give
us
us
a
a
callback
callback
function
function
that
that
will
will
listen
listen
to
to
any
any
changes
changes
to
to
that
that
collection
collection
in
in
real
real
time.
time
It's
it's
going
going
to
to
give
give
us
us
a
a
snapshot
snapshot
that
that
contains
contains
an
an
array
array
of
of
the
the
document
document
data,
data
And
and
then
then
we
we
can
can
map
map
that
that
snapshot
snapshot
down
down
to
to
an
an
actual
actual
JavaScript
javascript
object
object
that
that
we
we
can
can
show
show
here
here
in
in
our
our
front
front
end
end
application.
application
And
and
that's
that's
actually
actually
all
all
it
it
takes
takes
to
to
listen
listen
to
to
a
a
real
real
time
time
stream
stream
of
of
data.
data
Now
now
if
if
we
we
want
want
to
to
mutate
mutate
or
or
update
update
a
a
specific
specific
to
to
do
do
item,
item
we
we
just
just
make
make
a
a
reference
reference
to
to
its
its
location
location
in
in
the
the
database
database
and
and
then
then
we
we
call
call
update
update
on
on
that
that
reference
reference
with
with
the
the
new
new
data
data
that
that
we
we
want
want
to
to
send.
send
In
in
our
our
case,
case
we
we
want
want
to
to
update
update
a
a
to
to
do
do
item
item
to
to
complete,
complete
which
which
we
we
can
can
do
do
with
with
a
a
single
single
line
line
of
of
code.
code
So
so
with
with
Firestore,
firestore
you
you
get
get
simplicity
simplicity
without
without
any
any
boilerplate
boilerplate
code.
code
That
that
makes
makes
it
it
really
really
easy
easy
to
to
work
work
with,
with
especially
especially
if
if
you're
you're
building
building
complex
complex
real
real
time
time
features
features
because
because
all
all
of
of
the
the
difficult
difficult
real
real
time
time
stuff
stuff
is
is
done
done
for
for
you
you
automatically
automatically
under
under
the
the
hood.
hood
But
but
the
the
major
major
drawback
drawback
is
is
that
that
you're
you're
stuck
stuck
working
working
with
with
a
a
single
single
NoSQL
nosql
database
database
that
that
may
may
present
present
challenges
challenges
for
for
data
data
modeling
modeling
and
and
can
can
also
also
be
be
hard
hard
to
to
migrate
migrate
into
into
or
or
migrate
migrate
out
out
of.
of
Let's
let's
go
go
ahead
ahead
and
and
switch
switch
back
back
to
to
Amplify
amplify
to
to
see
see
how
how
this
this
looks
looks
with
with
GraphQL
graphql
and
and
AppSync.
appsync
We're
we're
going
going
to
to
first
first
run
run
amplify
amplify
add
add
API
api
to
to
provision
provision
these
these
resources
resources
in
in
the
the
project.
project
We'll
we'll
choose
choose
GraphQL
graphql
so
so
we
we
can
can
use
use
real
real
time
time
features,
features
then
then
make
make
sure
sure
to
to
choose
choose
API
api
for
for
the
the
authentication
authentication
type.
type
Now
now
with
with
GraphQL,
graphql
there's
there's
a
a
lot
lot
of
of
boilerplate
boilerplate
code,
code
But
but
the
the
nice
nice
thing
thing
about
about
the
the
Amplify
amplify
CLI
cli
is
is
that
that
it's
it's
going
going
to
to
walk
walk
you
you
through
through
that
that
code
code
and
and
generate
generate
most
most
of
of
it
it
for
for
you.
you
Conveniently,
conveniently
the
the
default
default
Schema
schema
matches
matches
the
the
data
data
type
type
that
that
we
we
already
already
have
have
set
set
up
up
in
in
our
our
front
front
end
end
app.
app
I'm
i'm
just
just
going
going
to
to
add
add
a
a
Boolean
boolean
property
property
called
called
complete.
complete
From
from
there,
there
you
you
can
can
run
run
amplify
amplify
push,
push
and
and
then
then
it
it
will
will
ask
ask
you
you
if
if
you
you
want
want
to
to
automatically
automatically
generate
generate
the
the
GraphQL
graphql
API.
api
Select
select
yes.
yes
And
and
in
in
this
this
demo,
demo
I'll
i'll
select
select
JavaScript
javascript
as
as
the
the
language.
language
Go
go
ahead
ahead
and
and
select
select
yes
yes
to
to
everything
everything
else,
else
and
and
it's
it's
going
going
to
to
finish
finish
up
up
by
by
giving
giving
you
you
a
a
GraphQL
graphql
API
api
endpoint
endpoint
as
as
well
well
as
as
an
an
API
api
key.
key
Then
then
head
head
over
over
to
to
the
the
AppSync
appsync
console,
console
and
and
you'll
you'll
find
find
a
a
Schema
schema
has
has
been
been
generated
generated
and
and
uploaded
uploaded
to
to
the
the
cloud
cloud
for
for
you.
you
This
this
is
is
really
really
cool
cool
because
because
you
you
now
now
have
have
a
a
GraphQL
graphql
API
api
deployed
deployed
that
that
can
can
be
be
accessed
accessed
by
by
any
any
client
client
that
that
has
has
that
that
API
api
key.
key
And
and
it
it
took
took
almost
almost
no
no
effort
effort
on
on
our
our
part,
part
but
but
the
the
API
api
itself
itself
is
is
pretty
pretty
useless
useless
unless
unless
there's
there's
a
a
back
back
end
end
data
data
source
source
attached
attached
to
to
it.
it
Amplify
amplify
will
will
automatically
automatically
set
set
up
up
an
an
instance
instance
of
of
DynamoDB,
dynamodb
which
which
is
is
a
a
NoSQL
nosql
database
database
that
that
is
is
roughly
roughly
equivalent
equivalent
to
to
MongoDB
mongodb
or
or
Firestore.
firestore
Now
now
we
we
can
can
go
go
into
into
the
the
database,
database
and
and
we'll
we'll
go
go
ahead
ahead
and
and
create
create
a
a
new
new
item
item
that
that
matches
matches
the
the
schema
schema
that
that
we
we
have
have
set
set
up
up
in
in
GraphQL.
graphql
Now
now
if
if
we
we
go
go
back
back
to
to
our
our
source
source
code,
code
you'll
you'll
see
see
that
that
there's
there's
an
an
automatically
automatically
generated
generated
GraphQL
graphql
folder
folder
in
in
the
the
source
source
directory.
directory
This
this
contains
contains
all
all
the
the
boilerplate
boilerplate
code
code
that
that
you
you
need
need
for
for
GraphQL
graphql
for
for
things
things
like
like
mutations,
mutations
queries,
queries
and
and
subscriptions.
subscriptions
Now
now
there's
there's
a
a
few
few
different
different
ways
ways
we
we
could
could
query
query
this
this
data
data
with
with
GraphQL,
graphql
QL.
ql
But
but
the
the
gold
gold
standard
standard
way
way
is
is
to
to
use
use
the
the
Apollo
apollo
client.
client
So
so
we'll
we'll
go
go
ahead
ahead
and
and
install
install
AWS
aws
AppSync
appsync
and
and
GraphQL
graphql
tag
tag
in
in
this
this
project.
project
And
and
then
then
I'm
i'm
creating
creating
a
a
new
new
JavaScript
javascript
file
file
called
called
client
client
dot
dot
JS
js
that
that
is
is
just
just
here
here
to
to
initialize
initialize
AWS
aws
AppSync.
appsync
From
from
there,
there
we'll
we'll
go
go
into
into
our
our
app
app
component
component
and
and
then
then
we'll
we'll
import
import
that
that
client,
client
as
as
well
well
as
as
the
the
list
list
to
to
do's
do's
query
query
from
from
the
the
GraphQL
graphql
directory.
directory
Now
now
we
we
can
can
make
make
a
a
query
query
for
for
the
the
actual
actual
data
data
in
in
the
the
database
database
by
by
saying
saying
GraphQL
graphql
list
list
to
to
do's,
do's
and
and
that
that
will
will
return
return
a
a
promise
promise
that
that
resolves
resolves
into
into
the
the
actual
actual
data
data
from
from
the
the
database
database
which
which
will
will
be
be
an
an
array
array
of
of
the
the
to
to
do
do
items.
items
So
so
that
that
provides
provides
a
a
relatively
relatively
easy
easy
way
way
to
to
fetch
fetch
the
the
data,
data
but
but
at
at
this
this
Point,
point
it's
it's
not
not
real
real
time.
time
If
if
the
the
user
user
clicks
clicks
mark
mark
complete,
complete
it's
it's
going
going
to
to
update
update
the
the
item
item
in
in
the
the
database,
database
but
but
it's
it's
not
not
going
going
to
to
actually
actually
notify
notify
us
us
of
of
that
that
change.
change
We'll
we'll
go
go
ahead
ahead
and
and
run
run
the
the
mutation
mutation
as
as
well
well
as
as
the
the
subscription
subscription
to
to
real
real
time
time
updates
updates
in
in
this
this
to
to
do
do
component.
component
We'll
we'll
need
need
the
the
update
update
to
to
do
do
mutation
mutation
as
as
well
well
as
as
the
the
on
on
update
update
to
to
do
do
subscription.
subscription
And
and
And
and
then
then
to
to
update
update
the
the
data,
data
we'll
we'll
call
call
client
client
mutate
mutate
and
and
then
then
pass
pass
in
in
an
an
object
object
that
that
contains
contains
the
the
data
data
that
that
we
we
wanna
wanna
change
change
on
on
that
that
database
database
record
record
in
in
DynamoDB.
dynamodb
Now
now
that's
that's
going
going
to
to
take
take
care
care
of
of
the
the
update,
update
but
but
we
we
still
still
want
want
to
to
listen
listen
to
to
real
real
time
time
changes.
changes
To
to
make
make
that
that
happen,
happen
we'll
we'll
go
go
ahead
ahead
and
and
set
set
up
up
a
a
subscription
subscription
here
here
that
that
listens
listens
to
to
the
the
update
update
on
on
this
this
to
to
do
do
item.
item
We'll
we'll
go
go
ahead
ahead
and
and
call
call
client
client
subscribe
subscribe
and
and
then
then
point
point
it
it
to
to
a
a
query
query
of
of
the
the
on
on
update
update
to
to
do
do
subscription.
subscription
And
and
then
then
we'll
we'll
call
call
subscribe
subscribe
on
on
that,
that
which
which
will
will
give
give
us
us
access
access
to
to
the
the
data
data
whenever
whenever
it
it
changes.
changes
Once
once
we
we
have
have
access
access
to
to
that
that
new
new
data,
data
we
we
can
can
just
just
go
go
ahead
ahead
and
and
update
update
the
the
property
property
on
on
this
this
component.
component
So
so
now
now
when
when
this
this
mutation
mutation
runs
runs
on
on
the
the
back
back
end,
end
it's
it's
going
going
to
to
update
update
the
the
UI
ui
on
on
the
the
front
front
end.
end
Now
now
Now
now
I
i
probably
probably
would
would
not
not
build
build
an
an
app
app
like
like
this
this
in
in
the
the
real
real
world,
world
but
but
I
i
just
just
want
want
to
to
give
give
you
you
an
an
idea
idea
of
of
what
what
it
it
takes
takes
to
to
get
get
things
things
set
set
up
up
with
with
real
real
time
time
data
data
in
in
AWS
aws
AppSync.
appsync
GraphQL
graphql
is
is
a
a
really
really
amazing
amazing
tool,
tool
but
but
in
in
a
a
lot
lot
of
of
cases,
cases
it
it
might
might
just
just
be
be
overkill.
overkill
We
we
have
have
a
a
lot
lot
of
of
complexity
complexity
in
in
this
this
app,
app
both
both
in
in
automatically
automatically
generated
generated
code
code
and
and
our
our
own
own
implementation
implementation
details
details
for
for
something
something
that
that
was
was
implemented
implemented
relatively
relatively
easily
easily
with
with
Firestore.
firestore
But,
but
again,
again
the
the
big
big
trade
trade
out
out
there
there
is
is
we
we
now
now
have
have
a
a
lot
lot
more
more
flexibility
flexibility
to
to
make
make
the
the
code
code
behave
behave
exactly
exactly
the
the
way
way
we
we
want
want
it
it
to.
to
I
i
want
want
to
to
finish
finish
things
things
off
off
by
by
saying
saying
that
that
both
both
platforms
platforms
are
are
awesome
awesome
in
in
their
their
own
own
ways,
ways
and
and
it's
it's
hard
hard
for
for
me
me
to
to
imagine
imagine
going
going
back
back
to
to
building
building
a
a
back
back
end
end
from
from
scratch.
scratch
These
these
services
services
will
will
save
save
you
you
time
time
and
and
money
money
and
and
help
help
you
you
get
get
your
your
product
product
in
in
front
front
of
of
customers
customers
faster.
faster
Now
now
to
to
sum
sum
up
up
the
the
comparison,
comparison
I
i
would
would
say
say
that
that
pricing
pricing
is
is
almost
almost
equivalent.
equivalent
One
one
might
might
be
be
cheaper
cheaper
than
than
the
the
other
other
depending
depending
on
on
how
how
you
you
use
use
it.
it
I
i
would
would
say
say
Firebase
firebase
is
is
generally
generally
easier
easier
to
to
use,
use
and
and
there
there
are
are
fewer
fewer
decisions
decisions
to
to
make
make
when
when
getting
getting
things
things
configured.
configured
And
and
that's
that's
especially
especially
true
true
when
when
you
you
compare
compare
GraphQL
graphql
and
and
Dynamo
dynamo
DB
db
to
to
Firestore.
firestore
But
but
on
on
the
the
other
other
hand,
hand
AWS
aws
is
is
superior
superior
when
when
it
it
comes
comes
to
to
flexibility.
flexibility
There
there
are
are
more
more
knobs
knobs
to
to
turn
turn
that
that
you
you
can
can
use
use
to
to
customize
customize
the
the
experience
experience
specific
specific
to
to
your
your
needs.
needs
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
And
and
if
if
you've
you've
experience
experience
with
with
both
both
Amplify
amplify
and
and
Firebase?
firebase
I'd
i'd
really
really
like
like
to
to
hear
hear
your
your
thoughts
thoughts
in
in
the
the
comments.
comments
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
talk
talk
to
to
you
you
soon.
soon
It
it
might
might
be
be
a
a
tumor.
tumor
It's
it's
not
not
A
a
tumor.
tumor
Not
not
a
a
tumor
tumor
at
at
all.
all
success
The speakers discuss the benefits of using both passenger car and truck platforms for app development, including a simpler back-end architecture and integration with APIs. They also compare Amplify to AWS and Azure, highlighting their superiority in flexibility and customization. The speakers explain how to use Amplify for authentication and real-time data updates, as well as how to update data in a graphite format and create new items. They also discuss the benefits of using GraphQL and App clarity, including saving time and money. The goal is to share customer thoughts on both platforms and mention a desire to hear feedback on both.
Firebase vs AWS Amplify
Today, we're going to compare Firebase to AWS Amplify, both of which are platforms that make it easy for app developers to manage and scale their cloud infrastructure. In In this video, we'll build a mini JavaScript app on both platforms so we can compare feature parity, the developer experience, and pricing. It's Showtime. If you're new here, like and subscribe, and check out the full write up on Fireship IO. Now for full disclosure, I am a huge fan of Firebase, and I've been using it for many years, while AWS Amplify was only released in 2018. The first major difference to point out is that Amplify will run on Amazon's cloud infrastructure, while Firebase will run on Google's. So there will be some degree of vendor lock in there, but that's just the trade off you make if you want a dramatically simplified back end. You are mine now. You belong to me. You're not gonna have your mommy slam Let's start by looking at some of the core features offered by both platforms. And I should point out that this isn't a one is better than the other type of Harrison, it's more about using the right tool for the job. And the first thing you'll need to know is whether or not your front end framework is supported. You'll find official support for iOS, Android, and the web. And with Amplify, you'll also find official support for React Native as well as React Web, Angular, and Vue. At the time of this video, it does not support Flutter or bundling with Rollup. But there are open issues for those, so they may be supported in the future. With Firebase, you do have official support for Flutter, and Angular and Vue both have official libraries under their mono repos for Firebase, and there are some really good community maintained projects for React and React Native. Now let's take a look at the core features of these platforms starting with the things that they share in common. They both provide user authentication, analytics, a way to manage real time data, push notifications, file storage, serverless functions and web hosting. We'll look at all these 1 by 1 throughout the video, but what does Amplify offer that Firebase does not? Come with me if you want to live. One of the first things I noticed was the ability to set up dedicated environments for development and production. You can do this in Firebase as well by just setting up multiple projects, but it's a little more streamlined And another thing that's more streamlined is setting up your continuous deployment. Amplify takes a very similar approach to Netlify where you connect your hosting account to a GitHub Though, then when you commit your code, it just automatically deploys that code to the hosting account. Now in all fairness, you can do this with Google Cloud Build and Firebase as well. There's just a few more configuration steps to get it set up. Another unique feature of Amplify is its integration with GraphQL, which we'll look at closely in a few minutes. And the last thing I'll point out is its integration with Sumerian, which might be useful if you're building an augmented or virtual reality app. So that's pretty cool, but what does Firebase have that Amplify does not? Case of the chopper. The first and most interesting thing is a dedicated database, and we'll compare that in detail to Amplify's GraphQL setup. And another feature in Firebase that I find to be very powerful is callable functions. These are serverless functions that you can call with the auth context from your front end, so you can easily tell in your back end code if a user is logged in or not. And that's a lot easier than setting up an API gateway or just writing the back end authorization logic from scratch. In Firebase, you also have a few tools for quality control, things like Crashlytics, performance and test lab. And then you have quite a few more features that are built on top of your analytics, things like predictions and remote config, just to name a few. And you also have ML Kit, which makes it really easy to implement machine learning features both in the Cloud and on device. Now, let's go ahead and switch gears to pricing. If you've ever shopped on Amazon.com, you'll know that they push prices to the absolute bottom. That's just built into Amazon's DNA and culture and we can see that with AWS Pricing going back 10 years in the past. We'll find a price of 15¢ per gigabyte in an s three storage bucket. And if we fast forward to the present day, it's It's only 2.3¢ per gigabyte. That's a price reduction of 85% over the course of 10 years. Remember, we are not undersold. We will not be undersold. We cannot be undersold. The home appliance But it's a little more complex than that. Both platforms have extremely generous pricing models and they both start out on a free tier, so you don't really pay for anything until you have a decent number of active users. And what you'll find on most services is that AWS is just slightly cheaper than GCP. For example, a gigabyte of storage is 2.3¢ on AWS and 2.6 on Firebase. But Firebase has a couple of services that are always free, such as user authentication and push notifications. On AWS, you pay about Half a penny for each monthly active user beyond 50,000 monthly active users. But the most interesting pricing comes into play when we start talking about databases and real time listeners to that data. With Firestore, you're billed for your reads and writes to the database. And all the real time syncing just happens automatically, so you don't really have to worry much about that as far as pricing is concerned. On On AWS, you have a service called AppSync, which will connect automatically to a Dynamo DB instance. And with AppSync, you pay $4 per 1,000,000 query or write operations. But with Firestore, that would only be 60¢ if they're read operations or a dollar 80 if they were write operations. In addition, with AppSync, you have additional costs associated with the actual back end database itself, and they also calculate billing in chunks of 5 kilobytes. So if you have a document that's a 100 kilobytes, That would equal 50 document read units. It is hard to compare these things side by side, but this appears to be an area where Firestore would be significantly less expensive as an app scales up. And the last thing I'll mention on pricing is that AWS does have a solid edge when it comes to serverless, costing 20¢ per 1,000,000 function invocations versus 40¢ on Firebase. Now pricing is an important thing to consider, but the whole reason you would use a framework like Amplify or Firebase in the first place is to increase the speed and flexibility of development. So what I've done here is built a little to do app that has user authentication and a real time to do list. It's built with Svelte 3, and we'll just use it to compare the developer experience between both platforms. We'll go ahead and start with Amplify. So at this point, you need to have an AWS developer account and also the Amplify CLI installed on your system. From there, we'll run amplify init, which will set up a project in our working directory. That'll ask us a series of basic questions, and it also gives us the option to set up amplify with a popular JavaScript framework. But we'll just go ahead and select none for vanilla JS. That'll take a minute to complete, and then when it's done, it will create this Amplify directory in the root of the project. And that just contains a reference to all of the AWS resources that we're using in this project. Now we can connect authentication to this app by running amplify add auth. That'll give us a few different options here, but we'll go with the most simple use case of just email password authentication. And once we selected those options, we can go ahead and run amplify push. This will take all the resources that we have staged locally for AWS and then actually allocate them in the cloud. In this case, user authentication is handled by an AWS service called Cognito. If we go to the AWS console, you'll see a user pool based on the app that you just created. And inside of here, you'll find all kinds of different configuration options. And this is an area where AWS has a big advantage over Firebase in terms of flexibility and customization. It allows you to do things like multifactor auth by sending a text message or email to the user with a special code that they need to verify. And you can also set up custom attributes on the user authentication record. And you also have additional triggers that you can use for serverless code. In Firebase, you can only trigger when a user is created or deleted, but with Cognito, you have additional places that you can hook in serverless code. Now if we switch over to the Firebase dashboard, you'll find that things are a lot more simplified. Things are generally faster and easier to set up, but they are less flexible by comparison. For example, if we wanted to set up passwordless authentication, we can just do that by clicking a button, whereas on AWS we can do that as well, but we'd have to set up several Lambda functions to make it happen. Now Now once we have the initial configuration done, the code for both platforms looks very similar. On my AWS Amplify branch, I had to switch over to webpack back and Svelte because apparently it doesn't work with roll up currently. And just a quick side note here, both Amplify and Firebase will add quite a bit of JavaScript to your final bundle size. For Firebase with user authentication and Firestore, you'll be looking at around 500 kilobytes, and AWS with AppSync and GraphQL is close to a full megabyte. In the main JS file in Svelte, I'm going to import Amplify from Amplify Core and then I'm going to call configure on it with our configuration details that were automatically generated by the DLI. From there, I'll just go into the app component, and then when this component is mounted, I'll go ahead and call auth current user to see if the current user is logged in. So just one line of code to check if the user's logged in. And then if we want to log in with email and password, we can call auth sign in with the username and password. And that's all it takes to get a user signed in, and then we can set that user as the user property on this component. Now if we click the login button, it's going to log us in with AWS Cognito, and then it'll show our username here in the UI. And I don't think it gets any easier than that as far as user authentication goes. Now if we switch over to our Firebase branch, we have the same basic setup Here, we initialize the SDK with our credentials from the Firebase console. And then from there, we'll go into the main app component. And you'll notice that the code is almost identical to AWS Amplify. We're simply calling auth current user to get the current user, and then we say sign in with email and password to sign the user in. Now the point I'm trying to make here is that both SDKs provide well organized JavaScript libraries that help you get things done with very few lines of code. But now I wanna switch gears here to real time data, and that's where things really start to get interesting. I'll go ahead and start by showing you the Firebase example. We're here in the Firestore database, and we're creating a document in a to dos collection. The user needs to be able to view this data and update the data and also stay up to date with any changes that happen to it in real time across all clients. And that's a very challenging requirement to not only implement, but also to do at scale. If we look at the app itself, the user should be able to tap the smart complete button and then see the data updated in the UI and then also in the back end as well. To implement this code, we'll go ahead and import Firestore, and then we'll make a reference to that to do's collection in the database. To query the collection, we just call on snapshot, and that will give us a callback function that will listen to any changes to that collection in real time. It's going to give us a snapshot that contains an array of the document data, And then we can map that snapshot down to an actual JavaScript object that we can show here in our front end application. And that's actually all it takes to listen to a real time stream of data. Now if we want to mutate or update a specific to do item, we just make a reference to its location in the database and then we call update on that reference with the new data that we want to send. In our case, we want to update a to do item to complete, which we can do with a single line of code. So with Firestore, you get simplicity without any boilerplate code. That makes it really easy to work with, especially if you're building complex real time features because all of the difficult real time stuff is done for you automatically under the hood. But the major drawback is that you're stuck working with a single NoSQL database that may present challenges for data modeling and can also be hard to migrate into or migrate out of. Let's go ahead and switch back to Amplify to see how this looks with GraphQL and AppSync. We're going to first run amplify add API to provision these resources in the project. We'll choose GraphQL so we can use real time features, then make sure to choose API for the authentication type. Now with GraphQL, there's a lot of boilerplate code, But the nice thing about the Amplify CLI is that it's going to walk you through that code and generate most of it for you. Conveniently, the default Schema matches the data type that we already have set up in our front end app. I'm just going to add a Boolean property called complete. From there, you can run amplify push, and then it will ask you if you want to automatically generate the GraphQL API. Select yes. And in this demo, I'll select JavaScript as the language. Go ahead and select yes to everything else, and it's going to finish up by giving you a GraphQL API endpoint as well as an API key. Then head over to the AppSync console, and you'll find a Schema has been generated and uploaded to the cloud for you. This is really cool because you now have a GraphQL API deployed that can be accessed by any client that has that API key. And it took almost no effort on our part, but the API itself is pretty useless unless there's a back end data source attached to it. Amplify will automatically set up an instance of DynamoDB, which is a NoSQL database that is roughly equivalent to MongoDB or Firestore. Now we can go into the database, and we'll go ahead and create a new item that matches the schema that we have set up in GraphQL. Now if we go back to our source code, you'll see that there's an automatically generated GraphQL folder in the source directory. This contains all the boilerplate code that you need for GraphQL for things like mutations, queries, and subscriptions. Now there's a few different ways we could query this data with GraphQL, QL. But the gold standard way is to use the Apollo client. So we'll go ahead and install AWS AppSync and GraphQL tag in this project. And then I'm creating a new JavaScript file called client dot JS that is just here to initialize AWS AppSync. From there, we'll go into our app component and then we'll import that client, as well as the list to do's query from the GraphQL directory. Now we can make a query for the actual data in the database by saying GraphQL list to do's, and that will return a promise that resolves into the actual data from the database which will be an array of the to do items. So that provides a relatively easy way to fetch the data, but at this Point, it's not real time. If the user clicks mark complete, it's going to update the item in the database, but it's not going to actually notify us of that change. We'll go ahead and run the mutation as well as the subscription to real time updates in this to do component. We'll need the update to do mutation as well as the on update to do subscription. And And then to update the data, we'll call client mutate and then pass in an object that contains the data that we wanna change on that database record in DynamoDB. Now that's going to take care of the update, but we still want to listen to real time changes. To make that happen, we'll go ahead and set up a subscription here that listens to the update on this to do item. We'll go ahead and call client subscribe and then point it to a query of the on update to do subscription. And then we'll call subscribe on that, which will give us access to the data whenever it changes. Once we have access to that new data, we can just go ahead and update the property on this component. So now when this mutation runs on the back end, it's going to update the UI on the front end. Now Now I probably would not build an app like this in the real world, but I just want to give you an idea of what it takes to get things set up with real time data in AWS AppSync. GraphQL is a really amazing tool, but in a lot of cases, it might just be overkill. We have a lot of complexity in this app, both in automatically generated code and our own implementation details for something that was implemented relatively easily with Firestore. But, again, the big trade out there is we now have a lot more flexibility to make the code behave exactly the way we want it to. I want to finish things off by saying that both platforms are awesome in their own ways, and it's hard for me to imagine going back to building a back end from scratch. These services will save you time and money and help you get your product in front of customers faster. Now to sum up the comparison, I would say that pricing is almost equivalent. One might be cheaper than the other depending on how you use it. I would say Firebase is generally easier to use, and there are fewer decisions to make when getting things configured. And that's especially true when you compare GraphQL and Dynamo DB to Firestore. But on the other hand, AWS is superior when it comes to flexibility. There are more knobs to turn that you can use to customize the experience specific to your needs. I'm gonna go ahead and wrap things up there. And if you've experience with both Amplify and Firebase? I'd really like to hear your thoughts in the comments. Thanks for watching, and I will talk to you soon. It might be a tumor. It's not A tumor. Not a tumor at all.
The speakers discuss the benefits of using both passenger car and truck platforms for app development, including a simpler back-end architecture and integration with APIs. They also compare Amplify to AWS and Azure, highlighting their superiority in flexibility and customization. The speakers explain how to use Amplify for authentication and real-time data updates, as well as how to update data in a graphite format and create new items. They also discuss the benefits of using GraphQL and App clarity, including saving time and money. The goal is to share customer thoughts on both platforms and mention a desire to hear feedback on both.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Firebase vs AWS Amplify 
        and a small summary : The speakers discuss the benefits of using both passenger car and truck platforms for app development, including a simpler back-end architecture and integration with APIs. They also compare Amplify to AWS and Azure, highlighting their superiority in flexibility and customization. The speakers explain how to use Amplify for authentication and real-time data updates, as well as how to update data in a graphite format and create new items. They also discuss the benefits of using GraphQL and App clarity, including saving time and money. The goal is to share customer thoughts on both platforms and mention a desire to hear feedback on both.
        [/INST]
        
        Generate the video : Today, we're going to compare Firebase to AWS Amplify, both of which are platforms that make it easy for app developers to manage and scale their cloud infrastructure. In In this video, we'll build a mini JavaScript app on both platforms so we can compare feature parity, the developer experience, and pricing. It's Showtime. If you're new here, like and subscribe, and check out the full write up on Fireship IO. Now for full disclosure, I am a huge fan of Firebase, and I've been using it for many years, while AWS Amplify was only released in 2018. The first major difference to point out is that Amplify will run on Amazon's cloud infrastructure, while Firebase will run on Google's. So there will be some degree of vendor lock in there, but that's just the trade off you make if you want a dramatically simplified back end. You are mine now. You belong to me. You're not gonna have your mommy slam Let's start by looking at some of the core features offered by both platforms. And I should point out that this isn't a one is better than the other type of Harrison, it's more about using the right tool for the job. And the first thing you'll need to know is whether or not your front end framework is supported. You'll find official support for iOS, Android, and the web. And with Amplify, you'll also find official support for React Native as well as React Web, Angular, and Vue. At the time of this video, it does not support Flutter or bundling with Rollup. But there are open issues for those, so they may be supported in the future. With Firebase, you do have official support for Flutter, and Angular and Vue both have official libraries under their mono repos for Firebase, and there are some really good community maintained projects for React and React Native. Now let's take a look at the core features of these platforms starting with the things that they share in common. They both provide user authentication, analytics, a way to manage real time data, push notifications, file storage, serverless functions and web hosting. We'll look at all these 1 by 1 throughout the video, but what does Amplify offer that Firebase does not? Come with me if you want to live. One of the first things I noticed was the ability to set up dedicated environments for development and production. You can do this in Firebase as well by just setting up multiple projects, but it's a little more streamlined And another thing that's more streamlined is setting up your continuous deployment. Amplify takes a very similar approach to Netlify where you connect your hosting account to a GitHub Though, then when you commit your code, it just automatically deploys that code to the hosting account. Now in all fairness, you can do this with Google Cloud Build and Firebase as well. There's just a few more configuration steps to get it set up. Another unique feature of Amplify is its integration with GraphQL, which we'll look at closely in a few minutes. And the last thing I'll point out is its integration with Sumerian, which might be useful if you're building an augmented or virtual reality app. So that's pretty cool, but what does Firebase have that Amplify does not? Case of the chopper. The first and most interesting thing is a dedicated database, and we'll compare that in detail to Amplify's GraphQL setup. And another feature in Firebase that I find to be very powerful is callable functions. These are serverless functions that you can call with the auth context from your front end, so you can easily tell in your back end code if a user is logged in or not. And that's a lot easier than setting up an API gateway or just writing the back end authorization logic from scratch. In Firebase, you also have a few tools for quality control, things like Crashlytics, performance and test lab. And then you have quite a few more features that are built on top of your analytics, things like predictions and remote config, just to name a few. And you also have ML Kit, which makes it really easy to implement machine learning features both in the Cloud and on device. Now, let's go ahead and switch gears to pricing. If you've ever shopped on Amazon.com, you'll know that they push prices to the absolute bottom. That's just built into Amazon's DNA and culture and we can see that with AWS Pricing going back 10 years in the past. We'll find a price of 15¢ per gigabyte in an s three storage bucket. And if we fast forward to the present day, it's It's only 2.3¢ per gigabyte. That's a price reduction of 85% over the course of 10 years. Remember, we are not undersold. We will not be undersold. We cannot be undersold. The home appliance But it's a little more complex than that. Both platforms have extremely generous pricing models and they both start out on a free tier, so you don't really pay for anything until you have a decent number of active users. And what you'll find on most services is that AWS is just slightly cheaper than GCP. For example, a gigabyte of storage is 2.3¢ on AWS and 2.6 on Firebase. But Firebase has a couple of services that are always free, such as user authentication and push notifications. On AWS, you pay about Half a penny for each monthly active user beyond 50,000 monthly active users. But the most interesting pricing comes into play when we start talking about databases and real time listeners to that data. With Firestore, you're billed for your reads and writes to the database. And all the real time syncing just happens automatically, so you don't really have to worry much about that as far as pricing is concerned. On On AWS, you have a service called AppSync, which will connect automatically to a Dynamo DB instance. And with AppSync, you pay $4 per 1,000,000 query or write operations. But with Firestore, that would only be 60¢ if they're read operations or a dollar 80 if they were write operations. In addition, with AppSync, you have additional costs associated with the actual back end database itself, and they also calculate billing in chunks of 5 kilobytes. So if you have a document that's a 100 kilobytes, That would equal 50 document read units. It is hard to compare these things side by side, but this appears to be an area where Firestore would be significantly less expensive as an app scales up. And the last thing I'll mention on pricing is that AWS does have a solid edge when it comes to serverless, costing 20¢ per 1,000,000 function invocations versus 40¢ on Firebase. Now pricing is an important thing to consider, but the whole reason you would use a framework like Amplify or Firebase in the first place is to increase the speed and flexibility of development. So what I've done here is built a little to do app that has user authentication and a real time to do list. It's built with Svelte 3, and we'll just use it to compare the developer experience between both platforms. We'll go ahead and start with Amplify. So at this point, you need to have an AWS developer account and also the Amplify CLI installed on your system. From there, we'll run amplify init, which will set up a project in our working directory. That'll ask us a series of basic questions, and it also gives us the option to set up amplify with a popular JavaScript framework. But we'll just go ahead and select none for vanilla JS. That'll take a minute to complete, and then when it's done, it will create this Amplify directory in the root of the project. And that just contains a reference to all of the AWS resources that we're using in this project. Now we can connect authentication to this app by running amplify add auth. That'll give us a few different options here, but we'll go with the most simple use case of just email password authentication. And once we selected those options, we can go ahead and run amplify push. This will take all the resources that we have staged locally for AWS and then actually allocate them in the cloud. In this case, user authentication is handled by an AWS service called Cognito. If we go to the AWS console, you'll see a user pool based on the app that you just created. And inside of here, you'll find all kinds of different configuration options. And this is an area where AWS has a big advantage over Firebase in terms of flexibility and customization. It allows you to do things like multifactor auth by sending a text message or email to the user with a special code that they need to verify. And you can also set up custom attributes on the user authentication record. And you also have additional triggers that you can use for serverless code. In Firebase, you can only trigger when a user is created or deleted, but with Cognito, you have additional places that you can hook in serverless code. Now if we switch over to the Firebase dashboard, you'll find that things are a lot more simplified. Things are generally faster and easier to set up, but they are less flexible by comparison. For example, if we wanted to set up passwordless authentication, we can just do that by clicking a button, whereas on AWS we can do that as well, but we'd have to set up several Lambda functions to make it happen. Now Now once we have the initial configuration done, the code for both platforms looks very similar. On my AWS Amplify branch, I had to switch over to webpack back and Svelte because apparently it doesn't work with roll up currently. And just a quick side note here, both Amplify and Firebase will add quite a bit of JavaScript to your final bundle size. For Firebase with user authentication and Firestore, you'll be looking at around 500 kilobytes, and AWS with AppSync and GraphQL is close to a full megabyte. In the main JS file in Svelte, I'm going to import Amplify from Amplify Core and then I'm going to call configure on it with our configuration details that were automatically generated by the DLI. From there, I'll just go into the app component, and then when this component is mounted, I'll go ahead and call auth current user to see if the current user is logged in. So just one line of code to check if the user's logged in. And then if we want to log in with email and password, we can call auth sign in with the username and password. And that's all it takes to get a user signed in, and then we can set that user as the user property on this component. Now if we click the login button, it's going to log us in with AWS Cognito, and then it'll show our username here in the UI. And I don't think it gets any easier than that as far as user authentication goes. Now if we switch over to our Firebase branch, we have the same basic setup Here, we initialize the SDK with our credentials from the Firebase console. And then from there, we'll go into the main app component. And you'll notice that the code is almost identical to AWS Amplify. We're simply calling auth current user to get the current user, and then we say sign in with email and password to sign the user in. Now the point I'm trying to make here is that both SDKs provide well organized JavaScript libraries that help you get things done with very few lines of code. But now I wanna switch gears here to real time data, and that's where things really start to get interesting. I'll go ahead and start by showing you the Firebase example. We're here in the Firestore database, and we're creating a document in a to dos collection. The user needs to be able to view this data and update the data and also stay up to date with any changes that happen to it in real time across all clients. And that's a very challenging requirement to not only implement, but also to do at scale. If we look at the app itself, the user should be able to tap the smart complete button and then see the data updated in the UI and then also in the back end as well. To implement this code, we'll go ahead and import Firestore, and then we'll make a reference to that to do's collection in the database. To query the collection, we just call on snapshot, and that will give us a callback function that will listen to any changes to that collection in real time. It's going to give us a snapshot that contains an array of the document data, And then we can map that snapshot down to an actual JavaScript object that we can show here in our front end application. And that's actually all it takes to listen to a real time stream of data. Now if we want to mutate or update a specific to do item, we just make a reference to its location in the database and then we call update on that reference with the new data that we want to send. In our case, we want to update a to do item to complete, which we can do with a single line of code. So with Firestore, you get simplicity without any boilerplate code. That makes it really easy to work with, especially if you're building complex real time features because all of the difficult real time stuff is done for you automatically under the hood. But the major drawback is that you're stuck working with a single NoSQL database that may present challenges for data modeling and can also be hard to migrate into or migrate out of. Let's go ahead and switch back to Amplify to see how this looks with GraphQL and AppSync. We're going to first run amplify add API to provision these resources in the project. We'll choose GraphQL so we can use real time features, then make sure to choose API for the authentication type. Now with GraphQL, there's a lot of boilerplate code, But the nice thing about the Amplify CLI is that it's going to walk you through that code and generate most of it for you. Conveniently, the default Schema matches the data type that we already have set up in our front end app. I'm just going to add a Boolean property called complete. From there, you can run amplify push, and then it will ask you if you want to automatically generate the GraphQL API. Select yes. And in this demo, I'll select JavaScript as the language. Go ahead and select yes to everything else, and it's going to finish up by giving you a GraphQL API endpoint as well as an API key. Then head over to the AppSync console, and you'll find a Schema has been generated and uploaded to the cloud for you. This is really cool because you now have a GraphQL API deployed that can be accessed by any client that has that API key. And it took almost no effort on our part, but the API itself is pretty useless unless there's a back end data source attached to it. Amplify will automatically set up an instance of DynamoDB, which is a NoSQL database that is roughly equivalent to MongoDB or Firestore. Now we can go into the database, and we'll go ahead and create a new item that matches the schema that we have set up in GraphQL. Now if we go back to our source code, you'll see that there's an automatically generated GraphQL folder in the source directory. This contains all the boilerplate code that you need for GraphQL for things like mutations, queries, and subscriptions. Now there's a few different ways we could query this data with GraphQL, QL. But the gold standard way is to use the Apollo client. So we'll go ahead and install AWS AppSync and GraphQL tag in this project. And then I'm creating a new JavaScript file called client dot JS that is just here to initialize AWS AppSync. From there, we'll go into our app component and then we'll import that client, as well as the list to do's query from the GraphQL directory. Now we can make a query for the actual data in the database by saying GraphQL list to do's, and that will return a promise that resolves into the actual data from the database which will be an array of the to do items. So that provides a relatively easy way to fetch the data, but at this Point, it's not real time. If the user clicks mark complete, it's going to update the item in the database, but it's not going to actually notify us of that change. We'll go ahead and run the mutation as well as the subscription to real time updates in this to do component. We'll need the update to do mutation as well as the on update to do subscription. And And then to update the data, we'll call client mutate and then pass in an object that contains the data that we wanna change on that database record in DynamoDB. Now that's going to take care of the update, but we still want to listen to real time changes. To make that happen, we'll go ahead and set up a subscription here that listens to the update on this to do item. We'll go ahead and call client subscribe and then point it to a query of the on update to do subscription. And then we'll call subscribe on that, which will give us access to the data whenever it changes. Once we have access to that new data, we can just go ahead and update the property on this component. So now when this mutation runs on the back end, it's going to update the UI on the front end. Now Now I probably would not build an app like this in the real world, but I just want to give you an idea of what it takes to get things set up with real time data in AWS AppSync. GraphQL is a really amazing tool, but in a lot of cases, it might just be overkill. We have a lot of complexity in this app, both in automatically generated code and our own implementation details for something that was implemented relatively easily with Firestore. But, again, the big trade out there is we now have a lot more flexibility to make the code behave exactly the way we want it to. I want to finish things off by saying that both platforms are awesome in their own ways, and it's hard for me to imagine going back to building a back end from scratch. These services will save you time and money and help you get your product in front of customers faster. Now to sum up the comparison, I would say that pricing is almost equivalent. One might be cheaper than the other depending on how you use it. I would say Firebase is generally easier to use, and there are fewer decisions to make when getting things configured. And that's especially true when you compare GraphQL and Dynamo DB to Firestore. But on the other hand, AWS is superior when it comes to flexibility. There are more knobs to turn that you can use to customize the experience specific to your needs. I'm gonna go ahead and wrap things up there. And if you've experience with both Amplify and Firebase? I'd really like to hear your thoughts in the comments. Thanks for watching, and I will talk to you soon. It might be a tumor. It's not A tumor. Not a tumor at all.
        