It's for people that don't want to handle the backend - whether they know how to work with it or not. Also, firebase provides client libraries for some environments, completely hiding the networking layer from the user of the library. You're using a high-level model while firebase actually does all the heavy lifting for you, which is extremely appealing for people that need to get an mvp out as quickly as possible.
In firebase is there backend logic or is it all supposed to take place client side? I glanced over it yesterday but I am going with DynamoDB + Sails.js on heroku currently as it seems like the quickest platform to build a backend API for my app MVP.
I have experience in JavaScript and the app is react native but server side code is newer to me so if HN has any wisdom I am looking for development speed foremost with maintainability and performance as a lesser priority.
I have never used Firebase, but I think they handle the data store and all the ways to access it's data (auth, sockets, etc.). So if you needed some kind of backend logic or task to happen, you would wire a separate backend app that authenticates to the firebase database and then it could read/update/create data.
Firebase has server-enforced permissions and validation. But for complex backend logic you would need to write a bot that watches data being entered and reacts to it.
I wouldn't recommend it at all. I built an app on it and it was an endless source of downtime and bugs. For example, the ref.onDisconnect() api call will not always fire, leaving fragmented data in your db. Long story. Don't use firebase for anything that will be used in production
I know I'm a little biased since I wrote the library, but we use Firebase in production and it works just fine for us. Auth, real time, scalability, and security out of the box is why I love Firebase. Not saying any other option is bad, I've just had plenty of success with Firebase.
Less the REST and more the realtime sync - push based architecture doesn't exist in REST sadly. I'm building an Open Source version of Firebase (http://github.com/amark/gun) with graph data structures, so I understand the appeal and can approve it is well warranted.
It's does low latency server push over websockets (with fallbacks for older browsers). Offline sync cache. Web and mobile. It's a much bigger technical challenge than writing a RESTful backend.
I really wish this included examples of how to test your code, either in the form of "recipes" or in the examples.
If I'm building something that I plan on maintaining for a medium to long amount of time, I'll want tests to give me some peace of mind. Especially when I go work on other stuff, and I come back a few months later to find myself stressed out because I don't know if things will break.
There wasn't a frustration with Firebase and React. It was a frustration with Firebase and vanilla flux. Firebase is essentially a store. So using vanilla flux you end up just trying to keep your store in sync with Firebase.
17 comments
[ 3.2 ms ] story [ 53.5 ms ] threadI have experience in JavaScript and the app is react native but server side code is newer to me so if HN has any wisdom I am looking for development speed foremost with maintainability and performance as a lesser priority.
Disclaimer: Firebase employee
My team had been patiently awaiting it for a long time, but had to give up, unfortunately, and have moved to CouchDB.
If I'm building something that I plan on maintaining for a medium to long amount of time, I'll want tests to give me some peace of mind. Especially when I go work on other stuff, and I come back a few months later to find myself stressed out because I don't know if things will break.
This one reads json-schemas and spits out a backend API. The same schemas can be used on the client for extra convenience.
http://ramses.tech (shameless plug from a co-author)