A backend service is typically a service in front of a group of backend instances that receive and process requests from a load balancer, as shown in Figure 11-3.
Figure 11-3. Backend service
Using the Google content delivery network
At this point, you could also decide to use a content delivery network (CDN) with this; Google Cloud’s built-in CDN can be used. This uses Google’s globally distributed edge points of presence to cache HTTP(S) load-balanced content close to your users. Caching content at the edges of Google’s network provides faster delivery of content to your users while reducing serving costs. There is an extra storage cost as there is a data cache at each edge and network costs to get it there; however, because the UI is only a few small files, this will be negligible.
URL map
A URL map routes incoming requests to the backend services you just created, as shown in Figure 11-4.
Figure 11-4. URL map
In this case, any request that starts with /api/ will be routed to the API Gateway backend service. Anything else, such as the requests for the HTML, JavaScript, and CSS files, will be routed to the backend bucket by default.
Target HTTPS proxy
The URL map is now ready to be used by the target proxy, as shown in Figure 11-5. The target proxy is the component that receives the incoming request and routes it to the URL map.
Figure 11-5. Target HTTPS proxy
Forwarding rule
Finally, create a forwarding rule to route requests to the target HTTPS proxy, as shown in Figure 11-6.
Figure 11-6. Forwarding rule
Make sure the IPAddress is the same as the IP address you created an A record for at your DNS provider earlier. When that DNS record propagates and your SSL certificate is issued, you will be in a position to test the UI.
Testing the UI
You can test the UI by visiting the domain name you created an A record for earlier. For example, I created an A record for skillsmapper.org, so you can visit https://skillsmapper.org in my browser and see the UI.
Authenticating Real Users with Identity Platform
In Chapter 7, you configured Identity Platform using an email and password provider for login. However, managing the passwords of many users can be a headache. Fortunately, Identity Provider also uses an external identity provider such as Google or Facebook. This is a common pattern for applications; it allows users to log in using their existing accounts.
Here is how you can configure Identity Provider to use Google as the identity provider. Go to the Identity Provider section of the Google Cloud console and make sure you select Providers from the menu on the left. You should see the Email/Password provider you created earlier.
Click “Add a Provider” and select Google from the list of providers.
The page will guide you through setting up the Web SDK configuration, including collecting the Web Client ID and Web Client Secret A from elsewhere in the Google Cloud console.
On the right, you should also see a box labeled Authorized Domains. This is where you can add the domain name you created earlier. For example, I added skillsmapper.org to the list of authorized domains. Without doing this, you will not be able to use the Google login. With the configuration complete, click Save.
Select the External option and complete the following:
• Give the user support email, to an email address you own.
• In authorized domain, add the value of the domain name you created earlier. For example, I added skillsmapper.org to the list of authorized domains.
• Provide the developer contact email, to an email address you own.
For the next two screens, accept the defaults, click “Save and Continue,” and then on the summary tab, click “Back to Dashboard.”
