Josh W Comeau:

> Over the past few months, I've spoken with lots of early-career devs who are getting more and more anxious about AI. They've seen the increasingly-impressive demos from tools like GPT-4, and they worry that by the time they're fluent in HTML/CSS/JS, there won't be any jobs left for them.
> 
> This sentiment is all over Twitter right now:
> 
> ![](https://cms.codedgeekery.com/assets/2b02ea68-849f-4095-8e22-92c30a4d1a43)
> 
>  I couldn't disagree more. I don't think web developer jobs are going anywhere. And I'm getting pretty sick of the FUD? being spread online.
> 
> [...]
> 
> I've heard from a few folks who have said that ChatGPT has been really helpful when it comes to learning technical skills. If you're confused by something in a tutorial, you can ask the AI to explain it to you!
> 
> This is a really interesting use case to me. Essentially, ChatGPT is like a pair programmer, someone who can help you make sense of things you don't understand. You can ask it specific questions and get specific answers.
> 
> But I do think you need to be careful. There's a right way and a wrong way to use tools like this to help you learn.
> 
> The wrong way would be to treat it like GPS navigation. When I have to drive somewhere, I pop the address into my GPS, and follow its instructions indiscriminately. I do generally wind up where I need to go, but it requires 0 mental effort on my part. As a result, my sense of direction has totally atrophied. I can't go anywhere now without a synthesized voice telling me what to do. 😬
> 
> Instead of treating it like a GPS, I'd suggest treating it like you're a member of a jury, and the LLM is the defendant, taking the stand.
> 
> You'll listen to what they have to say, but you won't accept it as fact. You'll be skeptical, and think critically about every word.
> 
> Instead of blindly copy/pasting the code that ChatGPT generates, go through it line-by-line, and make sure you understand. Ask it for clarification. And double-check things that seem suspicious with an authoritative source (eg. the official documentation). Keep in mind that LLMs are 100% confident, but not 100% accurate.
> 
> [...]
> 
> The reason I wanted to write this blog post was specifically to address folks who are in the process of learning web development and who are feeling anxious and despondent, like there's no point spending all of this time/energy building these skills when the whole field is about to be made obsolete.
> 
> I can't promise that things will stay exactly the same. I do suspect that AI will have an impact on how we work. I started tinkering with HTML/CSS/JS back in 2007, and things have changed so much since then. Developers have always had to be adaptable, to evolve alongside technology.
> 
> But so far, nothing I've seen suggests that our jobs are at risk. I've tried to imagine what it would look like, if non-developers were able to build entire web applications without understanding web technologies, and I come up with so many reasons why it wouldn't work, even if future iterations of GPT don't hallucinate as much.
> 
> I could be wrong. I don't have a crystal ball 🔮. For all I know, the sun might explode tomorrow. But I truly don't believe that we're on the cusp of web developers being made obsolete. And I worry that many would-be developers are taking their foot off the gas for no reason.
> 
> I don't want you to look back in 5 years, if software developers are even more in-demand, and regret that you stopped pursuing your dreams. ❤️

Go read the rest of Josh's post, his advice echoes what I've been saying to several people over the past few months, ChatGPT has it's uses in dev, but don't worry about it replacing you, work with it instead.

The End of Front-End Development?


[Dokku](https://github.com/dokku/dokku) is a handy PaaS service you can run on servers. I have it running on a couple Digital Ocean servers and it works nicely.

I also use Directus a lot as a Headless CMS and overall database management, so being able to quickly install is very handy.

Here's a little recipe I use to set it up. First, we want to create the app and set up everything we need:

```bash
dokku apps:create directus
dokku domains:add directus YOURDOMAIN
dokku postgres:create directus
dokku postgres:link directus directus

dokku storage:list directus
dokku storage:ensure-directory directus
dokku storage:mount directus /[SOME-FOLDER-ON-MACHINE]/data:/app/data
dokku ps:restart directus

dokku config:set --no-restart directus KEY=$(openssl rand -hex 32)
dokku config:set --no-restart directus SECRET=$(openssl rand -hex 32)
dokku config:set --no-restart directus ADMIN_EMAIL=[YOUR@EMAIL.com]
dokku config:set --no-restart directus ADMIN_PASSWORD=[YOUR-ADMIN-PASSWORD]
dokku config:set --no-restart directus PUBLIC_URL=[YOUR-DOMAIN]
dokku config:set --no-restart directus STORAGE_LOCATIONS="local"
dokku config:set --no-restart directus STORAGE_LOCAL_DRIVER="local"
dokku config:set --no-restart directus STORAGE_LOCAL_ROOT="/app/data/uploads"

dokku config:set --no-restart directus DB_CLIENT=pg
dokku config:set --no-restart directus DB_CONNECTION_STRING="<info from above command>"

dokku proxy:ports-set directus http:80:8055
```

This creates the app, and the database, and configures the app to use the env vars specified.

Next, we want to pull the Directus docker image and deploy it:

```bash
docker pull directus/directus
dokku git:from-image directus directus/directus

```

Last step is to set up our SSL certs:

```bash
dokku config:set --no-restart directus 
dokku letsencrypt:set directus email YOU@YOURDOMAIN
dokku letsencrypt:enable directus
```

That's it, you now have an Directus instance running, and you can add other instances quickly by making new apps.

To update, you can replace `latest` with any tag you want:

```bash
docker pull directus/directus:latest && dokku git:from-image directus directus/directus:latest
```

Deploy Directus to Dokku

Lee Rob:

> There's been massive innovation in the database and backend space for developers building applications with serverless and edge compute. There are new tools, companies, and even programming models that simplify how developers store data.
> 
> [...]
> 
> I'll focus on transactional workloads instead of analytical workloads.
> 
> The “backend” space is vast: search, analytics, data science, and more – so I'll niche down here. The primary criteria of this overview is:
> 
> 1. Services that work exceptionally well when paired with serverless and edge compute
> 2. Services that work with JavaScript and TypeScript codebases

I agree with Lee's lists but I also think [Directus](http://directus.io) should have been under there as well since Directus is more than just a headless CMS and is a full backend management platform with auth, API, GraphQL, and data studio built in, plus the flows and insights mean less coding needed to handle many tasks, and less tools needed.

The State of Databases for Serverless & Edge In 2023

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

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>


Coded Geekery

Recent Posts

The End of Front-End Development?

Deploy Directus to Dokku

The State of Databases for Serverless & Edge In 2023

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

Featured Posts

Deploy Directus to Dokku

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