This recipe takes the classic grilled cheese sandwich and improves on it just a little bit.

### What you need:

- 4 tablespoons unsalted butter, softened
- 8 slices of bakery Pullman bread
- 1/2 cup freshly grated Parmigiano-Reggiano cheese
- 1/2 pound sliced Swiss cheese, preferably Gruyère
- 8 ounces thinly sliced ham
- Dill pickle slices (optional)
- 2 tablespoons Dijon mustard
- 1/4 cup apricot preserves

### How to Make it:

1. Butter each slice of bread and sprinkle with Parmigiano, pressing to help it adhere. Invert the slices onto a work surface, cheese side down.
2. Top four of the slices with the Swiss cheese, ham, and pickles, if using. 
3. Mix the mustard and preserves and spread on the remaining 4 slices of bread. 
4. Close the sandwiches and griddle over moderate heat, turning, until golden-crisp on the outside and melted inside, about 3 minutes. 
5. Cut in half and serve right away. 

Inside-out grilled ham and cheese sandwiches

David Heinemeier Hansson (DHH):

> The recent and rapid advance of AI has rightfully giving many in software real doubts about the future of their profession. I'd probably still wager that the fears are overstated – that we also got prematurely euphoric about the imminent prospects of self-driving cars – and that AI generating code is different from it evolving existing systems. But I wouldn't want to bet the house on it. This might just be The Big One.
> 
> That uncertainty, whether we truly are on the cusp of a total transformation, is a surprising novelty to me, despite thirty years in software. We've been through so many breathless predictions about how this or that advancement in software would simply "Change. Everything. Forever." that a certain pessimism would be perfectly reasonable.
> 
> I've seen, for example, at least three hype cycles of No Code movements come and go over those thirty years, and none of them ever fulfilled their grand promises. Even the two properly big transformations we've had in that time, the internet and mobile, hasn't made the kind of programming most people do today look all that different from the kind of programming done in the 90s.
> 
> [...]
> 
> I like to imagine that all of us in software development, as it looks today, are busy making beautiful kerosene lamps in all shapes and sizes. We're improving the burn efficiency. We're finding ever clearer forms of glass to let the light through. We're tinkering with a formula that's been around for a long time. But as we do, Edison and Tesla are busy inventing electricity in the other room.
> 
> I'm sure it wasn't clear at all, even to Edison and Tesla, when exactly the switch would be flipped on that final lightbulb moment. And meanwhile, the world still needed to see in the dark, so the lamps of old were still necessary. That just might be us, right now, lighting the path to the future with the ways of what could soon be the past.


"How to continue making kerosene lamps on the eve of electricity"

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 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

[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.

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

Inside-out grilled ham and cheese sandwiches

"How to continue making kerosene lamps on the eve of electricity"

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

Featured Posts

Deploy Directus to Dokku

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

Setup an nginx proxy for docker-compose