BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Writing Firebase Apps on Windows, Mac, and Linux Using Electron

Writing Firebase Apps on Windows, Mac, and Linux Using Electron

Bookmarks

Key Takeaways

  • Electron-Firebase provides a quickstart framework for building cloud-connected applications on Windows, macOS, and Linux.
  • By integrating Electron and Firebase, just a few configuration settings allow you to include a complete authentication workflow into your app using email/password, phone number, Google, Facebook, or many other identity providers.
  • A simplified API is provided for secure cloud file and database access in the context of the authenticated user and application.
  • Electron-Firebase is unusual in being both an NPM module and an example application framework, and it spans both coding worlds of the Browser JavaScript environment and the host Node.js environment.

What Electron-Firebase provides for you

The unique advantages of using Electron-Firebase include:

  • An authentication workflow for many identity providers including social, phone and email
  • Secure communication between the Electron Browser and Main node.js processes
  • Authentication persistence, so that a user can launch your app without signing in again
  • Authorized user access to database and cloud storage with Firebase security rules
  • API access to Firebase Cloud Storage, which is not supported out of the box with the Node.js client
  • Firebase Cloud Storage listing and searching capability
  • Persistence of window positions on the screen
  • An example application for a quick start in creating your own application

Filling a gap in our software tools

Cross-platform development tools have been around for eons, but with the emergence of Electron, developers finally have true portability, access to the operating system and network, and a full-feature front-end user interface.

But Electron is only for the host environment, and building a custom scalable cloud back-end is a complex process.

When mobile apps emerged, it became clear that they were front-end portals into the cloud. Since mobile developers and startups often didn’t have the time, skill, and resources to build the needed cloud back-end, a new category emerged: Mobile-Backend-as-a-Service.

Of the several options that thrived, Firebase is one of the most capable, is owned by Google, and continues to expand with new features.

But as MBaaS systems were foremost intended for mobile apps, they largely ignored the client capability to build PC apps for the desktop and laptop.

Electron-Firebase bridges this gap, giving Electron connections to a rich set of Cloud services, and giving Firebase a PC client build environment.

For those followers of the model-view-controller paradigm, Electron-Firebase is a near-perfect fit.

But is this really cross-platform? The integration code and example application that form Electron-Firebase runs on Windows, MacOS, and Linux, yet has zero platform-specific code or configuration variations. This approach succeeds because Electron uses Chromium Browser technology to create platform-independent user experiences, and Node.js as platform-agnostic access to the operating system and network.

What’s Opinionated

The design of Electron-Firebase is specifically opinionated in a few key areas:

  • The integration between Electron and Firebase should be sufficiently complete that a developer can install this framework and quickly get started writing their application.
  • The Electron "Main" process is where most Firebase access should happen since it has access to all of the Node.js APIs and operating system. The exception being the firebaseui authentication workflow which needs to execute in the browser (a.k.a. Electron "Renderer" process).
  • Access to the Firebase database and storage should enforce authorization so that your app can only perform operations in the context of the signed-in user and application.
  • Communication between the Browser/Renderer and Main/node.js processes must be secured when the browser content contains foreign content or private information, such as the firebaseui workflow.

What’s NOT opinionated

Electron-Firebase is specifically not opinionated in these areas:

  • There is no application build and packaging process since there are multiple ways to accomplish this.
  • There is no preferred UI framework, because there are so many excellent choices. The example app uses Bootstrap in a minimal way.
  • There is no automated test framework, again because there are many options which carry their own overhead, so unit tests are simple JavaScript modules.
  • The Firebase API and capability set continues to expand, such as crash analytics, performance monitoring, and so on. Electron-Firebase does not integrate Firebase any further than the application foundation of authentication, database, and file storage.

What you need and how to get started

