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.
Related
I have been working on an app that uses Parse as its backend and while this works well, I don't want the app to become too dependent on Parse to work. Having the apps own Core Data implementation is probably the best way to go but the implementation must be flexible so that it can support syncing etc. I have been looking into frameworks like Ensembles, MagicalRecord, iOSDataManager and a number of others. I even looked at FTASync but this has not been updated for years and does not have a good reputation. I felt to ask the community what others may recommend as a good design of a backend system to sync with Parse or other web service. Particularly considering how important the backend is...
Thank you
I have used Ensembles, and I recommend it highly. The open source version is probably fine for your use, with the version 2 version available if you find you need any of the benefits for the paid upgrade.
If you want to see how to build a backend agnostic interface, then I also highly recommend studying the ensembles framework, especially how the interface for the cloud file system interface.
I have implemented my own backend for a specific project, and the interface is quite clear, and extremely useful for teaching one how to design and build such an interface.
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 looking for advice to save me time. I am planning to create a Q&A web app for my university, a stackoverflow clone. I know Rails and I know Angular but I never used them together. One option for me is to use Firebase APIs because it's simple. My question is which is easier, making Angular consume Rails APIs, or firebase APIs? Or is it the same steps no matter what I use to create the APIs ?
This is not going to be the same process. It's also not a direct comparison.
Firebase is a hosted third party 'backend-as-a-service' and you use what they give you for API calls, but you can more or less rely on the API working as advertised (though the docs can be less than useful in places).
That is vs building your own RoR API, which means just that - you pick the groceries just as you want them, but you also get to fix all the bugs on both your API and and your client. You also still need a DB selected.
A more direct comparison would be 'should I pick Node or RoR.' Your question as it's posed is really a question of your own backend implementation or a hosted package.
Which is easier?
There is not a real, single answer.
If by easier you mean 'most direct', Firebase has an Angular library called AngularFire. It translates a lot of Firebase paradigms into a pretty familiar Angular pattern, with a couple of nice extras. You focus on your client code and DB design, it handles the server operations. That seems fairly direct to me.
If by easier you mean 'most flexibility', it's hard to see how building your own doesn't give you that.
If by easier you mean 'less work for me', then 'it depends'. If you are comfortable writing RoR backends and less familiar with NoSQL patterns, then you can probably put it together faster on your own setting your API methods and selecting a DB you are comfortable with. If you feel stronger with Angular than RoR, then learning Firebase paradigms might be a shorter climb.
For what it's worth, given its limited set of API calls, there is probably more focused support for specific questions about Firebase. But you do sacrifice the option of doing it 'your way,' and the RoR community is far larger than Firebase's so you can probably still get plenty of help. Like I said, it can really depend.
I am beginning work on an individual project to bring an existing product out of the dark ages of classic ASP and into the light. My biggest decision to make before embarking on this lengthy journey is determining what frameworks and methodology I will implement for the new design.
Right now I am looking at MVC or MVVM (from what I gather this is just Silverlight?) for the web interface, Entity Framework or something I write myself as the model and MSSQL as the data.
Unfortunately I am just a fledgling programmer and I am not particularly aware of trends in the world of programming in general. I don't know what is just a passing fad and what technologies actually have lasting potential. I would really like to use something that is likely to remain relevant for some time. So I am looking to the professionals here for input on ideas that worked for you, pitfalls to watch out for and things to keep an eye on.
I appreciate any and all suggestions, keeping in mind that using the Microsoft and .Net is something of a prerequisite. I really want to make sure I am headed in the right direction before I start as this will probably take several months.
As for frameworks I personally suggest:
ASP.NET MVC 3 of MVC 4, depending on the question if beta software is allowed.
Entity Framework 4.3 or 5.0. 5.0 is a lot faster (is has auto compilation) but it's still a Release Candidate.
AutoMapper to map between Entities and ViewModels.
Ninject for dependency injection (useful if you want to write unit tests).
JQuery for stuff like clientside validation (integrates perfectly with ASP.NET MVC).
Possible some CSS framework like Bootstrap.
Maybe RestSharp so you can easily perform requests.
In case it's a cloud service (most SaaS are) and you'd like to host it on Azure (brilliant integration with the .NET stack) you'll need the Azure SDK.
As for software achitecture:
Use service layers
Use the repository patterns
Use ViewModels to pass to your view instead of entities
Set up a dependency injection container
That's my advice, I personally find this a golden combination for building enterprise applications (while not wasting too much time configuring lots of things).
Pitfalls:
I don't know if unit testing is really necessary. I should definately keep it in mind while setting up the architecture, but I personally choose to do that later because I don't even know if my product will succeed, so I can better put my time in building a fast Minimal Viable Product.
Don't assume anything. You can waste months of your precious time working on a cool feature that you think everyone will like, but often this is not the case. Do just the absolutely required minimum, and improve it later if your users like it.
I will add more to #Leon suggestions as I see those suggestion are great from application framework perspective, while I wanted to write here from cloud methodology perspective.
As you have chosen SaaS, definitely you are moving completely in Cloud while bring your application and data to cloud all together, that's great!!
There are several layers to any cloud application and to understand lets see what a cloud service stack look like. If we take an example of Windows Azure:
You have Compute, where your application runs with a web server (or not).
You have Azure table store which you can use to store key value pair in a row and then access them very fast.
You have Azure Queue allows decoupling of different parts of a cloud application, enabling cloud applications to be easily built with different technologies and easily scale with traffic needs.
You have Access Control Services to authenticate users through OpenID or AD
You have service bus to connect other services in cloud or on-premise at 3rd party.
You have Azure Blob storage to use as web based flat file server
You have Azure Cache (an in-memory cache build to scale in cloud)
You have SQL Azure as you cloud database
There are many more services which you can explorer and use
So when you decide to move your application from traditional web hosting to cloud you really have to look about how to take advantage of these different cloud services to scale your application when needed and save you lots of money.
With you application in Cloud you try something as below:
Keep you application logic as small as possible
Keep your static content outside the compute
Use cloud based cache for fast access as application scale out
Move data out of traditional RDBMS databases to NoSQL Framework (key-value pair, document etc to save money and flexibility), if possible and applicable
Take advantage of other available services to reduce application complexity
If you consider above aspect in your mind you will create a true cloud based application which will be fast and will save you money.
How can i write a cloud-aware application? e.g. an application that takes benefit of being deployed on cloud. Is it same as an application that runs or a vps/dedicated server? if not then what are the differences? are there any design changes? What are the procedures that i need to take if i am to migrate an application to cloud-aware?
Also i am about to implement a web application idea which would need features like security, performance, caching, and more importantly free. I have been comparing some frameworks and found that django has least RAM/CPU usage and works great in prefork+threaded mode, but i have also read that django based sites stop to respond with huge load of connections. Other frameworks that i have seen/know are Zend, CakePHP, Lithium/Cake3, CodeIgnitor, Symfony, Ruby on Rails....
So i would leave this to your opinion as well, suggest me a good free framework based on my needs.
Finally thanks for reading the essay ;)
I feel a matrix moment coming on... "what is the cloud? The cloud is all around us, a prison for your program..." (what? the FAQ said bring your sense of humour...)
Ok so seriously, what is the cloud? It depends on the implementation but usual features include scalable computing resource and a charge per cpu-hour, storage area etc. So yes, it is a bit like developing on your VPS/a normal server.
As I understand it, Google App Engine allows you to consume as much as you want. The back-end resource management is done by Google and billed to you and you pay for what you use. I believe there's even a free threshold.
Amazon EC2 exposes an API that actually allows you to add virtual machine instances (someone correct me please if I'm wrong) having pre-configured them, deploy another instance of your web app, talk between private IP ranges if you wish (slicehost definitely allow this). As such, EC2 can allow you to act like a giant load balancer on the front-end passing work off to a whole number of VMs on the back end, or expose all that publicly, take your pick. I'm not sure on the exact detail because I didn't build the system but that's how I understand it.
I have a feeling (but I know least about Azure) that on Azure, resource management is done automatically, for you, by Microsoft, based on what your app uses.
So, in summary, the cloud is different things depending on which particular cloud you choose. EC2 seems to expose an API for managing resource, GAE and Azure appear to be environments which grow and shrink in the background based on your use.
Note: I am aware there are certain constraints developing in GAE, particularly with Java. In a minute, I'll edit in another thread where someone made an excellent comment on one of my posts to this effect.
Edit as promised, see this thread: Cloud Agnostic Architecture?
As for a choice of framework, it really doesn't matter as far as I'm concerned. If you are planning on deploying to one of these platforms you might want to check framework/language availability. I personally have just started Django and love it, having learnt python a while ago, so, in my totally unbiased opinion, use Django. Other developers will probably recommend other things, based on their preferences. What do you know? What are you most comfortable with? What do you like the most? I'd go with that. I chose Django purely because I'm not such a big fan of PHP, I like Python and I was comfortable with the framework when I initially played around with it.
Edit: So how do you write cloud-aware code? You design your software in such a way it fits on one of these architectures. Again, see the cloud-agnostic thread for some really good discussion on ways of doing this. For example, you might talk to some services on GAE which scale. That they are on GAE (example) doesn't really matter, you use loose coupling ideas. In essence, this is just a step up from the web service idea.
Also, another feature of the cloud I forgot to mention is the idea of CDN's being provided for you - some cloud implementations might move your data around the globe to make it more efficient to serve, or just because that's where they've got space. If that's an issue, don't use the cloud.
I cannot answer your question - I'm not experienced in such projects - but I can tell you one thing... both CakePHP and CodeIgniter are designed for PHP4 - in other words: for really old technology. And it seems nothing is going to change in their case. Symfony (especially 2.0 version which is still in heavy beta) is worth considering, but as I said on the very beginning - I can not support this with my own experience.
For designing applications for deployment for the cloud, the main thing to consider if recoverability. If your server is terminated, you may lose all of your data. If you're deploying on Amazon, I'd recommend putting all data that you need persisted onto an Elastic Block Storage (EBS) device. This would be data like user generated content/files, the database files and logs. I also use the EBS snapshot on a 5 day rotation so that's backed up itself. That said, I've had a cloud server up on AWS for over a year without any issues.
As for frameworks, I'm giving Grails a try at the minute and I'm quite enjoying it. Built to be syntactically similar to Rails but runs on the JVM. It means you can take advantage of all the Java goodness, like threading, concurrency and all the great libraries out there to build your web application.