What is Firebase?

Wednesday 13 October 2021 07:15 PM Beirut Time · 911

Wajdi Alkayal

WMK MOBILE APPLITIION

About Services Clients Contact

☰ open

What is Firebase?

#html #css #javascript #webdev

BIGDATA WMKTECH NEWS Top List

BY:WMK-IT

Firebase is a development platform known originally for its realtime database that’s still at its core a multi-node, key-value database optimized for synchronizing data, often between user machines or smartphones and centralized storage in the cloud. It’s designed to make life easier for developers by handling much of the pushing and pulling of data. That relieves app developers of the programming burdens associated with managing versions or locations. They can write the new bits to Firebase and the data will be consistent throughout the system.

Firebase is valued largely because it can constantly propagate and synchronize changes between local copies of information stored on users’ machines with versions kept in the cloud. Firebase eliminates many of the challenges of mixing authentication, synchronization, and segregation by juggling multiple versions and ensuring the right bits are the same throughout the system.

Today, Firebase is a central part of the Google cloud development tool kit. The product, a culmination of years of evolution, was positioned at the center of a mobile backend-as-a-service offering from the company known as Firebase, which Google acquired in 2014. Firebase is available through Google. Meanwhile, open source libraries and tools are available that interface with Firebase.

Firebase was early to take the form of a database that is not limited to one physical computer. Its modern form allows it to split workloads between multiple machines by either splitting the datasets, creating copies of their bits, or both. Firebase extends the algorithms used for datacenter consistency to the entire network by treating the data stored on users’ phones or desktops as local versions of the big database. In essence, your phone or your laptop is now part of the cloud.

While Firebase began as a separate company, Google has tightly integrated the software with its other cloud software products. Firebase ML, for instance, is a collection of libraries that leverage the power of Google’s other tools, like AutoML or TensorFlow. Adding features like those used to find text in an image or find appropriate labels is relatively easy.

Developers don’t need to worry about the dangers of inconsistencies between the data on, say, a user’s phone and the central database. Once the data is stored locally, Firebase ships copies to cloud servers so both versions are consistent. The transfer also works in the other direction because changes made on the cloud are replicated locally. Server-side developers can communicate with client software running by simply writing data to the Firebase cloud.

Google’s Cloud Functions, a serverless option, can also be integrated with Firebase so new data can trigger functions. When a user first logs in, or each time the database changes, a function will be invoked that can then trigger other events or functions in the Google cloud or elsewhere. These functions can be used to post-process images, clean up text, or ensure data consistency.

Firebase Cloud Messaging adds an additional layer of organization to the process of sending messages by grouping users together by either name or topic. Once initialized, Firebase can ship event notifications as messages to predefined groups or users who have subscribed to certain topics.

Google has also built out a number of standard Firebase use cases, like resizing images or triggering email messages, that simplify some common tasks.

Flutter is another higher-level tool, also built by Google, that integrates sophisticated user interface widgets with the database underneath. It works with a number of databases that range from the simple, like SQLite, to the full-featured, like PostgreSQL. It can also rely upon Firebase itself.

How are established database companies approaching the problem?

When it comes to web development, most older databases placed too many programmatic chores on the backs of developers. These databases began life by storing data on just one machine. While the major databases have long expanded to replicate and share data across multiple databases and machines, they have generally avoided integration with the small, local copies of data cached on users’ machines. The cloud vendors are extending their own databases, often with extra layers.

AWS created Amplify by linking together several of its lower-level tools to handle authentication and data storage. The DataStore layer will store information locally and push it to the AWS cloud when a connection is available. The tool also bundles a number of other services, including hosting and a set of server apps for editing data structures and content.

What about the upstarts?

The problems Firebase addresses are common in modern development. So it is not surprising that upstart players are working to build on, or even outright replace, Firebase.

Supabase and NHost are building backend alternatives to Firebase by adding layers for authentication and replication to PostgreSQL. They’ve married more modern standards like GraphQL with a server-side core built on a trusted SQL-based engine.

Much of the competition is coming from full development platforms that are also adding layers to simplify interacting with the database. Parse, for instance, is a full platform for building client-server apps that integrate with a central database. It adds features like a GraphQL interface, a file system, and a notifications framework to a core that rests upon either PostgreSQL or MongoDB. Back4App is another layer built on top of Parse that simplifies the coding even further.