The Electron-Firebase framework works best for JavaScript engineers, because the presentation layer executes on the Chrome Browser and so is authored in HTML, CSS, and JavaScript, or whatever front-end framework that you prefer. The system code that interfaces to Firebase and the operating system, and any other services, is a Node.js process and can support either JavaScript or TypeScript. The development platform can be any of Windows, macOS, or Linux - in fact all three are encouraged for complete testing of your application. The only prerequisites on the development platform are Node.js and npm.

You will need to set up and configure your own Firebase account and select the Blaze level of service, however the free tier is generous and should see you through any development effort and maybe even smaller-scale deployments. Scaling-up user volume is not an architectural concern as Firebase is designed to handle scaling automatically.

For each identity provider that you would like to support, for example "sign in with Facebook", you will need to set up a developer account, create an authentication app definition with the ID provider, and configure the trust relationship between Firebase and the ID provider. This is all explained in step-by-step detail in the installation instructions at Electron-Firebase.

Authentication workflow

The Firebase team created firebaseui, a complete user experience workflow for integrating phone and email authentication, and third-party identity providers. Because firebaseui runs in a web browser, it’s a natural foundation for building authentication into Electron. Electron-Firebase handles launching the authentication window and running firebaseui. However ...

The Main process is the preferred choice for running the interface to Firebase as it has access to the operating system and network without the security constraints of the browser, and Firebase supports a Node.js client - so that looks like an ideal match, right? Somehow the user’s security context needs to get conveyed between firebaseui in the browser, and the Firebase Node.js client running in the Main process.

The first challenge is the security vulnerability of running firebaseui at all, since it’s foreign code as far as the Electron developer is concerned. Fortunately Electron has a switch that locks down browser window security so that any webpage code cannot get access to system functions or the Electron Main process, like the Inter-Process Communication (IPC) mechanism for convenient communication between the Browser Renderer process and the Main Node.js process.

Secure communication between the Browser and Main processes

Based on these conflicting requirements, if we properly secure the browser that runs firebaseui, we also cannot use Electron IPC to convey the user’s authentication context back to the Node.js process.

Electron-Firebase solves this problem by hosting an HTTPS web service in Node.js, so that the browser webpage that launches firebaseui simply needs to call a REST API to transmit the authentication context. Electron-Firebase generates a host X.509 certificate on the fly every time that it runs, and further has security checks on the certificate within the HTTPS service, to ensure private communications that prevent malicious snooping of the user’s authentication context.

After sign-in, this secure web service can be used by any browser process to communicate securely with the Node.js process, even if it is outside of Electron.

Authentication persistence

We are all familiar with single-page web apps that maintain an authentication session over weeks or months, even if the browser is terminated, avoiding the inconvenience of challenging the user for their credentials too often. This capability is built into firebaseui. However ...

There are really two authentication contexts that are represented by tokens. The first is the association between the user and their identity to Firebase, and, depending on the authentication method, the identity validation from an OAuth or OIDC provider which in turn is used to authenticate to Firebase. Electron-Firebase handles the token management and gives the Node.js process a valid authentication context, whether the user performed a complete sign-in with credentials, or whether the app was started using authentication persistence.

Authorized user access to the Firestore database

Firebase includes a document store - a NOSQL database - called Firestore.

The Firestore database incorporates a sophisticated security rules engine. Applying security rules is pretty much mandatory for any application to function reasonably, but it can be daunting to create specific rules and test them. Some developers disable security rules during development, but that may hide critical problems until the application goes into production. Making a mistake in a security rule definition can cause the entire database to become unavailable so it’s particularly tricky once an app is in production.

That said, the fundamental usage pattern is straightforward: a user should be able to access their own data set and not the data set of another user - but that’s not how Firebase works out of the box. Electron-Firebase solves this by deploying a default set of security rules that should solve for a wide range of app requirements. It works by exposing a data access API through three JavaScript objects which represent Firestore subtrees:

  • .doc - (/users/[userid]/) for only the signed-in user's documents in Firestore
  • .app - (/apps/[appid]/) for only the app being used, accessible to all users
  • .public - (/apps/public/) for any user or app to read or write

