Which is best for an app backend, Google App Engine, Parse, Firebase or AWS?

It depends on how you architect your backend. If you're just a mobile app developer and know nothing about coding web backends, then Parse is the way to go, but of course you'll suffer from occasional downtime of Parse for whatever reason.

Wouldn't recommend Google App Engine because of cost factor.

AWS and DigitalOcean gives you total control of your server environment, which requires you to code a web backend and manage your dependencies all by yourself. Cost factor forAWS is decent. Linux knowledge required to manage all these. DigitalOcean is really cheap to start off with.

Heroku and Open

It depends on how you architect your backend. If you're just a mobile app developer and know nothing about coding web backends, then Parse is the way to go, but of course you'll suffer from occasional downtime of Parse for whatever reason.

Wouldn't recommend Google App Engine because of cost factor.

AWS and DigitalOcean gives you total control of your server environment, which requires you to code a web backend and manage your dependencies all by yourself. Cost factor forAWS is decent. Linux knowledge required to manage all these. DigitalOcean is really cheap to start off with.

Heroku and Openshift has a nice touch of pushing your web component to their servers using git push. Pricing is decent. Haven't experienced the downtime for these two services before, but it's nice to have it as a dev server.

I recommend starting with Heroku.
For pros and cons see
What are the advantages and disadvantages of using heroku?

Before explaining the details, let me make it very clear Parse is already discontinued by Facebook in 2017.

Well, choosing the right tech-stack for app backend from Google App Engine, Parse, AWS or Firebase depends on numerous important factors such as type of app, architecture of your app backend, etc.

If you are not interested to go with an expensive option, then you are suggested to avoid thinking about Google App Engine.

Now talking about other tech stacks for app backend - AWS (Amazon Web Services) that lets you have a greater control over server environment. It makes necessary for you to co

Before explaining the details, let me make it very clear Parse is already discontinued by Facebook in 2017.

Well, choosing the right tech-stack for app backend from Google App Engine, Parse, AWS or Firebase depends on numerous important factors such as type of app, architecture of your app backend, etc.

If you are not interested to go with an expensive option, then you are suggested to avoid thinking about Google App Engine.

Now talking about other tech stacks for app backend - AWS (Amazon Web Services) that lets you have a greater control over server environment. It makes necessary for you to code backend, while managing your dependency on your own.

When it comes to cost factor for AWS, it is good for everyone. Meanwhile, one should have a well proficiency on Linux to manage all these in better way.

I have personally used AWS, Google Cloud as well as Firebase for various projects. I am not associated with either of the companies. I am summarizing my experience with the services here:

  1. AWS has a whole lot of services (almost anything you can think of), they basically convert many open source solutions AS-IS to cloud along with adding billing. Most of the services (except few) are services where you would still have to think of capacity, traffic etc. Something that requires a decent sized infrastructure team. Billing is (usually) complicated, some services have various tiers, different ways y

I have personally used AWS, Google Cloud as well as Firebase for various projects. I am not associated with either of the companies. I am summarizing my experience with the services here:

  1. AWS has a whole lot of services (almost anything you can think of), they basically convert many open source solutions AS-IS to cloud along with adding billing. Most of the services (except few) are services where you would still have to think of capacity, traffic etc. Something that requires a decent sized infrastructure team. Billing is (usually) complicated, some services have various tiers, different ways you can buy instances etc. If not used properly can potentially incur a lot of cost.
  2. Google Cloud also has a lot of services (but fewer than AWS) but I find that they are more advanced technologically (Bigquery, Image/Text/Voice apis etc.). Many of google services are geared towards autoscaling, automatic traffic management and low IT costs. Billing is usually simpler and consequently google tends to be cheaper at scale as well, particularly if you are a small team putting together a fast product. (At-least it was cheaper for me)

Firebase although did not start @google, adheres to some of the principles google tries to have in its cloud products. It is a backend as a service, requires very little server side code if at all. It scales/load-balances without any intervention from you. Support is very good, they respond quickly. There is a lot of library support as well from the open source community. The best part(s) about firebase are 1.) It is built over websockets so you can actually build realtime applications with ease. More importantly you can actually give a real-time feel to even traditional applications. (think gmail vs yahoo mail in 2004) 2.) Billing is very easy and straightforward and in my opinion quite low cost esp. after google started backing it.

It is standalone you can combine it with any backend AWS or google if you need to. So the choice is not really AWS vs Firebase.

In fact you can combine the good features of each cloud and not really have to choose between aws vs something.

Nope. Nope. Nope.

(Note that I moved away from GAE 10 months back, my information could be wrong in some cases, but the point is more or less same, also note that I am only talking about App Engine here and not Compute Engine)

