Backend stack choice for your iOS or Android app can be tough. Which is why here we look into Firebase vs Ruby on Rails-written backend, and investigate if there are any “kamikaze choices” of backend technology for a mobile application development. Are there any reasons not to use Firebase or Ruby? Is it possible to use firebase with Ruby on Rails? Let’s discover.
Would you agree with me if I state that marketing is a contest for people’s attention? More to this, that marketing is too important to be left for a marketing department. It has crawled it’s way even to the niche that seems to have nothing to do with promotion - software development; and marketing is already a part of it. Developers choose a solution for their project based on the stars a few similar libraries have on Github, and the amount of “tweets” of the account we are able to predict which technology is going to actively grow this year. This digital environment puts us at risk of becoming a victim of hype, where we might be misled - just falling in for the highly-recommended hypie tool, created by devilish marketers.
One of the tools everybody has been talking about recently is Firebase and its API, a mobile and web application development platform developed by Firebase, Inc. in 2011, then acquired by Google in 2014 as Wikipedia states. Before Firebase got acquired by Google in 2014, there was no evidence of the product’s rapid growth, and some claimed Firebase disadvantages are present. Though some things have changed since that time. Firebase has been implemented in the process of making apps like:
- Shazam
- Alibaba order & delivery app
- Todoist app organizer
Giants like Shazam would obviously not go into wanton budget spending, so consequently, for them Firebase was quite a reasonable choice. We tried to look at pros and cons of Firebase implementation, trying to figure out at which project it would be a good fit.
But there are 2 points to make before we dive into Firebase advantages - to get rid of all possible misunderstandings that might occur:
- Firebase wasn’t originally meant to be a backend option, this platform has a database at its core. It’s not like there are miraculously developed apps without the integrated server part.
- It is not a relational database though. Firebase is a NoSQL base, with all of it’s pros and cons attached + specific firebase development environment and architecture.
What is a NoSQL Database?
According to Basho, NoSQL (that means “Not SQL” or “Not Only SQL”) is an approach to databases that represents a shift away from traditional relational database management systems (RDBMS). To define NoSQL, it is helpful to start by describing SQL, which is a query language used by RDBMS. Relational databases rely on tables, columns, rows, or schemas to organize and retrieve data. In contrast, NoSQL databases do not rely on these structures and use more flexible data models. NoSQL is particularly useful for storing large amounts of unstructured data, that is gained faster than structured data is.
On the contrary, Structured Query Language (SQL) is a programming language used by database architects to design relational databases. In an SQL database like MySQL, Sybase, Oracle, or IBM DM2, SQL executes queries, retrieves data, and edits data by updating, deleting, or creating new records. SQL is a lightweight, declarative language that does a lot of heavy lifting for the relational database, acting like a database’s version of a server-side script.
[Source: Upwork]
Now as we’ve insured we’re on the same page, let’s extract a few advantages of using Firebase.
1. Firebase might be less time-consuming.
Once you get to building a realtime app with Firebase as backend, there is no server part development included - as NoSQLs do not require it. So, in a short-term perspective this platform may need less time to be developed. Once you want to create a simple app, with a tiny no-big-data backend for it, then Firebase can be quickly implemented into the project. When you have a set deadline or an upcoming event Firebase might be a decent temporary solution.
2. Firebase is a real-time solution.
If you need to have instant push-notifications and updates, then you need what is called a real-time app. In case of Firebase, there are many codelabs written for it - and some of them show you how to built a chat application for different platforms:
Which gives us a reason to conform - with all advantages and disadvantages of Firebase, it meets the needs of real-time communication apps.
3. Firebase development is a pretty secure solution.
As long as Firebase is built on Google’s infrastructure, it gives a good reason to state it is a well - protected solution. Although you could double your secureness by defining the rules of NoSQL database, as by default you don’t have control over the data stored - it is hosted on the servers of Google.
Every Rose Has Its Thorn.
So if you intend that thousands of people will use your product - then Firebase might be a worthless solution.
Once you choose Firebase as the primary backend stack, there are a few points you need to consider. Not the disadvantages of using firebase, just things you need to know about. With Firebase, you are free to choose the pricing plan - but the one fitting for the real time applications is a “pay as you go” one. With this plan, you pay only for the resources you consume, so the more users your app gets - the more will backend maintenance cost you.
Many people consider this to be amore of a plus - as many users on your product is fantastic, isn’t it? However, in the very beginning it is tough to monetize all of them - you need to make people love your product first. And in case with Firebase, you’ll get to spend money on all of your free users. So if you intend that thousands of people will use your product - then Firebase might be a worthless solution.
Rumor has it that Firebase also has hidden costs, when after a rapid user or usage growth you might get charged without a warning; so if you are not worried about being silently charged - then go for it.
Which is why another decent backend option for your app is a Ruby backend + a certain server for data storage (this is the approach we frequently use when working on our customers’ projects). Besides, Ruby on Rails backend and Firebase’s pluses are more or less the same. In Ruby’s case, they go as follows:
1. Ruby is a simple language.
There is a short list of frameworks to implement on it, even if compared to the PHP language and its source code, but there many gems - a complete system of multi-purpose libraries for Ruby. Samely simple is the languages architectural pattern - MVC, with clear entity dependencies.
Read more about the types and functions of architectural patterns
2. Ruby’s community stood the test of time.
Unlike the newly-formed Firebase developer society, Ruby’s community is gigantic, it has plenty of open-source gems, which allows coders to quickly open and develop complex applications. More to this, due to a certain Ruby’s “fame”, many famous services (like Stripe) have ready-made libraries for Ruby.
3. You can test your code on Ruby.
Ruby has an advanced development infrastructure that allows to maximize and write unit-tests all over the project - to reduce bugs in new and existing features. This will also cut down the cost of the future change in the middle of development process.
4. You are not tied to a specific type of a database.
Or, more precisely, to a specific type of a database. Ruby allows you to use any relational or oriental databases, as well as NoSQL and other different technologies - including Elasticsearch, Reddis and other less popular ones.
5. Ruby’s syntax is a piece of cake.
There are no data types in Ruby - and, respectively, no need to look whether the types of data are structured appropriately. Moreover, the composable error system(also called logging system) is also present; this makes search for an error easier, and then allows to fix the occurring bugs faster.
SO, Firebase vs RoR - Which One to Choose and When?
After the Firebase vs Rails comparison, the diplomatic answer is - it depends, on your aims mainly.
Firebase as a backend for mobile app development is a fit for you if you need one of the following:
- A small real-time app with simple features
- A simple app where you need to store loads and loads
- A concept-proving app that will later be fully-refurbished
Though If you are looking to create a complex mobile system, with perplexed algorithms and features, Ruby on Rails mobile app backend is a great choice as well. Besides, if an application doesn’t have a clear structure, in the non-relational database, which Firebase cloud backend undoubtedly is, you can not properly select the data out of it. The business logics created on Firebase is commonly put into the base; due to this, a mish-mash might appear when the application logics is a bit perplexed. And let’s not forget that you are charged every time you get a new user, even without informing you - your money might be simply transferred one morning when you wake up.
Hope reading this helped you to figure out how to use Firebase in mobile apps development - if you feel that it fits your needs.
Read also: React Native vs Native App Development - which one to choose?
Written by Oleg Tsarenko & Elina Bessarabova
