Firestore is a NoSQL document database that is built for automatic scaling, high performance, and ease of application development. Given the small amounts of data you’ll be storing for each user profile, Firestore is an excellent choice for your needs. Its serverless nature allows it to scale automatically according to demand, making it highly available and fault-tolerant.
While Firestore does require usage of a Google Cloud-specific API, and thus might not be ideal for all projects, it fits the current use case perfectly. The fact that it requires minimal configuration compared to other database services, such as Cloud SQL, significantly simplifies the maintenance of your service.
Google Pub/Sub
This service needs to know when a change has been made to the facts provided by a user. You can get the fact service to report changes by publishing an event to Google Pub/Sub.
Google Pub/Sub is a fully managed event ingestion and delivery system. It supports both event streaming similar to Apache Kafka and queue-based messaging similar to a message queue like RabbitMQ. It is a one-stop event and messaging system. This differs from AWS, for example, where queue (SQS), notifications (SNS), and event bus (Amazon EventBridge) features are provided by separate services. It is a highly available and fault-tolerant service that is scalable, serverless, and cost-effective.
In this project, you will be using Pub/Sub to push a notification to the profile service of changes to facts. The profile service will then update the profile of the user.
Cloud Run
For your profile service, you’ll write the code in Go and host it on Cloud Run. Go’s quick start-up time makes it ideal for situations where a service needs to start quickly in response to an event, do its work, and then shut down. This is an excellent use case for Cloud Run, which can start and stop instances rapidly, charging only for the time during which the service is running.
With these services, you will have a profile service that is responsive to changes, highly available, and cost-effective. Let’s dive into how to use these services to build the solution.
Implementation
It is time to get hands-on and implement the service.
Storing Data in Firestore
The profile service uses Firestore, or more precisely Firestore in Firestore Native mode, to store profiles, each profile being a JSON document. Firestore is part of Firebase and was originally designed for simultaneous connection from many mobile clients. The other mode available is Datastore mode which supports Datastore, a previous Google Cloud service.
Notice that this command has the alpha flag. This is because Firestore, like Firebase authentication, is not fully integrated with Google Cloud, and the command is not yet available in the main gcloud commands at the time of writing.
It used to be that you could only have one Firestore or Datastore database per project, and if you wanted to use Firestore in a different project, you would need to create a new project. In the case of this service, only one database is needed, so the default database is being used. However, during the writing of this book, the restriction was lifted and it is now possible to create multiple Firestore databases in a single project.