My first Mobile BaaS experience was Parse way back in 2011. It was elegant, simple, easy to use, and fulfilled most of the needs that a mobile application developer required.
Ever since Facebook acquired it, I was looking for an alternative solution. Firebase was a great direction to be orientated to, however before the Google acquisition, it had far fewer features than expected.
As years went by, Realm made history as a local database management system, despite its server-side implementation never was a real competitor. So we were able to use a decent (local and remote) setup, by picking the best available options from each side.
Although, the world is changing. Users, companies, and governments became more and more sensitive about where and how their data should be stored (GDPR, CCPA, HIPAA). In many cases, it's simply not an option to store the app database just somewhere in the cloud. And whenever we are talking about sensitive data (like education, healthcare, military, etc.) the server location shall be defined more precisely than just a certain continent.
Furthermore, I love the open platforms. The big tech companies often like to create their own walled garden and lock you in as tight as possible. And not just the end-users are in danger. A developer can also feel to be trapped by a 'perfect' ecosystem.
Long story short, GraphQL can be a solution. GraphQL can be something that big tech companies cannot acquire, monopolize, freeze, and/or lock in. You can connect from any kind of operating system with almost any kind of client. And you can also connect with almost any kind of database. It can be a long-term, open platform solution.
My only problem was with GraphQL (as an iOS developer), that it seemed to be needlessly convoluted. The available iOS implementations were so far from Parse, Firebase, or Realm that it made no sense to start the migration process from the well-known platforms.
But the customers usually do not care about the technical difficulties. They want the database to be located in their countries, in their cities, or in their buildings. They want large-scale, real-time implementations. Also, they want it preferably fast and cheap.
So we needed something that is robust, easy to use, and can be connected to any kind of GraphQL server. Also, it seemed to be important, if we need to switch between GraphQL platforms, then the client app should be able to operate without rewriting a single line of code.
To solve all these issues, we have implemented GraphQLite. We believe this could be a solution for most of the database (local and remote) related challenges we are facing with. It might be the first step towards our goals being achieved.