Chris Coyier:

> When you commit and push code to a Git repository, it can kick off a series of events. A pipeline for your software, as it were. This whole process is often called “continuous integration,” or CI for short. It’s pretty crucial to modern software development and falls under the umbrella of “DevOps” in current developer parlance.
> 
> [...]
> 
> What could a CI process do? Well, let me answer that by telling you what I think a CI process should do. Buckle up, it’s kind of a lot.
> 
> First, a few points:
> 
> 1. Not all CI should run all the time. You can get really specific with CI on what parts of it run under what conditions. Broadly, I think it makes sense to think of it as 1️⃣ run on any push to any branch, 2️⃣ run against pushes to PR branches only, or 3️⃣ only run on a push to the main branch. I’ve tried to indicate that under each title below.
> 
> 2. Things that run in CI very likely don’t only run in CI. You can (and probably do) run all these things locally because you have to view the site, because you’re testing it, or for any other reason it may be advantageous to do so.
> 
> 3. There is a concept of commit hooks. I can imagine some level of disagreement with me about what should run in CI, because there is workflow overlap on what hook and CI can do for a team. For example, you could force a pre-commit hook to run tests and prevent the Git push at all if they fail. I’d argue that you should do that, but then also run them in CI. The chances of CI working well are way higher than the chances of any given developer’s machine working well.
> 
> 4. Things in CI can fail. That’s part of the point and a strength of CI. If tests fail (for any reason), then the Pull Request (PR) that this CI ran against should be prevented from being merged. CI isn’t just for lookin’ at, it’s for providing real guards.

Chris makes a lot of good points in his post, which is why I wanted to share it. Finding a perfect CI process can be interesting but also important to the software cycle overall.

Chris Coyier: A “Perfect” CI Process