Some other competition comes from non-database companies that offer many of the features as part of mobile app development frameworks. Products like Xamarin are now more tightly integrated with clouds like Azure. GameSparks is designed to simplify building backends for networked games, a job that requires doing much of the same synchronization as Firebase.

Other tools, like Pubnub, have approached the problem of streaming messages for tracking virtual groups and spaces, another challenge that requires much of the same support Firebase provides. In some cases, such focused products may deliver exactly what is needed without building on top of Firebase.

Is there anything Firebase can’t do?

Firebase is an ideal tool for helping developers get started quickly because it handles much of the work of replicating data and pushing event notifications. It abstracts away the challenges of storing data simultaneously in a user’s phone and a central database.

The main data model is limited to NoSQL, although some developers have created FireSQL, a tool that adds SQL-like syntax. Firebase pricing is set according to each read or write, a feature that appeals to earlier developers but can sometimes surprise developers if the price jumps rapidly with a product’s growing popularity

What is Firebase? The complete story, abridged.

It seems like there’s an app for everything these days. Well, almost everything. I haven’t found an app that helps me remove impacted earwax. It happens to me sometimes, and it’s super obnoxious. But someone could build it! I’ll contribute to your Kickstarter.
If you’re the enterprising sort of person that tackles humanity’s urgent needs with a mobile app, you’ll want to know about Firebase. Firebase is Google’s mobile application development platform that helps you build, improve, and grow your app.
Here it is again in bigger letters, for impact:
Firebase is Google’s mobile application development platform that helps you build, improve, and grow your app.
And now you know what Firebase is. In theory, this blog post could be done!
Beyond the marketing copy
I have mixed feelings when someone asks me “What is Firebase?” (which happens a lot, since I work on it). On the one hand, I’m glad to know there’s interest! Thanks for asking! On the other hand, there’s so much to it, where do I even begin? The definition above is accurate, but it’s not very specific at all.
I like retro games, so I’ll try to explain Firebase again with a picture:

This makes a lot of sense — if you are me! But I understand that many of you are not me, so I’m sorry if you weren’t helped by that.

All joking aside (for the remainder of this paragraph only), Firebase is a toolset to “build, improve, and grow your app”, and the tools it gives you cover a large portion of the services that developers would normally have to build themselves, but don’t really want to build, because they’d rather be focusing on the app experience itself. This includes things like analytics, authentication, databases, configuration, file storage, push messaging, and the list goes on. The services are hosted in the cloud, and scale with little to no effort on the part of the developer.

When I say “hosted in the cloud”, I mean that the products have backend components that are fully maintained and operated by Google. Client SDKs provided by Firebase interact with these backend services directly, with no need to establish any middleware between your app and the service. So, if you’re using one of the Firebase database options, you typically write code to query the database in your client app.

This is different than traditional app development, which typically involves writing both frontend and backend software. The frontend code just invokes API endpoints exposed by the backend, and the backend code actually does the work. However, with Firebase products, the traditional backend is bypassed, putting the work into the client. Administrative access to each of these products is provided by the Firebase console.

If you identify as a “backend engineer”, you might be hearing this and thinking that your job is being eliminated! “OMG, no more backends — now I have to learn frontend development!” This isn’t really true, as there are some things that simply ought to be on the backend for a variety of reasons. Firebase recognizes this, and offers a way to do some backend development, where it makes sense for the app you work on. So, don’t worry, your job is safe, and I’ll talk more about this later on

Because of the way Firebase products work, some people might call Firebase a “platform as a service” or a “backend as a service”. I’ve never really felt comfortable wedging Firebase fully into one of these boxes. Firebase is Firebase. (I know, this statement obviously doesn’t help explain what Firebase is, which is supposed to be the purpose of this article!)

Anyway, at the time of this writing, I count 17 individual products in the Firebase suite. Here’s another helpful picture:

It’s said that a picture is worth a thousand words. I counted 37 in the picture, including two things that are not really words. Turns out, you’re in luck today, because I’m going to try to use up the other metaphorical 963 words in this article to help explain that picture a little better. But I’m not going to count them.

And if you want to find out what Firebase is not, well, you’ll have to read all the way to the end of this post. No skipping ahead! You’ll miss all the jokes!

