Forem: Arnaud Renaud

Build and Deploy a Free CMS-Powered Website (Next.js, Sanity, Netlify)

Arnaud Renaud — Fri, 29 Aug 2025 17:30:00 +0000

TL;DR

🌎 Live Demo: ssg-nextjs-cms-sanity.netlify.app
📑 Source Code: github.com/arnaudrenaud/ssg-nextjs-cms-sanity

Is this for you?

This guide is meant to help if:

you want a public, mostly read-only website (no user-supplied content)
content is not supposed to change dozens of times per day, as each update will trigger a rebuild

Advantages

If the above fits your needs, you’ll get:

a graphical CMS interface to manage content in the cloud
no server or database to maintain (less work, more security)
no deployment or hosting fees at all
fast-loading pre-rendered pages
browser-side interactivity, if wanted
some form functionality (see contact page)

The toolkit

📝 Language: TypeScript
🛠️ Build: Static Site Generation (SSG) with Next.js (App Router)
📄 Frontend: React.js, Tailwind CSS
🗂️ CMS: Sanity (free tier)
🌍 Hosting: Netlify (free tier)

How it works

Content Management System (CMS)

Content is managed through a web interface offered by Sanity, a cloud provider with a free tier. You may grant editor or administrator rights to users on your Sanity interface (called the Studio).

Entity types, with their attributes and relations, must be defined in code, and then deployed to the studio.

Once these types are deployed, you can create, update and delete records without updating the code.

Example: entity types for a Blog:

Posts: a collection of Post records, each with:
- title (text)
- publishedAt (date)
- mainImage (image upload)
- body (rich text)
- author (reference to Author)
Singletons (unique records), e.g.:
- HomePage (with a hero field)
- Metadata (for SEO: title, description)

Rendering

Pages are written with React, allowing browser-side behavior if wanted.

Next.js retrieves content from Sanity and uses it in page rendering.

Pages are rendered at build-time (server-side), by Next.js with the App Router. This is called static site generation (SSG) and results in a bundle of files: pages (HTML) and their assets (JS, CSS, images, etc.).

Deployment

Deployment is managed by Netlify, a hosting service that serves static websites for free, provided you don't exceed a monthly bandwidth (currently 5 GB) and a good hundred of builds.

You won't have to worry about updating the website following a change: whenever you update content in Sanity or push code changes to GitHub, Netlify is automatically notified and rebuilds the website with the latest content and code.

Get started

Fork or clone the code and make it your own (all technical steps in README.md):

👉 github.com/arnaudrenaud/ssg-nextjs-cms-sanity

Also published on my personal blog: arnaudrenaud.com

Both-sides form validation with Next.js (React Hook Form & next-safe-action)

Arnaud Renaud — Wed, 09 Apr 2025 13:03:06 +0000

TL;DR

✅ Result:

a form that submits to a server-side action
shared validation logic on both client and server
browser-side form state management: loading, success, and error states

🛠️ Tech stack:

Next.js Server Actions
next-safe-action
Zod
React Hook Form

📦 Code: https://github.com/arnaudrenaud/nextjs-forms-both-sides-validation

The problem

Forms have been – and still are – a pain for the web developer.

In particular, one has to enforce server-side validation for security, while also providing client-side validation for user experience (HTML-only validation does not cover all cases).

Without systematic handling, this is a tedious job, often leading the developer to overlook both security and user experience.

Let's see how the React-Next.js toolkit can make this easier.

🤔 My code is in TypeScript. Why would I need server-side type validation?

⚠️ TypeScript does not validate types at runtime. Besides, a Zod schema allows us to define constraints that go beyond TypeScript types, such as string length.

A developer-friendly solution

We would like to have:

arguments validated in real-time browser-side
arguments validated server-side before running the Next.js Server Action
a React hook to gather it all and access form state: field validation errors and submission state (loading, success, error)

Demo

Let's implement a form with a single email field.

Form schema

Using Zod, the form schema can be expressed this way:

export const schema = z.object({
  email: z.string().email(),
});

Form submission server-side

"use server";

import { schema } from "@/app/example/schema";
import { makeServerAction } from "@/lib/server/makeServerAction";

