BaaS pain

I'm using Firebase for Indie Hackers, and I've used it on many other projects in the past, too. I use a lot of Amazon Lambda, too, which I suppose you could classify as a BaaS, although maybe not.

What's lacking in Firebase? Various incremental improvements. I wish it was easier to diagnose performance. Ideally some sort of browser dev tool to analyze my Firebase queries and see how long they're taking. But to be honest, maybe that already exists? The fact that I don't know means that haven't gone searching for it, which means it hasn't become a high priority for me yet.

What's lacking in Lambda? I wish it was easier to create and deploy new functions, especially functions I want to be accessible over HTTP via Amazon's API Gateway. It feels like there are lots of manual steps involved. Then again, same story as above: maybe I can already handle 100% of the steps via Amazon's command line tools if I write a short script, but it's just been too low of a priority for me to do it.

Your second question is a bit confusing. What would I want to see in a new BaaS product? That's a technology-first way of thinking, and people don't really think like that. Instead, I think in terms of problems I want solved and desires I want fulfilled.

Similarly, I don't think you should be attached to building a BaaS product. Rather, think about a specific thing you want to help people do and how it will benefit them, and only turn it into a BaaS if a BaaS is the best possible way to do it.

I can only echo most of what @csallen has already said. I'm also a Firebase user. The limitations/shortcomings are, IMO, pretty well documented online already.

What I'd like to see more of with Firebase specifically is high quality, well-written tutorials/examples for real life use-cases. Firebase is developing so quickly that most third-party tutorials are out of date within 6 months or so. Firebase have their own extensive selection of tutorials, however I don't find them particularly intuitive or easy to use, especially from a beginner's standpoint.

The docs are excellent though IMO.

I'm using Firebase for www.avialoft.com - it's okay. I've used serverless/Lambda and was semi-happy with it. I've used loopback and was reasonably happy with it. One thing I think is missing is a clear (and easy!) migration path between BaaS services. That might be a service you could provide for a fee... on the topic of what is missing from existing BaaS - AWS Cognito is overly complex, and once you've chosen a configuration, you're unable to change it. Firebase auth is fantastic. It'd be nice to have a simple way to create and configure access controls on CRUD objects/API endpoints. Loopback does a great job of making CRUD api's easy to create, but the access config is lacking (I've used an older version, so maybe it's better now?). Otherwise, I don't have a big gripe with these three BaaS services.

We decided against using FireBase because of the documented limitations around data retrieval speeds. Also, it seemed like it was really designed for mobile and less so for an SPA.

We considered Backand but didn't go with them because we felt like everything they offered would/could be offered by Amazon in short order.

Really, you need to position how you're different from AWS from the get-go. Speaking for myself, seeing what happened with Parse made me always want to go with a larger vendor because I knew they would always offer the product. I.e. no one gets fired for picking AWS.

AWS, of course, is nowhere near as easy to get started with. But being the better technical product is not a guarantee of success with technology products.

Recently we've looked at Graph.cool in preparation for our version 2. I like that they offer host-your-own docker containers and that the framework is open-source so we'll never be entirely vendor-locked.

What I haven't seen in the BaaS market - and maybe I just haven't looked hard enough - is a highly-regulatory compliant environment. I.e., BaaS for Fintech (what we need), or BaaS for

Regardless, across all BaaS products, I don't see the same level of built-in / zero hassle for CI / CD. Microservices have their place but they result in an explosion of corresponding dev ops procedures. What I've seen so far doesn't hold a candle to the awesome simplicity of Heroku's built-in CI / CD "pipelines".

Hope this helps.

Check https://hasura.io
These guys has also build something similar

Thank you all for the responses. It sounds like a common frustration is ease of use, or lack thereof. This is helpful. The project I'm working on is more or less aligned with this frustration. The idea is that the service does less than the competition, but less means simpler, more focused on the essentials.

It does two things: user authentication and relational data persistence through a basic REST API. In a lot of cases, that's all the backend you need to build a solid web app.

One thing I'd like to achieve with this service is to give front-end developers a way to quickly turn an idea into a fully functional web application without writing any backend code or setting up any infrastructure. I guess that's the main, high level problem I'm trying to solve.

I've seen a lot of interesting experimental apps hosted on GitHub Pages, storing data in local storage. My aim is to make it trivial for those apps to become database backed. Storing data in a database should be just as easy as storing it in local storage.

I've used Elastic Beanstalk (tons of undocumented, or confusingly documented, behavior) and Parse (RIP).

I miss Parse. It wasn't perfect--there were scaling issues, and some weirdness around push notifications and device identification--but I loved being able to skip so much backed configuration.

I've used Firebase only a tiny bit, but found it confusing. The GUI felt counter intuitive, and it does way less than Parse did (but I gather it's way more scalable)

Firebase has the best presence system out of the group of products trying to compete with it (Deepstream, etc), but has quite a few issues, too. My biggest ones are

1. very hard to enforce schemas or migrate a bunch of firebase data at once. say you want to rename a column and you have millions of entries?
2. reliability
3. cost

This comment was deleted 9 years ago