# Git hooks with husky on a monorepo

Let's suppose your monorepo consist of a `frontend` directory and a `api` directory. If you want to only execute some task on pre-commit when files on the `frontend` app change, this should be your pre-commit script

```sh
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

DID_FRONTEND_CHANGE=$(git diff --cached --name-status | grep 'frontend/' || true)

if [ "$DID_FRONTEND_CHANGE" ]; then
  # DO SOMETHING IN HERE
fi
```

My use case was updating the version of a React app (using `npm version`), so I also needed a custom script to get the next version

```js
const exec = require('child_process').exec;

const execute = (command) => {
  return new Promise((resolve, reject) => {
    const child = exec(command, (err, stdout, stderr) => {
      if (err != null || typeof stderr != 'string') {
        reject(err);
      } else {
        resolve(stdout);
      }
    });
  });
};

(async () => {
  const getBranchNameCommand = `git rev-parse --abbrev-ref HEAD`;
  const getCommitHashCommand = `git rev-parse --short HEAD`;

  const response = await execute(`echo "$(${getBranchNameCommand})-$(${getCommitHashCommand})" | head -1`);

  const currentVersion = require('../package.json').version;
  const base = currentVersion.split('-').shift();

  const version = `${base}-${response.replace('/', '-')}`;

  process.stdout.write(version);
})();
```

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

Let's suppose your monorepo consist of a frontend directory and a api directory. If you want to only exec...

Git hooks with husky on a monorepo

# Add full-text search to your Firebase app