export const action = makeServerAction(schema, async ({ email }) => {
  console.log(`Processing form on the server with email "${email}"…`);

  return { message: `Processed ${email} successfully.` };
});

makeServerAction is our wrapper function binding the schema with the form submission handler.

With this wrapper, when the server receives a form submission, if validation fails for any field, an error is returned.

Form client-side

1. Form submission

"use client";

import { useFormServerAction } from "@/lib/browser/useFormServerAction";
import { schema } from "@/app/example/schema";
import { action } from "@/app/example/action";

export function Form() {
  const { form, submit } = useFormServerAction(schema, action);

  return (
    <form onSubmit={submit}>
      <label>
        Email address:
        <input type="email" {...form.register("email")} />
      </label>

      <button>Submit</button>
    </form>
  );
}

useFormServerAction will be our custom hook binding the browser-side form with the action and schema declared earlier.

For now, we only use:

form.register to bind the field to the form state
submit to call the action when submitting the form

2. Browser-side schema validation

Here, we see both our own validation (message in red) and the HTML-based validation offered by the browser (tooltip).

export function Form() {
  const {
    form,
+   fieldErrors,
    submit
  } = useFormServerAction(schema, action);

  return (
    <form onSubmit={submit}>
      <label>
        Email address:
        <input type="email" {...form.register("email")} />
      </label>
+     {fieldErrors.email && (
+       <div className="text-sm text-red-500">
+         {fieldErrors.email.message}
+       </div>
+     )}

      <button>Submit</button>
    </form>
  );
}

Our hook performs field validation in the browser (by default, on field blur) following the same schema as the one used on the server.

3. Server-side schema validation

Let's make sure server-side validation is enforced when bypassing the web interface and submitting a malformed email value:

The server does not run the action and it responds with an error object:

{ "validationErrors": { "email": { "_errors": ["Invalid email"] } } }

4. Success state

export function Form() {
  const {
    form,
    fieldErrors,
    submit,
+   action: { result },
  } = useFormServerAction(schema, action);

  return (
    <form onSubmit={submit}>
      <label>
        Email address:
        <input type="email" {...form.register("email")} />
      </label>
      {fieldErrors.email && (
        <div className="text-sm text-red-500">
          {fieldErrors.email.message}
        </div>
      )}

      <button>Submit</button>
+
+     {result.data && (
+       <div className="text-green-500">{result.data.message}</div>
+     )}
    </form>
  );
}

5. Loading state

export function Form() {
  const {
    form,
    fieldErrors,
    submit,
    action: {
+     isExecuting,
      result
    },
  } = useFormServerAction(schema, action);

  return (
    <form onSubmit={submit}>
      <label>
        Email address:
        <input type="email" {...form.register("email")} />
      </label>
      {fieldErrors.email && (
        <div className="text-sm text-red-500">
          {fieldErrors.email.message}
        </div>
      )}

-     <button>Submit</button>
+     <button disabled={isExecuting}>
+       {isExecuting ? "Loading…" : "Submit"}
+     </button>

      {!isExecuting && result.data && (
        <div className="text-green-500">{result.data.message}</div>
      )}
    </form>
  );
}

6. Error state

Unexpected errors are hidden from the user, replaced by a default message to avoid exposing any implementation details:

On the other hand, known exceptions are shown to help the user:

To throw an error recognized as a known exception, you must instantiate it as an Exception (a custom class that inherits the native Error).

export function Form() {
  const {
    form,
    fieldErrors,
    submit,
    action: { isExecuting, result },
  } = useFormServerAction(schema, action);

  return (
    <form onSubmit={submit}>
      <label>
        Email address:
        <input type="email" {...form.register("email")} />
      </label>
      {fieldErrors.email && (
        <div className="text-sm text-red-500">
          {fieldErrors.email.message}
        </div>
      )}

      <button disabled={isExecuting}>
        {isExecuting ? "Loading…" : "Submit"}
      </button>

      {result.data && (
        <div className="text-green-500">{result.data.message}</div>
      )}

+     {result.serverError && (
+       <div className="text-red-500">{result.serverError}</div>
+     )}
    </form>
  );
}

Full code

