In a recent article I gave an introduction to React. That article shows the first steps of building React components, but leaves us very far from building a useful web application. In this article we will learn how to create a real world application using Next JS.

Next JS

Next JS sells itself as the “React framework for production”. They promise smooth user experience combined with a rich set of features to build fast apps.

Environment set-up

To start an application from scratch we can use their generator:

1
npx create-next-app

We will be prompted for a name. I’ll use example for my app.

When the command finishes, we can start our app in development mode:

1
npm run dev

What we get out of the box:

• Compilation and bundling (Babel and webpack)
• Auto-refresh on changes
• Static Site Generation (SSG) and Server Side Rendering (SSR)
• Server of static files (Files under /public/)

React is without a doubt the most popular web component framework today. With the power of facebook backing it up, it has a lot of support and documentation behind it.

React by itself is not great for building web applications, but can be used with other tools or frameworks to build pretty much anything.

Environment set-up

Before we can start writing React components we need a web page where we want to use them. We’ll create a new folder for our project:

1
2
mkdir react
touch index.html

I started using Firestore a few months ago for a project and today I discovered that the IN operator accepts a maximum of 10 values. This limitation makes the IN operator unsuitable for a lot of real world scenarios.

In this article, I’m going to explore a few ways to work around the problem using the golang client.

What is PWA Builder?

PWA Builder is a set of tools and web components that can be used to publish a web app to different app stores (Android, Samsung and Microsoft).

Is the PWA ready?

The first thing we need to do is check if our app is ready. For this we can go to https://www.pwabuilder.com/ and enter the URL to our app. After submitting our URL, we will get a score:

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.