
# Motivation

I've been sick this week and needed a good distraction, so why not rebuild my old Gatsby site
using Next.js, MDX, Tailwind CSS, and Radix UI? I wanted to list out what libraries and resources I've found the most
useful.

# Libraries and references

0. [nextjs-typescript-mdx-blog](#nextjs-typescript-mdx-blog) was an amazing reference when setting up. I copied quite a bit from this project.
1. [next-mdx-remote](#next-mdx-remote) for serializing mdx and post metadata in `getStaticProps`.
2. [tailwindcss](#tailwindcss) for styles.
3. [@tailwindcss/typography](#tailwindcsstypography) for styling mdx.
4. [@radix-ui](#radix-ui) and `tailwindcss-radix` for some pretty great component primitives.
5. [framer-motion](#framer-motion) for simple filter and page transitions.
6. [react-headroom](#react-headroom) for fancier header nav behavior.

## nextjs-typescript-mdx-blog

I wanted to start by giving credit where it's mostly due - I referenced and copied [nextjs-typescript-mdx-blog](https://github.com/ChangoMan/nextjs-typescript-mdx-blog) a lot while setting this project up, especially the logic for building pages using `getStaticProps` and `getStaticPaths`.

## next-mdx-remote

[This package](https://github.com/hashicorp/next-mdx-remote) enables loading mdx files with metadata and plugins in `getStaticProps`, hydrating templates with content at build time. It's pretty cool - I suggest checking that link to see how it's done, or referencing the project above.

## tailwindcss

One of my main motivations in rebuilding this site was getting the opportunity to use tailwind a bit more, because I have always been a little skeptical of the hype. I still see value in using css modules instead, but I will save those thoughts for another day.

Tailwind was awesome for spinning something up quickly, and its baseline styles and colors are nice looking. I constantly had to reference the docs for every property (is it `font-bold` or `text-bold`?), but that time would have otherwise been spent setting up modules and applying classes, creating my own design system, etc. The ecosystem is awesome, the plugin configuration is easy and provided everything I needed, and I am happy that I used it. I still think it can look like spaghetti 🍝, but I tried to keep everything as simple as humanly possible to elminate those crazy long classnames.

Eventually, I will learn some pattern for maintaining these classnames by logical grouping with `classnames` or by another method. For now, it's fine.

## @tailwindcss/typography

Making our lives even easier, this package allows you to apply tailwind styles to other content we don't control. In this case, that is the mdx content. This is covered in the tailwind docs [here](https://tailwindcss.com/docs/typography-plugin), but for our case it takes two steps:

1. add the plugin to tailwind config:

```js:tailwind.config.js
module.exports = {
  theme: {
    // ...
  },
  plugins: [
    require('@tailwindcss/typography'),
    // ...
  ],
}
```

2. wrap the mdx component with an element with the `prose` class:

```jsx:/pages/posts/[slug].tsx
<div className="prose dark:prose-invert">
  <MDXRemote {...source} components={components}/>
</div>
```

## @radix-ui

I have always wanted an unopinionated library of components to build on top of so as not to have to constantly rebuild the same stuff between projects. I think this is what I've been looking for. I used it for the post filters,
and the dark mode toggle as well before switching to another lib for that. So far, I am sold.

## framer-motion

This is the first time I've used framer-motion, but I am in love with the interface, and the way they have simplified problems that used to be pretty time-consuming such as animating lists and page transitions.

### Post filter animation

The post list animation works by wrapping each list item in `motion.div` and providing each with a unique key. When a filter is selected and the list changes, framer handles everything else:

```tsx
// ...

posts.map((post) => {
  <motion.div
    key={post.slug}
    layout
    initial={{ opacity: 0 }}
    animate={{ opacity: 1 }}
    exit={{ opacity: 0 }}
    transition={{ duration: 0.25 }}
  >
    <Post post={post} />
  </motion.div>;
});

// ...
```

### Page transitions

The page transition works in a similar way by adding the route as a key and wrapping whatever elements need to be animated:

```tsx:/components/Layout.tsx
import { motion } from "framer-motion";
import { useRouter } from "next/router";
import React from "react";


export default function Layout({
  children,
}: {
  children: React.ReactNode;
}) {
  const router = useRouter();

  return (
    <div>
      {/* Nav and elements that I don't want to animate here */}
      <div>oh hi I don't animate</div>

      {/* Everything I want to animate here */}
      <motion.div
        key={router.route}
        initial="pageInitial"
        animate="pageAnimate"
        variants={{
          pageInitial: { opacity: 0 },
          pageAnimate: { opacity: 1 },
        }}
      >
        <main>{children}</main>
      </motion.div>
    </div>
  );
}
```

## react-headroom

This just keeps the nav out of the way as you scroll down, but exposes it again on scrolling up. I love little things like this, so I thought I would just shout it out. You can find an example [here](https://kyleamathews.github.io/react-headroom/).


Useful resources when building a blog with Next.js, MDX, Tailwind, and Radix UI


> "...though modern Americans have more choice than any group of people ever has before, and thus, presumably, more freedom and autonomy, we don't seem to be benefiting from it psychologically."
>
> <cite>- Barry Schwartz, The Paradox of Choice</cite>

There are myriad options for collecting information from users. Before code can be written, decisions have to be made; for my purposes, I chose to use Gatsby, ZEIT Now, and MongoDB, but here I want to briefly get into my use case and possible alternatives. If you don't care about the _why_ and just want to know the _how_, <a href="#how">skip ahead to the implementation</a>.

## Why

I am currently building a mobile app called [Hangbored](https://hangbored.com), which began with me needing an interval timer for training finger strength for climbing. While I await review and approval on my app's first release, I want users to be able to sign up on a landing page for early access. As of right now the app itself requires no back end, but at some point it might need one, so I want whatever system I build now for collecting emails to have the potential to scale.

### Why serverless?

My use case right now is incredibly simple -- I only need to store a list of emails. I could easily spin up a relational database to serve this purpose, but I'd rather not go through the hassle of creating a server for such a simple service. The lambda function that we deploy on ZEIT Now performs much like a route in an Express server. But spinning up a server takes time, and as I was already building this landing page with [Gatsby and Now](https://zeit.co/solutions/gatsby), I knew that [deploying serverless functions](https://zeit.co/docs/v2/serverless-functions/introduction#deploying-serverless-functions) could be included as a part of my existing service.

### Why write server-side code at all?

Secrets. We need credentials to establish a connection to our database, and some sort of layer needs to exist between the client and the database in order to establish this secure connection.

### Why MongoDB?

I don't want or need to create schemas, migrations, etc. Still, it would be nice to have a service that is scalable in the future. I will likely want to create user accounts in the future, and I can do so by adding additional properties to my existing user object in MongoDB instead of starting from scratch.

## How

Briefly:

1. [Create a project](#create-a-project).
2. [Create a ui](#create-a-ui).
3. [Create an api](#create-an-api).
4. [Connect to MongoDB](#connect-to-mongodb).

### Create a project

For this project I started with a [Gatsby site](https://www.gatsbyjs.org/docs/quick-start), but you can use whatever you want. Probably the easiest way to do this would be to run `npx gatsby new email-example` in the command line.

### Create a ui

It doesn't really matter how you get a form on a page. With React, it could look something like this:

```jsx
function Form() {
  const ref = React.useRef(null);

  const handleSubmit = (e) => {
    e.preventDefault();

    axios
      .post("/api/emails", { email: ref.current.value })
      .then((payload) => {
        console.log("payload: ", payload);
      })
      .catch((error) => {
        console.log("error: ", error);
      });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        aria-label="email"
        placeholder="Enter your email"
        ref={ref}
        required
        type="email"
      />
      <button type="submit">Submit</button>
    </form>
  );
}
```

Because our api will be served from a different endpoint in development, and because we want to avoid having to speficy this route or deal with potential CORS errors, we need to configure a development proxy in `gatsby-config.js` with the following code:

```js
module.exports = {
  proxy: {
    prefix: "/api",
    url: "http://localhost:3000",
  },
  ...

```

With other javascript frameworks such as create-react-app, you would add this line to your `package.json`:

```json
"proxy": "http://localhost:3000",
```

For the time being this won't do anything, so we need to create an endpoint at that location.

### Create an api

Create a folder at the root of this name project and call it `/api`. All files within this directory will become serverless functions available at endpoints that reflect the file structure here unless you prefix them with `_` or `.`, so `/api/signup.js` will automatically create the endpoint `/api/signup`, and so on. `signup.js` can just look like this for now:

```javascript
module.exports = (req, res) => {
  if (req.body && req.body.email) {
    res.status(200).send(`received ${req.body.email}`);
  } else {
    res.status(422).send("error");
  }
};
```

If you don't have the Now cli installed, [do that now](https://zeit.co/download) by running `npm i -g now`. Running `now dev` This will create development builds for both site and api.

### Connect to MongoDB

If you don't have a Mongo account, it's best to follow [these instructions](https://zeit.co/guides/deploying-a-mongodb-powered-api-with-node-and-now#step-1:-preparing-your-project) when it comes to [setting up an Atlas account and database](https://docs.atlas.mongodb.com/getting-started/). Pay special attention to the instruction to create 'whitelisted connections from anywhere', as this could cause headaches in the future. Following these instructions, We need to create a free tier cluster and a database `users` with a collection `emails`.

If you didn't already do so, install mongodb:

```bash
npm i mongodb
```

#### Secrets

For now, we just need secrets available for local development. We can create a `.env` file in the root of our project, ensuring that it is included in a `.gitignore` in case we might commit this code somewhere. Add your Mongo uri there:

```
MONGODB_URI=mongodb+srv://<user>:<password>@my-cluster-uf345.mongodb.net/<database-name>?retryWrites=true
```

Later we will want this secret available to our api as well,so store your secret in Now, changing my-mongodb-uri to whatever you want and adding your own username, password, and database name:

```bash
now secrets add my-mongodb-uri mongodb+srv://<user>:<password>@my-cluster-uf345.mongodb.net/<database-name>?retryWrites=true
```

... and create a `now.json` file in the root of your project so Zeit knows to use this secret in this project. The key here is what your app's reference to the variable will be (matching whatever we put in .env), and the value is a reference to whatever you called your secret on the line above:

```json
{
  "version": 2,
  "env": {
    "MONGODB_URI": "@my-mongodb-uri"
  }
}
```

At this point we need to edit our api to complete this connection between api and server. Change api/emails.js to the following:

```js
const url = require("url");

const MongoClient = require("mongodb").MongoClient;
// Create cached connection variable
let cachedDb = null;

async function connectToDatabase(uri) {
  if (cachedDb) {
    return cachedDb;
  }

  const client = await MongoClient.connect(uri, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
  });
  const db = await client.db(url.parse(uri).pathname.substr(1));
  cachedDb = db;
  return db;
}

module.exports = async (req, res) => {
  try {
    const db = await connectToDatabase(process.env.MONGODB_URI);
    const collection = db.collection("emails");
    collection.insertOne(req.body, (err, data) => {
      if (err) {
        res.status(422).send(err);
      } else {
        res.send("success");
      }
    });
  } catch (error) {
    res.status(400).send(error);
  }
};
```

The `connectToDatabase` function is used to cache the database connection and enable pooling because [creating database connections is expensive](https://blog.mlab.com/2013/11/deep-dive-into-connection-pooling/). At this point, restart the now server with `now dev` and verify that emails are recorded in MongoDB. Whether or not things go successfully, your user would probably appreciate some feedback. I updated my simple Form component as follows:

```jsx
function Form() {
  const [state, setState] = React.useState({});
  const ref = React.useRef(null);

  const handleSubmit = async (e) => {
    e.preventDefault();
    setState({ loading: true });

    axios
      .post("/api/emails", { email: ref.current.value })
      .then(() => {
        setState({
          loading: false,
          success: true,
        });
      })
      .catch((e) => {
        let err = "Something went wrong :(";

        if (e.response?.data?.errmsg?.includes("duplicate key")) {
          err = "You've already signed up!";
        }

        setState({
          loading: false,
          err,
        });
      });
  };

  return (
    <form onSubmit={handleSubmit}>
      {state.success ? (
        <p>
          Thanks for signing up! <br /> You'll be the first to know about the
          newness.
        </p>
      ) : (
        <div>
          <div>
            <input
              type="email"
              placeholder="example@hi.com"
              ref={ref}
              required
              aria-label="email"
            />
            <button type="submit">
              <span>Sign up</span>
            </button>
          </div>
        </div>
      )}
      {state.err && (
        <div>
          <p>{state.err}</p>
        </div>
      )}
    </form>
  );
}
```

## Conclusion

Using ZEIT Now is just one of the many ways one can spin up a landing page to accept user signups. For my purposes, it turned out to be the easiest. In the unlikely scenario that traffic for my small sideproject skyrockets, I will be able to scale. In the scenario that I decide I don't like whitelisting all IPs and want more customization for my lambda, I can always switch to something like AWS, where [your first 1 million requests each month are free](https://aws.amazon.com/lambda/pricing/). But for now, I would much rather spend my limited free time on building my actual app rather than this (admittedly corny) marketing page.

#### Links:

- [my corny landing page](https://hangbored.com)
- [github repo](https://github.com/charliedieter/hangbored.com)


Collecting user emails on a Gatsby site with Vercel Serverless Functions and MongoDB


[Gatsby](https://www.gatsbyjs.org/) is a fantastic tool for those of us who find React syntax familiar, but want to create simple static pages. Its community is large and active, and getting started in development requires little investment. Yet going to production -- especially when considering including a Gatsby project in an existing codebase -- can be another story. Gatsby comes with a `gatsby start` command that runs the production build on a Node server, and it is easy to misinterpret this as the proper way to serve Gatsby pages in production. By using Docker and Nginx to serve a production Gatsby site, pages can be compressed and served in gzip format, optimized for SEO, and ingtegrated into an existing project incrementally.

---

Go ahead and just get the [source code here](https://github.com/CharlieDieter/gatsby-nginx-docker-starter).

---

## Getting started

This tutorial is going to assume you already have some experience working with Gatsby and already have an existing site. If not, a very easy way to do this is by using npx with `npx gatsby new <your-site-name>`, as detailed [here](https://www.gatsbyjs.org/docs/quick-start/#use-the-gatsby-cli).

## Building pages

Right now, the only way you can build and run this site is with the help of Gatsby running a server for you. The first step in creating a production-ready Nginx server is adding a Dockerfile at the root of your project. The first stage of this multi-stage Dockerfile will handle building the production pages of your site.

```docker
FROM node:alpine

COPY . .

# System dependencies for packages that use node-gyp
RUN apk add --update --no-cache \
  python \
  make \
  g++

RUN npm install && npm run build

```

To ensure that this is working properly, run `docker build . -t my-gatsby-site` from the same location as the Dockerfile. Now we need to create our server.

## Nginx

Nginx is open-source software that powers a large portion of the internet's web servers<sup>[1](https://w3techs.com/technologies/cross/web_server/ranking)</sup>. While it provides many features, it is also incredibly simple to get up and running. In order to get started, create a file `nginx.conf` in the root of the project and add the following code:

```nginx

server {
    listen 80;
    server_name _;

    root /var/www/;
    index index.html;
}

```

In order to run this server in Docker, we need to add to our Dockerfile:

```
FROM node:alpine as gatsby-pages

COPY . .

RUN apk add --update --no-cache \
  python \
  make \
  g++

RUN npm install && npm run build

FROM nginx:stable as release

COPY --from=gatsby-pages public /var/www/
COPY ./nginx.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

```

In order to have multiple stages that can reference each other, we alias our initial Gatsby build as `gatsby-pages`. The static files that are built in the initial step are then copied to `var/www` in the release build, where our Nginx config is expecting them. Now we can rebbuild the container:

```bash
  docker build . -t my-gatsby-site
```

And then run it:

```bash
  docker run -p 80:80 my-gatsby-site
```


dieter.rodeo

Useful resources when building a blog with Next.js, MDX, Tailwind, and Radix UI

Collecting user emails on a Gatsby site with Vercel Serverless Functions and MongoDB

Preparing a Gatsby site for production with Docker and Nginx