Many of "advantages" of GAE evaporate very quickly as soon as you start to scale. Unless you are not serious about potential scalability of the project you should not host it on GAE.

First of all from commercial perspective bill for using GAE goes insanely higher as you scale, you are not only paying for maintaining data, you are also paying for every read and w

Nope. Nope. Nope.

(Note that I moved away from GAE 10 months back, my information could be wrong in some cases, but the point is more or less same, also note that I am only talking about App Engine here and not Compute Engine)

Many of "advantages" of GAE evaporate very quickly as soon as you start to scale. Unless you are not serious about potential scalability of the project you should not host it on GAE.

First of all from commercial perspective bill for using GAE goes insanely higher as you scale, you are not only paying for maintaining data, you are also paying for every read and write that occurs on your datastore database. Even though on paper it looks fair, reality is very different. No matter how hard you try reduce number of queries, once your service starts getting popular, your bill amount would increase exponentially.

Second from developer perspective, I find Google to be very slow, to provide support for new stuff, at the time I left GAE, web sockets were not supported. Imagine some interesting new tech comes along, that can widely benefit your customers, would you prefer to wait for GAE to implement support for that tech or would you want to build it asap? (to enable push messaging you need to contact third party supporters who can make push calls for you). Besides some of the rules are very restrictive, you can't run a query that gives 1000 rows, you can't run a task for more than 10 minutes. On GAE we were spending disproportionate amount of time hacking around these restrictions to do trivial things.

Third, GAE being platform as a service the lock in is very dangerous, you are not only writing custom queries that suit their needs you are also designing your application in a way that suits architecture of GAE. At the time of moving (And believe me, looking at the bill you would want to move one day) you will be redesigning not only your codebase but rewriting all your custom queries.

Some of the web tools provided are hilariously weak, for example search results on logs go only 10 pages by default, billing portal doesn't let you change maximum billable amount more than twice (That caused a downtime on our servers once).

Typical recommendation is to use GAE on side projects and use something else for production, I would contend that one should not use GAE for any purpose, not even for side projects. Most side projects are done for the purpose of learning, if you want to learn you are better off learning on platform that you are going to use in production.


Note: I still keep on getting mails on downtime for GAE, look at the timestamps, surely not looking very bright there. (To be fair, things were better on stability front when I was using it on production)

Because Parse is shutting down end of January 2017, it might sound like not a good idea.

BUT, Parse has open-sourced their platform code, mobile sdk’s, and even the web dashboard that can be used to manage the data and even manage push notifications.