Using these Firestore interface objects instead of the Firestore API will guarantee a safe operating experience for all users during development, testing, and production.

Authorized user access to the Firebase Cloud Storage

Complementing the Firestore database, Firebase includes object (file) storage called Firebase Cloud Storage. And like Firestore, Cloud Storage may be secured with its own version of the security rules engine, which has similar caveats for rules development and deployment. However ...

There is an additional challenge because the Node.js client does not include an interface to Firebase Cloud Storage. To simplify access to Cloud Storage, Electron-Firebase provides an API that uses a cloud-native REST API, and exposes three secure objects in a similar fashion to Firestore:

  • .file - file access limited to the current signed-in user
  • .app - file access limited to any user of this app but not other apps
  • .public - file access without restriction

As with the Firestore API, using these JavaScript objects will guarantee safe access to files in Firebase Cloud Storage.

Firebase Cloud Storage listing and searching capability

The functionality of Firebase Cloud Storage is pretty straightforward - upload a file, download a file, and delete a file. Electron-Firebase extends the Cloud Firestore API by providing file listing and searching within the JavaScript access objects. Each file operation is tracked using the Firebase .doc, .app, and .public objects, allowing listing and searching across file meta information.

Persistence of window positions

A simple window manager is available within Electron-Firebase, for opening windows and popup dialogs, closing windows, and listing open windows. Moveable windows will also retain their position and state, so that every time the app is opened, windows get restored to their prior locations and dimensions.

An example application

Most NPM installations simply install or update an NPM Package containing a Node.js Module. Electron-Firebase does indeed install a module called "electron-firebase", but it also installs an example application into the root of the project. For this reason, you generally won’t want to install electron-firebase into an existing project because it won’t be so easy to cleanly remove it. You are better off creating a new NPM project and then installing Electron-Firebase.

The example application root-level folders and files added to an NPM project are as follows:

  • /config - configuration files for your application
  • /functions - functions to be deployed to the Firebase Cloud
  • /pages - top-level web server folder for HTML pages accessible to the Browser
  • /scripts - top-level web server folder for JavaScript modules to the Browser
  • main.js - the example application main file and overall program structure
  • answerBrowser.js - app support file, functions that export APIs used by the Browser
  • setupApp.js - app support file that generates example data sets on startup

While updating node_modules is a well-known and well-behaved process, an NPM package update that modifies the root file structure is not well defined. Electron-Firebase follows this policy: when performing an update, any of the example application files that have been modified by the developer will not get updated. Otherwise, the example application files will get updated. This result may be exactly the behavior that you want for your app, or exactly the behavior that you don’t want - but either way, it’s safer for your app.

Install and enjoy

Electron-Firebase was developed and tested on Microsoft Windows 10, Apple macOS 10.15, and Ubuntu Linux 20, so you should be able to use any or all of these. Earlier and later OS versions should work, but have not been tested.

There are a number of installation steps beyond "npm install electron-firebase" because a Firebase account must be established, identity providers must be configured, and all of this linked together. All of the steps are documented in detail in the Electron-Firebase README file. Please take this step-by-step and you should have an efficient workflow for getting your example app up and running.

Once installed, your desktop and laptop applications can enjoy the same kind of cloud connectivity as mobile apps, and Firebase users now have a way to extend their application reach to desktop and laptop apps. Happy coding!

About the Author

David Asher has recently been the Head of IoT Cloud Platform at Bose, building out a fantastically talented team that created infrastructure and operations on Kubernetes and AWS to support millions of the company’s smart speakers, soundbars, headphones, and wearables. He has previously led a product management life, for the startup ViziApps and owning the Iron Mountain Digital portfolio of SaaS data protection products. In spite of a professional management career, Asher still codes. Electron-Firebase was his most recent project. His Freedom Trail Boston was a popular mobile app for iOS and Android for a number of years. You can find him on LinkedIn, GitHub or his blog.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT