I am working on a project that will include a Laravel web application, Android application, and iOS application. I am new to iOS. Since a user's data will need to be synchronized across all platforms, I assume the optimal way to do this is with a Relational Database (i.e. MySQL) and a PHP Web Service that interacts with the mobile apps.
Everything I see online says to basically use Firebase for mobile apps. There is a lot of work to create the PHP Web Services necessary. I am surprised the dominant recommendation is to use Firebase. About every iPhone app I have has both web and mobile platforms where data must be synchronized. I assume they cannot use Firebase and must use PHP Web Services.
Am I missing something?
You are absolutely correct that it is not a foregone conclusion that one would use Firebase. It’s a great solution that fills a particular niche, but developing separate web services is extremely common. (I suspect that that your online research may be biased by the fact that most of these articles are likely geared for mobile developers who might not have the wherewithal to develop, maintain, and support their own web server infrastructure.)
That having been said, I would not have jumped to the conclusion that the “optimal” way would be to write your own backend going against some RDBMS. These NoSQL solutions, like Firebase, are perfectly up to the job in most cases. There are pros and cons on both sides of the NoSQL vs RDBMS discussion (which is probably beyond the scope of this question).
So, do not be unduly biased by these Firebase articles you found online, but consider adding it to your tech stack if:
there are some compelling Firebase features that you don’t want to reinvent yourself (e.g. the integrated authentication options are nice; the realtime observers for database changes is a killer feature, if you need that; etc.);
the NoSQL paradigm of Firebase’s “Real-time Database” fits your app’s requirements; and
you need backend server capabilities, but don’t want to deal with the overhead of developing and maintaining your own backend.
In your case, because you’re already developing a Laravel app, that largely undermines that last rationale, because you’ve obviously already signed up for that.
So, it is just a question of what Firebase features you need and whether these features are compelling enough to justify adding Firebase to your tech stack. But don’t use Firebase because you found a bunch of articles advocating for it. Nor should you dismiss Firebase because you fear it won’t be “optimal”. It depends.
All of that having been said, the excellent, seamless, object-to-database mapping that Laravel provides really begs for the SQL database approach. If you tried to use Firebase for the backend, you’d likely lose a lot of the benefits of Laravel.
I am an novice programmer and I need a little direction.
Here is the concept of what I am looking to do:
Let's say I have an iOS and or OS X app for let's say storing people's names and phone numbers. Now I want to be able to have multiple people to be able to use the same app on different devices and access the same database; read and write values at the same time.
I am moderately well versed with Core Data and I have found that it works well but is not capable of accomplishing what I am trying to do.
Could someone point me in the right direction to find resources where I could learn how to do this? Thanks.
I apologize if the question has been asked before; I tried to do searches but I didn't know exactly what to search/could not find what I was looking for.
It seems that what you want to achieve will require an external database storage, which would provide an API that both your iOS and Mac OS apps will use in order to read/write to this common database.
There are plenty of resources on how to setup a database and an API. A pretty simple (yet heavy) approach would be to create a little web server in the language of your choice (PHP, Ruby on Rails, Node...) that exposes a hosted database, and communicate with that API from your apps. My advice if you are a beginner, would be to have a look at RoR to setup a simple web server/Restful API that exposes a MySQL database: http://guides.rubyonrails.org/getting_started.html.
If this is not the answer you're looking for, maybe you want to use iCloud in order to keep your data in sync between devices. However, this is not applicable in a multi-user land (e.g. this will work fine for multiple devices of the same user).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
MongoDB vs Firebase
What are some quantitative advantages of using Firebase over MongoDB? (not opinions)
I know that Firebase is a cloud-based service with its own API, but I feel like Mongo may give me greater control in the long run.
Firebase is a real-time engine with backward connectivity. I.e. you might build a cross-platform app where clients subscribe to events on specific data and server actively informs clients about changes
The data layer is hosted for you. Mind that it is highly scalable. It's a nice kickstarter solution. Including auth management
Geo-Fire. Real-time geo coordinates solution.
Evident drawbacks of Firebase are:
You have to pay for it as soon as you start growing
You can't host datalayer (if owning data is critical or you develop an app for some separated subnet)
EDIT: here is a nice article how to replace Firebase in your app with Node.js+MongoDb. It shows how much work you would have to do on your own, and explains, IMHO, why a startup (small app) should begin with Firebase (if real-time updates to clients are required) and proceed with MongoDb (in any case self-written solution) if the project keeps evolving
EDIT 2: after being acquired by Google Firebase now offers various perks on top of its basic features which you would struggle to build on your own:
For development
Cloud Messaging: Deliver and receive messages across platforms reliably
File Storage: Easy file storage (including iOS)
Hosting: deliver static files from Firebase's servers (Included in Free plan)
Crash Reporting: Not a full logging service, but crucial help
For growth
Remote Config: Customize your app on the fly: suitable for A/B testing
Dynamic Links: Send users to the right place inside your app
Notifications: Engage with users at the right moment
Apples and oranges. Firebase is a Backend-as-a-Service containing identity management, realtime data views and a document database. It runs in the cloud.
MongoDB on the other hand is a full fledged database with a rich query language. In principle it runs on your own machine, but there are cloud providers.
If you are looking for the database component only MongoDB is much more mature and feature-rich.
Firebase is designed for real-time updates. It easily integrates with angular. Both are NoSQL databases. MongoDB can also do this with Angular through Socket.io integration. Meteor.js also makes use of MongoDB with an open socket connection for real-time updates.
MongoDB can be run locally, or hosted on many different cloud based providers. Firebase, in my opinion is great for smaller apps, very quick to get up and running. MongoDB is ideal for more robust larger apps, real-time integration is possible but it takes a bit more work.
After using Firebase a considerable amount I've come to find something.
If you intend to use it for large, real time apps, it isn't the best choice. It has its own wide array of problems including a bad error handling system and limitations. You will spend significant time trying to understand Firebase and it's kinks. It's also quite easy for a project to become a monolithic thing that goes out of control. MongoDB is a much better choice as far as a backend for a large app goes.
However, if you need to make a small app or quickly prototype something, Firebase is a great choice. It'll be incredibly easy way to hit the ground running.
I will answer this question in terms of AngularFire, Firebase's library for Angular.
Tl;dr: superpowers. :-)
AngularFire's three-way data binding. Angular binds the view and the $scope, i.e., what your users do in the view automagically updates in the local variables, and when your JavaScript updates a local variable the view automagically updates. With Firebase the cloud database also updates automagically. You don't need to write $http.get or $http.put requests, the data just updates.
Five-way data binding, and seven-way, nine-way, etc. I made a tic-tac-toe game using AngularFire. Two players can play together, with the two views updating the two $scopes and the cloud database. You could make a game with three or more players, all sharing one Firebase database.
AngularFire's OAuth2 library makes authorization easy with Facebook, GitHub, Google, Twitter, tokens, and passwords.
Double security. You can set up your Angular routes to require authorization, and set up rules in Firebase about who can read and write data.
There's no back end. You don't need to make a server with Node and Express. Running your own server can be a lot of work, require knowing about security, require that someone do something if the server goes down, etc.
Fast. If your server is in San Francisco and the client is in San Jose, fine. But for a client in Bangalore connecting to your server will be slower. Firebase is deployed around the world for fast connections everywhere.
Firebase is a suite of features .
Realtime Database
Hosting
Authentication
Storage
Cloud Messaging
Remote Config
Test Lab
Crash Reporting
Notifications
App Indexing
Dynamic Links
Invites
AdWords
AdMob
I believe you are trying to compare Firebase Realtime Database with Mongo DB .
Firebase Realtime Database stores data as JSON format and syncs to all updates of the data to all clients listening to the data . It abstracts you from all complexity that is needed to setup and scale any database . I will not recommend firebase where you have lot of complex scenarios where aggregation of data is needed .(Queries that need SUM/AVERAGE kind of stuff ) . Though this is recently achievable using Firebase functions . Modeling data in Firebase is tricky . But it is the best way to get you started instantaneously .
MongoDB is a database. This give you lot of powerful features. But MongoDB when installed in any platform you need to manage it by yourself .
When i try to choose between Firebase or MongoDB(or any DB ) . I try to answer the following .
Are there many aggregation queries that gets executed .(Like in
case of reporting tool or BI tool ) . If Yes dont go for Firebase
Do i need to perform lot of transaction . (If yes then i would
not like to go with firebase) (Tranactions are somewhat easy though
after introduction of functions but that is also a overhead if lot of
transactions needs to be maintained)
What timeline do i have to get things up and running .(Firebase
is very easy to setup and integrate ).
Do i have expertise to scale up the DB and trouble shoot DB related
stuffs . (Firebase is more like SAAS so no need to worry about scaleability)
In my experience, working with Firebase is a huge advantage if you are trying to do user management, database, messaging sort of app since all of these features are already well integrated.
Like others have said, if you're just focused on the database/querying aspect, stick to mongo.
Firebase provides some good features like real time change reflection , easy integration of authentication mechanism , and lots of other built-in features for rapid web development.
Firebase, really makes Web development so simple that never exists. Firebase database is a fork of MongoDB.
What's the advantage of using Firebase over MongoDB?
You can take advantage of all built-in features of Firebase over MongoDB.
I am just starting to study and develop Mac OSX applications, and I'd like to design an app that uses a database.
I'm not opposed to something like MySQL, but I'm looking for something that can be single user and can be stored directly on the device so internet access is not required. I'd prefer not to resort to writing/reading from a file either.
The closest I've come to find is SQLite, which I am familiar with in Android development, but my question is: is that what most OSX developers use?
I am trying to pose this question in a way that is not opinion-driven, as I know there are countless DBMS out there. Is there one that leads the pack as far as being used with OSX?
Higher Abstractions:
Core Data is available on iOS and OSX.
Realm is a popular alternative to Core Data. Some of the features include:
Fast
Memory efficient
Its safe and easy to use across multiple threads (core data can be tricky here).
Like Core Data it uses the Active Record pattern, where persistence methods are defined on the model objects themselves (unlike the DAO pattern, which uses a separate interface).
Lower Abstractions:
FMDB is a nice Objective-C API that sits over the pure C API to sqlite.
I'm programming a mobile application in Sencha Touch with the backend being Rails. I've found that I've been separating the two more and more as I get deeper into Sencha: where Im basically at the point where Rails only functions as my model storage (database) and Sencha pulls in everything it needs via JSON - reproducing much of the logic already present in rails.
My question, is what do you advise when it comes to delegating functions to each application? I've implemented REST in my Sencha app so it can communicate User, and associated data and store it in the same format.
Is this the right way to go for User Session management? Should I give more power back to rails? IE : where do I store the session? Can I do it on the server? Should I do it as session storage management? Local storage? I just dont know.
I'd appreciate any advice. Thanks.
This is not exactly a specific answer to your question, but I would just like to add that I do think you're on the right lines, and I wouldn't be worried that you've overstepped the architectural line, so to speak.
The web is going from one of rendered documents (where the server did absolutely everything and the browser was essentially dumb) to one where the browser and server are more symmetric peers - and your challenges become more around keeping two fully-fledged MVC apps in sync!
(Arguably, we might see a world where servers become fairly dumb, relative to the richness of the applications on the client side. I guess this is just the next cycle of the thick-client/thin-client pendulum that's been swinging for decades ;-) )
But for mobile, this is not just some arbitrary computer science problem - the mobile device might easily have partial or sporadic network coverage, and so the ultimate test of your application design is to work out whether the user can continue to work on the app when the device is offline - driven into a tunnel, for example - and then re-sync back once the network is available again. A rich, responsive client is really the only way to go.
In that scenario, storing the session richly in the browser seems like a reasonable step. In fact, it's easier to keep session state in sync between a single client and a server than it might for some other types of data record (that might be being manipulated by multiple clients simultaneously).