The Battle Against Chauffeur Knowledge: Guestbooks, Wristbands, and Why I Chose JWT for the French Writing Playground

The Battle Against Chauffeur Knowledge: Guestbooks, Wristbands, and Why I Chose JWT for the French Writing Playground

Published: December 2, 2025 • 12 min read

Welcome to the second blog post of the Battle Against Chauffeur Knowledge series where I do a deep dive to better explain in my own words all the responses to the questions in the blog post, 15 Questions a Senior Developer Might Have About the French Writing Playground Version 2.0.

As I mentioned in that blog post, the goal of this series is to ensure that I fully understand the responses to the questions on a deeper level by ensuring that I can simplify them in my own words. Another goal is to expose what technical terms I glossed over and failed to take the time to explore deeply.

In this blog post, I'll be responding to the question: "Explain the trade-offs between using NextAuth JWT sessions versus database sessions for a French language learning application with real-time messaging."

So let's dive in!

How the Internet Actually Works

Let's start from the very basics. When you visit a website, let's say you type www.frenchwritingplayground.com, the moment you press enter, you notice that http or https gets added to the beginning of the website URL so that it becomes https://www.frenchwritingplayground.com/.

Sometimes you don't actually see the http or https, but try copying and pasting the URL and immediately you see that it changed. Why does that happen?

Well, for you to access data or information on any website, that data has to be retrieved from something called a web server. HTTP, which stands for HyperText Transfer Protocol, is the language that your browser uses to talk to a web server.

Now a web server is not some static storage box that just stores a bunch of data. Here is an interesting way to think of a web server.

Meet Fento Resto

Let's imagine you are at a restaurant, let's call it Fento Resto. This, however, is no ordinary restaurant. In Fento Resto, you go in, take a seat, look at the menu which is on the table and then yell out exactly what you want. No waiter comes to attend to you, you simply have to yell out like a crazy person exactly what you want.

Fento Resto's kitchen is very similar to a web server for the following reasons:

• Actively Listen: Because people come in and scream their orders, the chefs in the kitchen are always on the lookout, actively listening and waiting for incoming orders. They are essentially doing this because they need to know immediately if someone wants something, and exactly what they want, otherwise they may lose customers.

• Processing: Then the moment they receive a request, they have to figure out how to prepare the meal based on your request. Different people might order chicken wings but someone might request plum sauce on the side, another person might request that the chicken already be dipped in the sauce, others might request a completely different sauce. At this stage, the chefs are basically processing what you have requested so that they figure out what to send back.

• Responding: The moment they figure out what to send to you, they prepare your meal and then serve it to you.

So every time you are browsing the web, and you click a link or submit a form or load a page, your browser sends a request to a server that is doing three things:

1. Actively listening for incoming requests
2. Processes those requests
3. Then finally responds with data

So actions like clicking a download button link or logging into an account are similar to you walking into Fento Resto and screaming out what you want so that the kitchen brings it out to you.

The Problem - HTTP is Stateless

In case you've forgotten, HTTP (HyperText Transfer Protocol) is the language your browser uses to talk to web servers. One thing about HTTP though is that it is stateless. Now what does that even mean?

Well, it simply means that the server has zero memory between requests.

Back to Fento Resto, when you place an order, it listens, processes and then delivers your order, then completely forgets who you are. This means that if you ordered chicken wings and fries and that gets delivered, then you try to make a subsequent order like, "Can I also get some ketchup to dip my fries in", the kitchen staff wonders, "Who are you? Have we met? What fries? I don't know what you're talking about."

Every single interaction is completely independent as the kitchen treats you like a stranger every single time. You can imagine that Fento Resto isn't doing well financially given that they don't even make an attempt to remember you... or are they? Keep reading!

What This Means for the French Writing Playground

So when you visit https://www.frenchwritingplayground.com, this is what happens:

1. First, the browser requests the landing or home page from the web server and the server fulfils this request. That is why you see the landing page. The server then immediately forgets you.

2. Then you click sign in, the server responds with the sign in page. Remember that HTTP is stateless so the server has no clue that you just visited the home page.

3. You enter your credentials and then click the submit button. The server verifies your credentials, says "yes, valid user!" Then immediately forgets.

