0

I'm building a invoice app for iOS. I need a way to sync data between several devices of the same company that use the app. This have the common customers, product, inventory, invoices/detail tables.

I wonder if firebase is suitable for this.

Mainly, my main concern is that some iOS devices need to operate disconnected for some time (up to 1 day, people work in locations with poor or non-existent communication).

My second concern is for some customers that could use it as POS, and generate large amounts of invoices, to the same company group. My app is used for small supermarkets and wholesale distributors, that is the reason some travel and some stay in a local.

For the look of it, I think firebase is the closer solution for this (I'm considering pusher, parse and pubnub) because have a copy of the data and become the "database master" of this.

I have think in have a central postgress database as the database master, but maybe unnecesary with firebase?

mamcx
  • 15,916
  • 26
  • 101
  • 189

2 Answers2

4

I started working with Firebase about a year ago after going to a Facebook Hackathon in Austin. I instantly fell in love with the system and don't have enough good things to say about it. The benefits with Firebase are obvious, but it can be daunting to use such a new system for sensitive information.

1). if Firebase disconnects a websocket, it stores the information and once the socket is reconnected, it wills end of the information. It is wonderful and has saved us quite a bit of headache.

2). It handles large amounts of data really well. I'm not 100% sure I follow your question, but it sounds like you want to ensure it can transfer/store the large amount of data. While we never had to send a ton of data all at once, we have pulled in large amounts (half a gig of text) and had no real issues (a bit slow for reporting, but that can't really be avoided).

3). If you want to store all the information locally as well, you can pass the info to Firebase via any backend that can ping a server (ie: curl).

Also, one of the awesome things that Firebase introduced a couple months ago was validation (so no one can ping Firebase and tell them to drop all your info without being validated). This uses read/write privileges that are really easy to set up.

Let me know if you have any more questions about it

David Ziemann
  • 960
  • 1
  • 8
  • 22
  • 2) A invoice is not much data, but using firebase for sync the invoices across all our users is other thing. I wonder how well that could be (how much can scale) – mamcx May 10 '13 at 22:28
  • The syncing only becomes an issue if you have tons of users constantly changing info on the invoice at one time while others have them open. We would push out global notifications to 1000+ concurrent users without any issues. Let me know if you have any more questions and I would be more than happy to give you any insight I have. – David Ziemann Jun 10 '13 at 21:00
  • This mean is only a problem if is a concurrent edit on a single node? – mamcx Jun 11 '13 at 02:38
  • Sorry, I think my last comment wasn't very well written. Firebase sets up a web socket when you create a firebase reference (new Firebase()). As long as a single user is not connected to a bunch of sockets, you should be fine. It would make sense that a user would only have one connection and then it shouldn't be an issue. – David Ziemann Jun 11 '13 at 14:25
0

Take a look at Couchbase Lite. It seems to be designed for storing JSON documents (+attachments) locally on sporadically connected devices and automatically synching across devices.

It doesn't have the same latency as Firebase - documents get shared in 1-2 seconds, but the offline working and local storage comes free.

Also its not a service, although I think there are service providers who will host it as one.

Rajat
  • 1,043
  • 12
  • 23
Dave Holdsworth
  • 1