Backend-as-a-Service (BaaS) platforms aim to accelerate the development process through out-of-the-box features such as databases, APIs, functions, and push notifications and many more. Further, the BaaS provider handles server operation and maintenance and take care of issues like scalability or availability. This allows developers to focus mainly on frontend or client development.
Firebase is one of the best known BaaS providers and helps to solve issues such as building and hosting apps, releasing & monitoring, and keeping the users of the application engaged:
It is used in 81% of the top 200 Android apps and 47% of the top 200 iOSApps. This makes it the undisputed market leader regarding app development platforms, which means they will do a lot of things well and right.
However, this raises the question of why it can’t do so well and what disadvantages it has. To get straight to the point: For me, the most important disadvantages are the following:
Therefore, there are a lot of different alternatives like AWS amplify, Back4App, Supabase and many more.
However, there is another one that just launched in 2021, which is hardly considered, but bypasses some downsides of Firebase impressively. You may have guessed after you read the title, it’s called Appwrite!
What is Appwrite?
According to the developers:
Appwrite is a self-hosted backend-as-a-service platform that provides developers with all the core APIs required to build any application.
Basically, it’s a self-hosted open source backend server for frontend and mobile developers that offers REST APIs and SDKs to help frontend and mobile developers build their apps faster.
Below, we take a look at how Appwrite handles the most important functions of Firebase and compare the advantages and disadvantages of each platform in detail.
Before addressing the benefits of Appwrite compared to Firebase, let’s take a look at how Appwrite handles build & release, integration and monitoring of applications.
Set-up
Before I introduce Appwrite in more detail and compare it with Firebase, let me briefly show how it is set up as a Docker container.
There are two options to run Appwrite as docker container locally.
docker-compose up -d --remove-orphans
Now you should be able to see a landing page like the following:
Integration
As soon as you have an Appwrite server up and running, you can integrate it on the client side or on the server side. Offered SDKs for the client side are:
To build server side integrations, you can use one of the following SDKs
Appwrite offers a GUI for basic monitoring of an application. If you enable user authentication, the number of users in a given time frame can be evaluated. Appwrite also monitors the number of requests, created documents and data storage out of the box.
To keep users engaged, you can easily set up webhooks with Appwrite like shown below.
Webhooks allow you to set up integrations which subscribe to certain events on Appwrite. When an event is triggered, an HTTP POST payload is sent to the configured URL.
However, no Appwrite equivalent is offered for Firebase tools such as Google Analytics, A/B Testing and Crashlytics, which are designed to help you engage users by monitoring and evaluating user behaviour.
Compliance with the GDPR can determine the success or failure of a software project. Limited control also stems from the fact that Firebase runs exclusively in the Google Cloud, which means that data is stored on Google servers.
Additionally, I want at least mention, that Google had different lawsuits and payouts regarding data protection in the past.
With Appwrite on the other hand, you have full control over your servers. You are single-handedly responsible where your container runs and where the data of your users is stored.
Appwrite simply offers much more flexibility than Firebase. This starts with the aforementioned flexibility of where the container should run, and continues with the flexibility to adapt the code to one’s own needs. Unlike Firebase, Appwrite is open source. So if we urgently need a feature, we can fork the repository and implement it.
Firebase does not offer tools for migrating data to another platform. In addition, Firebase has several inherent functions and special features that are not available anywhere else. This makes it extremely difficult to move away from it. So you have to rely on it and adapt to all the changes in their API as well as rising prices. With Appwrite, on the other hand, you have much more control over where and how your data is stored, and you don’t have to adapt to API adjustments in newer versions.
Firebase’s SLA promises commercially reasonable efforts to make Firebase available with at least 99.95% uptime per month, which would be sufficient for most use cases. However, there are at least two problems if you want to use Firebase for a highly available service. First, Firebase does not promise to maintain 99.95% uptime, only to strive to do so. If they do not achieve this uptime, which seems to be the case from time to time, you simply get a discount. Secondly, you have no way of increasing Firebase’s uptime. So if you need uptime of, say, 99.99 or more, you need to consider other options like Appwrite, which as a self hosted solution offers you lot more control in this regard.
If you are using Firebase for a large project, pricing can be difficult to predict. Firebase offers free usage of its infrastructure for a limited amount of data, cloud function invocations and phone verifications. If you use more than what is offered in the free plan you have to pay for the services. In general, I believe the prices are quite reasonable with for example $0.108 per GiB of stored data in the Cloud Firestore and $0.80 for 2.000.000 invocations of a cloud function. If you want to see the pricing details of Firebase in more detail and play around with the amount of data and number of invocations, you can go here.
However, pricing for a larger user base as well as estimating the number of invocations as well as data that needs to be stored might be hard to predict, especially without much experience using Firebase. A more detailed discussion between Cloud and On-Premise Cost can be found here.
A major benefit of Firebase is that you do not need to worry about scaling since the necessary resources are automatically allocated.
The costs of using Appwrite depend on whether you run your OCI container on your own servers or in the cloud. The risk for unexpectedly high bills might be much smaller if you run Appwrite on your own server. However, it might lead to higher costs and much more effort if your user base increases or the usage of your app has high spikes depending on the time of day or year. Especially, a poor implementation of autoscaling might lead to high costs. Initially setting up an infrastructure for Appwrite which scales well and is cost-effective is a lot more effort compared to Firebase where these tasks and decisions are shifted to the cloud provider.
Additionally, Appwrite Cloud is currently in the beta program and might offer an easy solution in the future if you do not want to deal with these aspects. However, keep in mind that using Appwrite cloud might lead to similar problems as discussed above.
So, should we use Appwrite instead of Firebase for our next Software Project? As always, it depends.
If you are looking for the most easy to setup solution for an application with a small user base, then maybe Firebase is the right choice for you. However, if owning your data and high flexibility is important for your application, maybe you should consider using Appwrite.