I’m exploring the different free tier offerings by Google Cloud trying to find ways to save some money and learn something new at the same time.

Currently I’m using an F1-micro instance (also free tier) to run an application inside a container. This works pretty well, except for:

• Google keeps telling me that the instance is overutilized
• I manually renew my SSL certificate every time it expires
• To update the container code I need to SSH to the instance, fetch the latest image and run it

I could probably do something to automate some of these points, but I’m hoping I can get all problems solved and stay in the free tier by moving to Cloud Run.

In this post we are going to learn how we can use Google Analytics to find out how a web application is being used.

This method applies to any single page application even if they are not PWAs (Progressive Web Apps).

Tracking traditional web sites

Adding google analytics to a traditional website is very easy. Google provides a script we can add to each page. Every time a page is load, the script will be run and the visit will be recorded. The script looks something like this:

1
2
3
4
5
6
7
8
9
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-XXXXXXXXX');
</script>

In a previous article I wrote about Google Cloud Functions. They are good for single purpose endpoints, but if we want to run a full application without having to manage our infrastructure, App Engine is a better option.

App Engine natively supports some of the most popular programming languages (e.g. Java, Python, Go, …), but also allows us to use any other programming language by supporting docker containers.

Standard and flexible environments

App Engine offers two environment types. There is good documentation explaining the difference betweent Standard and Flexible, so I’m just going to summarize what I think are the most important points:

Compared to most popular databases, Google Firestore is very minimalistic.

A very important feature that it lacks, is that of unique constraints (unique indexes). This feature is particularly important when we are building a system that allows users to pick a username. If we don’t enforce uniqueness we could end with two users with the same username, which is not what we want.

Using Document ID and transactions

If we are able to use the username as the user id, then things are a little easier. We can follow these steps to create a new user (wrapped in a transaction):

• Get user by ID (username)
• If it exists, user is taken, return an error
• If it doesn’t exist, add it

Before we proceed with this solution, there are a few things that are important to know about transactions in firestore:

In a previous article, we started playing with Google Firestore. In this article we are going to learn how we can test our applications without the need to talk to Google Cloud.

Note that the local version of Google Firestore is intended for testing only and shouldn’t be used for production systems. It doesn’t provide the reliability or scalability features that the real Firestore does.

Firebase emulator suite

Google provides this suite to help developers test applications without having to use production data or incur cost. The suite doesn’t only emulate the database, but also cloud functions and real-time functionality, to name a couple. In this article we’re only going to focus on the Firestore database.

Firestore is Google’s serverless document database offering.

What does serverless mean?

Serverless means that we don’t have to worry about managing the servers on which the database runs. All the management is done automatically by Google. The database will scale up or down depending on the demand.

What’s a document database?

A document database is a non-relational database that stores data in a semi-structured format. A common format used by many document databases is JSON.

In a relational database, we usually create tables with a defined structure (columns and types). In a document database, it’s not necessary to specify the different columns.

In this post we’re going to learn how to use Google Cloud IAM (Identity and Access Management) to limit who can manage resources in a Google Cloud account.

If you are interested in AWS IAM, you can check my Identity and Access Management with AWS article.

Concepts

• Member - An entity that needs to perform an action on a resource. An end user or a service are examples of members
• Identity - Another name for Member
• Resource - A resource is pretty much anything that can be managed in GCP. A compute engine instance or a cloud storage bucket are examples of resources
• Permission - Allows or denys access to resources. For example: create a storage bucket
• Role - A collection of permissions. Roles can be granted to members
• Policy - Defines who (member) can perform which actions (permissions) on which resources

I’ve been writing this blog for a while and I recently thought it would be nice if it could help pay for the servers I use for my other projects. At the time of this writing, this blog gets around 25,000 views per month, which is not much, but might be enough to pay for a couple of virtual machines (Hopefully. I’ll know more after I have ads running for some time).

Since this blog is built with Jekyll, I’m going to show how to add Adsense to similar blogs.

Creating a site in Adsense

Before we can start adding ads to our site, we need to tell Google that the site is ours. To do that we need click Add site on the Sites section:

We will then get a code that we should put in the <head> of our website. The code looks something like this:

1
<script data-ad-client="ca-pub-12345678987654321" async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>

Cloud Functions are Google’s offering for serverless architecture (similar to AWS lambdas).

What is serverless?

Before we look into how to use Cloud Functions, we should understand some things about it.

Code needs servers to run, so serverless doesn’t mean there are no servers, it means that we don’t need to manage those servers ourselves.

In a usual server based architecture, we might create a service and deploy it to a machine. This service will be running in the machine all the time waiting for requests. This has the disadvantage that even if there are no requests, the machine would need to be up, and incurring cost.

On the other hand, if we use Cloud Functions, we write a service and register it with Google. Google will then listen to the endpoint this service cares about and will only start it when there are requests. If it detects that there haven’t been requests for some time, it will stop the service again.

Modules are the new way of doing dependency management in Golang.

A module is a collection of packages that are distributed together (e.g. a single binary). A module contains a go.mod file at its root.

With modules, it is not necessary to have our code in $GOPATH/src anymore, so we can create a project anywhere.

Let’s start a new project:

1
mkdir ~/project

And make it a module:

1
2
cd ~/project
go mod init mymodule/hello