4. Now you try to view your dashboard (which you can only view when logged in) but since the server forgot that it just validated you, it says "Who are you? I don't know you. Unauthorized." Now you don't even get to see your dashboard.

Now if you've read this far, you are probably wondering, why is HTTP designed to be this way? It seems inefficient doesn't it?

Well, it's actually an intentional feature of HTTP for the following reason. Servers handle millions of requests per second from different users using the internet. If they had to "remember" every conversation:

• They'd need massive memory
• They'd get confused about which conversation is which
• If they crashed, all that memory would be lost

So instead, they're stateless: handle request, respond, forget. I believe it is obvious how similar this is to Fento Resto. The chefs in the kitchen have multiple customers walking into the restaurant and yelling out their requests. It is simply not possible for them to remember exactly what each customer ordered.

Enter Sessions (The Solution)

Now you are probably thinking in your head, this has never happened to me. Every time I visit a website and login, it always remembers me. Well this is where sessions (and cookies) come into play.

But let's try to understand sessions from the perspective of Fento Resto.

So it's the end of the year and the managers at Fento Resto realize something. Their revenue is down by more than 60%. They are having less and less customers because the customers get angry that their orders keep getting forgotten in between requests.

So the managers of Fento Resto decide to do what every normal restaurant is expected to do: they hired waiters! Now these waiters actually track what you have ordered and remember you. You also don't have to scream out your orders.

When browsing the internet, since HTTP itself won't remember you, a layer has been built on top of it. This layer is called Sessions.

Now when you log in to version 2 of the French Writing Playground, the server, which is already actively listening, processes the login requests by validating your credentials and boom, you are logged in. Except this time, the server goes an extra mile by giving your browser a small piece of data that says "You are Rachel". This piece of data, in technical terms, is called a cookie.

Now when you make any subsequent requests to the server, like trying to access the dashboard page in the French Writing Playground, your browser automatically sends that cookie to the server. The server then reads the cookie and now knows who you are!

Here's a visual representation:

Request without cookie:

GET /dashboard HTTP/1.1
→ Server: "Who are you?" → 401 Unauthorized

Request with cookie:

GET /dashboard HTTP/1.1
Cookie: session=abc123
→ Server reads cookie → "Ah, you're Rachel" → 200 OK, here's your dashboard

The Big Question

Now let's take a look at the original question this blog post aims to respond to. We want to explain the trade-offs between using NextAuth JWT sessions versus database sessions for the French Writing Playground app which has a real-time messaging feature.

To explain this, let's understand what the difference between NextAuth JWT sessions and database sessions is. But by now, you should be able to tell that both of them are solutions to the same fundamental problem: HTTP doesn't remember you, so we need to remind it who we are on every single request.

As we look deeper into them, you will understand why the French Writing Playground app uses NextAuth JWT sessions and not database sessions.

Database Sessions - The Guestbook System

So Fento Resto hired waiters to help "remember" customers. But these waiters are only human and they are likely to forget customers if they do not come up with a solid system for remembering the customers. The managers thought about this and decided to implement The Guestbook System.

Here's how it works:

When you walk in:

• A waiter walks up to you and writes your name, table number, and any notes (allergies, preferences) in a big guestbook at the front desk
• Then they hand you a small ticket with a random number on it, say #247
• You take your seat at the table with the number assigned to you

Every time you need something:

• You wave at a waiter and show them your ticket with the number: #247
• The waiter walks to the front desk, flips through the guestbook, finds entry #247
• "Ah, you're Rachel at table 5, allergic to peanuts, ordered the chicken wings"
• Now they know who you are and can help you

When you leave:

• The host crosses out your entry in the guestbook
• Your ticket number #247 is now meaningless. If someone found it on the floor and tried to use it, there's no matching entry in the guestbook

Database sessions work in a similar way:

Login → Server creates a row in the "sessions" database table
      → Server gives you a cookie with session ID: "abc123"

Every request → Server receives your cookie "abc123"
              → Server queries: SELECT * FROM sessions WHERE id = 'abc123'
              → Server now knows who you are

Logout → Server runs: DELETE FROM sessions WHERE id = 'abc123'

The key insight: Your identity lives in the guestbook (the database). The ticket number is just a lookup key, and similarly, the session ID number is also just a lookup key.

