There's so many red flags in this article I'm not sure what I can really take away from it.
> These things may still be "hacked" using Firebase, but it means that you will have to add even more code to your web-app, and it could be a nightmare to maintain if you have a mobile app too.
So don't hack it and don't repeat it. Do it once on your server.
> You may query directly Firebase over the network, right from your backend, but you should avoid doing this because it is really slow at scale.
So queries from a browser and mobile client are more performant than a server running in Google's own datacenter? I'm guessing they're running queries that don't fit Firebase. It's a key/value store with a single simple query mechanism. The awesome feature is that it will solve the data synchronization problem. On the forums and stackoverflow, the Firebase team is quick to point people to using a server process to keep things simple.
> dealing with relations with Firebase is pain in the ass.
> Want to build an API for your product? It's impossible.
WTF?
> old-fashioned SQL Database, which overs 90% of our data storage needs... For the 10% part, we decided to use MongoDB to store messages and conversations at scale.
So no ONE datastore that you could find solves your problems well, but Firebase sucks because it didn't?
Sorry, I've been building a prototype with Firebase lately and this article goes beyond unhelpful into the land of complete nonsense. If someone has run into these issues, I'd love to dig into specifics.
Their statements contradict the docs without explanation and are not internally consistent. It sounds more like engineers scapegoating a tool than a well thought out critique.
> These things may still be "hacked" using Firebase, but it means that you will have to add even more code to your web-app, and it could be a nightmare to maintain if you have a mobile app too.
So don't hack it and don't repeat it. Do it once on your server.
> You may query directly Firebase over the network, right from your backend, but you should avoid doing this because it is really slow at scale.
So queries from a browser and mobile client are more performant than a server running in Google's own datacenter? I'm guessing they're running queries that don't fit Firebase. It's a key/value store with a single simple query mechanism. The awesome feature is that it will solve the data synchronization problem. On the forums and stackoverflow, the Firebase team is quick to point people to using a server process to keep things simple.
> dealing with relations with Firebase is pain in the ass.
Why are you using a key/value store?
> it's not possible to export your users data
Are the Firebase docs lying to me? https://firebase.googleblog.com/2015/03/private-backups-for-...
> Complex queries are impossible
It's a key/value store...
> Want to build an API for your product? It's impossible.
WTF?
> old-fashioned SQL Database, which overs 90% of our data storage needs... For the 10% part, we decided to use MongoDB to store messages and conversations at scale.
So no ONE datastore that you could find solves your problems well, but Firebase sucks because it didn't?
Sorry, I've been building a prototype with Firebase lately and this article goes beyond unhelpful into the land of complete nonsense. If someone has run into these issues, I'd love to dig into specifics.