2 ms·
I've been using Firebase for a couple of months now for an iOS app I'm building for a client, and it has been a fantastic experience. For anyone who doesn't kn
by zackmorris 12y ago
I've been using Firebase for a couple of months now for an iOS app I'm building for a client, and it has been a fantastic experience.
For anyone who doesn't know, it's main selling point is that it automatically syncs with the server so you can focus on the data instead of the communication protocol or replication. Its nosql data store looks like a local filesystem, so you can save trees of data to it as JSON. It also has server-side rules written in javascript that enforce constraints on data and read/write permissions per user. They also have a free test account for developers.
"What about merge conflicts?" was my first question, but luckily it has transactions on an individual node (and its subtree) that perform an "optimistic-concurrency transactional update" which basically means a compare-and-swap where you review the current value in a callback and decide whether to try to commit that value (or a new value, say, for a counter) or give up. For most other writes, you're usually just saving status updates where there is little or no danger of being rejected or encountering merge conflicts. If in doubt, it's possible to get a callback with the final value.
So when it’s all said and done, I can totally see writing a full-featured app using it without a single line of server-side code. I used their hosting while it was in development to store images (like a CDN) and it’s very simple to use from the console, so if you have a build script, it could push to production with a single call. After an exhausting ordeal battling iCloud for a different project, Firebase is so profoundly better that I will never go back.