Midtype as a Firebase Alternative

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 application backend as a service with user registration, login (“authentication”), and a datastore out of the gate. This allows 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 and get the benefit 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 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 which 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 needsto 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 thatAPI calls can pull in more or less data by changing the query in the requests’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 theyget 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 it’s 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, please consider giving Midtype a go.

Need to launch your web app tomorrow? Leave it to Midtype.

Midtype helps builders launch and iterate on web apps at light speed. We provide a hosted backend with user login, payments, a database, and much more built in. We allow you to focus on your core product without reinventing the wheel.

Why GraphQL is the Ideal API Language for Frontend Engineers

Facebook unveiled GraphQL to the developer community in 2015. What was once an internal research project quickly became the hot new standard…

Add Password Based Accounts to Your App

Now, in addition to signing in with Google, your users can create their own password based accounts for your app. To maximize conversion…

Collect Subscription Payments in Minutes with Midtype and Stripe

Subscriptions are at the core of every SaaS product. That’s why we’re excited to announce integration with Stripe to make managing…