In this service, a fact is made up by relating a person to a skill via a level of interest or proficiency. A skill is represented by a Stack Overflow tag you retrieved in Chapter 5 and made searchable in Chapter 6. However, you need a way of capturing the person it is associated with, and for that, you can use Identity Platform. Identity Platform provides backend service, SDKs, and UI libraries that allow you to authenticate users. It is part of the Firebase app development platform.
Tip
Identity Platform is a fully managed service that handles user authentication and identity management on behalf of the application developer. Be careful not to confuse it with Google Cloud Identity which is a different service that enables you to use Google accounts for single sign-on, third-party applications.
Firebase began as a separate application development platform and was acquired by Google in 2014, with Firebase Authentication being one of the features. Firebase targets web and mobile development, and even now it feels one step removed from Google Cloud and not as strongly integrated as other services. Identity Platform supports a range of identity providers, including Google, GitHub, Twitter, and Microsoft accounts. This is great, as it offloads all the responsibility for account creation, storing sensitive information and managing accounts to these trusted providers. However, to get up and running and make testing straightforward, you will start with a simple username and password.
Cloud SQL
Cloud SQL is a Google service for providing managed relational databases in the cloud. It supports PostgreSQL, MySQL, and SQL Server. All three databases are SQL-compliant and are managed similarly. The main difference is the underlying technology used to provide the database.
I would not classify Cloud SQL as a cloud native database; rather than a database that has been designed specifically for the cloud, it is a traditional database hosted in the cloud. Cloud SQL is a fully managed service, so you don’t need to worry about provisioning, patching, backups, high availability, or disaster recovery, but there are some limitations associated with the traditional databases it supports.
The most significant of these limitations is that you need to plan capacity up-front, and apart from automatically increasing storage, it struggles to scale up and down as scaling is only vertical, in that the machine hosting the database can be given more CPU and memory. Horizontal scaling, creating multiple instances, is limited to read replicas. The database also requires downtime for maintenance and restarts for many of the configuration changes. These are limitations that should be left behind in a true cloud native solution. However, the databases supported by Cloud SQL, especially PostgreSQL, are widely used technologies, and Cloud SQL can be low cost while providing reasonable resilience with a 99.95% SLA, and some configurations recently offering a 99.99% SLA. It is often going to be worth considering.
When using PostgreSQL, you can use the PostgreSQL protocol that is also supported fully or partially by Google’s cloud native relational databases, AlloyDB and Spanner. This makes the transition straightforward when the limitations of Cloud SQL have been reached and 99.99%, or even 99.999%, availability and global scale are required. For that reason, you are going to choose Cloud SQL for PostgreSQL for this project.