Building a Python app connected to Firebase

1. Introduction

Firebase is a platform for web and mobile development launched in 2011 and acquired by Google in 2014.

It is a cloud platform integrated with Google Cloud Platform that provides tools to create, synchronize and scale projects without building the whole infrastructure from scratch.

• Simple data synchronization without complex communication logic.
• Compatibility with web applications, Android, iOS, Unity and C++.
• Automatic scaling on Google infrastructure.
• The possibility of creating projects without your own server.
• Extensive official documentation and an active community.

2. Implementation

This is deliberately a server-side example. The Firebase service account is loaded from Python, so the private credentials stay outside the browser and the client does not need direct permission to read the database. That separation is important when the same data later feeds an Angular frontend, a scheduled job or an internal dashboard.

In this example, the goal is to send an email to the addresses stored in Firebase. For that purpose, an auctions collection with a structure similar to the following one has been defined:

The first step is to install the firebase-admin library:

From that moment on, the information stored in the database can already be accessed. The data are recovered from JSON documents with the following code:

If we analyze the code, one of the key steps is obtaining the JSON credentials from the file clave.json:

To obtain this document, you can access the Google Cloud console here: https://console.cloud.google.com/projectselector/apis/api/firebasedatabase.googleapis.com/overview?hl=es

Once access has been configured, it is already possible to recover the information directly from the database:

In short, Firebase makes it possible to build lightweight backend solutions that are very quick to integrate, especially when you want to centralize data and automate actions such as sending emails.

Security and production notes

The most important rule is that the service account JSON file must never be exposed in Angular or committed to a public repository. It belongs on the backend, protected by environment variables, a secret manager or a private deployment directory. The frontend should call a controlled API endpoint instead of connecting with administrative permissions.

It is also worth separating read logic from notification logic. A small service can read Firestore, validate the expected fields, build a normalized DTO and then pass only the necessary values to the email module. That makes errors easier to test and avoids sending messages from partially malformed documents.

• Use least-privilege credentials and rotate service account keys when people leave the project.
• Log delivery failures without storing private message content unnecessarily.
• Validate recipient addresses before calling SMTP or a transactional email provider.
• Move scheduled jobs to a queue or cron task if the operation grows beyond a small script.

Another practical improvement is to add a dry-run mode. In dry-run mode the backend reads Firestore, prepares the message and writes the intended recipients to logs, but does not send the email. This is useful when testing a new collection structure or validating that a scheduled notification will not contact the wrong users.

For SEO and maintainability, this article now separates the conceptual Firebase explanation from the backend security decisions. That makes the page more complete than a code snippet and helps readers understand why the administrative SDK belongs in Python, not in the browser.

If the next step is exposing these data to an Angular application, it is worth reviewing the Angular HttpClient API example and the guide about protecting an Angular API with Nginx and FastAPI.