This blog was on Remix for the past six months or so, and I still have other [sites](https://rogerstringer.com) on Remix, and continue to build with Remix as it's a great framework, but I decided to move this one back to Next, mostly so I could play with some recent additions in Next with Next 13.

I'm not using Next's new app folder yet since that's still in beta, but I will play around with that feature as it becomes more stable.

On the frontend, it's using MDX to generate it's markup you see on posts, with tailwind handling the styling. 

In the backend, I'm using Directus as a headless CMS which hasn't changed, then I'm using Flows to handle things like implementing Incremental Static Regeneration by letting Vercel know a post has been updated as a button in the Directus sidebar.

I've also added another flow that can be used to trigger a full site rebuild if needed, although the ISR flow handles most things quite nicely since I pass the collection and the key(s) being changed and the site then updates the appropriate pages.

<callout-info>
And now here's some code to show how to set up ISR with flows.
</callout-info>

### Create a flow

You could set this flow to trigger on creation or update of certain collections but in this case, I prefer a manual trigger flow that I can just hit a button and have it update on the frontend.

![](https://cms.codedgeekery.com/assets/2fd54dac-2ecb-4306-9a1a-194b5c2f7dec)

Choose a webhook action:

![](https://cms.codedgeekery.com/assets/f8bd46cf-bb4f-4120-a1b9-29d7dc969c56)

Next, in the flow, set the content-type, a webhook secret and pass the body to the webhook:

![](https://cms.codedgeekery.com/assets/96eaf8ae-394f-4ed9-9c25-e916bfb2c709)

Then, create `pages/api/revalidate.ts`:

```ts:pages/api/revalidate.ts
import type { NextApiRequest, NextApiResponse } from 'next';
import { getDirectusClient } from '~/lib/directus-server';

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {  
  const body = await readBody(req);
  
  const headers = req.headers;
  if (!headers["x-webhook-secret"]) {
    return res.status(403).send("Forbidden");
  }

  const receivedSecret = headers["x-webhook-secret"];

  const secret = process.env.REVALIDATE_SECRET;

  if (receivedSecret !== secret) {
    return res.status(403).send("Forbidden");
  }
  
  const directus = await getDirectusClient();

  const { collection, keys } = JSON.parse(body);
	
  if (collection === "posts") {
    for (const key of keys) {
      const directusRes = await directus.items(collection).readOne(key, { fields: ["slug"] });
      await res.revalidate(`/blog/${directusRes.slug}`); // post
    }      
    await res.revalidate('/blog'); // blog page
    await res.revalidate('/'); // homepage
  } else if (collection === "snippets") {
    for (const key of keys) {
      const directusRes = await directus.items(collection).readOne(key, { fields: ["slug"] });
      await res.revalidate(`/snippets/${directusRes.slug}`); // snippet
    }      
    await res.revalidate('/snippets'); // snippets page

  } else if (collection === "page") {
    for (const key of keys) {
      const directusRes = await directus.items(collection).readOne(key, { fields: ["slug"] });
      await res.revalidate(`/${directusRes.slug}`); // page
    }
  }
    return res.status(200).send("Success");
}

export const config = {
  api: {
    bodyParser: false
  }
}

async function readBody(readable: NextApiRequest) {
  const chunks = []
  for await (const chunk of readable) {
    chunks.push(typeof chunk === 'string' ? Buffer.from(chunk) : chunk)
  }
  return Buffer.concat(chunks).toString('utf8')
}
```

When this URL is called and includes an appropriate webhook secret, collection and key(s) it will then tell vercel which pages to re-generate.

Back to Next.js

> How we write and think about CSS has changed significantly since the web’s beginning.
> 
> We’ve come a long way from table-based layouts, to responsive web design, and now into a new era of adaptive layouts powered by modern CSS features.
> 
> Managing and organizing CSS has always been challenging, where consensus is hard to find.

CSS is always changing, adapting and growing, if you've been using it since the early days it's a very different, but similar, language / framework.

The evolution of scalable CSS

Kent C.Dodds:

>  There's this pattern I’ve been using in my apps that has been really helpful to me and I'd like to share it with you all. I’m calling it "full stack components" and it allows me to colocate the code for my UI components with the backend code they need to function. In the same file.

Kent C. Dodds on Full Stack Components

Craig Doremus:

> Fresh is the Deno full-stack framework created by Luca Casonato of the Deno core team and now hosted in the Deno github repository.
> 
> Fresh uses Preact for the UI. Recently the Preact team has released a new library called Signals for reactive state management. Preact Signals are used for both global and local state management.

Fresh is a fun Deno framework to use and adding Preact Signals to handle state management makes it more useful.

Using Preact Signals with Fresh

Jenna Smith:

> There has been a lot of talk on the socials lately about progressive enhancement. Some good, some bad, and while the bad is often misled I get it.
> 
> Educational content on this topic usually focuses on making things work without JavaScript. That is cool but I agree with the naysayers that JavaScript is a fundamental part of the web these days, so why should we invest time in making things work without it?
> 
> Well, it isn't only about building things that "support 1% of users without JavaScript" and I'd like to try explain why. But first, let's talk about that 1%.

Progressively enhance for a more resilient web

Nick Olszanski:

> I want to be frank about my experiences with React. I’ve been using it heavily for far over 6 or 7 years and I am doing great. React is amazing!
> 
> I know that people will always find ways to shoot themselves in the foot. At the same time I understand that batteries-not-included approach will lead to that sad result. When it comes to React projects I feel that I know a few tricks to sidestep problems that people discuss online.
> 
> Let's speak about the main problems first. People get out of their skin and try to make React projects a complicated and entangled mess. In programming, there was always a semi golden rule, to not architecturally fuse your business logic to any particular framework. We logically isolate our app from whatever framework we are using at the moment.
> 
> I’ve given the same demo day (task) exercise to ~50+ React devs. Basically two inputs and a button to draw a pattern on an HTML canvas. You wouldn’t believe how many of them (roughly 47) completely and unnecessary implemented most of the business logic inside React components. The sad part is this app doesn’t need React at all. Or one could implement 99% of the business logic in pure JS and just call one function from React.
> 
> React gives an option to store business logic state in `useState` and manage it via `useEffect` and we gladly use that to our demise. Litter our code with singleton instances of a business logic because we’ve “forgot” how to do a DI without a framework.
> 
> Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way. They describe how their Rube Goldberg flux redux machine works. A machine to read and write data into a JSON object.
> 
> React is pretty bare bones and before critiquing it we should take a hard look in the mirror. In my view, the framework is doing it’s job just fine. Unless we learn what really goes wrong with React projects we are doomed to repeat the same mistake again and again in the next (pun intended) framework.

Overcoming Popular Issues With React Projects

[Directus](https://directus.io/) is one of the nicer headless CMSes out there, their UX, API, Insights and no-code data studio make it a powerful tool.

Fly.io hosts Directus nicely and I've set up this [repo](https://github.com/freekrai/directus-fly) to quickly get started on Fly.io, it uses SQLite for the database, and also includes [https://github.com/dimitrov-adrian/directus-extension-wpslug-interface](https://github.com/dimitrov-adrian/directus-extension-wpslug-interface) extension already setup to handle generating slugs, it's quick to change the db to postgres or other if you like.

By the way, I highly recommend taking a look at the [Directus examples repo](https://github.com/directus/examples) to get a feel for what you can do using Directus with various frameworks like Next, Remix, Nuxt, Astro, etc.

## Important 🚧

Fly requires a globally unique name for all the apps, and we've used the directory name and random hash as the app name. Of course, you can change this anytime you want BEFORE launching the app with Fly CLI. But it's not a big deal since you can reassign the internal Fly URL to any custom domain by adding a [`CNAME`][cname] record to your custom domain pointing to the Fly internal URL. We'll see that later when deploying the app to production.

## Fly Setup 🛠

1. [Install Fly](https://fly.io/docs/getting-started/installing-flyctl/)

2. Sign up and log in to Fly

```bash
flyctl auth signup
```

## Deployment 🚀

### Initial setup 👀

Before proceeding to deploy our app, we have some steps to take care of:

- Create a GitHub account [GitHub](https://repo.new)
- Create a new app on Fly

```bash
flyctl launch --name [YOUR-APP-NAME] --copy-config --no-deploy
```

<callout-info>
⚠️ **Note:** Make sure this name matches the `app` set in your `fly.toml` file. Otherwise, you will not be able to deploy.
</callout-info>

<callout-warning>
⚠️ Remember not to deploy since we have some setup steps left to complete!
</callout-warning>
  
### Environment variables and Secrets 🤫

This template comes with GitHub actions workflows to automatically deploy the app to Fly.io. First, we need to set up our GitHub actions and the Fly app with some secrets. Let's do that now.

To push the build image to the remote Fly registry from GitHub action, we need an access token from Fly. We can generate that using the Fly command line, run:

```bash
flyctl auth token
```

The command will generate an access token. You can then add this token to your GitHub actions secrets by visiting your GitHub repository's `settings` page `https://github.com/:owner/:repo/settings/secrets/actions` and then click `New repository secret`. Next, GitHub will prompt for a key and a value. The key should be `FLY_API_TOKEN`, and the value will be the token generated by the command line.

We also need to set the Fly app name as a secret, the key should be `FLY_APP_NAME`, and the value will be the app name specified in [fly.toml](./fly.toml)

Now we need to set up secrets in our Fly app.

We also need a secret to sign our session. We can do that by running the command:

```bash
flyctl secrets set KEY=$(openssl rand -hex 32)
flyctl secrets set SECRET=$(openssl rand -hex 32)
```

```bash
flyctl secrets set ADMIN_EMAIL=[YOUR@EMAIL.com]
flyctl secrets set ADMIN_PASSWORD=[YOUR-ADMIN-PASSWORD]
```

The last secret, is your `PUBLIC_URL`, you can get the initial domain from fly by typing: `flyctl info`

To get the current app URL and IP address. The app URL will be `https://YOUR-APP-NAME.fly.dev`. 

```bash
flyctl secrets set PUBLIC_URL=https://[YOUR-APP-NAME].fly.dev
```

You can change this by following Fly's DNS docs and then just update the secret anytime

### Volumes 💾

We also need to create a volume in Fly to persist our app data (SQLite DB) so that Fly can persist the data stored across deployments and container restarts. Again, we can do that using the Fly command line.

```bash
flyctl volumes create data --region [REGION] --size 1
```

<callout-info>
Note: REGION should be the region selected when launching the app. You can check the region chosen by running `flyctl regions list`.
</callout-info>
  
It's important to note that Volumes are bound to an app in a region and cannot be shared between apps in the same region or across multiple regions.

You can learn more about Fly Volumes [here](https://fly.io/docs/reference/volumes)

You should also update the region in your `fly.toml` file to whichever region you selected:

```toml
[env]
  FLY_PRIMARY_REGION = "[REGION]"
```

The other variables you can leave alone.

### Deploy 🥳

We are ready for our first deployment.

You have two ways to deploy:

- Via `npm run deploy`: deploy the current folder
- Via Github actions.

GitHub actions workflows are configured to run on push to the `main` branch. 

So let's push the local branch `main` to remote, triggering the workflows.

Once all the checks are passed, and the deployment is complete


### Logs

You can check the logs using the command `flyctl logs` from the project directory, containing the `fly.toml` file in the project's root. You can also check the logs from the console by visiting [fly.io/apps](https://fly.io/apps).

### Console

You can also log in to the remote console using the `flyctl ssh console` command.

### Connecting to your database

The sqlite database lives at `/data/database/data.db` in your deployed application. 

You can connect to the live database by running `flyctl ssh console -C database-cli`.

### Adding extensions 🔌

There are two ways to add extensions:

1. Via `package.json` like the included `directus-extension-wpslug-interface` extension or
2. Installed inside the `extensions` folder.

This works the same as any other Directus installation

2 A22 Ffbd 89 Dc 474 D Ac 4 D 2 B8 Ded 6573 C3 Ad005116ee.png

Quickly Deploy Directus On Fly.io

[The Directed Stack](https://github.com/freekrai/directed-stack) is a full-stack Remix stack that combines Directus as the backend and Remix for the app, easily customizable to build on

I use Directus for a lot of apps, from this blog, to several other projects.

The Directed Stack is based on the apps I built, you can see a [demo](https://notes.haxstax.xyz/) where you can see the about page, blog posts and sign up and add markdown notes (based on the [Indie Stack](https://github.com/remix-run/indie-stack)), all the backend work is stored in Directus.

To get started, you can fork the repo or run the following command:

```bash
npx create-remix --template freekrai/directed-stack
```

## Development

This repo contains two folders plus the root:

- `directus`: our Directus headless CMS
- `scripts`: our Directus schema
- `/`: our Remix app

## First run

On first one, clone this repo and run:

```bash
yarn
yarn setup
```

Then go into the directus folder and set up for local development by copying your `.env.example` into `.env` and filling out the fields.

Then run:

```bash
npx directus bootstrap
```

You can then import your schema into your local Directus by going into the scripts folder, save `.env.example` to `.env`, and save the required info then run:

```bash
cd scripts
node schema.mjs
```

This will create the collections locally in Directus, you can update the `.env` and run it again once your deploy _(we'll talk about that further down)_.

If you want to test creating users locally, then you'll also need to create a `users` role inside the Directus Data Studio, which needs the following permissions  _(again, we'll talk about that further down with prod)_:

- notes
   - create: all access
   - view: where `created By` equals `$CURRENT_USER`
   - edit: where `created By` equals `$CURRENT_USER`
   - remove: where `created By` equals `$CURRENT_USER`
- users:
   - view: all access, Directus handles the proper rules
   - edit: where `ID` equals `$CURRENT_USER`

On the same page, there are checkboxes for app and admin, uncheck both of these if they are checked as this role will be through the api only.

Take note of this role's ID as you'll need it when you deploy the remix app

Also edit the `public` role: 
   - directus_files
     - view: all access

Finally, let's load the remix app.

Copy `.env.example` into `.env` and fill out the info:

```yaml:.env
# run openssl rand -hex 32 to generate
SESSION_SECRET=session-secret

# DirectUs
DIRECTUS_URL=http://localhost:8055
DIRECTUS_STATIC_TOKEN=static-token
DIRECTUS_USER_ROLE=role-to-give-frontend-users
```

Now run `yarn dev` and go to `http://localhost:3000`.

## Deploying

### Railway

This app uses a [slugs](https://github.com/dimitrov-adrian/directus-extension-wpslug-interface) extension that you want pre-installed, you can use my [Directus Railway](https://github.com/freekrai/directus-railway) repo to get started on Railway, to deploy Directus to railway, click:

[![Deploy on Railway](https://railway.app/button.svg)](https://railway.app/new/template/_dszdt?referralCode=codedgeekery)

You can find more info on this repo [here](https://codedgeekery.com/blog/directus-railway).

### Fly.io

If you're prefer to install Directus on [Fly.io](http://fly.io), you can follow this [repo](https://github.com/freekrai/directus-fly) repo instead.

### Directus Cloud

Directus also gives a terrific option of hosting via their [cloud service](https://directus.cloud), but you can't use extensions on the free tier so the included schema would need to be changed so that the slug field is just a text field instead. 

Once deployed, go into the scripts folder, save `.env.example` to `.env`, and save the required info then run:

```bash
cd scripts
node schema.mjs
```

Which will create the necessary collections on your deployed Directus site.

#### Permissions

Earlier, we setup permissions for testing everything locally, we need to do the same thing to our deployed site, so create a `users` user role, which has permissions as follows:

- notes
   - create: all access
   - view: where `created By` equals `$CURRENT_USER`
   - edit: where `created By` equals `$CURRENT_USER`
   - remove: where `created By` equals `$CURRENT_USER`
- users:
   - view: all access, Directus handles the proper rules
   - edit: where `ID` equals `$CURRENT_USER`

Take note of this role's ID as you'll need it when you deploy the remix app.

Also edit the `public` role: 

   - directus_files
     - view: all access

### Vercel

The vercel button is already preloaded with the information you need to get deploying to Vercel

[![Deploy with Vercel](https://vercel.com/button)](https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Ffreekrai%2Fdirected-stack&env=SESSION_SECRET,DIRECTUS_URL,DIRECTUS_STATIC_TOKEN,DIRECTUS_USER_ROLE)

## What's Next?

You can build on this pretty easily to create pretty much any type of app.

<callout-info>
Stay tuned for a more detailed post about how to build this site out  step by step coming soon 🙏🏻
</callout-info>


Directed Stack

The Directed Stack: A Full-Stack App built with Remix and Directus

The [Remix Blog](https://github.com/freekrai/remix-blog) Stack is a Remix [stack](https://remix.run/stacks) I wrote for quickly building an MDX blog in Remix, it's had a few revisions recently so I thought I'd share how to get it set up and running.

To get started, you can fork the repo or run the following command:

```bash
npx create-remix --template freekrai/remix-blog
```

## Config

By default, remix-blog will try to use the file system to read files, this works great but if you are on a hosting service like cloudflare where you can't access the file system then we need to use Github, you can configure how it accesses files in your `.env` file:

- `SESSION_SECRET`: Session Secret used for sessions such as dark mode
- `USE_FILESYSTEM_OR_GITHUB`: this is either `fs` or `gh`
- `GITHUB_TOKEN`:  your Personal access token
- `GITHUB_OWNER`: your Github name
- `GITHUB_REPO`: your Github repo

The Github variables are only needed if `USE_FILESYSTEM_OR_GITHUB` is set to `gh`, it's `fs` by default.

This does allow you to do things like have one repo for the codebase and one for just content which can be handy.

---

## Development

To run your Remix app locally, first, copy `.env.example` to `.env` and configure as needed following the `Config` step above.

Next, make sure your project's local dependencies are installed:

```bash
npm install
```

Afterwards, start the Remix development server like so:

```bash
npm run dev
```

Open up [http://localhost:3000](http://localhost:3000) and you should be ready to go!

---

### Structure

It's been set up so that you have flexiblity in terms of content, for example the default setup is:

- `content`: where mdx is stored
- `content/posts`: blog posts, stored as: `SLUG/index.mdx`
- `content/pages`: pages, stored as `SLUG/index.mdx`

The structure is based on Gatsby and gives more flexibility, each page and post is a folder and contains an `index.mdx` file, this folder name becomes the slug.

This can be used to create other content types as well, posts, pages, workshops, snippets, anything you want and then just call it, you can look at the blog files for using an entire post type.

This can be expanded further, for example, you can have multiple files and folders inside one folder:

- `content/posts/hello-world/index.mdx` returns as `/hello-world`
- `content/posts/hello-world/abc.mdx` returns as `/hello-world/abc`
- `content/posts/hello-world/more-hello/index.mdx` returns as  `hello-world/more-hello`
- `content/posts/hello/still-hello/index.mdx` returns as `hello/still-hello`
- `content/posts/2022/test/index.mdx` returns as `/2022/test`

This lets you structure content however you want.

On build, the stack generates a json file in content (`blog-cache.json`) for all blog posts, which is then referenced later for the blog index, rss, sitemap, etc.

The stack also generates a separate json file in content (`page-cache.json`) for all pages, this can then be used for sitemap, etc as well.

If you are doing other content types besides posts and pages, you may want to edit `scripts/cachePosts.ts` and follow what was done for `getPosts` and `getPages` functions to create a cache file for each of those as well, the app uses these as a sort of _read-only_ database.

Mdx files contain frontmatter which is used to know about each post, this frontmatter looks like:

```jsx
---
meta:
  title: Another Post
  description: A description
date: '2021-10-02T00:00:00'
excerpt: Hello Gaseous cloud...
headers:
  Cache-Control: no-cache
---
```
---

## Deployment

Initially, this stack is set up for deploying to Vercel, but it can be deployed to other hosts quickly and I'll update the [wiki](https://github.com/freekrai/remix-blog/wiki/Deploying) with instructions for each, but to get started on Vercel:

Open `server.js` and save it as:

```jsx:server.js
import { createRequestHandler } from "@remix-run/vercel";
import * as build from "@remix-run/dev/server-build";
export default createRequestHandler({ build, mode: process.env.NODE_ENV });
```

Then update your `remix.config.js` file as follows:

```jsx:remix.config.js
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
  serverBuildTarget: "vercel",
  server: process.env.NODE_ENV === "development" ? undefined : "./server.js",
  ignoredRouteFiles: ["**/.*"],
};
```

This will instruct your Remix app to use the Vercel runtime, after doing this, you only need to [import your Git repository](https://vercel.com/new) into Vercel, and it will be deployed.

If you'd like to avoid using a Git repository, you can also deploy the directory by running [Vercel CLI](https://vercel.com/cli):

```bash
npm i -g vercel
vercel
```

It is generally recommended to use a Git repository, because future commits will then automatically be deployed by Vercel, through its [Git Integration](https://vercel.com/docs/concepts/git).

This repo is open for pull requests and ideas to expand on it, but I wanted to make it flexible to start off.

Coded Geekery

Recent Posts

Chris Coyier: A “Perfect” CI Process

Back to Next.js

The evolution of scalable CSS

Kent C. Dodds on Full Stack Components

Using Preact Signals with Fresh

Progressively enhance for a more resilient web

Overcoming Popular Issues With React Projects

Quickly Deploy Directus On Fly.io

The Directed Stack: A Full-Stack App built with Remix and Directus

The Remix Blog Stack

Featured Posts

Quickly Deploy Directus On Fly.io

The Directed Stack: A Full-Stack App built with Remix and Directus

Setup an nginx proxy for docker-compose