Firebase is a great platform on which to build a web app. It provides authentication, a massively scalable NoSQL datastore with real-time data synchronization, and a mature set of SDKs for both the web and server. Firebase also hosts and scales your backend so you can focus on your app.
Midtype is a backend-as-a-service platform built to suit modern frontend apps based on popular frameworks like React, Angular, and Vue. Midtype provides a bespoke GraphQL API for each app that a developer can customize to match the needs of their app. By leaving user registration and login, subscription payments, and data storage to Midtype, developers can focus on their value differentiators.
Let’s dig into the similarities and differences between Firebase and Midtype.
Where Firebase and Midtype are On Par
On many fronts, Firebase and Midtype are equal:
1. Both Midtype and Firebase provide an application backend as a service.
This includes features like user registration, login (“authentication”), and a datastore out of the gate, allowing developers to bring their own frontend and let these platforms provide everything behind the API.
2. Both Midtype and Firebase are hosted on Google Cloud.
They both get the benefits of Google’s world-class infrastructure, scale, and security.
Where Midtype Excels over Firebase
Midtype is a better alternative to Firebase for those who are hindered by any of the following limitations of Firebase:
1. Firebase datastore has a limited query interface.
If your app needs to fetch data based on multiple conditions, Firestore often doesn’t work. For example, if you need to find all cities having more than 1 million residents and fewer than 250 parks, this is not possible in Firebase.
There are workarounds one can use to overcome this. For instance, you can do server-side filtering for the first clause and then client-side filtering for the second clause. But this stops working at even a moderate scale.
Furthermore, querying relational data is cumbersome. Say you have a list of users and a list of associated comments posted by those users, it is not possible to find all comments from users who are paid subscribers unless you also duplicate the user’s paid_subscriber field in each comment. This is obviously doable, but when a user downgrades to a free plan, all comments authored by this user will need to be updated to reflect the new state of the user.
Midtype provides a turnkey solution for both these problems. We expose a rich query interface over a relational database without having to implement these workarounds.
2. Firebase fails to provide type safety on data shape.
Firebase provides a document-based NoSQL database that accepts data values of arbitrary shapes. While this provides great flexibility, it also allows one to make mistakes. For instance, you can write your data using the ageh field but query data using age field. Firebase won’t prevent this, leading to unexpected errors.
Midtype, on the other hand, ensures all data conforms to a given data shape.
3. Firebase makes it hard to test changes before rolling them out to users.
It is possible to create a separate “staging” Firebase project and testing everything there before applying the change to your “production” project. However, this requires quite a bit of work and there is no way to guarantee that all changes have been tested exhaustively in the staging environment.
With Midtype, a staging environment is a built-in construct. While, we are still in the process of releasing it, in the future, testing all changes will be far easier.
4. Firebase doesn’t provide the ability to collect subscription payments.
If you wanted to have your users pay a subscription fee, you can do this on Firebase by writing cloud functions that understand and interact with the API of a payment vendor (like Stripe). This is doable but takes a lot of effort writing non-differentiated code.
With Midtype, the ability to charge customers is built-in. You can spin up your own application API with user registration and subscription payments in minutes.
5. Firebase speaks REST natively, which doesn’t map well to data-driven components.
REST is the API standard for web apps. However, there are some serious limitations:
- REST requires different endpoints for different responses. As such, more code needs to be written and managed to deliver a new app feature on time.
- Endpoints have a predefined response — often returning more data than needed for a given view.
GraphQL, on the other hand, comes with some huge advantages, the biggest being that API calls can pull in more or less data by changing the query in the request’s body, without writing any more backend code. Midtype uses GraphQL, which pairs splendidly with the data-driven component architecture espoused by React, Vue, Angular, etc.
6. Firebase doesn’t expose users as a first-class primitive.
Many app-level features are closely tied to user data and permissions — voting, payments, team permissions, feature flagging, and more. However, Firebase doesn’t have any special functionality built-in for users (besides using them in Firestore security rules).
Users are a first-class primitive in Midtype, making it much easier for us to provide those features to customers with minimal setup.
7. Firebase is a closed platform.
It is hard to migrate off of Firebase as it is built on top of a proprietary, closed source datastore and application server.
Midtype is built on top of modern, open-source database PostgreSQL. We even allow our customers to export all their data whenever they’d like. We believe Midtype provides so much value to developers that they will not want to move off of it once they get used to building atop Midtype.
Where Firebase Excels over Midtype
On many fronts, Firebase continues to excel over Midtype:
1. Firebase has excellent real-time data synchronization.
If your app needs real-time data synchronization, Firebase is just too good here and remains a perfect provider for such workloads.
2. Firebase supports mobile platforms.
Firebase provides a mature set of SDKs on all major mobile platforms. While Midtype backends can be called from any mobile platforms via GraphQL libraries (or even direct HTTP calls), we do not yet have an SDK to make implementation easier.
3. Firebase has been around for longer.
Due to its age, Firebase has more mature documentation and a larger developer community. Midtype is just getting started so we have plenty to catch up on. However, at the moment, Midtype founding team members answer all incoming customer questions.
Midtype as a Firebase Alternative
You can’t go wrong with Firebase as your backend. However, if you are developing an app that may run into any of Firebase’s limitations, consider giving Midtype a go.