JWT Sessions - The Wristband System

A few months later, Fento Resto is booming. So much so that they open 5 new locations across the city. But there's a problem: the guestbook system doesn't scale well. If you start your meal at the downtown location, then need to pop over to the uptown location to pick up a dessert order, the uptown guestbook has no idea who you are.

So the managers devise a new system: The Wristband System.

Here's how it works:

When you walk in:

• Instead of writing in a guestbook, the waiter prints out a special wristband for you
• The wristband has ALL your information printed directly on it:
  • Your name: Rachel
  • Your table: #5
  • Your allergies: Peanuts
  • When you arrived: 7:30 PM
  • When your reservation expires: 10:30 PM
• But here's the magic: the wristband has a special tamper-proof seal with Fento Resto's secret stamp. If anyone tries to change what's written on the wristband, the seal breaks and becomes obviously fake.
• You wear your wristband and take your seat

Every time you need something:

• You wave at a waiter
• The waiter glances at your wristband, checks that the seal is intact, and reads your info directly from it
• No trip to the front desk. No guestbook lookup. They instantly know who you are.

When you leave:

• This is where it gets tricky. There is no guestbook to cross out.
• If you leave before your reservation expires, the wristband is still technically valid until it expires at 10:30 PM
• If Fento Resto desperately needed to kick you out and invalidate your wristband, they'd have to either:
  • Change their secret stamp (which would invalidate EVERYONE's wristbands, including those whose reservation has not expired)
  • Start a "banned wristbands" list and check it every time (which defeats the speed benefit of not having to go look at a guestbook)

JWT sessions work in a similar way:

Login → Server creates a JWT containing {id: "user123", email: "rachel@email.com", exp: "30 days"}
      → Server signs it with a secret key (the "seal")
      → Server gives you a cookie containing this JWT

Every request → Server receives your JWT cookie
              → Server verifies the signature is valid (seal not broken)
              → Server reads your info directly from the JWT
              → NO database query needed

Logout → Server... can't really invalidate it (more on this later)

The key insight: Your identity lives on the wristband itself. No guestbook (database) is ever touched.

What JWT Actually Means

Before we dive into the trade-offs, let's quickly breakdown what JWT actually means: JSON Web Token.

• JSON: The format the data is stored in (like a structured text file)
• Web: Designed for web applications
• Token: A self-contained piece of data

If you could see inside a JWT, it looks something like this:

eyJhbGciOiJIUzI1NiJ9.eyJpZCI6IjEyMyIsIm5hbWUiOiJSYWNoZWwifQ.signature
      ^                              ^                           ^
   Header                         Payload                    Signature
(algorithm used)               (your actual data)          (the "seal")

The signature is created using a secret key that only the server knows. If anyone tampers with the payload, the signature won't match, and the server will reject it. This is similar to how a broken seal on the wristband would alert the waiter that something is wrong.

The Trade-offs

Now that we understand both systems, let's explore why you'd choose one over the other.

Trade-off 1: Speed

Winner: Wristband (JWT)

At Fento Resto with the guestbook system, every single interaction requires a trip to the front desk. Waiter sees your ticket, walks to the guestbook, flips through pages, finds your entry, walks back. That takes time.

With the wristband system, the waiter just glances at your wrist. Instant.

In the French Writing Playground, there are over 20 different API routes (different things you can ask the server to do). Every single one needs to verify who you are. With JWT, that's just decoding the token which takes microseconds. With database sessions, that's over 20 potential database queries per user session.

If you had 1,000 users making 50 requests each per day:

• JWT: 0 session-related database queries
• Database sessions: 50,000 database queries just to answer "who is this person?"

Trade-off 2: Updating Your Information

Winner: Guestbook (Database Sessions)

Let's say you're at Fento Resto and you realize you forgot to mention you're allergic to shellfish too.

With the guestbook system: The waiter walks to the front desk, adds "shellfish" to your entry. Done. Every waiter who looks you up from now on will see the updated info.

With the wristband system: Your allergy info is printed on the wristband. To update it, you'd need to:

• Go to the front desk
• Get a brand new wristband printed
• Throw away the old one

In the French Writing Playground, if you change your display name for instance, the JWT doesn't automatically know. The app has to explicitly request a new token. There's a delay. With database sessions, you'd update one row, and the very next request would see the new name.

Trade-off 3: Kicking Someone Out

Winner: Guestbook (Database Sessions)

Imagine someone at Fento Resto is being disruptive and needs to be removed immediately.

With the guestbook system: The host crosses out their entry. Their ticket #247 is now meaningless. Any waiter who tries to look them up will find nothing. They're out.

With the wristband system: Their wristband is still valid. It has the seal, it has the info, it hasn't expired. The only options are:

• Change the secret stamp (invalidates EVERYONE's wristbands - all customers get kicked out)
• Start a "banned wristbands" list and check it every time (but now you're doing lookups again, defeating the speed benefit)
• Wait for the wristband to expire naturally

In the French Writing Playground, if a user's account gets hacked and they need to be logged out everywhere immediately, database sessions make this very easy. JWT makes it complicated.

Trade-off 4: Multiple Locations (Scalability)

Winner: Wristband (JWT)

Remember how Fento Resto opened 5 locations? With the guestbook system, each location has its own guestbook. If you start at downtown and go to uptown, uptown has no idea who you are.

Solutions for guestbooks across locations:

• Have all locations share one giant guestbook (but now every waiter has to call the central guestbook location - slow)
• Sync guestbooks between locations (complicated and can get out of sync)

With the wristband system: Your wristband works everywhere. The uptown location just looks at your wrist, verifies the seal matches Fento Resto's official stamp, and serves you. No calling anyone.

For web apps, this matters when you deploy to multiple servers around the world for speed. JWT tokens work anywhere - any server can verify them locally.

Trade-off 5: Real-Time Features (Like Messaging)

Winner: Guestbook (Database Sessions) has advantages

Let's say Fento Resto wants to add a feature where they can announce "Rachel, your friend just arrived!" the moment your friend walks in.

With the guestbook system: The host can see everyone currently at the restaurant by looking at the guestbook. They can track who's connected and send them announcements.

With the wristband system: The restaurant has no central list of who's currently here. People are just walking around with wristbands. To build this feature, they'd need a separate system to track presence.

In the French Writing Playground, the messaging feature could benefit from knowing "who's online right now" for things like typing indicators or instant notifications. Database sessions naturally track this. JWT requires building a separate system for it.

Why the French Writing Playground Uses JWT

Given all these trade-offs, why did I choose JWT for the French Writing Playground?

The app is read-heavy: The main flow is write French → submit → view corrections → check collage. Lots of reading, not much real-time interaction. JWT's speed benefit shines here.

Cost-conscious: The app runs on Supabase's free tier. Fewer database queries means that I can stay within limits.

Profile updates are rare: Users don't change their name every 5 minutes. The update delay is acceptable.

Real-time messaging isn't the core feature: Yes, messaging exists, but this is a French learning app, not WhatsApp. Users aren't expecting instant typing indicators... at least I hope they're not for now.

Simplicity: NextAuth makes JWT dead simple. It is literally one line of configuration:

session: {
  strategy: 'jwt',
  maxAge: 30 * 24 * 60 * 60, // 30 days
}

When Would Database Sessions Make More Sense?

If the French Writing Playground evolved to include:

• "Marie is online" indicators: need to track who's connected NOW
• "Jean is typing..." indicators: real-time session state
• Instant ban capability: block abusive users immediately
• "Log out all other devices" feature: for multi-device session management

Then database sessions (or a hybrid approach using both) would become worth the extra database queries.

Summary

So there you have it. Database sessions and JWT sessions are two different solutions to the same problem: HTTP is forgetful, and we need a way to remind it who we are.

Database sessions (the Guestbook): Your identity lives in the database. Flexible, easy to update, easy to revoke - but requires a database lookup on every request.

JWT sessions (the Wristband): Your identity lives in the token itself. Fast, scalable, works anywhere - but harder to update and nearly impossible to revoke before expiration.

For the French Writing Playground, JWT was the right choice. For other applications, it might be different. The key is understanding the trade-offs and choosing based on what matters most for your specific situation.

I hope this was a great learning experience for you as much as it was for me.

As always, thanks for reading!