If you don't want to deal with back-ends at all, not-parse is the way to go. If you're planning on scaling your application(s) and creating a legitimate business, Parse can be a great option to bootstrap a custom BaaS of your own in a manner of minutes (if you know what you're doing. It took me a couple days because I don't know what I'm doing). You

Because Parse is shutting down end of January 2017, it might sound like not a good idea.

BUT, Parse has open-sourced their platform code, mobile sdk’s, and even the web dashboard that can be used to manage the data and even manage push notifications.

If you don't want to deal with back-ends at all, not-parse is the way to go. If you're planning on scaling your application(s) and creating a legitimate business, Parse can be a great option to bootstrap a custom BaaS of your own in a manner of minutes (if you know what you're doing. It took me a couple days because I don't know what I'm doing). You can then run this bootstrapped backend on your own AWS instances, scale it up and down to keep costs low. There was any a price cliff like other BaaS services have where you end up paying thousands of you end up succeeding.

Then in the future as you grow, any back-end dev that knows Node.js can come in and continue scaling your platform, and the accompanying dashboard, and client sdks to do whatever you want.

So which is better? Depends on what you wanna do. If you want a legitimate company eventually around your product, Parse is EVEN better now that they are shutting down, because they are being so generous with their technology. Not to mention the community that is cropping up around these open projects to ensure that quality is maintained as time passes.

Google Firebase is an entire platform for building apps with authentication, hosting, a database backend, storage, analytics and more.

AWS Cognito is not a platform, it’s only used for authentication and identity management. The AWS product that competes with Firebase is AWS Amplify.

If you’re only comparing Firebase Auth with AWS Cognito, then they’re both very similar and offer 90% of the same functionality. Both will do fine in simple username (or email) + password sign-in, along with federated logins using Google, Microsoft, Facebook, and other social accounts.

AWS Cognito offers more advance

Google Firebase is an entire platform for building apps with authentication, hosting, a database backend, storage, analytics and more.

AWS Cognito is not a platform, it’s only used for authentication and identity management. The AWS product that competes with Firebase is AWS Amplify.

If you’re only comparing Firebase Auth with AWS Cognito, then they’re both very similar and offer 90% of the same functionality. Both will do fine in simple username (or email) + password sign-in, along with federated logins using Google, Microsoft, Facebook, and other social accounts.

AWS Cognito offers more advanced functionality by giving you a standalone site for OAuth and OpenID Connect redirect endpoints. Firebase Auth does not have this and relies on you to provide your own site using their Firebase JS-based UI components.

AWS Cognito also has more backend functionality for user attributes, profile mapping, security rules, lambda processing events, and backend integration into IAM. This is because Cognito is a standalone identity product which makes it easy to add app clients and API resources for a well-built token authentication system.

Firebase is more of an integrated offering into Firebase and meant to be used as part of the “apps” inside a Firebase Project, but it’s not really designed to handle multiple protected API endpoints and clients.

So if you need advanced authentication, standalone OIDC endpoint, tokens for multiple protected API resources accessed by multiple clients, then Cognito is a good choice. If you just need simple password or social login for a few apps, then either will work.

First things first. It´s important to understand AWS it is not a mBaaS, but a infrasctructure provider. These are two different concepts. The table below will help to understand the major differences.

There is no right or wrong for AWS or a mBaaS. It depends on the on the type of application being developed and I will detail below the pros and cons of each one.

BaaS –Backend as a Service Overview

The best way to understand the concept behind the BaaS is to visualize a bridge connecting the backend to the frontend of an application. BaaS help developers to accelerate software development and simpl

First things first. It´s important to understand AWS it is not a mBaaS, but a infrasctructure provider. These are two different concepts. The table below will help to understand the major differences.

There is no right or wrong for AWS or a mBaaS. It depends on the on the type of application being developed and I will detail below the pros and cons of each one.

BaaS –Backend as a Service Overview

The best way to understand the concept behind the BaaS is to visualize a bridge connecting the backend to the frontend of an application. BaaS help developers to accelerate software development and simplify API creation.Instead of coding the entire backend developer will use a BaaS to create theAPIs and link it to the applications. The table below provides a clear view and details the differences between severalcloud services.

Wikipedia does also provide a good overview of what is a backend as a service and please see further details on the link below:

https://en.wikipedia.org/wiki/Mo...

Vendors Overview

The main player of this market is a Parse. They have more than 1 million applications hosted on their platform and more than 600K users. Parse was acquired byFacebook a few years ago, but early 2016 Facebook decided to shut down the platform in 2017. It will make millions of applications to migrate to alternative vendors. The list below provides a vendor overview:

Back4app: Help developers and companies to build and host Parse APIs for web, mobile and IoTApps. Site: www.back4app.com

Firebase – Firebase can power your app's backend, including data storage, user authentication,static hosting, and more. Focus on creating extraordinary user experiences.

Accengage - Provides mobile app engagement tech for push notifications, in-app messages and mobileretargeting.

Cloud Boust - Offers Storage, Search and Real-time capabilities for your apps. Its perfect forbuilding data-intensive applications and services.

BackAnd – Aplatform that allows you to create an AngularJS ready backend for your app. Itsreally good of you are working on AngularJS web apps and your data is stored onAmazon RDS.

RapidAPI - Abackend platform that allows for saving data and integrating APIs. It is basedon blocks so each basic action is represented by a block.

Stamplay - Build backend of apps in your browser without coding using APIs as Lego blocks. Itbrings together built-in features such as User management, social login, clouddata storage, database, automatica API generation, SDKs, cdn backed hosting,and integrations with any 3rd party API.

Please see below a Github link with a comprehensive list of BaaS to replace ( migrate ) Parse.

ParsePlatform/parse-server

Why to use a BaaS?

Web and mobile applications demand analogous set of features on the backend. Forexample, e-mail notification, social network integrations, push notifications, cloud storage and etc. Each of these services has its own API that must be separately incorporated into an application. This is a time consuming practice, a process that can be time-consuming and complicated for applications and can be automatized with an BaaS. The main reasons a BaaS is used are highlighted below:

Development Cost – Software projects are usually very expensive and very time consuming. The main reason for it is because most of development is not automatized and it tailor made for each client. One of the main purposes of the BaaS is to automatize repetitive tasks andavoid allocating software engineers to do low value added activities. Doing so,less development hours are allocated on the project and the total project costis much lower. A cost from a software project can be reduced up to 80% using aBaaS.

Speed – Depending on the type ofapplication backend development can be speeded up to 4 times. It allow large companies to change morequickly to market needs (does not takes months to implement a change request)and startups to have their MVP – Minimum Viable Product ready faster.

Developer Experience – The learning curve to use a BaaS is usually very low and demands very few effort for adeveloper to use this type of platform. This means a front end developer or a mobile developer can build an entire software project alone without (for small projects)the intervention of a full time backend developer. For large projects, thebackend developer can focus their time on high value tasks instead of allocatingdevelopment time on repetitive activities.

MarketOverview

The BaaS –Backend as a Service market it is growing very fast and it will reach US$ 30Billion in 2019. There will be over 25 million software developers by 2020. So,the BaaS becomes one of the hottest markets in tech and will support thefastest growing professional segment in the world. Developers will bespread out among 140 K startups, 230 K software development agencies and severalother segments of companies.

Advantages and Disadvantages

PROS

Vendors – The market is relatively matureand there are several vendors available for all types of needs. Please findbelow a couple of vendors.

Development Effort - A developercan save weeks in terms of backend development. Usually the back enddevelopment is a repetitive activity is quite monotonous for developers. BaaSvendors show as a real good alternative to speed up software development.

Monetization - Considering theeffort to create an application is much lower, the product MVP can be launchedfaster and start to generate revenue earlier. It is in special important forStartups!

Front End Development - Developers canfocus on front end development and adapt it in very fast way based on marketneeds.

Scalable – The totalquantity of user can grow very fast without downtime or performance decrease.

Security – Most of the BaaSvendors do provide real good security protocols.

CONS

Control – Developersusually like to have complete control over the source code and most BaaSrestrict access to the backend source code.

Vendor Lock In – The user have toread carefully the terms of use of each vendor and evaluate if there is avendor lock in or the data / source can be migrated if necessary.

Disclaimer: I´mpart of Back4app team.

Great question. All three of these can be used together and solve different problems.

Firebase is an umbrella brand for a number of different cloud products that are aimed at mobile application developers primarily. It’s most well-known / original product was a realtime database that could be used by mobile applications without writing any server code. However, its mission has expanded to include a number of other products, as well, such as Firebase Cloud Messaging (formerly known as Google Cloud Messaging) and Firebase Storage (a layer on top of Google Cloud Storage that adds some additional f

Great question. All three of these can be used together and solve different problems.

Firebase is an umbrella brand for a number of different cloud products that are aimed at mobile application developers primarily. It’s most well-known / original product was a realtime database that could be used by mobile applications without writing any server code. However, its mission has expanded to include a number of other products, as well, such as Firebase Cloud Messaging (formerly known as Google Cloud Messaging) and Firebase Storage (a layer on top of Google Cloud Storage that adds some additional features to make it easy to use in mobile apps directly without an additional server).

Google App Engine is a platform-as-a-service (PaaS) product that is designed to make it easy to write web applications / server software. Whereas Firebase is about “serverless” development (with respect to the customer — obviously, Google itself, has servers to make Firebase work), App Engine is for those who desire to create their own server software.

Cloud Endpoints is a service / technology for developing, managing, and syndicating APIs. In particular, it facilitates defining APIs, generating client libraries in a number of programming languages for interacting with the APIs, and also access control. It can be used with Google App Engine, Google Compute Engine, or Google Container Engine.

There is a really good diagram that describes the difference between Firebase and AppEngine. To be clear, Firebase and AppEngine are NOT substitutes, they can be used together.

Firebase provides a tremendous amount of mobile functionality like authentication, authorization, analytics, real-time synch across users, etc but does not have a backend.

You can build it only in Firebase and/or only in AppEngine. The absolute easiest way to build a simple app would be just to use Firebase. In fact, there are lots of tutorials on this.

Firebase would be an excellent choice for your beginning chat app and

There is a really good diagram that describes the difference between Firebase and AppEngine. To be clear, Firebase and AppEngine are NOT substitutes, they can be used together.

Firebase provides a tremendous amount of mobile functionality like authentication, authorization, analytics, real-time synch across users, etc but does not have a backend.

You can build it only in Firebase and/or only in AppEngine. The absolute easiest way to build a simple app would be just to use Firebase. In fact, there are lots of tutorials on this.

Firebase would be an excellent choice for your beginning chat app and minimum viable product but as you grow to Snapchat like scale, you will need a backend like AppEngine to support lots of the business logic and more control over the services you offer.

They are not really the same. AWS is a service that hosts your websites, files and data. Parse is an API that you use to talk to the database. A better question would be what is the difference between using parse or making your own REST API. Parse is just a REST API using a Mongo DB.

It all depends on what kind of app it is and what you need from a backend. Firebase is built to be a fast, NoSQL database and is geared toward real-time, open-socket data streams. It works best for lightweight data (strings, numbers, dictionaries) and isn’t really set up for large data storage (images/video/etc). AWS is predominantly a data storage solution. There’s no reason your app can’t use both. It’s not a binary choice