Server components enable you to render the entire pages on the server without messing around with API endpoints and data fetching logic. But handling the different states remains an issue for the optimal usability experience. Without handling these states the user interface feels sluggish while waiting for the server response and an error would render the entire screen useless with a white screen of death. Not ideal, but strategies to mitigate these undesirable behaviors do exist and are easy to use.

Limiting OpenAI’s token usage isn’t merely desirable because it is cheaper and faster, but also because it increases the size of the overall context. OpenAI caps this at 8.000 tokens for most models with a possibility of up to 32.000 tokens (if you are lucky to get invited, presumably). I haven’t seen anybody offering 32K tokens computations nor showcasing it. So in the meantime optimizing the token usage makes even more sense.

While I was building aihelperbot.com I did what I imagine many developers do: I used an ORM for everything database related. I used ORM to handle migrations, define schemas, insert data, update data, select data, etc. I didn’t think much about it.

It was only later while building aihelperbot.com I started to wonder if I really needed an ORM? Using AI more and more I started to realize that I could do most of the things I did with an ORM directly with SQL. And that I often could do it quicker because I didn’t have to lookup ORM specific syntax. I could just write SQL queries directly.

I wanted to add markdown blog to my NextJS app. Initially I feared it would be a lot of work. But it turned out to be easy when using NextJS server side components, i.e. the appDir. This is the end result:

• blog overview
• blog post

To get started I added the scaffolding for the markdown blog to the appDir:

app/
├── posts/
│   ├── [slug]
│   │   ├── head.tsx
│   │   └── page.tsx
│   ├── head.tsx
│   ├── page.tsx
│   └── utils.ts

The routing logic behind the folder structure is the same used in the pages folder. The blog will be located on /posts and each blog post on /posts/[slug]. The page file in each folder is rendered only on the server and contains the markup for the page. The head files add <title> tags and a few other relevant meta tags.

What does it cost to host a small web app on Render vs Digitalocean with Render’s new pricing model? The tech stack:

• web app running Node.js
• database running Postgres (Render only support Postgres)

What initially made me move git18n and aihelperbot from DigitalOcean to Render was the price. Render’s new pricing model has made it more expensive than DigitalOcean albeit offering significantly less services and options. Render has always felt a bit rough and limited but for the lower price it was still a good deal. Now it’s not.