What sort of apps is Firebase good for?

There’s really no limit to the types of apps that can be helped by Firebase products. There are only limits to the platforms it can be used on. iOS and Android are the primary targets for the Firebase SDKs, and there’s increasing support for web, Flutter, Unity, and C++. You should also know there’s an Admin SDK available for a variety of languages, to be used with any backend components you might require.

On top of those SDKs, there’s a library called FirebaseUI (Android, iOS, web) that provides a bunch of helpful utilities to make development with Firebase even easier. And there are also projects such as AngularFire that wrap the web SDKs for use with Angular. These are open source. Firebase likes open source.

Here are a couple examples of developers using Firebase.

Greta builds mobile games with Unity:

And Shawn is building a social networking app:

You can tell from the looks on their faces that they’re having a blast building apps with Firebase.

Greta doesn’t think of herself as an “app developer”. Games are not apps! Or are they? I don’t know. But games and traditional apps have a lot of similar needs that could be met by Firebase. For fun, I just imagine that games are apps with a highly customized UI, that happen to have a really strong gamification strategy. Anyway, Greta and Shawn face similar challenges, despite the fact they’re building very different things.

To get a sense of what Firebase products actually do in an app, I’ll go through the individual products from that image above. You saw, in that image way up there, three main groups of products: “build”, “improve”, and “grow” (but these categorizations are not strict). I’ll talk about the “build” group first, and give some specific cases where Greta and Shawn make use of each product.

Build your app — creating the “guts”

The “build” group of products are these:

Authentication — user login and identity
Realtime Database — realtime, cloud hosted, NoSQL database
Cloud Firestore — realtime, cloud hosted, NoSQL database
Cloud Storage — massively scalable file storage
Cloud Functions — “serverless”, event driven backend
Firebase Hosting — global web hosting
ML Kit —SDK for common ML tasks

Firebase Authentication takes care of getting your users logged in and identified. This product is essential to getting some of the other products configured properly, especially if you need to restrict access to per-user data (which nearly every app will want to do).

What’s special about Firebase Authentication is that it makes easy to perform secure logins, which is incredibly difficult to implement correctly on your own. And it’s “federated”, which is to say that the United Federation of Planets encourages its use. Here’s what the Federation’s Captain Picard thinks of implementing your own auth system:

Others may say that “federated identity” means that you can link a user’s accounts from the various identity providers (Facebook, Twitter, Google, GitHub) into a single account on Firebase Authentication. But I like my definition better.

In any event, I strongly recommend learning Authentication and integrating it into your app first, which will hopefully prompt you to think about the security of per-user data that you might store using some of the other “build” group products.

Firebase Realtime Database and Cloud Firestore provide database services. I listed them both as “realtime, cloud hosted, NoSQL databases”. They have individual strengths and weaknesses, and you may need to do some research to figure out which one is better for your needs. Hint: start with Cloud Firestore, as it likely addresses more of your needs (and it’s also massively scalable). You can use either one, or both together, if that suits your app.

It’s worth noting that Firestore is technically a Google Cloud product, not a Firebase product. Why is it listed with Firebase? Firebase adds SDKs to use in your mobile app to make direct data access possible, removing the need for that pesky middleware component. There are other products listed here with a similar relationship with Google Cloud, which I’ll also note.

What’s really special about these databases is that they give you “realtime” updates to data as it changes in the database. You use the client SDK to set up a “listener” at the location of the data your app wants to use, and the listener gets invoked with that data repeatedly, every time a change is observed. This lets you keep your app’s display fresh, without having to poll the data of interest.

With realtime data like this, our friend Greta uses realtime data in her games to maintain live leaderboards of in-game events for everyone to see. Shawn uses them to provide messaging between friends on his social network. Because we just don’t have enough chat apps out there!

Fun fact: Realtime Database was the original “Firebase” before it joined Google in 2014. To this day, people still colloquially (but incorrectly) refer to Realtime Database as just “Firebase”. But you shouldn’t do that, because it’s wrong.

Greta’s games use Cloud Storage to let people upload custom avatars for display in the game, and Shawn’s social network lets people share their photos with each other. Neither of them worry about running out of space, because Cloud Storage scales to exabytes of data. Have you ever stored an exabyte of data? Do you even have a mental model of how much data that is? I don’t! But I ran some numbers, and let’s just say it’s enough for every person on the planet to store 1000 high quality photos. Ping me if you publish the app that achieves this feat!