Take a look at the wrapper functions makeServerAction and useFormServerAction to glue action, schema and form.

📦 Code: https://github.com/arnaudrenaud/nextjs-forms-both-sides-validation

Summary

With a small set of abstractions, we get:

Consistent validation across browser and server using a shared Zod schema
Simplified form components, thanks to a custom hook that abstracts form state

This setup scales well as forms grow in complexity, and helps you avoid bugs from mismatched validation logic.

Next steps

You can copy the wrapper functions to your Next.js codebase to start using this pattern today.

To tweak or extend behavior, check out the underlying tools:

next-safe-action's createSafeActionClient
React Hook Form's useForm
Zod schema primitives (you can also define multi-field validation rules)

10 Ways to Improve for a Junior Developer

Arnaud Renaud — Fri, 05 Jul 2024 12:00:00 +0000

I taught the practice of web development to around 200 students in six years. Here are ways to improve on the mistakes and misconceptions I noticed most often.

TL;DR

Use automatic code formatting
Look for error messages
Simplify your code until the bug goes away
Solve only one problem at a time
Split tasks and commits
Give symbols a proper name
Refrain from DRYing everything out
Optimize reasonably
Test the risky parts first
Avoid persisting redundant data

Use automatic code formatting

Even if you work alone, automatic formatting is a free time saver: you can write code faster, and will be able to read it more easily later.

If you write JavaScript or TypeScript, install the Prettier extension for Visual Studio Code and enable "Format on save".
That's all, you don't need a configuration file, but you can add one at the root of your project if you need to override the default rules.

Look for error messages

When the app doesn't work, look for an error message. This is especially true when your app is made of multiple services.

Let's say your Next.js web app with server-side rendering relies on your back-end server. When something fails, here are four places you have to look for an error:

the browser console (error on the client)
the server response body in the inspector's Network tab (invalid request error, it should appear in the UI)
the Next.js server console (error during SSR)
the back-end server console (error on the back end)

Simplify your code until the bug goes away

What to do if you can't find any error message, or if the cause of a bug remains obscure after searching the error online?

Simplify your code (for instance, comment out some part that runs when the bug happens), and try to reproduce the bug again. If reproducible, repeat again and again until the bug is gone.

Sometimes, you only need to do this once to find the faulty part in your program.

Some other times, you simplify your program so much that it looks like a Hello world boilerplate and yet the bug is still here.
Try updating dependencies or changing environment variables. If you are still unlucky, post your issue on Stack Overflow or, if applicable, on your framework's repository issues on GitHub, and provide your simplified code.

Solve only one problem at a time

If you try to simultaneously fix a bug, implement a new feature and refactor code, chances are you will waste time by breaking your code or mix unrelated changes in a single commit, which will make code review harder.

If you feel the need for a refactor or a bug fix in the middle of an unrelated feature, refrain from doing it. Save it for later, preferably by opening a dedicated ticket (you can automate it with a GitHub action that will create an issue from any "TODO" mention in your code, for example TODO to Issue).

Split tasks and commits

When you receive a ticket for a new feature, work on it before you start implementing it. Add a checklist of subtasks and cases to handle, and implement them one after the other. You can also use this detailed case-by-case specification to write automated tests. This will help you keep going when the task at hand is overwhelming.

The same discipline goes for commits for large features: help the code reviewer by splitting your work into commits with a clear title.

Give symbols a proper name

Symbols are all the phrases that you define in your code: types, interfaces, constants, variables, functions, classes, methods.

The name data is rarely helpful when reading code. Take some time to give a descriptive name to your data and don't forget to use the plural for arrays.

Function and method names should start with a verb that describes what is returned (and/or performed).

Do not be afraid of longer names if necessary: Everything should be made as simple as possible, but not simpler. (Einstein).

Follow these rules and your code should read almost like a sentence in English.

Refrain from DRYing everything out

It is tempting to deduplicate everything in your codebase because someone said "Don't repeat yourself".

You can have rules that look the same but are conceptually different. If you refactor them into an abstraction, they could become harder to understand and maintain.

Rather than DRY, make your code ETC: Easier To Change.

This means using a single source of truth for things that are conceptually the same, for example: duplicate constants, business rules or UI components. If you copy-paste them, they will become hard to change.