As it is publicly known, Firestore as a database [does not allow full-text searches](https://firebase.google.com/docs/firestore/solutions/search). So in case you would like to run a query with an operator such as `LIKE` (as you would do in a SQL database), you would hit a wall. It is possible however to make such a query, but only integrating third-party software as a sort of search engine. The Firebase team recommends [using Algolia](https://firebase.google.com/docs/firestore/solutions/search#solution_algolia), but I find it extremely expensive for simple projects (although it provides several client libraries to integrate it seamlessly with your apps). In this tutorial, we are going to use another very popular alternative, which is **Elasticsearch**

In this article, we are going to add a search functionality to the Firebase-based REST API we developed in [this previous article](https://collectednotes.com/lucianoserruyaaloisi/develop-and-deploy-firebase-based-rest-apis)

**Repo for this article is available [here](https://github.com/LucianoFromTrelew/contacts-on-fire/)**

## Elasticsearch

As described in the [What is Elasticsearch page](https://www.elastic.co/what-is/elasticsearch), it is a *distributed, open source search and analytics engine for all types of data, including textual, numerical, geospatial, structured, and unstructured [...]*. Sounds pretty complex and I don't certainly know what it means, but I do know it can help us with our use case.

You can use Elasticsearch's JavaScript client both from your web app (client-side code), or from your server (node.js code). As we are building a REST API, we are just going to communicate with Elasticsearch from our server.

First of all, we need an instance of Elasticsearch running. We can rely on a cloud provider (such as [elastic.co](https://www.elastic.co/) or [bonsai.io](https://bonsai.io/)), or spin our own instance locally using Docker (this is an incredible advantage over Algolia, as as far as I know, you cannot run an instance of Algolia locally). Create your docker container with the following command

```bash
docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:7.9.3
```
*Version 7.9.3 is the current latest up to this day (Oct 31, 2020)*

Then, we need to install Elasticsearch's SDK for JavaScript

```bash
npm install @elastic/elasticsearch
```

And we are done with the set up. We are now ready to index our documents when we do a write to the database (create or update a document) and search them when doing a read (reading from the database).

### Indexing data

First of all, create your ES client

```typescript
import { Client } from "@elastic/elasticsearch"
...

const app = express()
// Change the URL accordingly to your situation
const esClient = new Client({ node: "http://localhost:9200" });
const ES_INDEX_NAME = "contacts";
```

Then, in your `POST` handler, index your contact

```typescript
app.post("/contacts", async (req, res) => {
  // Validate data and create document in here

  await esClient.index({
    index: ES_INDEX_NAME,
    id: doc.id,
    body: { firstName, lastName, address},
  })
  ...
});
```

You would want to do the exact same thing when updating a contact. Oh and don't forget to remove the document from the index when deleting it from the database! You can achieve that with the following code

```typescript
await esClient.delete({ index: ES_INDEX_NAME, id: doc.id })
```

### Searching data

Now, the one feature we are trying to achieve with all of these third-party integration - full-text search! We are now going to add support for a query parameter to our list endpoint. If present, we are going to search and return only those contacts that match a certain criteria dictated by the query parameter value. If not present, we are going to return all contacts

```typescript
app.get("/contacts", async (req, res) => {
  const { q } = req.query;
  if (q) {
    // Search documents in ES
  } else {
    // Return all documents
  }
})
```

We will use the query parameter to search every document that matches in any of its fields with the query parameter value

```typescript
const { body } = await esClient.search({
  index: ES_INDEX_NAME,
  body: {
    query: {
      bool: {
        should: [
          { wildcard: { firstName: `*${q}*` } },
          { wildcard: { lastName: `*${q}*` } },
          { wildcard: { address: `*${q}*` } }
        ]
      }
    }
  }
});

const contactIds: string[] = body.hits.hits.map(
  (hit: { _id: string }) => hit._id
);

const contacts = await Promise.all(
  contactIds.map(async id => {
    const doc = await contactsCollection.doc(id).get();
    if (!doc.exists) return;
    return { id: doc.id, ...doc.data() };
  })
);

return res.json({
  data: { contacts: contacts.filter(contact => contact) }
});
```

That's a lot of code, I know, but the most important part of it is actually the first one, when we are reaching to our Elasticsearch instance to search documents that matches with the query parameter. What we do then is obtain those documents' ids, fetch those documents from the database and return them.

## Conclusion

In this article we saw how to implement one of the most requested features for Firestore (which I don't think will be implemented natively, 
due to how Firestore works internally), which is full-text search. We accomplished this by integrating a third-party software, such as Elasticsearch.

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

As it is publicly known, Firestore as a database does not allow full-text searches. So in case you wou...

Add full-text search to your Firebase app

# Develop and deploy Firebase-based REST APIs

Firebase is an awesome product suite. You can use its client SDKs to add back-end functionalities to your web or mobile apps, up to deploying full-stack applications to Firebase. In this short tutorial we will see how can we develop a Firebase-powered REST API and deploy it to Firebase, using Node.js and TypeScript.

## Getting started

We will [develop locally with Firebase](https://collectednotes.com/lucianoserruyaaloisi/developing-locally-with-firebase), but we still need to use a Firebase project. Head over the [Firebase console](https://console.firebase.google.com/) and create a new project. We will also need to have the `firebase` CLI tool installed in our machine, so install it running `npm install -g firebase-tools`.

Following with our scaffolding, we now need a NPM project. To create a new one, first create a new directory, `cd` into it, and start a new NPM project with `npm init`. We will build a REST API for storing contacts, so our project will be called `contacts-on-fire`

```bash
mkdir contacts-on-fire && cd contacts-on-fire && npm init -y
```

Once created, initialize your Firebase project locally in your directory via the command `firebase init`. Choose `Functions` and `Emulators` pressing the space bar, and choose your recently created project when prompted to select one. When setting up your functions, it will create a new `functions` directory (we will delete it and restructure the project) and install some dependencies. When setting up the emulators, select the Functions and Firestore emulators and use the default ports (or remember what ports you changed, you will have to update some files to make it work).

If you see what is inside the `functions` directory, you will see there is another `package.json` file with its corresponding `node_modules` directory, which means is a different NPM project. This brings some complications we don't want, so we will rescue the files we want, and delete the rest. Move to your root project the following files and directories

- `src` directory
- `.eslintrc.js`
- `tsconfig.json`
- `.gitignore` (in case you created a git repository)

You can now delete the `functions` directory

```bash
mv functions/src functions/.eslintrc.js functions/tsconfig.json functions/.gitignore . && rm -rf functions
```

As we are building a server-side application, we won't install any client-side Firebase SDK, but the admin one. We will also need to install the `firebase-functions` package.

```bash
npm install firebase-admin firebase-functions
```

We need to install some development-only dependencies as well, such as the TypeScript compiler, `eslint`, and some `eslint` plugins

```bash
npm install --save-dev typescript eslint eslint-plugin-import @typescript-eslint/eslint-plugin @typescript-eslint/parser
```

As we move our Cloud Functions code from the `functions` directory to our root project, we need to update the `firebase.json` and `package.json` files. Your `firebase.json` file should look like the following

```json
...
"functions": {
  "predeploy": [
    "npm --prefix \"$RESOURCE_DIR\" run build"
  ],
  "source": "."
}
...
```

**The main update is the `source` entry,** specifying where our code is located

Your `package.json` should look like this

```json
...
"main": "lib/index.js",
"scripts": {
  "build": "tsc"
},
"engines": {
  "node": "10"
}
...
```

**The main update is the `main` entry**, specifying which file is the entry point for our Cloud Functions (Firebase looks for this file when deploying our Cloud Functions and when running the Emulators), **the build script**, and **the engines entry**

Open your `src/index.ts` file and uncomment the only Cloud Function definition in there

```typescript
export const helloWorld = functions.https.onRequest((request, response) => {
  functions.logger.info("Hello logs!", {structuredData: true});
  response.send("Hello from Firebase!");
});
```

Run the Firebase emulators with `firebase emulators:start` and you shouldn't have any problems up to this point. Navigate to `localhost:4000` (in case you used the default ports when setting up the Firebase Emulators), and you should see the Firebase Emulators UI. Click on the Functions section, look for your `helloWorld` function's URL, navigate to it using your browser, and it should return the message `Hello from Firebase!`. We are done with the Firebase set up, we can now start developing our REST API!

## Coding time

It's time for us to start coding our application. Our contact model will only have three fields: `firstName`, `lastName`, and `address`. We will implement the following endpoints:

- `GET /api/contacts` -> Retrieve all contacts
- `GET /api/contacts/:id` -> Retrieve single existing contact
- `POST /api/contacts` -> Create new contact
- `PUT /api/contacts/:id` -> Update existing contact
- `DELETE /api/contacts/:id` -> Delete existing contact

We can create a HTTP-based Cloud Function based of a express.js application. To do so, we first need to install express.js and some development-only dependencies

```bash
npm install express && npm install --save-dev @types/express
```

Then, in your `src/index.ts` file create a new express.js app and pass it to your Cloud Function

```typescript
// src/index.ts

import * as functions from 'firebase-functions';
import express from "express"

const app = express()

app.get("/contacts", async (req, res) => {
  res.json({
     data: []
  })
});

export const api = functions.https.onRequest(app);
```

If you now try to run the Firebase Emulators or to compile your TS code with `npm run build`, you will see an error because of the way we are importing `express`. To fix it, add the following line to your `tsconfig.json` file

```json
{
  "compilerOptions": {
    ...
    "esModuleInterop": true,
    ...
  }
}
```

Try again now, it should work.

Try changing anything from the code by yourself, you will realize that your changes aren't impacting your Cloud Function - that's because you have to stop the Emulators, and run them back again to recompile your code. To avoid having to stop them manually every time we make a change, let's install a really handy package to help us with this issue.

```bash
npm install --save-dev concurrently
```

We now have to update our npm-scripts to use `concurrently`

```json
...
"scripts": {
  ...
  "dev": "npm run build && concurrently --kill-others-on-fail 'tsc -w' 'firebase emulators:start'",
  "prebuild": "rm -rf lib",
  "build": "tsc",
  ...
}
...
```

We added quite a few new npm-scripts. Now, to run the emulators, you would have to run `npm run dev` **but only once**, when you first start developing - you don't have to stop them every time you make a change to your code. This script will first build our code, then it will run two script in parallel (with the help of `concurrently`), and if one of them ends with a non-zero code (it ended because of an error), it will restart both the failing process and the other one

### Storage

We have a basic endpoint that returns an empty array. We now can integrate our database (Firestore) into the mix. We can easily do so by initializing our app and retrieving a reference to our database

```typescript
// src/index.ts
...
import {initializeApp, firestore} from "firebase-admin";

initializeApp();
const db = firestore()
```

Now, in your handler for your only route

```typescript
app.get("/contacts", async (req, res) => {
  const { docs } = await db.collection("contacts").get();
  const contacts = docs.map(doc => ({ id: doc.id, ...doc.data() }));
  res.json({ data: contacts });
});
```

We are retrieving every document present in the "contacts" collection, and send it back to the client as an array of objects. Run the Emulators, go to the Firestore Emulator, create a new collection called "contacts" and add some documents. Hit your Cloud Function and you should see your recently created document

*If you called your Cloud Function (the function your are exporting from `src/index.ts`) `api`, you can make a HTTP request to it via `http://localhost:5001/<PROJECT_ID>/<REGION>/api`. Use the correct port in case you changed it when setting up the Emulators. If not working, check the Functions Emulators log to see the URL*

I'm not going to show how to code the rest of the endpoint, they are quite easy and repetitive. In case you'd like to see them, please refer to [this repo](https://github.com/LucianoFromTrelew/contacts-on-fire).

## Deployment

Because we already set up our Firebase project on the cloud and initialized locally, deploying our functions to our Firebase project is as simple as running `firebase deploy`

## Conclusion

In this tutorial we saw how to locally develop a Firebase-powered REST API using express.js, Cloud Functions for Firebase, and Firestore, and deploy it to a serverless provider such as Firebase.

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

Firebase is an awesome product suite. You can use its client SDKs to add back-end functionalities to...

Develop and deploy Firebase-based REST APIs

# Developing locally with Firebase 🔥

In case you ever used any Firebase product in a project, you would quickly realize that you were always hitting your production project. Or maybe you were cautious enough to use a second Firebase project as a development environment. But what about developing locally? Can't we just run some commands in our machines to spin up a "Firebase server" so our app can communicate with it instead of reaching out to the cloud? As a matter of fact, you can do that! The [Firebase Emulator](https://firebase.google.com/docs/emulator-suite) has been around for quite some time now, but the Firebase team recently released the [Firebase Emulator UI](https://firebase.googleblog.com/2020/05/local-firebase-emulator-ui.html), so you can have an almost identical Firebase console locally.

## Getting started

**You need to have JDK 8+ installed to run the emulators**

Although we will have a "local instance" of a Firebase server, we still need to have a Firebase project created, so we first need to do that before moving on. Go to the [Firebase console](https://console.firebase.google.com) and create a new project.

Then, we need to have the `firebase` CLI tool installed to initialize our project locally and run the emulators

```bash
npm install -g firebase-tools
```

To try out Firebase Emulators, we are going to create the simplest to-do app in React, so we first need to [create a new project](https://console.firebase.google.com/u/0/) before continuing

```bash
npx create-react-app firebase-emulators-todo-app --template typescript && cd firebase-emulators-todo-app
```

We are going to use the Firebase Web SDK to directly store data from our React app, so we need to install it

```bash
npm install firebase
```

Once installed, we need to get our credentials to connect our app with the Firebase project. Go to the Firebase console, select your project, then click on the wheel right next to *Project Overview*, and select *Project Settings*. Scroll down until you see the *Your apps* section. Add a new web app, and copy your config object to your `src/index.ts` file

```typescript
const firebaseConfig = {
  apiKey: "...",
  authDomain: "...",
  databaseURL: "...",
  projectId: "...",
  storageBucket: "...",
  messagingSenderId: "...",
  appId: "..."
};
```

We haven't initialized Firebase in our React app. To do so, run `firebase init` inside your React app directory, and using the space bar **only select**  `Emulators` and then `Firestore Emulators`. It will ask you some questions about several configurations, which you can complete them by pressing Enter to use the default values. Once finished, start the emulators by running `firebase emulators:start`. If everything starts correctly, you can visit the Emulator UI by navigating to `localhost:4000` (if using the default port)

Up to this point we could already start writing our app that will store data to our Firebase project hosted on the cloud. But that's not what we want, we want to communicate with our local emulator, so we need to tell Firebase somehow that we want to use our local instance (only in development)

```typescript
// src/index.ts

import firebase from "firebase/app";
import "firebase/firestore";

firebase.initializeApp(firebaseConfig);

const env = process.env.NODE_ENV;
if (env.match(/development/i) || window.location.hostname === "localhost") {
  firebase.firestore().settings({
    host: "localhost:8080",
    ssl: false
  });
}
```

*The setup would be exactly the same in case you were using Firestore as a database for a backend project using [Firebase Admin](https://firebase.google.com/docs/admin/setup), for example. You can see [this repo](https://github.com/LucianoFromTrelew/sharing-types-react) if you are looking to use the Firebase Emulators with a express.js-based API*

## Application

We are good to go now. Our React app is set up to communicate with our local instance of Firebase. Open the Firebase Emulators UI (`localhost:4000`) and go to the Firestore Emulator. Create a new collection called `todos` and some documents. To keep it simple, we are creating to-dos with only a `title` property.

Go to your `App.tsx` file and add the following effect to retrieve our manually created to-dos

```typescript
import React, { useEffect } from "react";
import firebase from "firebase/app";
import "firebase/firestore";

function App() {
  useEffect(() => {
    const fetch = async () => {
      const todos = (
        await firebase.firestore().collection("todos").get()
      ).docs.map(d => d.data());
      console.log({ todos });
    };
    fetch();
  }, []); 

  return (...)
}

export default App;
```

Start your React development server in case you weren't already running it with `npm run start`. Go to `localhost:3000`, open your console, and you should see your to-do created via the Firebase Emulator UI. Great!

**In case you are getting an error when trying to fetch documents from Firestore**, please check that you didn't initialize Firestore in your React app. In case you did, you will see a `firestore.rules` file. This file specifies **security rules** for your Firestore database. For this simple project, we won't need any, so you can just delete that file. If you want to keep it, you will have to update the only security rule it has (only allows authenticated requests to read and write data) to allow every request.

```
allow read, write: if true;
```

In order to add new todos, we will need a form. Our `App` component is the following

```typescript
import React, { FormEvent, useEffect, useState } from "react";
import firebase from "firebase/app";
import "firebase/firestore";

interface Todo {
  id: string;
  title: string;
}

function App() {
  const [title, setTitle] = useState("");
  const [todos, setTodos] = useState<Todo[]>([]);

  useEffect(() => {
    const fetch = async () => {
      const todos = (
        await firebase.firestore().collection("todos").get()
      ).docs.map(doc => {
        return { id: doc.id, ...doc.data() } as Todo;
      });
      setTodos(todos);
    };
    fetch();
  });

  const handleSubmit = async (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();
    try {
      await firebase.firestore().collection("todos").add({ title });
      alert("To-do created successfully!");
    } catch (e) {
      alert("Something went wrong :/");
    } finally {
      setTitle("");
    }
  };

  return (
    <div className="App">
      <section>
        <form onSubmit={handleSubmit}>
          <label htmlFor="title">Title:</label>
          <input
            type="text"
            name="title"
            id="title"
            value={title}
            onChange={e => setTitle(e.target.value)}
          />
        </form>
      </section>
      <section>
        <ul>
          {todos.map((todo, i) => (
            <li key={i}>{todo.title}</li>
          ))}
        </ul>
      </section>
    </div>
  );
}

export default App;
```

Add a couple of to-dos, and check your Firebase Emulators console. Go to the Firestore emulator tab and you should see them.

### Persisting data between starts

Something that happens with the Firebase Emulators is that data isn't stored automatically when you stop the emulators and start them back again. This is easily achievable by passing two parameters when starting the emulators, `--export-on-exit` and `--import <DIRECTORY>`. So, the full command to start the emulators, store your data in a file, and import it next time you run the emulators is 

```bash
firebase emulators:start --export-on-exit --import data
```

I called the directory Firebase Emulators will store data just `data` but you can use whatever name you want (remember to ignore it from your source control versioning)

## Deployment

We can easily deploy our React SPA to Firebase Hosting. To do so, run once again `firebase init` in your React app directory, and this time only initialize `Firebase Hosting` (you can make it faster writing `firebase init hosting`). When asked what do you want to use as your public directory, input `build`, which is the directory React generates when building your app. Also write `y` when asked if you want to configure it as a single-page app.

Once done, build your app with `npm run build`, and deploy it with `firebase deploy --only hosting`

If you now navigate to the URL Firebase gives you after deploying your app, you may see in the console a permission error, which can be fixed by changing the security rules of your database in the Firebase console (the [cloud version](https://console.firebase.google.com), not your local one). Deploy your security rules from the web editor and try again, it should work now.

Your deployed version of the app won't write data to your local emulator, but to your online Firestore database. To now check your data, go to the Firestore console in your Firebase project

## Conclusion

In this short tutorial we saw how to set up a local Firebase Emulator, and how to connect a React data to it. We also saw how to deploy our app and use the online version of the database instead of the local one.

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

In case you ever used any Firebase product in a project, you would quickly realize that you were always hitti...

Developing locally with Firebase 🔥

# Deploying full-stack applications with Firebase

*This note was firstly meant to be part of [this other note](https://collectednotes.com/lucianoserruyaaloisi/typescript-sharing-type-definitions-seamlessly-between-server-and-client), but I then decided to write it as a separate note, so please read the [first one](https://collectednotes.com/lucianoserruyaaloisi/typescript-sharing-type-definitions-seamlessly-between-server-and-client) before continuing*

## Deployment

We have our Vue app and our Express server, both written in TypeScript and working seamlessly **in development**. But what about deployment? How do we deploy this app? We can't just build our Vue app and deploy it in a static files hosting serving such as Netlify or Firebase Hosting because it makes HTTP requests to a `/api` endpoint, so we need to deploy our Express back-end as well. For this tutorial, we are going to use Firebase Hosting for our SPA (it only consists in a single HTML file and some JavaScript bundle files), and Cloud Functions for Firebase for our backend.

### Setting up Firebase

First and foremost, we need to have the `firebase-cli` installed in our machine (`npm install -g firebase-tools`). Once installed, initialize firebase in your project by running `firebase init` inside your project's directory. Select both `Hosting` and `Functions`. Create a new Firebase project or use an existing one, you choose (I have a *playground* project that I use for playing around with Firebase and GCP).

Select `TypeScript` when prompted what language will you use to write your Cloud Functions, `No` to TSLint, and `Yes` to installing dependencies.

For Firebase Hosting, use your `dist` directory as your public directory (`dist` is automatically created by Vue when we generate our production bundle), `Yes` when prompted to configure it as a single-page app, and `Yes` when prompted to overwrite `index.html` (or `No`, doesn't matter).

Okay awesome, we have now set up Firebase Hosting and Cloud Functions for Firebase in our projects. You will see a brand new directory called `functions` - that's where your Cloud Functions' source code is in. If you open `functions/src/index.ts`, you will see a commented-out HTTPS Cloud Function. If you'd like to try it out, uncomment it and run `npm run serve` **while inside of your `functions` directory**. This will transpile your TS code and spin up the Firebase emulators in port 4000 by default for you to test locally your functions or your Firebase Hosting project.

What is really cool about HTTPS-based Cloud Functions is that you can pass your whole Express app to handle any incoming request - and that's what we are going to do now! As we don't want to install Express once again in our `functions` directory, we are going to create and export a new function in `src/server/index.ts` that will create a `express` object, configure it with our routes, and return it. Your `src/server/index.ts` file should look like this

```typescript
import express, { Express } from "express";

export interface APIIndexRouteResponse {
  message: string;
}

export function configureServer(app: Express) {
  app.get("/api", (_, res) => {
    const response = { message: "Hello world!" } as APIIndexRouteResponse;
    res.json(response);
  });
}

export function createAndConfigureServer(): Express {
  const app = express();
  configureServer(app);
  return app;
}
```

Great! We can now call this new function in our `functions/src/index.ts` file to get a configured `express` object to handle HTTP requests

```typescript
// functions/src/index.ts

import * as functions from "firebase-functions";
import { createAndConfigureServer } from "../../src/server";

export const helloWorld = functions.https.onRequest(createAndConfigureServer());
```

If we now try to spin up Firebase emulators, it will fail telling us something about `esModuleInterop` and what have you. We can sort that out easily by setting `"esModuleInterop": true` in `functions/tsconfig.json`, as a `compilerOptions` setting. **Remove `functions/lib` before trying again**. If we now try once again, it still won't work! It now says something about a valid "main" entry in `package.json`. Yet another easy bug to fix, open `functions/package.json` and change `"main": "lib/index.js"` for `"main": "lib/functions/src/index.js"`. Remove `functions/lib`, run `npm run serve` and it now works! You should see a JSON object with your message when navigating to `http://localhost:5001/<FIREBASE_PROJECT_ID>/<REGION>/helloWorld/api` (don't forget to hit the `/api` route! We are not handling any other route).

We are going to add some really handy npm-scripts in our base `package.json` to build our application: one for building our SPA, one for building our Cloud Functions, and one for building both.

```json
// ./package.json
...
  "scripts": {
    "dev": "nodemon",
    "serve": "vue-cli-service serve",
    "build:app": "rm -rf dist && vue-cli-service build",
    "build:functions": "rm -rf functions/lib && npm --prefix functions run build",
    "build": "npm run build:app && npm run build:functions",
    "lint": "vue-cli-service lint"
  },
```

Finally, we are going to add one rewrite rule to our Firebase file for Firebase Hosting (`firebase.json`)

```json
{
  "functions": {
    "predeploy": "npm --prefix \"$RESOURCE_DIR\" run build"
  },
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [
      {
        "source": "/api",
        "function": "helloWorld"
      },
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}
```

We are telling Firebase Hosting to rewrite incoming request to `/api` to our backend, which is running in a Cloud Function called `helloWorld` (of course you could name it whatever you want, but bare in mind that you would have to update this file if you do so).

**October 12 Update**. I've recently realized that Firebase Hosting rewrites incoming requests to `/api` *only*, so if you had a `/api/login` route for example, you wouldn't be able to reach it via `<YOUR_SITE>/api/login`. To solve this issue, you would have to update your rewrite rule to also catch any subsequent path

```json
"hosting": {
  "rewrites": [
    {
      "source": "/api{,/**}",
      "function": <YOUR_FUNCTION>
    }
  ]
}
```

And we are done setting up Firebase for our project! To test it locally before deploying, you can simply run `firebase emulators:start`, and navigate to `localhost:4000` to see the Firebase Emulators Suite. Your SPA will be served by default on `localhost:5000`, and your Cloud Functions will be available on `localhost:5001`. If you are happy with what you see, deploy it with `firebase deploy`

Hope you liked it!

🐦 [@LucianoSerruya](https://twitter.com/LucianoSerruya)

📧 lucianoserruya (at) gmail (dot) com


*This note was firstly meant to be part of this other note, but I then decided to write it as a ...

Deploying full-stack applications with Firebase

# Running Cloud SQL proxy with docker-compose

Create a service account key file and name it `serviceAccount.json` right next to your `docker-compose.yml` file. For this example, my GCP project's id is `project-ac42`, chosen region is `us-central1`, and my Cloud SQL instance's name is `playground-cloud-sql-instance`

```yml
version: "3.8"
services:
  proxy:
    container_name: "cloud-sql-proxy"
    image: gcr.io/cloudsql-docker/gce-proxy:1.16
    volumes:
      - ./serviceAccount.json:/config
    ports:
      - 127.0.0.1:5432:5432
    command: "/cloud_sql_proxy -instances=playground-ace42:us-central1:playground-cloud-sql-instance=tcp:0.0.0.0:5432 -credential_file=/config"
```

Create a service account key file and name it serviceAccount.json right next to your `docker-compo...

Running Cloud SQL proxy with docker-compose

# Wordpress docker image with host user + docker-compose

```docker
FROM wordpress

# Taken from here:
# https://jtreminio.com/blog/running-docker-containers-as-current-host-user/

ARG USER_ID
ARG GROUP_ID

RUN if [ ${USER_ID:-0} -ne 0 ] && [ ${GROUP_ID:-0} -ne 0 ]; then \
    userdel -f www-data &&\
    if getent group www-data ; then groupdel www-data; fi &&\
    groupadd -g ${GROUP_ID} www-data &&\
    useradd -l -u ${USER_ID} -g www-data www-data &&\
    install -d -m 0755 -o www-data -g www-data /home/www-data &&\
    chown --changes --silent --no-dereference --recursive \
          --from=33:33 ${USER_ID}:${GROUP_ID} \
        /home/www-data \
        /var/www \
        /etc/apache2 \
;fi
        
USER www-data
```

```yml
version: '3.8'

services:

  wordpress:
    build:
      context: .
      args:
        USER_ID: 1000
        GROUP_ID: 1000
    image: wordpress:custom-user
    restart: always
    ports:
      - 8080:8080
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: exampleuser
      WORDPRESS_DB_PASSWORD: examplepass
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - ./wp:/var/www/html
      - ./apache-conf:/etc/apache2

  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_USER: exampleuser
      MYSQL_PASSWORD: examplepass
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql

volumes:
  db:
```

FROM wordpress

# Taken from here:
# https://jtreminio.com/blog/running-docker-...

Wordpress docker image with host user + docker-compose

# Notes on Dagger for Android

These are some notes I wrote back when I was doing some Android development and started learning about Dagger. I'm quite fond of Collected Notes now so I might as well share them!

You can find a demo app implementing Dagger + Architecture Components [here](https://github.com/LucianoFromTrelew/albums)

---

## Install

```gradle
apply plugin: "kotlin-kapt"

dependencies {
    implementation "com.google.dagger:dagger:{version}"
    kapt "com.google.dagger:dagger-compiler:{version}"
}
```

## `@Component`

An interface annotated with `@Component` gives the information Dagger needs to generate the dependencies graph at compile-time, manage them and be able to get dependencies from the graph. The parameters of the interface methods define what classes request injection. `@Component` will make Dagger generate code with all the dependencies required to satify the parameters of the methods it exposes

```kotlin
@Component(...)
interface AppComponent {
    .
    .
    .

    fun inject(activity: MyActivity)
}
```

## `@Inject`

Adding the annotation `@Inject` to a class will tell Dagger how to create a dependency. The constructor parameters will be the dependencies of that class.

So, with the `@Inject` annotation, Dagger knows how to create instances of the class, and what are its dependencies.

In case we are not able to instanciate certain object (for example, Activities and Fragments), we need to specify its dependencies not as constructor dependencies, but as field-level dependencies. To accomplish this, we need to annotate with `@Inject` the fields that we want Dagger to provide. We then need to obtain the app component and inject the Activities/Fragment dependencies calling the `inject` method and passing `this` as an argument in the `onCreate` method for Activities (**before calling super** - to avoid issues with fragment restoration), or in the `onAttach` method for Fragments (it can be done before or after calling `super`)

```kotlin
class MyViewModel @Inject constructor(...)
```

```kotlin
class MyActivity : AppCompatActivity() {

    @Inject
    lateinit var myViewModel: MyViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        (application as MyApplication).appComponent.inject(this)
        super.onCreate(savedInstanceState)
    }
}
```

There are two different ways to interact with the Dagger graph:

1. Declaring a function that returns `Unit` and takes a class as a parameter allows field injection in that class (i.e `fun inject(activity: MyActivity)`)
2. Declaring a function that returns a type allows retrieving types from the graph (e.g `fun mySubcomponent(): MySubcomponent.Factory`)

## `@Module`

Dagger Modules give us another way to provide instances of a type (mainly user defined interfaces). A Dagger Module is a class annotated with `@Module`. There we can define how to provide dependencies with the `@Provides` or `@Binds` annotations. Modules are a way to encapsulate how to provide objects in a semantic way.

You can include modules in components but you can also include modules inside other modules. Once a module has been added to either a component or another module, it's already in available in the Dagger graph, which means Dagger can provide those objects in that component. Before adding a module, **check if that module is part of the Dagger graph already** by checking if it's already added to the component or by compiling the project and seeing if Dagger can find the required dependencies for that module.

Good practice dictates that **modules should only be declared once in a component**.

## `@Binds`

Use `@Binds` to tell Dagger **which** implementation of an **interface** it needs to use when injecting the interface; it must annotate an abstract function (the class needs to be abstract too). The return type of the abstract function is the interface we want to provide an implementation for. The implementation is specified by adding an unique parameter with the interface implementation type (which should be annotated with `@Inject` so Dagger knows how to create it)

```kotlin
@Module
abstract class MyModule {
    @Binds
    abstract fun provideMyDependency(dependency: MyDependencyImpl): MyDependency
}
```

## `@Provides`

Apart from `@Inject` and `@Binds` annotations, we can use `@Provides` to tell Dagger **how** to provide an instance of a class inside a Dagger Module.

The return type of the `@Provides` function tells Dagger what type is added to the graph. The parameters of that function are the dependencies that Dagger needs to satisfy before providing an instance of that type. `@Provides` tell Dagger how to create instances of the type that that function returns

```kotlin
@Module
class MyModule {
    @Provides
    fun provideMyDependency(...): MyDependency {
        return MyDependencyImpl(...)
    }
}
```

## `@BindsInstance`

`@BindsInstance` tells Dagger that it needs to add some dependency in the graph (created outside of the dependency graph, for example `Context`) and whenever that instance is required, provide that object. With `@BindsInstance`, that dependency will now be available in the graph

```kotlin
@Component(...)
interface AppComponent {
    @Component.Factory
    interface Factory {
        fun create(@BindsInstance context: Context): AppComponent
    }
}
```

## `@Scope`

Dagger's default behaviour is to always provide a new instance of a type when inject dependencies. In case we want share the same instance across several objects (or if an object is very expensive to create, and we do not want to create a new instance every time it's declared as dependency), we can use **Scopes**. Using Scopes, we get an unique instance of a type in a Component. This is what is also called _to scope a type to the `Component`'s lifecycle_. Scoping a type to a `Component` means that the same instance of that type will be used every time the type is provided by a `Component`.

```kotlin
@Scope
@MustBeDocumented
@Retention(value = AnnotationRetention.RUNTIME)
annotation class MyScope
```

Add scope annotations in classes when using constructor injection (with `@Inject`) and add them in `@Provides` methods when using Dagger Modules.

### `@Singleton`

For scoping types to AppComponent's lifecycle, we can use the `@Singleton` scope annotation that is the only scope annotation that comes with the `javax.inject`. If we annotate a `Component` with `@Singleton`, all the classes also annotated with it will be scoped to the annotated `Component`

## `@Subcomponent`

Subcomponents are components that inherit and extend the object graph of a parent component. Therefore all object provided in the parent component will be provided in the subcomponent too. In this way, an object from a subcomponent can depend on an object provided by the parent component.

```kotlin
@Subcomponent
interface MySubcomponent {
    @Subcomponent.Factory
    interface Factory {
        fun create(): MySubcomponent
    }

    fun inject (...)
}
```

We also must define a subcomponent factory inside our subcomponent so that our main component knows how to create instances of our subcomponent

To include subcomponents to our app's component, we need to define a `Module` which lists every subcomponent, and then add that Module to our main component.

```kotlin
@Module(subcomponents = [MySubcomponent::class])
class AppSubcomponent
```

```kotlin
@Component(modules = [AppSubcomponents::class...])
interface AppComponent {
    .
    .
    .
    fun mySubcomponent()
}
```

### Scoping subcomponents

If we annotate the `Component` and classes with the same scope annotation, that'll make that type to have an unique instance in the `Component`.

The scope annotation's name should be named **depending on the lifetime it has** since annotations can be reused by sibling `Component`s

```kotlin
@MyScope
class MyViewModel @Inject constructor(...) { ... }
```

```kotlin
@MyScope
@Subcomponent
interface MySubcomponent { ... }
```

### Scoping rules

- When a type is marked with a scope annotation, it can only be used by `Component`s that are annotated with the same scope
- When a `Component` is marked with a scope annotation, it can only provide types with that annotation or types that have no annotation
- A subcomponent cannot use a scope annotation use by one of its parent `Component`s

### Subcomponents lifecycle

The lifecycle of a `Subcomponent` (or a `Component`) is the same lifecycle as the object that instanciated it. For example, if the Application class creates the `AppComponent`, then `AppComponent`'s lifecycle will be Application's lifecycle. If an Activity creates a `Component`, the `Component` will provides the same instances as long as that Activity is active

## `@Qualifier`

Qualifiers are useful when we want to add different implementations of the same type to the Dagger graph. A qualifier is a custom annotation that will be used to identify a dependency.

### `@Named`

`@Named` annotation allows us to provide a `String` to differentiate several objects of the same type

```kotlin
@Module
open class Bag {
    @Provides @Named("Love")
    fun sayLoveDagger2(): Info {
        return Info("Love Dagger 2")
    }
    @Provides @Named("Hello")
    fun sayHelloDagger2(): Info {
        return Info("Hello Dagger 2")
    }
}
```

```kotlin
@Inject @field:Named("Love") lateinit var infoLove: Info
@Inject @field:Named("Hello") lateinit var infoHello: Info
```

## Best practices

- When we create a component, you should consider **what element is responsible for the lifetime of that component**
- Use scoping **only when it makes sense**. Overusing scoping can have a negative effect on your app's runtime performance as objects stay in memory as long as the comnponent is in memory

## Testing

### Unit tests

You don't have to use Dagger for unit tests. when testing a class that uses contructor injection, you can directly call its constructor passing in fake or mock dependencies directly.

### End-to-End tests

A good practice is to create a `TestApplicationComponent` meant for testing. **Production code and testing code use different component configurations**. You also need a `TestApplication` class that creates the `TestApplicationComponent` instead of an `ApplicationComponent`. Then, this test application is uses in a custom `TestRunner` that you'll use to run your instrumentation tests.

```kotlin
class CustomTestRunner : AndroidJUnitRunner() {

    override fun newApplication(cl: ClassLoader?, name: String?, context: Context?): Application {
        return super.newApplication(cl, TestTodoApplication::class.java.name, context)
    }
}
```

In your `app/gradle.build` set up your custom test runner

```gradle
android {
    .
    .
    .
    defaultConfig {
        .
        .
        .
        testInstrumentationRunner "<YOUR_CUSTOM_TEST_RUNNER>"
    }
}
```


## References

- [Using Dagger in your Android app - Kotlin](https://codelabs.developers.google.com/codelabs/android-dagger)
- [Dagger basics](https://developer.android.com/training/dependency-injection/dagger-basics)
- [Using Dagger in Android apps](https://developer.android.com/training/dependency-injection/dagger-android)
- [Dependency Injection: Dagger and Koin](https://fueled.com/blog/dependency-injection-dagger-koin/)
- [How to Inject ViewModel using Dagger 2](https://www.techyourchance.com/dependency-injection-viewmodel-with-dagger-2/)
- [Dagger's documentation](https://dagger.dev/)
- [Dagger & Android's documentation](https://dagger.dev/dev-guide/android.html)

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

These are some notes I wrote back when I was doing some Android development and started learning about Dagger. I'm q...

Notes on Dagger for Android

# TypeScript: sharing type definitions seamlessly between server and client (with React.js)

This note will not be a fully detailed tutorial, as it would repeat many things already explained in [the original version](https://collectednotes.com/lucianoserruyaaloisi/typescript-sharing-type-definitions-seamlessly-between-server-and-client-with-vue-js). In this note I will explain briefly how to set up your React app (created with `create-react-app`) to share types between client and server.

You can find the repo for this demo app [here](https://github.com/LucianoFromTrelew/sharing-types-react)

---

1. Create your app with `create-react-app`

```bash
npx create-react-app <PROJECT_NAME> --typescript
```

2. Add the exact same `server` directory inside `src` than in the [Vue.js version](https://collectednotes.com/lucianoserruyaaloisi/typescript-sharing-type-definitions-seamlessly-between-server-and-client-with-vue-js). The `tsconfig.json` file won't be the exact same though, add the following content

```json
// src/server/tsconfig.json

{
  "include": ["*.ts"],
  "compilerOptions": {
    "module": "CommonJS",
    "outDir": "dist",
    "esModuleInterop": true
  }
}
```

3. Having created our React app with CRA, is not that easy to customize the webpack configuration used under the hood (props to Vue.js on that, it is really easy to do so). We will need a third-party dependency to customize webpack's development server configuration. In this note, we will be using [`react-app-rewired`](https://github.com/timarney/react-app-rewired). Install it with `npm install --save-dev react-app-rewired` and follow the instructions available on their [README file](https://github.com/timarney/react-app-rewired#readme).

4. Once installed, create a file named `config-overrides.js` right next to your `node_modules` directory and add the following content inside it

```javascript
const { configureServer } = require("./src/server/dist");

module.exports = {
  webpack: function (config, env) {
    return config;
  },
  jest: function (config) {
    return config;
  },
  devServer: function (configFunction) {
    return function (proxy, allowedHost) {
      const config = configFunction(proxy, allowedHost);
      config.before = configureServer;
      return config;
    };
  },
  paths: function (paths, env) {
    return paths;
  }
};
```

We are doing the same as in the [original note](https://collectednotes.com/lucianoserruyaaloisi/typescript-sharing-type-definitions-seamlessly-between-server-and-client-with-vue-js), importing our `configureServer` function and passing it to the `before` property for webpack's development server configuration

4. Install `nodemon` (`npm install --save-dev nodemon`) and create a file named `nodemon.json` right next to your `node_modules` directory. Add the following content inside it

```json
{
  "watch": ["src/server"],
  "exec": "tsc -p src/server && npm start",
  "ext": "ts"
}
```

5. Add a new npm-script to run `nodemon`

```json
"scripts": {
  "dev": "nodemon",
  ...
},
```

And we are done! You can now share type definitions between your node.js backend and your React app seamlessly.

Hope you liked it!

🐦 [@LucianoSerruya](https://twitter.com/LucianoSerruya)

📧 lucianoserruya (at) gmail (dot) com

This note will not be a fully detailed tutorial, as it...

TypeScript: sharing type definitions seamlessly between server and client (with React.js)

# TypeScript: sharing type definitions seamlessly between server and client (with Vue.js)

**TL;DR** - Have both your server code and client code within the same directory. Configure [webpack's devServer](https://webpack.js.org/configuration/dev-server/#devserverbefore) to host your API routes so you also avoid CORS issues during development

---

You can find the repo for this demo app [here](https://github.com/LucianoFromTrelew/sharing-types)

Have you ever created both your SPA and your server in TypeScript, and quickly realized that you needed to share type definitions between the two, but couldn't do it? Yeah, me too. This was most probably because you had two applications: one named "client", and another one named "server". Each directory had its own `package.json` and you had to run `npm <SOMETHING>` in different consoles to run your client server (development server most probably) and your back-end server. But here is the thing, you could only have a single server that serves both your SPA (when making a HTTP request to `/`), and your API routes (when making HTTP requests that start with `/api/`). I'm going to show you how to do this with a Vue app, but I don't think it'd much different with a React app (haven't tried though, in case you have and have faced issues, please let me know!).

Whenever you build a Vue app created with the `vue-cli`, you are working with a lot of webpack configuration under the hood that `vue-cli` handles for you. Luckily enough, you can tweak those settings to your liking creating a file named [`vue.config.js`](https://cli.vuejs.org/config/#vue-config-js) and exporting your changes. When you run Vue's development server via `npm run serve`, you are relying on [`webpack-dev-server`](https://github.com/webpack/webpack-dev-server), which can be highly customized. What we are going to do is pass a function to webpack to configure the development server, so we can add our API routes to it. This function receives an `express` server object for us to configure. After doing this, both our SPA and our API routes will be handled by the same server, and as a side-effect, **we don't have to worry about CORS** (our front-end app will be making HTTP request to the same origin, so we won't see any such errors in our browser's console)

## Scaffolding our app

We are going to create our app using the `vue-cli`, which in case you don't have it installed in your computer you can install it by running `npm install -g @vue/cli` or `yarn global add @vue/cli`. Then, create your Vue app by running `vue create .` to create your app in the current working directory (you can specify a name to create a brand new directory as well). Select `Manually select features` when asked and then check `TypeScript` by hitting the space key while selecting it. Press enter and leave the rest of the options with the default values. Once the `vue-cli` finished creating our app, run the dev server by typing `npm run serve` in your console.

Okay great, so far we have only created a Vue app with TypeScript support. Next, we are going to create our back-end server. To do so, add `express` as a dependency (`npm install express`) and its types as a development dependency (`npm install --save-dev @types/express`). Create a new directory called `server` inside `src` (`src/server`), and add an `index.ts` file inside of it (`src/server/index.ts`). We won't add anything special in this folder, we are only going to create and export our function to configure the server

```typescript
import { Express } from "express";

export function configureServer(app: Express) {
  app.get("/api", (_, res) => {
    res.json({
      message: "Hello world!"
    });
  });
}
```

Our function `configureServer` receives an `express` server object, and adds to it a request handler to response with a JSON object whenever a `GET` HTTP request is made to `/api`. You could of course connect to a database, read files, and what have you, but for the sake of this article we are going to keep it as simple as possible. If you would like to see a little bit more complex project, you can check [this repo of mine](https://github.com/LucianoFromTrelew/url-shortener) where I followed this same structure and connected the server to a Mongo database.

Next thing we need to do is tell webpack somehow we want to use that function to set up the development server. To do so, Vue allows us to create a `vue.config.js` file to customize webpack. We now face our first problem, as Vue [doesn't allow to create a `vue.config.ts` file](https://github.com/vuejs/vue-cli/issues/2138), so we cannot import our function from a TypeScript file into a JavaScript file without transpiling our TS code first. 

To transpile our TypeScript code, we need to run `npx tsc src/server/index.ts`, which will create a `index.js` file inside `src/server`. In case you want to reuse or extend some of your base  `tsconfig.json` settings (the one located at the same level as your `node_modules`, created by default by `vue-cli` when you created your Vue app with TypeScript support), you could add a new `tsconfig.json` in `src/server` with the following content

```json
{
  "extends": "../../tsconfig.json"
}
```

You should now compile your server-side TS code by doing `npx tsc -p src/server`.

Now that we have compiled down our TS code to JS, we can import our `configureServer` function into `vue.config.js`. Create a file named `vue.config.js` at the same level as your `node_modules` directory and add the following content

```javascript
const { configureServer } = require("./src/server");

module.exports = {
  devServer: {
    before: configureServer
  }
};
```

By doing this, [we are adding extra functionality to the development server](https://webpack.js.org/configuration/dev-server/#devserverbefore) before webpack configures it.

If we now try to run `npm run serve` once again, we see a syntax error telling us that about an unexpected token "export". This happens because our `src/server/index.js` code does not follow a format that node understands, or to be more precise, our TypeScript code is compiled to use in as a ECMAScript module, which is something node by default does not understand. To sort this out, we need to tweak our `src/server/tsconfig.json` file a little bit, changing the compiler options to compile our code to `commonjs`

 ```json
{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "module": "CommonJS"
  }
}
```

If we now compile once again our server-side code by doing `npx tsc -p src/server`, we should successfully run our app by doing `npm run serve`. Up to this point, we already have an API endpoint for us to try out. Navigate to `localhost:8080/api`, and you should get back a JSON object with a message.

This article is about sharing type definitions, but we haven't done anything of that yet! That's the next thing we are going to do, but before moving forward I'd like to tell that having to stop our development server, recompiling our server-side TS code, and running our dev server again every single time we make a change in our back-end is quite tedious, isn't it? We can sort that out by using `nodemon`. Install `nodemon` as a development dependency (`npm install --save-dev nodemon`) and then create a `nodemon.json` file (right next to your `package.json` file) with the next content

```json
{
  "watch": ["src/server"],
  "exec": "tsc -p src/server && npm run serve",
  "ext": "ts"
}
```

We are asking `nodemon` to watch files with the `ts` extension in our `src/server` directory, and run `tsc -p src/server && npm run serve` whenever a `*.ts` file inside `src/server` changes. To run `nodemon` with this configuration, we only need to run `npx nodemon` or create a npm-script in our `package.json`

```json
// package.json
{
  "scripts": {
    "dev": "nodemon",
    ...
  }
}
```

## Sharing type definitions

Great! Now whenever we change our back-end code our development server will restart automatically.

Let's now share some type definitions between our front-end and our back-end. Create and export the following `interface` in `src/server/index.ts` called `APIIndexRouteResponse`

```typescript
// src/server/index.ts

export interface APIIndexRouteResponse {
  message: string;
}
```

The response we are sending back whenever our back-end receives a `GET` HTTP request to `/api` already implements this interface, but it won't hurt us if we make it explicit

```typescript
app.get("/api", (_, res) => {
  const response = { message: "Hello world!" } as APIIndexRouteResponse;
  res.json(response);
});
```

Now, go to `App.vue` and add a async method called `mounted` in which we are going to make a HTTP request to our back-end using the `fetch` API

```vue
// src/App.vue
<template>
...
</template>

<script lang="ts">
import { Component, Vue } from "vue-property-decorator";
import { APIIndexRouteResponse } from "@/server";

@Component({})
export default class App extends Vue {
  data: APIIndexRouteResponse | null = null;
  async mounted() {
    const res = await fetch("/api");
    this.data = (await res.json()) as APIIndexRouteResponse;
  }
}
</script>

<style>
...
</style>

```

See how we are *treating* the back-end response as `APIIndexRouteResponse`? That's something we couldn't do if we had two different applications running, one for the front-end and another for the back-end.

Another thing to bear in mind is *how* we are importing type definitions. We are able to do `import {...} from "@/..."` because we have and `alias` set up in our `tsconfig.json` that maps `@/*` to our `src/` directory, so we don't have to navigate up in our files tree to import something.

## Conclusion

In this article we saw how to share type definitions between an Express app and a Vue app. It wasn't anything complicated, the trick was having both your front-end and back-end code in the same directory, and as an extra we saw how to host your API routes in the same server your client code is being served, to avoid CORS issues.

Hope you liked it!

🐦 [@LucianoSerruya](https://twitter.com/LucianoSerruya)

📧 lucianoserruya (at) gmail (dot) com

TL;DR - Have both your server code and client code w...

TypeScript: sharing type definitions seamlessly between server and client (with Vue.js)

# Firebase, am I right?

*Oh, Firebase. Didn't we all fell in love it with when we just knew it?* I know I did. Although I think is an awesome toolbox (I'm currently using it in many of my projects), we should also know where and when it works best.

## What is Firebase anyway?

Back in 2011 when it was first created, Firebase was a real-time database which allowed users to get updates whenever data changed. In 2014, it was acquired by Google, and nowadays Firebase is a *product suite* consisting in 19 different products (July, 2020). In case you want to have real-time updates of your data, send push notifications to your users, implement analytics and what have you, Firebase's got you covered. 

Firebase's original product still exists, and is actually called Firebase Real Time database (and it's not the only database offered by Firebase that allows you to get real-time data updates). But now Firebase is more than that, is a whole *platform*.

Because it is now part of Google, Firebase relies heavily on Google Cloud Platform. It depends so much on it that if you create a Firebase project, it automatically creates an underlying GCP project for you to use. You can also go the other way around, creating a GCP project first and then a Firebase project on top of your GCP project.

If you see some of the products Firebase offers, you may see that some of their names start with *Cloud*, such as *Cloud Firestore*, *Cloud Storage*, and *Cloud Functions*. This means that they are not "exclusive" Firebase products, but GCP products which can be accessed through Firebase. For those cases, Firebase provides Web and Mobile SDKs so you can easily use them from your web or mobile app.

When it comes to Cloud Functions, there is something more to say. To this day (July 7, 2020), you can write your Cloud Functions and deploy them through GCP in JavaScript (Node.js), Python, Go, and they've recently added Java (so you can also write them in any JVM-based language, such as Kotlin, Scala, and Clojure). If you deploy your Cloud Functions through Firebase, you can only choose Node.js (the `firebase` CLI also allows you to scaffold a TypeScript setup so you can write your code in TS instead of plain JavaScript). If you are writing serverless functions, GCP offers you a broader selection of languages and customization than Firebase. On the other hand, deploying your functions through Firebase is easier because you declare what type of event each function will listen to directly in the code, whereas with GCP you have to provide that information via CLI flags.

As a *Backend-as-a-Service* provider or a *comprehensive app development platform* (taken from [Firebase's landing page](https://firebase.google.com/)), Firebase **allows us to add elements of back-end as needed**. Maybe we bootstrapped our web app with a single `index.html` file and deployed it to Firebase Hosting, then we needed a database, so we integrated Firestore to our app, finally we required to run some code on the back-end or respond to some event, so we added some Cloud Functions.

## Golden Hammer

After my first experience of using Firestore to store data for some projects I worked on (and using the Firebase SDK, so hitting Firestore directly from the client app), I thought that we would increasingly stop relying on a back-end infrastructure having such technologies. After some weeks into these projects, I realized that I couldn't be further away from the truth. However, it is true that using Firestore or Real-Time Database you don't need a back-end at all for really simple projects ("simple projects" when it comes to back-end logic or data storage, I mean), but sooner or later they will require some sort of back-end when you want to tackle issues such as security, performance, UX, and so on. Maybe some day we won't require a back-end anymore, but I personally think that Firebase as a data storage provider won't quite make it possible.

Now I'd like to talk a little bit about Firestore. Firestore is a NoSQL document-based database (something like MongoDB) and one of its most interesting features is real-time updates. It was released back in 2017, and it certainly is Firebase's recommendation for a database - the Real-Time database still exists and you can use it, or even use both. [This article](https://firebase.google.com/docs/database/rtdb-vs-firestore) talks abouts key differences and helps you choose the optimal one for your project.

Instead of having tables and rows like in a SQL database, in Firestore we have collections and documents (documents can also have subcollections). Every document can have one or multiple fields of a certain type (such as string, boolean, number, timestamp, and some complex types such as arrays and maps), and you can have different documents in a single collection with different fields (they don't follow any sort of schema or structure). This flexibility comes as a trade-off over integrity, which you can have but you would have to do it manually (using [Cloud Functions](https://firebase.google.com/docs/firestore/extend-with-functions) or [Security Rules](https://firebase.google.com/docs/firestore/security/overview)). I won't dive deeper into how Firestore works; if you would like to know, I recommend you searching through the [Firestore's documentation](https://firebase.google.com/docs/firestore) and watching [this amazing video series](https://www.youtube.com/playlist?list=PLl-K7zZEsYLluG5MCVEzXAQ7ACZBCuZgZ) by [Todd Kerpelman](https://twitter.com/ToddKerpelman).

I would like to mention that every single data field in every single Firestore document in *indexed*, which means that queries are really fast, even if you are querying a massive collection (I won't explain how an index works or why it makes querying so fast though, sorry). The things is that having every single field indexed restricts how many operators we can use to query data, being only able to query for *equal*, *greater/lesser (or equal) than*, and some arrays operations. If you noticed, you cannot query for *distinct than* (you can work around this limitation by using an array and using the `in` operator in case you are looking for a discrete value).

Let's now suppose we're using Firestore to build a chat application. Firestore seems like a great choice for this kind of application, as we need to get real-time updates whenever data changes. Our MVP is up and running, but our users request for a search feature, which should allow you to search messages based on a string they give you. In a SQL world, we can very naively implement this feature by using the `LIKE` operator, like so

```sql
SELECT * FROM messages WHERE body ILIKE '%<TEXT>%'
```

(as far as I know, `ILIKE` is a PostgreSQL-specific feature)

Such a simple query is impossible to make in Firestore, and in fact there is a [whole page](https://firebase.google.com/docs/firestore/solutions/search) in Firestore's documentation talking about this issue and how to solve it using a third-party service such a Algolia (you could also solve it using Elasticsearch). 

So you now need to index your messages in a third-party service, and to do so you would add a Cloud Function that triggers when a new document is written to your Firestore collection. Then, you also need some way to communicate with your message-indexing service; maybe you are lucky enough to have a client SDK that allows you to do that from your client app, but if that's not the case (or if you don't want to communicate directly with it from your client app), you also need an endpoint which then hits your message-indexing instance. At the end of the day, you added several pieces of back-end infrastructure to add a single feature just because Firestore doesn't allow you to do a *full-text search* (and because of how Firestore works, it won't ever be able to do so).

Having said that, my recommendation is to bear in mind Firestore's limitation when choosing a data storage technology, because it'll be really hard to remove it once your app is integrated with Firestore than not using it in the first place (will be even worse if you use any client SDK to hit Firestore directly from your app). A rule of thumb I coined is that **if you need to search data in your app, do not use Firestore** (at least as your main database; you can of course use it to synchronize data between multiple clients).

## What about hosting?

If you want to host you static app or static files, Firebase has a product that meets your needs, and it is actually called Firebase Hosting. It really is an awesome product, because not only it allows you to host your static files, but it also caches your files in CDNs worldwide, so your files will be delivered almost instantly to your users.

If your app does not consist in a single static file (if it is not a Single Page Application, for example), but you need a server instance to render it (a Server-Side Rendered app), Firebase Hosting can also give you a hand. You can serve your app from a Cloud Function or a docker container running on Cloud Run, and rewrite any incoming request from Firebase Hosting to your app.

If you migrated your completely static app to a Server-Side Rendered one and you are still using Firebase Hosting, bare in mind the following: [**Firebase Hosting gives precedence to any files in your `public` directory you uploaded**](https://firebase.google.com/docs/hosting/functions#use_a_web_framework), so if you are still uploading a `index.html` file, that file will be served instead of reaching out to your server to render your app (I talked about this topic in [my previous article about Angular Universal](https://collectednotes.com/lucianoserruyaaloisi/angular-universal-what-they-don-t-tell-you)). To work around this issue, you would have to avoid uploading any HTML files to Firebase Hosting if you are always rendering your markup on the server (or maybe even upload a empty directory to Firebase Hosting). If you do so, please remember what will happen: as you will be reaching out to your server to render your app *every time*, it may take some time to start seeing any sort of response (due to the process of rendering your app, and due to [*cold starts*](https://cloud.google.com/run/docs/tips/general#optimizing_performance)). If you think it twice, maybe you don't want to render your app *every single time*, but you can cache it in a CDN. To still leverage Firebase Hosting's abilities of caching your content in CDNs worldwide, [**you will have to manually send the corresponding HTTP headers**](https://firebase.google.com/docs/hosting/manage-cache).

## Conclusion

There is not doubt that Firebase is an awesome tool set, but it has its pros and cons. It can be very useful when we are prototyping or scaffolding our app, but it may bring more headaches than solutions in the long run (or it may not, depends on the feature set).

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

Oh, Firebase. Didn't we all fell in love it with when we just knew it? I know I did. Although I think is an awesome tool...

Firebase, am I right?

# Angular Universal: what they don't tell you

*`ng add @nguniversal/express-engine` and we are good to go?*. Technically, yes, but you should keep reading

## What is Angular Universal anyway?

[Angular Universal](https://angular.io/guide/universal) is Angular's official library for rendering your Angular app on the server. Installing it with the previous command scaffolds an [express](https://expressjs.com/) server with proper setup to render your app. Because you now have an express server, you can easily add API routes or serve your static files for example, and you don't even have to worry about CORS! (your front-end app is being served from the same origin your back-end is). In other words, Angular Universal is the way to go in Angular if you want to implement SSR (*Server-Side Rendering*). Although it is the official library, there is a strange lack of official documentation about it (the whole Angular Universal docs in the angular.io site is only one-page long); luckily enough [Angular University has an amazing blog post with all you need to know about this library](https://blog.angular-university.io/angular-universal/)

Now that you have your Angular Universal app ready to go, you can run your development server doing `npm run dev:ssr`. *So, if my app is rendered in the server, what about event handlers?* Having an SSR app means that it will be rendered in the server, and the resulting markup will be sent to the client, but once in the browser **it will be executed once again**, so your client-side JavaScript code is booted (I recommend reading [this amazing article](https://developers.google.com/web/updates/2019/02/rendering-on-the-web) about rendering content on the web) - this process of executing your code once again is known as *rehydration*.

The thing is, you most probably are fetching your data in your component via a service, right? For example, if you were building a blog, you're probably calling methods of your `PostService` class. That's great, you are following Angular's guidelines (and you should definitively keep doing that now that you have an Angular Universal app). You're fetching your data in your component via your service, your component is rendered in the server, and once it's loaded on the user's browser, it will execute once again your component's code, so fetching your data a second time.

What can we do about this issue? We don't want to duplicate our requests to our back-end. Luckily enough, Angular provides us with some handy functions to detect what platform are we currently running our code on

```typescript
import { Component, Inject, PLATFORM_ID } from "@angular/core";
import { isPlatformBrowser } from "@angular/common";

@Component({...})
export class ... {
  constructor(..., @Inject(PLATFORM_ID) private platformId: Object) {}

  someMethod() {
    if(isPlatformServer(this.platformId) {
      console.log("This code will only execute on the server");
    }
  }
}
```

Besides [`isPlatformServer`](https://angular.io/api/common/isPlatformServer), Angular also provides other functions such as [`isPlatformBrowser`](https://angular.io/api/common/isPlatformBrowser), [`isPlatformWorkerApp`](https://angular.io/api/common/isPlatformWorkerApp),  and [`isPlatformWorkerUI`](https://angular.io/api/common/isPlatformWorkerUi).

This certainly does not look like a viable solution, as we would have to update all of our components that fetch data via services. The alternative would be to move this logic of only fetching data in the server/client to desired services.

Let's suppose we only fetch data in the client. This would work okay, and would solve our problem of fetching data twice. But about SEO? Didn't we move to a SSR application for SEO matters? We would be in the same place as before. Fetching data in the client would also mean that we would need to display some sort of progress bar or spinner to indicate that the app is loading.

Okay so, let's go the other way around, we'll fetch data only in the server. After you implemented that, you realized you don't see any data in your app. That's weird, because if you inspect the HTML returned by the server, data *is there*, but when you try to see it in the browser, it is not. Strangely enough, when your app now loads, it flashes some data, and then it disappears!

So what's going on here? Let's analyze a little bit further what's happening. Once again, data is fetched and components are rendered in the server, and resulting markup is sent back to the client's browser. Once in the browser, components' code will execute again, and data fetched a second time. Unfortunately, Angular does not preserve state between executions in different platforms, so that's why we first see a flash of data, and then a blank screen (the application loses its state it came from the server when it's executed a second time).

Having said that, we now need some mechanism to fetch initial data only in the server, and preserve it once it hits the browser. For that matter, Angular provides us with a class called [TransferState](https://angular.io/api/platform-browser/TransferState). This class allows us to cache our data in a key/value store and retrieve it later

```typescript
export class PostService {
  constructor(..., private transferState: TransferState) {}

  getPosts() {
    const GET_POSTS_KEY = makeStateKey<Post[]>("GET_POSTS_KEY");
    if (this.transferState.hasKey(GET_POSTS_KEY)) {
      const posts = this.transferState.get(GET_POSTS_KEY, [])
      return of(posts);
    }
    return this.http.get(...).pipe(
      tap(posts => {
        this.transferState.set(GET_POSTS_KEY, posts);
      })
    );
  }
}
```

The previous snippet shows the usual flow you would implement using TransferState

1. Check if data is already available, and return it as an Observable if it is
2. If it is not available, fetch it and cache it using `TransferState`

As your app's code will first be executed in the server, data will not be available, so it will make the HTTP request (following the previous example) and store it using `TransferState`. Then, when your app is booted in the browser, it will check if it has data available, which will have, and then return it without making any further request.

It is also pretty important to note that `TransferState` will **serialize your data**, and store it in a `script` tag inside your page, so **be sure that your data objects are serializable**

In order to use `TransferState`, you first need to import it in your app's modules. As you will be using it in both the browser and server, you need to import in in both `app.module.ts` and `app.server.module.ts`

```typescript
// app.module.ts

import { ..., BrowserTransferStateModule } from "@angular/platform-browser";

.
.
.

@NgModule({
  ...,
  imports: [
    ...,
    BrowserTransferStateModule
  ]
});
export class AppModule { ... }
```

```typescript
// app.server.module.ts

import { ..., ServerTransferStateModule } from "@angular/platform-server";

.
.
.

@NgModule({
  ...,
  imports: [
    ...,
    ServerTransferStateModule
  ]
});
export class AppServerModule { ... }
```

To further read about `TransferState`, I recommend you taking a look at [this article by Philippe Martin](https://medium.com/angular-in-depth/using-transferstate-api-in-an-angular-5-universal-app-130f3ada9e5b)

### Note for Firebase users

If you are using Firebase for its real-time capabilities and you are thinking about migrating your Angular SPA to Angular Universal, bare in mind that you will have to rethink how your application consumes data in real time. You won't be able to receive any updates if you cache your data using `TransferState`. If you still want to update your UI automatically when Firebase pushes a new snapshot of your data, you should only set your listeners **on the browser** - it won't make any sense setting real-time listeners in the server as execution will end once your app is rendered and ready to be sent to the browser

## Native APIs

Be aware that your app now first runs on a Node.js environment, so browser APIs won't be available. In case you were accessing `document` or `window` directly, you will now need to check if your app is currently running in the browser using the `isPlatformBrowser` function. [This document from the Angular Universal repo](https://github.com/angular/universal/blob/master/docs/gotchas.md) explains things a little bit in more detail and with some examples of how to avoid running into bugs.

## Deployment

You don't have a SPA anymore, so you can't rely on your static file hosting service any longer. You now need some server environment to deploy and serve your app. Fortunately enough, when you installed Angular Universal using express starter, it already set up a function called `app` in the `server.ts` file that returns a express server, so you can pass any incoming HTTP request from a serverless function to that express server, for example. You could also deploy it to a VPS or to Cloud Run or ECS dockerizing your app as well.

If you are deploying your Angular Universal app using Cloud Functions, **be extremely careful with the following**. Some tutorials on how to deploy your Angular Universal app to Cloud Functions are outdated, such as [this one from AngularFire docs](https://github.com/angular/angularfire/blob/master/docs/universal/cloud-functions.md) and [this one from Fireship](https://fireship.io/lessons/angular-universal-firebase/). Angular Universal starter introduced a subtle change but can introduce some tricky bugs. In previous versions, Angular-Universal-express starter used to create a `server.ts` file which exported an express server called `app`, so you could import this `app` object directly in your Cloud Functions code and pass it the incoming `req` and `res` objects. Latest versions of Angular-Universal-express starter now export an `app` **function** in your `server.ts` file, which receives no arguments and returns an express server, so in your Cloud Functions code instead of doing this

```typescript
import * as functions from 'firebase-functions';
const universal = require(`${process.cwd()}/dist/server`).app;

export const ssr = functions.https.onRequest(universal);
```

you would do this

```typescript
import * as functions from 'firebase-functions';
const universal = require(`${process.cwd()}/dist/server`).app();

export const ssr = functions.https.onRequest(universal);
```

Note that we are now calling `app` by doing `app()`. Pretty tricky bug, although easy to fix.

In case you had your Angular SPA deployed via Firebase Hosting, you can still use Firebase Hosting to proxy any requests to your SSR app hosted in a Cloud Function. In your `firebase.json` file, add a `rewrite` rule to pass any traffic to your Cloud Function, like so

```json
"hosting": {
  "rewrites": [{
   "source": "**",
   "function": "ssr", 
  }]
}
```

(assuming your Cloud Function that serves your Angular Universal app is named `ssr`. Change that name to whatever you named your Cloud Function).

There is a pretty significant caveat with Firebase Hosting. If you were serving your app using Firebase Hosting, you most definitively were uploading your static files using the `firebase` CLI. Now, our app is not static, is rendered by our `ssr` Cloud Function, but [Firebase Hosting gives a higher priority to static files in the `public` directory that you uploaded](https://firebase.google.com/docs/hosting/functions#use_a_web_framework). 

Let's now suppose that your app's index page (`/`) is server-side rendered, but you are still uploading to Firebase Hosting a static file called `index.html` - **this static file will be served by Firebase Hosting**, instead of reaching out to your Cloud Function to render your app. A workaround for this issue would be to create an empty directory (called `empty-dist`, for example), and uploading that directory to Firebase Hosting, so every incoming request is always passed to your Cloud Function. You `firebase.json` file should look like this

```json
"hosting": {
  "public": "empty-dist",
  "rewrites": [{
   "source": "**",
   "function": "ssr", 
  }]
}
```

## Conclusion

Angular is a great framework and it won't go away any time soon. In case you need to server-side render your app, Angular Universal is the go-to library - it comes with its caveats though.

Firebase is a pretty popular product suite that is used in many Angular apps, so it is to expect that it will still be used to host Angular Universal apps, but not without previously sort some issues out.

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

Angular Universal: what they don't tell you

ng add @nguniversal/express-engine and we are good to go?. Technically, yes, but you should keep...

Angular Universal: what they don't tell you

# Building a full-stack app with Next.js - Pagination

Hey there! This is the fourth (and maybe last) part [of a series](https://collectednotes.com/lucianoserruyaaloisi/building-a-full-stack-app-with-next-js-crud-operations) about building a full-stack app with Next.js and deploying it to the cloud using GCP and AWS (we are on a budget). Our app currently allows us to add, edit, delete, and list posts, using a PostgreSQL database.

Let's suppose you created a lot of posts in your app, up to a hundred. If you go to the index page of your app, it will display every single one of them all at once. This is not something good to have, as it becomes quite hard to navigate through your app. In this part of the series we are going to add *pagination*, which means that a row of buttons will appear at the bottom of the page to go to the previous/next one. As we are using a ORM that provides us some functionalities to implement this feature, it shouldn't require a lot of work.

This is how our pagination mechanism will work:

- If we visit `/`, the first 10 post will be displayed
- Our pages will work on a 0-based index, so page 0 will be the first one.
- To get another page, we will need to indicate it as a query parameter (for example `/?page=1` will display posts 11-20)
- To change the page size (default is 10 post per page), we will need to indicate it via the `count` query parameter.

So, if we visit the URL `/?page=2&count=20`, we should see posts 41-60.

We are going to add our pagination logic right into the `getServerSideProps` function in `pages/index.tsx`

```typescript
// pages/index.tsx

export async function getServerSideProps(context: GetServerSidePropsContext) {
  // `page` defaults to "0" and `count` to "10" if not sent
  const { page = "0", count = "10" } = context.query;
  const pageNumber = parseInt(page as string);
  const countNumber = parseInt(count as string);
  const postsToSkip = countNumber * pageNumber;

  const conn = await getOrCreateConnection();
  const postRepo = conn.getRepository<Post>("Post");

  const postsCount = await postRepo.count();
  const posts = (
    await postRepo.find({ take: countNumber, skip: postsToSkip })
  ).map(p => JSON.stringify(p));

  const previousPage = pageNumber > 0 ? String(pageNumber - 1) : "";
  // We don't want to indicate there is a next page if it'll be a blank page
  const nextPage =
    postsToSkip + countNumber < postsCount ? String(pageNumber + 1) : "";

  return {
    props: {
      msg: "Hello world!",
      posts,
      pagination: { previousPage, nextPage }
    }
  };
}
```

We are now using some of the query options TypeORM offers us to only fetch those posts that we want, using `take` (similar to `LIMIT` in SQL) and `skip` (used to tell TypeORM how many posts we want to skip).

Our pagination logic is now ready, we now have to display some buttons to navigate back and forth. For that, we are going to create a different component.

```react
// components/Pagination.tsx

type Props = {
  previousPage: string;
  nextPage: string;
};

type PaginationButtonProps = {
  page: string;
};

const PreviousPageButton: React.FC<PaginationButtonProps> = ({ page }) => {
  return (
    <a href={`?page=${page}`}>
      <button className="border border-teal-500 text-teal-500 block rounded font-bold pl-4 pr-2 py-4 flex items-center">
        <svg
          className="h-5 w-5 mr-2 fill-current"
          version="1.1"
          id="Layer_1"
          x="0px"
          y="0px"
          viewBox="-49 141 512 512"
        >
          <path
            id="XMLID_10_"
            d="M438,372H36.355l72.822-72.822c9.763-9.763,9.763-25.592,0-35.355c-9.763-9.764-25.593-9.762-35.355,0 l-115.5,115.5C-46.366,384.01-49,390.369-49,397s2.634,12.989,7.322,17.678l115.5,115.5c9.763,9.762,25.593,9.763,35.355,0 c9.763-9.763,9.763-25.592,0-35.355L36.355,422H438c13.808,0,25-11.193,25-25S451.808,372,438,372z"
          ></path>
        </svg>
        <span className="hidden md:block">Previous page</span>
      </button>
    </a>
  );
};

const NextPageButton: React.FC<PaginationButtonProps> = ({ page }) => {
  return (
    <a href={`?page=${page}`}>
      <button className="border border-teal-500 bg-teal-500 text-white block rounded font-bold pl-2 pr-4 py-4 ml-2 flex items-center">
        <span className="hidden md:block">Next page</span>
        <svg
          className="h-5 w-5 ml-2 fill-current"
          id="Layer_1"
          x="0px"
          y="0px"
          viewBox="-49 141 512 512"
        >
          <path
            id="XMLID_11_"
            d="M-24,422h401.645l-72.822,72.822c-9.763,9.763-9.763,25.592,0,35.355c9.763,9.764,25.593,9.762,35.355,0
                l115.5-115.5C460.366,409.989,463,403.63,463,397s-2.634-12.989-7.322-17.678l-115.5-115.5c-9.763-9.762-25.593-9.763-35.355,0
                c-9.763,9.763-9.763,25.592,0,35.355l72.822,72.822H-24c-13.808,0-25,11.193-25,25S-37.808,422-24,422z"
          />
        </svg>
      </button>
    </a>
  );
};

export const Pagination: React.FC<Props> = ({ previousPage, nextPage }) => {
  const previousPageButton = previousPage
    ? PreviousPageButton({ page: previousPage })
    : null;
  const nextPageButton = nextPage ? NextPageButton({ page: nextPage }) : null;
  return (
    <section className="flex justify-end m-4">
      {previousPageButton}
      {nextPageButton}
    </section>
  );
};
```

(it's a lot of code, but we added three new components: `Pagination`, `PreviousPageButton`, and `NextPageButton`, although we are only exporting the first one)

Pagination buttons taken from [here](https://tailwindcomponents.com/component/pagination-buttons).

To use our brand new pagination component, we just need to import it in our `pages/index.tsx` file and add it to its markup

```react
// pages/index.tsx

export default function Home({
  posts,
  msg,
  pagination
}: InferGetServerSidePropsType<typeof getServerSideProps>) {
  const postObjs = posts.map(p => JSON.parse(p) as Post);

  return (
    <Fragment>
      <h1 className="m-4 text-center text-4xl text-red-500">{msg}</h1>
      <PostList posts={postObjs} />
      <Pagination {...pagination} />
    </Fragment>
  );
}
```

We can do `{...pagination}` because `pagination` has the same fields that `Pagination` component requires as props.

## Deployment

Same as last part. Use our really handy npm-scripts to build and deploy our app

```sh
npm run gcp:build && npm run gcp:deploy
```


Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

Hey there! This is the fourth (and maybe last) part of a series about building a full-stack ...

Building a full-stack app with Next.js - Pagination

Hello there! This is the third part of a series about building a full-stack app with Ne...

Building a full-stack app with Next.js - CRUD operations

# Building a full-stack app with Next.js - Adding a database

Hello there! This is the [second part of a series](https://collectednotes.com/lucianoserruyaaloisi/building-a-full-stack-app-with-next-js) about building a full-stack app with [Next.js](https://nextjs.org/). After the first article, we built and deployed to the cloud (using Docker) an app that fetches posts from a API, displays them as a list, with the ability to navigate to a different page to see some post in detail whenever you click on one on the index page. In this article, we are going to add a database and fetch our posts from it, instead of a remote API.

## Setting up our local database

We're using Docker for our deployment, but nothing is stopping us from using Docker for development as well! In this case, we'll be using a dockerized database so we don't have to deal with installing a new service in our machine, setting up users and what have you.

We are going to use [docker-compose](https://docs.docker.com/compose/install/) to spin up a PostgreSQL database. Once you have it installed, create a `.env` file and a `docker-compose.yml` file next to your `node_modules` with the following contents

```yml
# docker-componse.yml
version: '3.8'
services:
  pg:
    image: "postgres:alpine"
    container_name: "next-db"
    env_file:
      - ".env"
    ports:
      - "5555:5432"
    volumes:
      - "pg:/var/lib/postgresql/data"
    restart: "always"
volumes:
  pg:
```

```
# .env
POSTGRES_PASSWORD=password
POSTGRES_USER=user
POSTGRES_DB=db
POSTGRES_HOST=localhost
POSTGRES_PORT=5555
```

A quick rundown of what we just did. Having these files set up, we will create a docker container based on the `postgres:alpine` image. That container will create a PostgreSQL database named `db`, with a user named `user` whose password is `password` (you can of course change this values to your like). The `POSTGRES_HOST` and `POSTGRES_PORT` environmental variables will be only used in our app.

Create your container by running

```sh
docker-compose up -d
```

This will download required docker images in case you didn't have them already and create every specified container in the `docker-compose.yml` file.

We mapped container's port 5432 to our local 5555 port, so we could access our dockerized Postgres instance by running

```sh
psql -h localhost -p 5555 -U user -d db
```

Or, if you don't have `psql` (PostgreSQL client) installed locally, you could achieve the same by creating a docker container and running `psql` from it, and deleting it after closing the `psql` session

```sh
docker run -ti --rm --network=host postgres:alpine psql -h localhost -p 5555 -U user -d db
```

After typing our provided password (if your didn't change the `.env` file, it should be `password`), we should see a `psql` prompt, in which we could write some SQL statements.

## Connect our app to our local database

Awesome! Up to this point we have our PostgreSQL database running. Next thing we have to do is connecting our app to it.

To do so, we are going to use [TypeORM](https://typeorm.io/#/), an Object-Relational Mapping library for TypeScript. Install required dependencies with the following command

```sh
npm install --save typeorm pg reflect-metadata
```

Next, we'll have to update our `tsconfig.json` file to enable some TypeScript settings TypeORM requires

```
"compilerOptions": {
  .
  .
  .
  "emitDecoratorMetadata": true,
  "experimentalDecorators": true
}
```

Add the following line at the top of your `_app.tsx` file

```typescript
import "reflect-metadata"
```

We are almost done with this part. Next thing we'll do is define our `Post` model. Although we already had one, we need to create a class now and decorate it with the `@Entity` decorator so TypeORM can create the underlying tables in our database, and knows how to retrieve, update, and save such an object. Create a `models` directory next to your `pages` directory and add the following file

```typescript
// post.model.ts

import { Entity, Column, PrimaryColumn } from "typeorm";

@Entity()
export class Post {
  @PrimaryColumn()
  id: number;
  @Column({ length: 256 })
  title: string;
  @Column("text")
  body: string;
}
```

Great. We now need to establish a connection with our database somewhere in our application. For that, we are going to create a utility function that returns a connection. Create a directory called `utils` (next to `pages/`) and create a `index.ts` file inside of it

```typescript
// utils/index.ts
import { Post } from "../models/post.model";
import { getConnection, createConnection } from "typeorm";

export async function getOrCreateConnection() {
  try {
    const conn = getConnection();
    return conn;
  } catch (e) {
    return createConnection({
      type: "postgres",
      host: process.env.POSTGRES_HOST as string,
      port: parseInt(process.env.POSTGRES_PORT as string),
      username: process.env.POSTGRES_USER as string,
      password: process.env.POSTGRES_PASSWORD as string,
      database: process.env.POSTGRES_DB as string,
      entities: [Post],
      synchronize: true,
      logging: false
    });
  }
}

```

This function tries to get the default connection, and creates a new one if it doesn't exist.

Next.js picks up automatically any `.env` files in our project, and uses it to populate the `process.env` object with its values. We can now  use those values to establish a connection with our database. As you can also see, we are indicating our entities to TypeORM in the `entities` entry (we only have one entity, but if we were to add more we would have to update that list so TypeORM can create the corresponding tables in the database)

In your home page (`pages/index.tsx`), get a connection in the `getServerSideProps` function

```typescript
// pages/index.tsx

export async function getServerSideProps() {
  const conn = await getOrCreateConnection();
.
.
.
```

If you now try to navigate to `http://localhost:3000/`, a 404 page will be shown and a error message will be displayed in your server console saying that `Support for the experimental syntax 'decorators-legacy' isn't currently enabled`. To solve that, stop your development server, and install the following dev dependencies

```sh
npm install --save-dev @babel/plugin-proposal-class-properties @babel/plugin-proposal-decorators babel-plugin-transform-typescript-metadata
```

(yes it's ugly, I know)

Then, create a `.babelrc` file next to your `node_modules` and add the following content

```
{
  "presets": ["next/babel"],
  "plugins": [
    "babel-plugin-transform-typescript-metadata",
    ["@babel/plugin-proposal-decorators", { "legacy": true }]
  ]
}
```

Next.js will automatically apply any configuration to Babel if a config file is available. Start the development server (`npm run dev`) once again and it should work just fine

## Fetching data from our local database

After sorting out some issue we had with TypeORM, it's time of us to fetch some posts. To do so, we need to get the corresponding repository from the connection object

```typescript
// pages/index.tsx

import { Post } from "../models/post.model";

export async function getServerSideProps() {
  const conn = await getOrCreateConnection();
  const postRepo = conn.getRepository(Post)
.
.
.
```

Strangely enough, that fails. To sort it out, we need to tweak it a little bit

```typescript
const postRepo = conn.getRepository<Post>("Post")
```

It certainly does not look pretty, but it solves our problem (if you know why this issue occurs, please reach out to me, you will find my contact info at the bottom of the article).

Once we have our posts repository, we can fetch our posts from the database and make queries to it!

```typescript
const localPosts = await postRepo.find();
console.log(`${localPosts.length} posts fetched from the database`);
```

If you refresh your page, you will see that your server console printed it fetched 0 posts from the database, which makes sense, as we don't have any posts in our database right now. What can we do right now? We don't have any form to create a new post either. We can access the database directly, so we could `INSERT` some records into it.

 Connect to your database as you did before, and run some `INSERT` statements to create some posts. If you like, you can run `\d post` in your `psql` console to see how TypeORM created your `post` table. It should look something like this

```sql
db=# \d post
                       Table "public.post"
 Column |          Type          | Collation | Nullable | Default 
--------+------------------------+-----------+----------+---------
 id     | integer                |           | not null | 
 title  | character varying(256) |           | not null | 
 body   | text                   |           | not null | 
Indexes:
    "PK_be5fda3aac270b134ff9c21cdee" PRIMARY KEY, btree (id)
```

```sql
db=# INSERT INTO post VALUES (1, 'My first post', 'Hello world!'), (2, 'Next.js is awesome', 'It really is great!'), (3, 'TypeScript also rocks', 'TS rlz');
INSERT 0 3
```

If you now refresh your page, it should display a message in the server console saying that it fetched three posts from your database.

Okay great, we now have a local database with some data, our app is connecting to the database and fetching some posts. What we now need to do is pass that data to our page component as props.

```typescript
export async function getServerSideProps() {
  const conn = await getOrCreateConnection();
  const postRepo = conn.getRepository<Post>("Post");

  const posts = await postRepo.find();
  console.log(`${posts.length} posts fetched from the database`);

  return {
    props: { msg: "Hello world!", posts }
  };
}
```

Refresh your page, aaaand it fails. It now says that it cannot serialize our `Post` object. To sort it out, we may have to serialize our data objects, and then parse them back again in our page component

```react
import { InferGetServerSidePropsType } from "next";
import { Fragment } from "react";
import { PostList } from "../components/PostList";
import { getOrCreateConnection } from "../utils";
import { Post } from "../models/post.model";

export async function getServerSideProps() {
  const conn = await getOrCreateConnection();
  const postRepo = conn.getRepository<Post>("Post");

  const posts = (await postRepo.find()).map(p => JSON.stringify(p));
  console.log(`${posts.length} posts fetched from the database`);

  return {
    props: { msg: "Hello world!", posts }
  };
}

export default function Home({
  posts,
  msg
}: InferGetServerSidePropsType<typeof getServerSideProps>) {
  const postObjs = posts.map(p => JSON.parse(p) as Post);
  return (
    <Fragment>
      <h1 className="m-4 text-center text-4xl text-red-500">{msg}</h1>
      <PostList posts={postObjs} />
    </Fragment>
  );
}
```

We are now fetching our posts from the database, converting them to a string, passing them to the component as props, and finally parsing them back as `Post` objects. Maybe there is a better solution to this issue than serializing and parsing our data objects manually, but I haven't found it yet (if you have please let me know).

You can see that our home page now displays our posts, great! But our `PostList` and `PostListItem` components are outdated - their props expect a `Post` that's defined in our `types.d.ts` file, so we should update that. First, delete `types.d.ts`. Then, import `Post` model in both `components/PostList.tsx` and `components/PostListItem.tsx` (I know, we are now importing our `Post` model everywhere we reference, instead of having it globally available - tough luck)

If you click on a post on the home page now, the detail page shows other post (the one fetched from the API), we have to update that page as well

```react
// pages/[id].tsx

import { GetServerSidePropsContext, InferGetServerSidePropsType } from "next";
import { Fragment } from "react";
import { getOrCreateConnection } from "../../utils";
import { Post } from "../../models/post.model";

export async function getServerSideProps(context: GetServerSidePropsContext) {
  const { id } = context.params;
  const conn = await getOrCreateConnection();
  const postRepo = conn.getRepository<Post>("Post");
  const post = JSON.stringify(
    await postRepo.findOneOrFail(parseInt(id as string))
  );
  return {
    props: { post }
  };
}
export default function PostDetailPage({
  post
}: InferGetServerSidePropsType<typeof getServerSideProps>) {
  const postObj = JSON.parse(post) as Post;
  return (
    <Fragment>
      <h1 className="m-4 text-center text-3xl text-red-400">{postObj.title}</h1>
      <p className="m-8">{postObj.body}</p>
    </Fragment>
  );
}
```

Nothing new here. We are using the `findOneOrFail` method from the `postRepository` object to fetch a single `Post`, serializing it, and then parsing it back to a `Post` object in our page component

## Deployment

We have successfully integrated a database into our app. Now instead of fetching posts from a REST API, we are fetching them from a PostgreSQL database running locally. Now we have to deploy our app's new version to the cloud, but what can we do about our database?

GCP has its own serverless SQL provider ([Cloud SQL](https://cloud.google.com/sql)), but after being charged 15 USD for an instance I didn't use at all I wouldn't recommend it for such a toy project. Unfortunately it doesn't have a free-tier so I wouldn't even consider it for this case.

If we search for other cloud providers, we can find that AWS offers [RDS](https://aws.amazon.com/rds/), which has a pretty generous free quota of 750 hours a month, so we might as well choose RDS over Cloud SQL for this project.

Here is the thing, our app is running in Cloud Run, which gives us a HTTPS URL to visit our app once deployed. As our container that's running the app can be torn down at any time, we don't get a fixed IP to referece, only the URL. On the other hand, RDS allows us to configure security rules to allow inbound and outbound traffic from or to a specific IP, or a specific VPC, but not to allow traffic from a URL, so we couldn't tell RDS to only allow incoming traffic from our app. A workaround we could implement here, is allowing *all traffic* to our database, so our app running in Cloud Run could communicate with our database running in RDS. Although this solves our issue, **we would be exposing our database to the world**

What about migrating our app to AWS then? It is a very feasible option, yes. We could deploy our app to an ECS cluster using [AWS Fargate](https://aws.amazon.com/fargate/), which is a somewhat similar product to Cloud Run (serverless containers). I tried this alternative, and I found it quite more complicated that using Cloud Run (creating a cluster, using a load balancer to get a URL, creating a repository to deploy your image, and so on). Also, there were two things I didn't like about deploying this app to AWS:

1. *Lack of SSL certificate out-of-the-box*. In case you noticed, our app running on Cloud Run is accessible via a HTTPS URL. GCP takes care of provisioning our app with a certificate for secure communications.
2. *Pricing*. Running containers on Fargate is *expensive*. I deployed a simple nginx container over the weekend, and I had been charged 1 USD on Monday already, for the simplest container that received no traffic at all.

So, my recommendation for this app is Cloud Run (GCP) for our app, and RDS (AWS) for the database. This multi-cloud approach is based solely on a pricing matter, we don't want to spend any money on a toy app, don't we? Nonetheless is a trade-off, where we are choosing pricing over security (our database would of exposed to the world)

So, create a PostgreSQL database in RDS (save your master username and password!), and once you have it available you need to edit its security rules to allow any incoming traffic. To do so, do the follwing

1. Go to RDS dashboard and select your database
2. In the `Security group rules` card, select any security group
3. Select `Actions` > `Edit inbound rules`
4. Add a new rule with type `All traffic`, and source `Anywhere`, and save changes

Having done that, now we have to tell somehow to our app running in Cloud Run how to reach to our PostgreSQL database. In development, we are using a `.env` file, and credentials are picked up from environmental variables. We are doing the same in here, but without a `.env` file. Cloud Run allows us to define environmental variable to our service, so that's what we are going to use

1. Go to GCP console, and then to Cloud Run dashboard
2. Select your service
3. Click `EDIT & DEPLOY NEW REVISON`
4. Select the `Variables` tab
5. Add the following environmental variables
   5. `POSTGRES_HOST`. Your RDS database endpoint
   5. `POSTGRES_PORT`. 5432 by default
   5. `POSTGRES_USER`. Your RDS database username
   5. `POSTGRES_PASSWORD`. Your RDS database username password
   5. `POSTGRE_DB`. `postgres` by default
6. Click `DEPLOY`

Before deploying, we need to indicate docker to ignore our `.env` file when building our image. To do so, just add the following line to `.dockerignore`

```
.env
```

Our app now has the corresponding environmental variables, but we haven't deployed our app's latest version. To do so, repeat the deployment steps made in the first part of this series. If you like, you can add some really handy npm scripts to automate this process a little bit

```json
"scripts": {
    "gcp:build": "gcloud builds submit --tag gcr.io/<YOUR_PROJECT_ID>/my_nextjs_app
",
    "gcp:deploy": "gcloud run deploy <YOUR_SERVICE_NAME> --image gcr.io/<YOUR_PROJECT_ID> --platform managed --region us-central1 --allow-unauthenticated"
}
```

Now in order to build your app and deploy it to Cloud Run, you only need to run

```sh
npm run gcp:build && npm run gcp:deploy
```

Build your image, deploy your app, and check the live version. You shouldn't see any data, as our RDS database doesn't have any data whatsoever. Create some data by connecting to your RDS database using `psql` (just like we did before, but you will now have to change the host you were indicating to `psql` via the `-h` flag)

```sh
docker run -ti --rm --network=host postgres:alpine psql -h <YOUR_RDS_ENDPOINT> -p 5432 -U <YOUR_RDS_USER> -d <YOUR_DB_NAME>
```

---

In this second part of the series we didn't add any features to our app, but completed a migration to displaying data from a database. It did require quite some work but we made it through! In the next part we are going to add a form so we can add and edit posts, and we are going to see how we can send data back and forth to the server. Also, we will add a button to delete posts.

Hope you liked it!

🐦 @LucianoSerruya

📧 lucianoserruya (at) gmail (dot) com

Hello there! This is the second part of a series about building a full-stack app with...

Building a full-stack app with Next.js - Adding a database

In my last article I talked about SEO, SSR, and how Next.js can help us in those matters. In this new art...

Building a full-stack app with Next.js

# My take on Next.js

Hi! My name is Luciano Serruya Aloisi, I'm a 23-years old software developer from Trelew, Chubut, Argentina 🇦🇷. I've been wanting to start writing for some time now, and having such an amazing platform as Collected Notes really made my mind about it, so here it goes!

In this first article, I'd like to write about [Next.js](https://nextjs.org/), the React framework. *But, how come?* some may ask to themselves; *isn't React a framework already?*. Well, not exactly. As it says right in [React.js' home page](https://reactjs.org/), is a JavaScript library for building user interfaces. The confusion arises because it can be used as a framework, scaffolding your app with `create-react-app`. In such an app, you can write your components using JSX, display several "pages" using react-router, handle your app's state with Redux, validate your forms using Formik, and so on. As you may have noticed, I named several others libraries besides React for building your React app. So, to move on with the article, I want to make clear that React is a library that does one and one thing only, and that is helping you build user interfaces (and it does it really really well).

*Okay great, we have create-react-app for ours React apps, why do we need a framework for our UI library then?*. That's a valid question as well, yes. Although a React app created with `create-react-app` already provides a lot of setup, it may not be the best option for some scenarios.

Lets suppose you are building a platform for knowledge sharing, where users can create entries about a certain topic and some other s users can update it (yes you are building another Wikipedia, I know). The way a traditional React app works (and not only React apps, Vue and Angular apps works this way as well) is serving only a single HTML file with one or more JavaScript files to render your whole app. This is what is called a *Single Page Application* (*SPA*), where the server only responds to HTTP requests with a single file and page routing is done via JavaScript on the browser.

Okay, so you have your brand new app which is already deployed and working, but you try searching some entry you know is on your site in Google and you can't find anything, or if you are lucky enough you do find something, but really deep into Google's pages. Google is merciful enough to at least show your site in some entries, but you also tried with Bing and DuckDuckGo with even worse luck, your site doesn't even appear on other search engines. *What is going on?* - you say to yourself. The thing is, because your app is a single HTML file *with no content on it*, but content is rendered after it is loaded into the client's browser,  search engines' crawlers cannot index your app's pages properly - I won't dive deeper into how crawlers work because I don't really know about the topic, but you can think of them as programs that constantly fetch web pages and build some sort of index (the same kind you can find in a book) which indicates where to go if you are looking for a specific term.

That's a problem, because you already built your site as a SPA but you need search engines' crawlers to be able to index your content so it can be easily found when searching for it - in other words, you need to do some *Search Engine Optimization* (*SEO*) on your site. One of the most typical solutions to tackle this issue is doing *Server-Side Rendering* (*SSR*), that is rendering your content on the server, and serving your markup already rendered. But again, you have a React SPA, which renders content on the browser, so what can you do?

Here is when Next.js comes into play. It would be wrong from my side to say that SSR is the only thing that Next.js can give you (it offers  plenty of features), but in this article I'll be only focusing on it. One of the biggest selling points of Next.js is its ability to render your React components on the server (a Node.js server), and respond with that markup to any HTTP requests that it receives. This will be a major improvement when it comes to searching your site in several search engine (it won't be instant-quick though, some time will pass before crawlers index your content).

Sounds pretty good, right? It is, but before jumping in the Next.js boat and rush to migrate your React app/s to a Server-Side rendered version, bear in mind that a migration of such sort won't be that easy. There are three key points I would like to talk about:

## File structure

In Computer Science and Software Development, one of the most typical definition of a *framework* is *some code that you don't directly call, but it calls your code*. Using this pretty vague description of what a framework is, we can clearly tell that Next.js is a framework. Next.js implements what is called a "file-based routing", so you can define your routes creating a different file per route inside the `pages` directory (or `src/pages`) . For example, if you want an `about` and a `contact` page, you would create an `about.js` and a `contact.js` files.

Migrating to Next.js wouldn't mean a great effort if you already had a `views` or a `pages` directory in your React app. Of course you can keep your `components` directory or whatever other file structure you were using, the only rule you have to follow is the *page-components-go-in-pages-directory*. 

## Data fetching

This one is quite interesting and, in my opinion, one of the best features Next.js provides. In your SPA built with React, you most surely fetch your data in the `componentDidMount` method or using the `useEffect` hook. With Next.js, as you want your component to be populated with data before reaching the client's browser, the framework offers a method called `getServerSideProps` (Next.js 9.3+) in which you can get all the data you need to render your component. This means making HTTP requests, querying a database, reading a file, and so on. Whatever data this function returns, will be passed as props to your page component. Two take-away points:

1. Only page components should export a `getServerSideProps` function - won't work with non-page components
2. Data meant to be passed as props to your page component should be under the `props` key in the object you are returning from `getServerSideProps`

```typescript
export async function getServerSideProps(context: GetServerSidePropsContext) {
.
.
.
return {
  props: {
    <YOUR_DATA>
  }
};
```

(oh as you may have noticed, Next.js supports TypeScript out of the box. Just create a empty `tsconfig.json` at root level and rename your `.js` file for `.tsx`)

Having this method comes really handy, as you don't need to have an API endpoint for fetching your initial data - you just query your database directly in the `getServerSideProps` method

## Deployment

Once you have your Next.js app, how can you deploy it? Next.js allows you to generate static files out of all your pages, so you can deploy them to a static hosting service. One thing to keep in mind is that if you choose this approach, your static files will be generated at build time, which means they will fetch any server-side data at build time (there is [a whole section in the docs](https://nextjs.org/docs/basic-features/pages#static-generation-recommended) that talks about generating static file with and without external data).

If build-time data-fetching is not what you are looking for (for example, if you want to query a database every time a page is visited), you should consider deploying your site as a Node.js app to a VPS, as a Docker container, using a *Function-as-a-Service* provider (you need a [custom server](https://nextjs.org/docs/advanced-features/custom-server) for this approach), and so on.

---

There is yet another catch with Next.js (well actually, with Server-Side Rendered JavaScript components libraries/frameworks) when it comes to rendering components. I said before that your UI components are rendered in the server whenever a HTTP request comes in. But that's not the end of it, because when the app is loaded in the client's browser, **components are rendered again** (so they are rendered twice, once in the server, once in the browser). To demonstrate this point, I've developed a [demo app in Next.js](https://rendered-twice-yb3hbijb5q-uc.a.run.app/) which this is the only thing it shows

```react
export default function Home() {
  return <h1>{Math.random()}</h1>;
}
```

It has a single page, and the only thing it shows is a random number. As this component will be executed twice, the server will generate a random number and render it inside an `h1` element. Then, when the page hits the client's browser, the component will be executed once again, generating yet another random number. To check that the displayed number is not the same the server generated, check the page's source (`Ctrl+U` in Chrome) and look for the `h1` element, you should see a different floating number.
 
## Conclusion

In this article I talked about how a SSR page can help you with SEO, and how Next.js helps you to achieve that for your React apps. I also named a few caveats to bear in mind while (or if) migrating your React SPA to a Next.js SSR app. Next.js may not be the end-all, and maybe not the best option for your situation either, but it is nonetheless a great framework with a lot of out-of-the-box features that you shouldn't stop checking!

Hope you liked it!

🐦 [@LucianoSerruya](https://twitter.com/LucianoSerruya)

📧 lucianoserruya (at) gmail (dot) com