Authentication works extremely well with these three products with the use of security rules (for Realtime Database, Firestore, and Cloud Storage) that you can use to set access control to your data at the source. This ensures that clients can access that data only in the ways you allow, avoiding the tragic situation with the lolrus above. Users signed into an app with Authentication will automatically provide an identification token that you can use in your rules to protect who can read and write which items of data. So, if you store personal data about your users, definitely use Firebase Authentication with security rules to limit access appropriately. You may even get a gentle reminder from Firebase if your rules appear overly permissive.Cloud Functions is yet another a Google Cloud product that works well with other Firebase and Cloud products. Using the Firebase SDKs for Cloud Functions, you can write and deploy code, running on Google “serverless” infrastructure, that automatically responds to events coming from other Firebase products. That’s right, it’s serverless!When people say “serverless”, they don’t suggest a lack of servers. With a serverless backend architecture, there are still servers in play, you just don’t have to know much about them. You don’t provision, maintain, scale, or do any of the devops required in a traditional (or “serverful”, my word) architecture. You just write and deploy code, and Google does the rest.

Cloud Functions for Firebase is the one product of the entire Firebase suite that actually has you writing backend code. In my opinion, some types of code should be running in a controlled backend environment. And you should be giving those backend devs a job, because of that promise I made earlier.

The list of things you can do with Cloud Functions is ginormous — take a look at all these samples! But I’ll boil it down to one main concept: Firebase products (database, storage, auth, etc) emit events when data changes within the product, and your code deployed to Cloud Functions is triggered in response to those events.

Shawn uses Cloud Functions to automatically delete data from his database and storage when someone deletes their account (because user privacy must be protected in many situations, and getting billed for unused data is terrible). Greta uses Cloud Functions to execute game logic and scoring on a secure backend, because she knows that hackers may try to cheat by reverse engineering her game code.

Firebase Hosting is a secure, global web hosting CDN (Content Delivery Network). It’s really good at quickly delivering static content (HTML, CSS, JS, images) using servers that are close to your users. And you can get it set up quickly, with or without your custom domain, along with a provisioned SSL certificate that costs you nothing.

Firebase Hosting has one important point of integration with the rest of Firebase, and that’s through Cloud Functions. Firebase Hosting lets you proxy the request and response to and from Cloud Functions when writing HTTP type functions. And, even better, it’ll cache the responses from your functions, if you configure them properly. What a great way to build a “RESTful” API!

ML Kit for Firebase lets you take advantage of a wealth of machine learning expertise from Google, without having to know anything about ML. This is great for me, because I don’t know anything about ML! But what I get out of ML Kit is the ability to recognize things that my device camera captures, such as text, faces, and landmarks. And it can work on my mobile device with very limited computing power. For those of your with more advanced understanding of ML (again, not me), you can upload a TensorFlow model for more sophisticated use cases. The roadmap for machine learning products at Firebase will be fully “federated”:

Shawn uses ML Kit to locate faces in the photos and videos uploaded by the users of his social network, then he performs some image manipulation on them. Greta doesn’t use ML Kit yet, because there’s no Unity implementation for the SDK yet. Dang! But if there was, she might use it to let people scan QR “coupon” codes for free promotional in-game items.

And that’s it for the “build” group. Lots of useful tools in there! But there’s still much left to discuss about Firebase.

Grow your app — attract and retain users

The “grow” group of products are these:

Analytics — understand your users, and how they use your app
Predictions — apply machine learning to analytics to predict user behavior
Cloud Messaging — send messages and notifications to users
Remote Config — customize your app without deploying a new version; monitor the changes
A/B Testing — run marketing and usability experiments to see what works best
Dynamic Links — enable native app conversions, user sharing, and marketing campaigns
App Indexing — re-engage users with Google Search integration
In-App Messaging — engage your active users with targeted messages

Google Analytics for Firebase is the core of the “grow” offering. If you need to better know your users, and how they make use of your app, Analytics can show you that. When you publish an app for the first time, you might have an idea who your user base is going to be, where they live, and how they might use your app. And those ideas might be completely wrong in practice! The only way to know for sure is to collect data, and that’s where Analytics helps.