Optimize reasonably

Just like excessive DRYness, premature optimization is a waste of time.

You might want to improve the performance of an algorithm, for instance by replacing a loop with a regular expression.

Is the performance gain valuable to the user in real-world conditions, with actual data? Is the gain offset by a potential loss in code readability?

A lot of time, micro-optimizations are not worth it.

A rule of thumb to avoid poor performance before it hits you in production:

keep the time complexity of the algorithm under O(n log n)
if you run database queries, do not run them in a loop of the size of the input but use a fixed number of join queries instead

Test the risky parts first

What part of my code should I test?

Again, make good use of your time. Test what is most critical and/or most at risk of failure.

You can start by testing the core business rules of the application, especially if they are supposed to evolve over time (they are at risk of regression).

Also, when a bug is reported, you can start by writing a test that highlights the bug (which means it should fail) before fixing the implementation (test-driven development).

Should I test all cases?

Test cases that are expected to happen in real-world usage, starting with the most important ones, business-wise.

Avoid persisting redundant data

Again, aim for a single source of truth.

Whether you're developing a stateful user interface or a service connected to a database, you're going to persist a state (in memory or on the disk).

In React components, I have seen many times a filtered array set to state whereas it could be calculated at render time. Instead of setting in state only the filter arguments, both the arguments and the derived array are stored, making code more verbose and error-prone because both state values must be updated everytime the filter arguments change.

Similarly, I have seen redundant database design, where data is set in a column whereas it could be derived (calculated) in real time.

However, while this single-source-of-truth approach is conceptually cleaner and easier to maintain, it can lead to performance issues if the calculation is heavy and repeated multiple times with the same arguments: why recalculate it if the result remains the same?

In this case, you can cache the result of the calculation using memoization: for instance useMemo in React, which will automatically refresh calculation when arguments change.

In a database, for instance Postgres, you can use materialized views, but you will have to refresh their content manually.

Summary

Actively look for error messages ; don't be afraid of them
Keep your work going by splitting tasks into smaller units that are easier to complete
Think of the person that will read your code: favor readability over excessive factorization or optimization
Beware of premature optimization: use your time to fix perceivable problems

What to Do with Runtime Errors

Arnaud Renaud — Mon, 29 Apr 2024 10:38:29 +0000

Errors are painful for the developer and the user alike. Errors without a clear message even more. And what about silent errors that make debugging a pain?

TL;DR

Do not blindly use try-catch blocks
Uncaught errors end up in logs, making debugging easier
If an error is not your fault, catch it (it is called an exception)
If an error is the user's fault, tell them about it

Goals

The objective of this practical guide is to help you, the developer:

Distinguish exceptions from errors
Give yourself full information about the error
Give the user limited but useful information about the error

We’ll use the example of a web server, but the same principles apply to any other type of server-side and to most client-side applications.

Error or exception?

A runtime error happens when an instruction fails to complete.

You can either:

let errors terminate the program – in this case, errors are left unckecked
or catch them before they do – in this case, errors are checked and are called exceptions

Unchecked error

Errors may imply a bug: a logical misconception or some misconfiguration. In this case, they should not be caught and silenced but rather fixed.

Examples:

an algorithm crashes unexpectedly
you try to connect to a database with invalid credentials

Exceptions (checked error)

Reciprocally, an error may not imply a malfunction in the program. It is typically the case when abnormal behavior comes from a third party.

Hence the name, exception: exceptionally, it should be caught and worked around because there is nothing to fix in our program.

Examples:

a user requests a non-existent resource
a user submits malformed data
an external provider does not respond

What to do in four cases

1. User-induced error

In case of a user-induced error (for example, a malformed request):

⚙️ Is it an error or an exception?

An exception (it must be caught).

🧑‍💻 Should I tell the user all about it?

Absolutely, so they can fix it.

📝 Should I output the error to logs?

You may, marking it as a user-induced exception. This way, you could learn about app usage and improve user experience.

2. Third-party-induced error

In case of a third-party-induced error (for example, an external remote API used by your app):

⚙️ Is it an error or an exception?

An exception (it must be caught).

🧑‍💻 Should I tell the user all about it?

Yes, so that they know it’s not a bug on your side: you can’t do much, they just have to wait.

📝 Should I output the error to logs?

Yes, marking it as a third-party-induced exception. This way, you could learn about deficiencies among your external providers.

Internal error

3. Outside a user request

In case of an error occuring outside a user request (for example a script failing at server startup):

⚙️ Is it an error or an exception?

An error (it must not be caught).

📝 Should I output the error to logs?

Absolutely, it’s a failure that needs to be fixed.

You have nothing to do in this case. By default, it will crash the server and output the error.

4. Within a user request

In case of an error occuring inside a user request:

⚙️ Is it an error or an exception?

An error (it must not be caught).

🧑‍💻 Should I tell the user all about it?

No, just show them a simple message (such as "Internal server error") so that they know something has to be fixed on your side.

📝 Should I output the error to logs?

Absolutely, it’s a failure that needs to be fixed.

You generally have nothing to do in this case. Any error uncaught by the developer will, in the end, be caught by the server and result in a default client-side error message while it outputs the full error in logs.

Note: in Node.js Express 4 however, you have to catch async errors yourself to avoid a server crash.

In practice in JavaScript

Some programming languages provide a distinction between plain errors and exceptions, such as Java with classes Error and Exception.

In JavaScript, you can only throw new Error(…). It is up to you to distinguish exceptions and actual errors.

Below is a example with a Node.js Express server (version 5.0.0-beta.3) handling all four different cases seen above:

User-induced exception
Third-party induced exception
Error outside a user request
Error within a user request

// ⚠️ This will fail with Express version 4: make sure you use Express 5+ (tested on `express@5.0.0-beta.3`)
const express = require("express");

const EXCEPTIONS = {
  THING_WITH_NAME_ALREADY_EXISTS: {
    id: "THING_WITH_NAME_ALREADY_EXISTS",
    message: "A thing with the same name already exists.",
    status: 400,
    // case 1: we do not want to log this user-induced exception
    shouldLog: false,
  },
  NOTIFICATION_SERVICE_UNAVAILABLE: {
    id: "NOTIFICATION_SERVICE_UNAVAILABLE",
    message:
      "The notification service is currently unavaible, please retry later.",
    status: 500,
    // case 2: we want to log this third-party-induced exception
    shouldLog: true,
  },
  // …
};

// this function will distinguish exceptions and unchecked errors
function handleErrors(error, req, res, next) {
  const exception = EXCEPTIONS[error.message];

  if (!exception || exception?.shouldLog) {
    console.error({
      type: exception ? "EXCEPTION" : "ERROR",
      error,
    });
  }

  res
    .status(exception?.status ?? 500)
    .send(exception?.message ?? "Internal server error.");
}

async function notify() {
  try {
    await service.sendNotification(/* … */);
  } catch (error) {
    // case 2: third-party-induced exception
    throw new Error(EXCEPTIONS.NOTIFICATION_SERVICE_UNAVAILABLE.id, {
      cause: error,
    });
  }
}

async function runServer() {
  // case 3: an error at startup will crash the server, as wanted
  await database.connect(/* … */);

  const server = express();

  server.get("/", () => {
    // case 4: error will be caught by `handleErrors`, which will tell the user "Internal server error."
    throw new Error("random unchecked error");
  });

  server.post("/things", async (req, res) => {
    const existingThingWithName = await database.find(/* name from req.body */);
    if (existingThingWithName) {
      // case 1: user-induced exception
      throw new Error(EXCEPTIONS.THING_WITH_NAME_ALREADY_EXISTS.id);
    }
    await notify(/* … */);
    res.sendStatus(201);
  });

  server.use(handleErrors);

  server.listen(4000, () => {
    console.log("Server listening on port 4000…");
  });
}

runServer();

Summary

Using these rules, both you and the user will be properly informed at the correct level:

The user knows whether:
- their request is incorrect
- or they just need to wait for a third-party service to resume
- or they need to wait for a fix
You know whether errors need a fix or if they are exceptions independent of your work

Finally, you have seen it is no use to surround everything with try-catch blocks: you should only catch known exceptions and let your server treat the rest as errors.