The main idea is pretty simple. Define the model once in the richest representation you have, then generate or derive everything else from it. For TypeScript applications, I think Zod is a really good place to put that canonical definition because it gives you both runtime validation and static types from the same object.

The Problem With Defining the Same Model Over and Over

A pretty normal application ends up defining the same thing several different ways. You might start with a TypeScript interface:

interface Player {  
  name: string;
  email: string;
  active?: boolean;
}

Then you have something similar in your database:

const PlayerSchema = new Schema({  
  name: String,
  email: String,
  active: Boolean,
});

Then validation:

const playerValidator = z.object({  
  name: z.string().min(1),
  email: z.string().email(),
  active: z.boolean().optional(),
});

Then your frontend form has another definition, the API documentation describes the same fields again and maybe your tests have some factory that also knows what a valid Player is. None of these are necessarily wrong, but you now have several different things that are supposed to represent the same model.

Eventually somebody updates one and forgets another. Maybe the frontend says a field is optional while the API says it's required, or TypeScript says something is valid but your runtime validator rejects it. The problem isn't really writing the code, it's keeping all of these definitions synchronized.

Making Zod the Canonical Schema

A simplified Player schema could look like this:

import { z } from 'zod';

export const PlayerSchema = z.object({  
  id: z.string(),
  name: z.string().min(1),
  email: z.string().email(),
  teamId: z.string(),
  active: z.boolean().optional(),
});

export type Player = z.infer<typeof PlayerSchema>;  

Right away the TypeScript interface goes away because the type is derived directly from the schema:

type Player = z.infer<typeof PlayerSchema>;  

At the same time, you also have runtime validation:

PlayerSchema.parse(data);  

That by itself is already useful, but I think the more interesting part is continuing this idea further. Instead of only generating the TypeScript type, the Zod schema becomes the canonical representation and everything else becomes a projection of it.

                    ┌─ TypeScript types
                    │
                    ├─ API validation
                    │
Zod canonical ──────┼─ Forms  
schema              │  
+ metadata          ├─ Database models
                    │
                    ├─ OpenAPI
                    │
                    ├─ Documentation
                    │
                    ├─ Test fixtures
                    │
                    └─ AI schemas

Some of these projections are basically free and some require a little bit of code generation, but the important part is that they all start from the same place.

Sharing the Same Schema on the Frontend and Backend

This gets especially useful in a monorepo. You can put the canonical schema in a shared package and both the frontend and backend import it.

packages/  
  schemas/
    player.ts

Then both sides can use:

import {  
  PlayerSchema,
  type Player,
} from '@staty/schemas';

The API knows what a Player is, the frontend knows what a Player is and a form can use the exact same validation rules. Instead of keeping the frontend and backend "in sync", they are actually using the same object.

For example, React Hook Form can use the same schema directly:

useForm({  
  resolver: zodResolver(PlayerSchema),
});

Or if a form only uses part of a model, you can derive another schema from it:

const EditPlayerSchema = PlayerSchema.pick({  
  name: true,
  email: true,
});

I like this a lot more than creating something like EditPlayerFormValidator, EditPlayerDTO and EditPlayerType separately and hoping they continue to match six months from now.

Parse at the API Boundary

Another part of this pattern is parsing input at the API boundary instead of trusting it. This is something TypeScript by itself doesn't really solve.

This:

const player = req.body as Player;  

doesn't validate anything. It basically just tells TypeScript to trust you.

Instead:

const result = PlayerSchema.safeParse(req.body);

if (!result.success) {  
  return res.status(400).json(result.error);
}

const player = result.data;  

Now you have runtime validation and typed output at the same time. Zod objects also strip unknown properties by default, which makes this useful as a payload whitelist before data ever reaches the database.

If somebody sends:

{
  "name": "Taku",
  "email": "test@example.com",
  "admin": true
}

and admin isn't part of the schema, it doesn't become part of the parsed object. In Staty I use a similar idea when sanitizing model payloads before they reach the database, and I think this is one of the better places to enforce that kind of behavior.

Zod Can't Describe Everything

The obvious limitation is that Zod doesn't know everything your database needs to know. A teamId might reference a Team, an email might need a unique index, a field might need an index or MongoDB may own _id.

Those aren't really validation concerns, so I don't think they need to be forced into the schema itself. I think of the canonical representation more like:

Zod schema  
+
metadata  

For example:

export const playerMetadata = {  
  email: { unique: true },
  teamId: { ref: 'Team', index: true },
};

Zod 4 has better support for metadata and registries now, which makes this general approach cleaner, but database-specific concepts still need some conventions of your own. The important part to me is that I still don't want to manually redefine the entire model in another place just because the database needs a few extra details.

Generating the Database Model

This is where it starts becoming more interesting. Instead of maintaining a PlayerSchema in Zod and then separately maintaining a PlayerMongooseSchema, you can derive the Mongoose representation from the canonical schema.

A very simplified converter could look something like this:

function zodToMongoose(field) {  
  if (field instanceof z.ZodString) return { type: String };
  if (field instanceof z.ZodNumber) return { type: Number };
  if (field instanceof z.ZodBoolean) return { type: Boolean };

  return { type: Schema.Types.Mixed };
}

Then you can walk the Zod object:

function toMongooseSchema(schema) {  
  return Object.fromEntries(
    Object.entries(schema.shape).map(([name, field]) => [
      name,
      zodToMongoose(field),
    ])
  );
}

And create the model from the generated result:

const Player = model(  
  'Player',
  new Schema(toMongooseSchema(PlayerSchema))
);

Obviously the real implementation has to understand optional values, arrays, nested objects, dates, refs, indexes and other things. But I don't think putting a 100-line converter into a blog post makes the concept any clearer.

The part I care about is the direction.

Zod  
 ↓
Mongoose  

Instead of:

Zod ← developer → Mongoose  

The second version has two independently maintained definitions. The first one has a canonical definition and a projection.

Mongoose, Prisma and Drizzle Are Not Equal Here

Mongoose is probably the cleanest fit for this pattern because its schemas are runtime JavaScript objects. You can inspect the Zod schema and turn it directly into a Mongoose schema without having to generate an intermediate file.

For example:

teamId: z.string()  

plus:

teamId: { ref: 'Team' }  

could become:

teamId: {  
  type: Schema.Types.ObjectId,
  ref: 'Team',
}

Prisma is a little different because Prisma expects its own schema DSL. So the flow is more like:

Zod  
 ↓
generator  
 ↓
schema.prisma  
 ↓
Prisma  

The generated output might look like:

model Player {  
  id       String  @id
  name     String
  email    String  @unique
  teamId   String
  active   Boolean?
}

If I was doing this with Prisma, I would probably commit the generated schema.prisma and have CI make sure it hasn't drifted:

pnpm generate:prisma  
git diff --exit-code  

If somebody changes the canonical schema but forgets to regenerate Prisma, the build fails.

Drizzle sits somewhere in the middle because its tables are TypeScript runtime builders. A table might look like this:

const players = pgTable('players', {  
  name: text('name').notNull(),
  email: text('email').notNull().unique(),
  active: boolean('active'),
});

So you can write a converter that maps Zod fields into the appropriate Drizzle builders without necessarily generating a separate DSL file.

function zodToDrizzle(name, field) {  
  if (field instanceof z.ZodString) return text(name);
  if (field instanceof z.ZodNumber) return integer(name);
  if (field instanceof z.ZodBoolean) return boolean(name);
}

I think it's important to be honest about the ergonomics here. Mongoose is probably the easiest fit, Drizzle is a pretty good fit and Prisma works but requires more traditional code generation.

Also, this doesn't magically make your database interchangeable. Queries, relations, transactions, migrations, indexes and database-specific features are still going to leak into the application. What it does is remove one pretty large area of duplication, which is the basic definition of what your data looks like.

Canonical Doesn't Mean Every Layer Uses the Exact Same Schema

Another distinction I think is important is that a canonical schema doesn't mean every part of your application uses the entire schema. A database Player might contain id, created, updated and internalNotes, while a registration form only needs name, email and teamId.

That is where projections are useful.

const CreatePlayerSchema = PlayerSchema.omit({  
  id: true,
});

const EditPlayerSchema = PlayerSchema.pick({  
  name: true,
  email: true,
});

const PublicPlayerSchema = PlayerSchema.omit({  
  internalNotes: true,
});

These are different schemas, but they are intentionally different and they all have a relationship back to the canonical model. That's a lot different than three developers independently creating three separate definitions that just happen to look similar.

Generating More Than Code

Once you have a canonical machine-readable schema, the generation doesn't really need to stop at database models. The same information can be used for API documentation, OpenAPI, test fixtures, environment variable validation and other generated artifacts.

If the schema says:

email: z.string().email()  

your documentation generator already knows it's a string and that it must be an email. You can also generate valid fixtures for testing rather than having every test manually decide what a valid Player looks like.

const player = generateFixture(PlayerSchema);  

I've also been using this same general idea for documentation in Staty. Once the schema and application metadata are machine-readable, that same source can generate developer documentation and even content used by an AI help assistant.

Canonical Schema  
       │
       ├── API docs
       ├── developer docs
       └── AI retrieval corpus

I think that gets pretty interesting because when the actual application changes, the documentation used by the AI can change with it. The AI doesn't have to rely as much on some Markdown document somebody wrote months ago and forgot to update.

AI Makes This More Important, Not Less

This is probably the main reason I've been thinking about this pattern more lately. AI can generate a lot of code very quickly, which is obviously useful, but it can also create duplication very quickly.

An AI agent can easily create:

Player.ts  
PlayerDTO.ts  
PlayerRequest.ts  
PlayerResponse.ts  
PlayerForm.ts  
PlayerValidator.ts  
PlayerModel.ts  

Each file can be perfectly reasonable by itself, but now you have seven representations of basically the same thing. The cost of writing all of these has dropped close to zero, but the cost of keeping them synchronized has not.

It also creates a context problem for AI. If an agent is trying to change a Player, it now has to figure out which of those seven files is authoritative and which ones are just copies or variations.

I would rather give the agent a much simpler rule:

This is the canonical schema. Do not redefine the model. Derive from it.

That's easier for developers to understand and it's also much easier to put into something like AGENTS.md for AI coding agents.

Schemas Are Starting to Become Inputs for AI Too

There's another side of this that didn't really exist in the same way before. Schemas aren't only useful for normal application code anymore.

LLMs increasingly use structured output and tool calling, which means you are already describing the shape of data you expect the model to return. The same schema that describes a Player to your frontend and backend can potentially also describe that Player to an AI model.

So instead of:

PlayerSchema  
   │
   ├── TypeScript
   ├── API
   ├── database
   └── frontend

you increasingly have:

PlayerSchema  
   │
   ├── TypeScript
   ├── API
   ├── database
   ├── frontend
   └── AI

That makes the investment in having a clean canonical schema a lot more valuable.

Be Careful With Defaults

One issue I ran into with this approach was defaults. Something as simple as this can look harmless:

active: z.boolean().default(false)  

But if your database generator reads that and produces:

active: {  
  type: Boolean,
  default: false,
}

you have now turned a validation default into persistence behavior.

We ran into a version of this with configuration inheritance where there were effectively three different states:

undefined → inherit from parent  
false     → explicitly disabled  
true      → explicitly enabled  

Those three values had different meanings. Once .default(false) caused undefined to become false, the application could no longer tell the difference between something that had never been configured and something somebody explicitly disabled.

That broke inheritance behavior in a way that wasn't very obvious at first. Since then I've become a lot more conservative about putting defaults into the canonical schema.

My general rule now is that defaults should belong to the consumer unless the default is really universal.

If a form should initially show an unchecked checkbox:

const formDefaults = {  
  active: false,
};

that's a frontend concern.

If MongoDB should add a value when a document is created:

const databaseDefaults = {  
  active: false,
};

that's a database concern.

The canonical schema should describe what the data is and what is valid. It shouldn't accidentally make business decisions for every layer consuming it.

Why I Think This Matters More Now

Before AI, duplication had a pretty obvious cost because somebody had to manually sit there and write all of it. Now AI can generate an interface, validator, database model, API type, form schema, tests and documentation almost instantly.

I don't think that means architecture like this matters less. I think it matters more.

The problem is changing from:

How do we write all of this code?

to:

How do we make sure all of this code stays consistent?

You can always ask an AI agent to update five different definitions every time a model changes. I'd rather not have five independent definitions in the first place.

The pattern I've been settling on is pretty straightforward: define the model once, derive everything you reasonably can from it, validate data at the boundaries, keep consumer-specific behavior outside the canonical schema and use CI to make sure generated artifacts don't drift.

Zod works pretty well for this in TypeScript because it sits in an interesting middle ground. It's not your database, ORM, form library or API documentation, but it understands what the data looks like, how it should be validated and what its TypeScript type should be.

That makes it a pretty good canonical layer. Everything else can be a projection of that definition, and as more code gets written and maintained with AI, I think having a clear answer to "where is the real definition of this model?" becomes a lot more important.

Over the last 10+ years we've moved more and more functionality into managed platforms. Authentication goes into Clerk or Auth0. Payments go into Stripe. Search goes into Algolia. Commerce goes into Shopify. Feature flags go into LaunchDarkly.

From an engineering perspective this usually makes a lot of sense. I would much rather use Stripe than build a payment platform from scratch, and I definitely don't want to build authentication, password resets, MFA, OAuth and session management unless I absolutely have to.

The problem is that AI coding tools mostly understand what they can see, and a lot of the actual application is no longer in the repo.

Managed Application Platforms

I think managed application platforms is probably the best way to describe this category. They're more than just normal SaaS products because they're often part of the runtime behavior of your application. They own application state, configuration and sometimes a pretty significant amount of business logic.

Some obvious examples are:

Clerk  
Shopify  
Stripe  
Auth0 / Okta  
LaunchDarkly  
Algolia  
Contentful  
Sanity  
Salesforce  
ServiceNow  

The application usually interacts with them through an SDK or API, but the SDK only shows part of what's actually happening.

You might have this in your code:

const user = await currentUser();  

The AI can understand that line pretty easily. What it can't necessarily see is everything configured behind it:

organization roles  
permissions  
SSO configuration  
session settings  
MFA requirements  
dashboard settings  

That configuration still affects the application. It just doesn't live in Git.

Clerk

Clerk is probably one of the clearest examples I've run into personally.

Your application might contain something like:

has({ permission: "org:admin" })  

From the code this looks pretty simple. If an admin suddenly can't access something, an AI coding tool might search the repository, inspect the authorization check and conclude that the code looks correct.

The real problem could be that the permission was never assigned to the role in Clerk.

There may be absolutely nothing wrong with the application code. A human engineer who's been working on the system for a while probably knows to check Clerk. The AI might spend a bunch of time trying to "fix" code that isn't broken because that external configuration isn't part of the context it has.

Shopify

Shopify has the same problem but at a much larger scale. I've worked with Shopify where a lot of the behavior wasn't really owned by the React application at all.

Products, metafields, discounts, checkout behavior, themes, extensions, merchant configuration and installed apps can all change what happens.

The application might simply do:

const product = await shopify.getProduct(id);  

but the behavior behind that product could depend on configuration that never appears anywhere in the repository.

This gets especially interesting when something breaks in production. The code didn't change, but Shopify configuration did.

If the AI only has access to Git, its view of the problem is incomplete before it even starts debugging.

Stripe

Stripe is another obvious one because a lot of payment logic looks like normal application logic from the outside:

await stripe.paymentIntents.create(...)  

But Stripe owns a huge amount of state:

customers  
products  
prices  
subscriptions  
connected accounts  
invoices  
tax configuration  
webhook configuration  
payment methods  

I've worked with Stripe Connect where the state of the connected account mattered just as much as anything happening in our own database. An AI looking at the code might see a connected account ID and understand that we're sending money somewhere, but it doesn't know who actually owns that account, whether payouts are enabled, what bank account is attached or what configuration was changed in the Stripe Dashboard.

Again, part of the application is outside the application.

Auth0 and Okta

Auth0 and Okta have the same issue as Clerk, especially once you get into larger organizations. You might have application code that validates a token and checks some claims, while the actual behavior depends on:

roles  
groups  
identity providers  
SSO  
MFA rules  
tenant configuration  
custom actions  
claims  

A lot of this can change without a deployment, which I think is one of the more interesting parts of the problem.

We've always thought of source control as the history of how the application changed. That's not completely true anymore. The application can change while Git stays exactly the same.

LaunchDarkly

LaunchDarkly might actually be the purest example.

Your code could contain:

if (flags.newCheckout) {  
  return <NewCheckout />;
}

return <OldCheckout />;  

The AI sees two code paths, but which one is production actually using?

Maybe both.

The answer could depend on:

environment  
user ID  
organization  
percentage rollout  
segment  
prerequisite flag  
manual override  

None of that logic necessarily exists in your repository.

You could ask an AI:

Why does Customer A see the new checkout but Customer B doesn't?

and it could spend a lot of time analyzing React when the actual answer is just a LaunchDarkly targeting rule.

That's a pretty large blind spot.

Algolia

Search is another place where a surprising amount of behavior can live outside the code. I've worked with Algolia where the frontend really only knows how to send a query and display the results.

The actual search behavior can depend on:

ranking  
searchable attributes  
facets  
synonyms  
replicas  
merchandising  
index configuration  

Suppose somebody says:

Search results are bad for "black dress."

The AI opens the frontend and finds:

index.search("black dress");  

There's not much to fix there.

The problem could be that somebody changed ranking configuration or synonyms inside Algolia. A human who knows the application understands that search isn't just code. The AI has to somehow be given that context.

Contentful and Sanity

CMS platforms create a similar problem, although in a slightly different way.

Your React application might know about:

article.title  
article.heroImage  
article.body  

but the actual content model, published entries, references, localization and editorial state live somewhere else.

This isn't necessarily traditional business logic, but it still affects application behavior. An AI can look at the component and decide that heroImage should always exist because the TypeScript interface says it's required, while an editor may have created 300 older articles before that field existed.

The production data is telling a different story than the code.

Sanity is a little better here because more of its schema can be represented as code, but the actual content and relationships still exist outside the application repository.

Salesforce and ServiceNow

Salesforce is where this problem can get pretty extreme. I've seen enterprise applications where Salesforce isn't just a database. It contains a huge amount of business behavior.

Things like:

validation rules  
flows  
approval processes  
permissions  
custom objects  
automation  
workflow rules  

Imagine your application does this:

await salesforce.updateCustomer(customer);  

Then something unexpected happens.

Maybe an approval process starts. Maybe another record gets updated. Maybe an email gets sent. Maybe the update is rejected because of a validation rule.

None of that behavior has to exist in your application's repository. You could give the AI every line of your code and it still wouldn't understand the complete workflow.

ServiceNow is very similar. A lot of enterprise workflows can live almost completely inside the platform through forms, business rules, approvals, permissions, integrations and automation. From the application side you might just see an API call, while behind that call there could be years of business logic.

This is probably where the term "black box" starts feeling pretty accurate.

The Repository Isn't the Application Anymore

This is the part I find most interesting.

For a lot of modern applications, the real system looks closer to:

Application Repository  
        +
MongoDB  
        +
Clerk  
        +
Stripe  
        +
Shopify  
        +
Algolia  
        +
Feature Flags  
        +
CMS  
        +
Production Configuration  
        =
The Real Application  

But an AI coding agent might only see:

Application Repository  

Maybe the database schema too, if you're lucky.

That's a huge difference in context, and AI is extremely dependent on context.

I think this also changes the idea of "give the AI the whole repo." Even if you give it every file in Git, you still may not be giving it the whole application.

Humans Have Institutional Context

A senior engineer working on an application for a few years picks up a lot of information that never gets written down.

You start knowing things like:

That permission is configured in Clerk.

That product price comes from Stripe.

Don't change that field, Shopify owns it.

That search issue is probably Algolia.

That customer is on a feature flag override.  

None of those things are necessarily obvious from reading the code.

When another human joins the team, that knowledge gets transferred slowly through pull requests, Slack messages, documentation and somebody eventually saying, "oh yeah, that's weird because..."

AI doesn't really get that same onboarding. Every new coding session can effectively start with:

Here's the repository. Figure it out.

That's probably fine when most of the application lives in the repository. It's much harder when half the application lives in dashboards.

Vendor Lock-In vs Context Lock-Out

The traditional criticism of these platforms has always been vendor lock-in. You build heavily around Shopify and now moving away from Shopify is difficult. You build around Stripe and now Stripe is deeply embedded in your payment infrastructure.

That's still true.

But I think AI introduces another problem that I would call context lock-out.

Vendor lock-in is basically:

It's difficult to move away from this platform.

Context lock-out is:

It's difficult for an AI agent to understand the application because important parts of the application live inside this platform.

The application can still work perfectly fine and the developer can still understand it. The problem is that the AI has an incomplete model of the system.

I think that's becoming a real architectural cost.

This Doesn't Mean We Should Stop Using SaaS

I'm definitely not suggesting we start rebuilding all of this ourselves. That would probably be much worse.

I don't want our authentication implementation sitting in 30,000 lines of custom code just so an AI can read it. The benefits of these platforms are still huge:

less code  
faster development  
better security  
specialized infrastructure  
compliance  
scalability  
reliability  

And generally fewer things we have to maintain.

The tradeoff is that we're moving application knowledge somewhere else. That was already a problem for developers, but AI makes the cost much more obvious because the quality of the output depends so much on the context the model actually has access to.

Maybe These Platforms Need to Become AI-Native Too

I don't think the obvious solution is putting everything back into the repository. It's probably giving AI access to more of the external context.

Imagine an AI coding agent being able to inspect:

Clerk roles and permissions  
Stripe products and subscriptions  
Shopify metafields and configuration  
LaunchDarkly targeting rules  
Algolia index configuration  
Contentful schemas  
Salesforce flows  

Now when you ask:

Why doesn't this user have access?

the AI could inspect both:

application code  
+
Clerk configuration  

That's a much more useful debugging environment.

Some of this is already possible through APIs, MCP servers, CLIs and other integrations, and I think that's going to become increasingly important.

It's probably not enough for AI coding tools to understand the repo.

Eventually they need to understand the application environment.

The Hidden Complexity Never Really Went Away

For years we've been moving functionality out of our applications and into managed platforms. For the most part, I still think that was the right decision.

We write less code, ship faster and let companies that specialize in authentication, payments, commerce or search handle the difficult parts.

AI changes the tradeoff a little.

The better these coding tools get, the more valuable complete context becomes. A modern application's context isn't necessarily in Git anymore. It's spread across the repository, database and probably five or ten different SaaS dashboards.

We've spent years making applications easier to build by hiding complexity behind APIs. AI is starting to make something else obvious: the complexity may be hidden, but it was still part of the application the whole time.

The more I use AI coding tools, the more I think TypeScript becomes even more valuable because it gives AI more context about what the application is actually supposed to do. Javascript is flexible, which is obviously one of the reasons people like it, but flexibility also means ambiguity. A developer who has worked on an application for three years can usually fill in a lot of those blanks mentally. An AI agent doesn't necessarily have that institutional knowledge unless it can find it somewhere in the codebase.

Types Give AI More Context

Take something simple like this:

function updateRegistration(data: any) {  
  // ...
}

A developer familiar with the application might already know what data is supposed to contain. Maybe it looks something like this:

{
  teamId: string;
  divisionId: string;
  status: string;
  players: Player[];
}

AI doesn't automatically know that. It has to inspect the function, search where it's being called, look at other objects that seem related and then infer what the shape probably is.

Now compare that with:

interface RegistrationUpdate {  
  teamId: string;
  divisionId: string;
  status: RegistrationStatus;
  players: Player[];
}

function updateRegistration(data: RegistrationUpdate) {  
  // ...
}

There is a lot less to guess. It gets even better with unions:

type RegistrationStatus =  
  | "pending"
  | "accepted"
  | "waitlisted"
  | "cancelled";

If an AI agent is adding a registration workflow, it now has a very obvious list of valid states. Without that type it might search through the repository, find "inactive", "removed", "cancelled" and "dropped" in various pieces of old code and decide that one of those is probably the right value.

That is exactly the kind of mistake AI can make pretty easily. The code might look completely reasonable, the naming might fit the application, but the assumption itself is wrong.

any was always dangerous, but I think it's a little more expensive now because AI doesn't have all the knowledge that developers slowly accumulate while working on a system. Types move some of that knowledge out of people's heads and put it directly into the code.

AI Also Makes Strong Typing Cheaper

One of the complaints about TypeScript over the years has always been that it creates extra work. You have to create interfaces, DTOs, enums, generics and sometimes spend way too much time convincing TypeScript that something you already know is valid is actually valid.

That still happens. The difference is that AI is pretty good at doing a lot of the boring part now.

If I have an API response like this:

{
  "id": "123",
  "name": "Tigers",
  "division": {
    "id": "456",
    "name": "Mens Open"
  }
}

I can have an AI coding tool generate the TypeScript type or Zod schema basically immediately. The same thing applies to a lot of mechanical transformations:

API response  
→ TypeScript type
→ Zod schema
→ test fixture

The cost of creating decent type coverage has gone down quite a bit.

At the same time, AI is also increasing the amount of code we can produce. If one engineer can now create significantly more code in the same amount of time, I think guardrails become more important, not less.

An AI can write a lot of bad Javascript very quickly. At least with TypeScript, the compiler gets a vote.

That's one of the reasons I think the tradeoff has shifted. We have less excuse for leaving something vaguely typed because a lot of the repetitive work can now be generated, while the downside of incorrect generated code is actually becoming larger because we're producing more of it.

Sharing Models and Business Logic Across the Stack

One thing I've always liked about using TypeScript on both the frontend and backend is being able to share models. This becomes even more useful with AI because it gives the agent fewer representations of the same thing to reconcile.

For example:

export interface RegistrationTeam {  
  id: string;
  name: string;
  divisionId: string;
  status: RegistrationStatus;
  players: Player[];
}

That type can potentially be shared by:

React application  
admin application  
Node API  
background workers  
tests  

Instead of having one object shape on the frontend, another on the backend and maybe a slightly different version in some worker or admin application, there is one shared definition.

The same thing applies to business logic. For example:

export function canRegister(  
  division: Division,
  team: RegistrationTeam
) {
  return (
    team.players.length >= division.minPlayers &&
    team.players.length <= division.maxPlayers
  );
}

The frontend can use that function to determine whether a registration is valid before submission, and the backend can use the same function before actually saving anything. The backend should still be the source of truth, but there isn't much reason to independently implement the same rule twice.

In the AI era I think this is even more valuable because there is one obvious place for the agent to find the rule.

Instead of:

frontend implementation  
backend implementation  
admin implementation  

you have:

shared registration logic  

The less duplicated business logic there is, the less chance the AI has to update one copy while forgetting another.

This lines up really well with monorepos too. If the frontend, API, workers and shared libraries all live in the same repository and share TypeScript packages, an AI agent has a much better chance of understanding how a change actually moves through the system.

One Language Can Cover a Lot More of the Application

Javascript started in the browser, but TypeScript can cover a pretty large percentage of a modern application now.

You can use it for:

React  
Next.js  
Node.js  
React Native  
Electron  
Cloudflare Workers  
serverless functions  
background jobs  
build scripts  
tests  

Obviously that doesn't mean everything should be written in TypeScript. There are plenty of good reasons to use Python, Go, Rust, Java or whatever else makes sense for a particular problem.

But for a normal SaaS application, using one language across a large percentage of the stack has some pretty obvious advantages. A developer can move from a React component to an API endpoint to a background worker to a shared library without constantly switching languages and ecosystems.

React component  
→ API endpoint
→ job worker
→ shared library

AI gets a similar benefit. If the agent already understands the TypeScript types, conventions and patterns being used in one part of the application, a lot of that context transfers naturally into another part.

It isn't jumping from TypeScript on the frontend to Java on the backend and then Python for a worker while also trying to figure out how three different implementations map back to the same business domain.

That alone isn't a reason to rewrite an existing system, but if I'm starting a new application today and TypeScript is already a good fit for the workload, AI being able to operate across more of the stack with the same language is another advantage.

The Compiler Becomes Part of the AI Feedback Loop

I think this might be the biggest advantage.

AI can write some code and immediately find out whether its assumptions were structurally wrong.

The loop looks something like:

AI writes code  
    ↓
tsc  
    ↓
compiler errors  
    ↓
AI fixes code  
    ↓
tsc again  

That feedback loop is really useful.

For example, AI might generate:

registration.playerCount  

when the actual model is:

registration.players.length  

In Javascript, you might not notice the mistake until that particular code path runs. TypeScript can immediately return something like:

Property 'playerCount' does not exist on type 'RegistrationTeam'  

Now the AI has deterministic feedback instead of having to guess whether its implementation was correct.

I think this is important because LLMs are probabilistic. They can generate something that looks correct, follows the naming conventions of the application and is still completely wrong.

The compiler doesn't really care how convincing the code looks. Either the property exists or it doesn't.

Obviously this doesn't mean TypeScript proves your application is correct. You can write completely wrong business logic that compiles perfectly:

function calculateRefund(payment: number) {  
  return payment * 2;
}

TypeScript has no problem with that. Tests still matter, runtime validation still matters and code review still matters.

But TypeScript eliminates a pretty large category of structural mistakes before the tests even run, and I think that becomes especially valuable when the code is being generated by AI.

TypeScript Also Helps Centralize Context

I've been thinking a lot lately about how important context is for AI coding tools, and this is part of why I've become more interested in monorepos.

If your frontend, API, workers and shared libraries all live together, the AI has a better chance of understanding the application as one system instead of a bunch of isolated repositories.

TypeScript adds another layer to that.

The monorepo gives the AI more code.

TypeScript gives the AI more information about that code.

A repository might contain thousands of functions and objects, but types start describing how those pieces are related.

Something like:

interface Payment {  
  registrationId: string;
  userId: string;
  amount: number;
  status: PaymentStatus;
}

already tells the AI that payments are related to registrations and users.

Then a function signature like:

function refundPayment(  
  payment: Payment,
  registration: Registration
): RefundResult

describes another relationship.

You start building a kind of graph of the application just through the type system. Humans get value out of this too, but I think it's especially useful for AI because the agent doesn't have years of experience with the application and doesn't know all of the relationships by memory.

The more of the architecture and business domain we can make explicit, the less the AI has to infer.

Why I Think TypeScript Is More Valuable Now

TypeScript was already useful before AI. It made Javascript safer, made refactoring easier and helped larger teams understand how data moved through an application.

I think AI increases the value of those same features.

AI makes code significantly cheaper to generate, but that doesn't necessarily make correctness cheaper. If anything, I think it makes correctness and context more valuable because there is simply more code being produced.

Types give AI more information about what the application expects, the compiler gives it an immediate feedback loop, and using TypeScript across more of the stack makes it easier to share models and business logic instead of duplicating them.

The interesting part to me is that TypeScript may be becoming more important for a reason that wasn't really part of the original pitch.

It isn't just making Javascript easier for developers to understand. It's also making the application easier for AI to understand.

There are also obvious downsides. The repo gets huge, build systems get more complicated, CI can get expensive and if boundaries aren't enforced properly everything eventually starts importing everything else.

AI changes the tradeoff a little bit though.

The more I've been using AI for development, the more I think having related applications in the same repository is becoming an advantage. Not because monorepos suddenly got simpler, but because context is becoming a much bigger part of the development environment.

The More Context the Better

One of the biggest limitations with AI right now is context. If I'm asking an engineer to change a feature, they usually already know some things about the application. They know where the API is, how authentication works, which database models are involved and probably which other application consumes the same API.

AI doesn't necessarily know any of that unless you give it the context.

If everything is in one repository, it can potentially see something like:

/apps/web
/apps/admin
/apps/api
/packages/types
/packages/ui
/packages/utils
/packages/config

Now if I ask:

Add a new registration status and update the admin UI  

the AI can potentially find the backend enum, database schema, API response, shared TypeScript type and the frontend component using it.

That's a lot better than giving it access to only the admin repository and having it guess what the backend looks like.

For AI, context is basically part of the development environment now.

Repository Boundaries Are Also Context Boundaries

I've worked on systems where the frontend, API and other services were all in separate repositories. There are plenty of good reasons for doing that, especially once teams get larger.

The problem with AI is that the repository boundary also becomes a context boundary.

Imagine:

frontend-repo  
api-repo  
jobs-repo  
shared-library-repo  

You ask an AI agent to change something in frontend-repo, and it finds:

await api.updateRegistration(data);  

It can see that the frontend calls an API, but it doesn't necessarily know what updateRegistration actually does, what validation happens on the backend or whether some background job gets triggered afterward.

A human engineer who's worked on the system for two years might already know all of that. The AI doesn't.

You can obviously give AI access to multiple repositories, and I'm sure tooling around that will continue to improve, but at some point you're basically rebuilding a shared view of the system anyway.

That's one reason monorepos are starting to look more interesting to me again.

Shared Business Logic Was Already Useful

Shared business logic was probably one of the strongest reasons I liked monorepos even before AI. There are always rules that multiple parts of an application need to understand:

registration status  
permissions  
pricing rules  
validation  
date formatting  
API contracts  
sports-specific rules  

Without a monorepo, you have a few choices. You can duplicate the logic, publish a shared npm package, create another internal service or just accept that slightly different versions of the same rule are going to exist in different applications.

None of those are necessarily terrible, but they all add some overhead.

In a monorepo you can do something like:

/packages/registration
/packages/permissions
/packages/types

and have multiple applications depend on the same implementation.

This also gives AI something pretty useful: one obvious place to look.

Instead of trying to figure out which of three different implementations is correct, there's hopefully one package where that business rule lives.

Of course, "hopefully" is doing a lot of work there. A badly organized monorepo can still have five implementations of the same thing, which is really just the worst of both worlds.

Cross-Application Changes Are Where This Gets Interesting

This is probably where I see the biggest advantage with AI.

A feature that sounds simple can touch a surprising amount of the application.

For example:

Add waitlist support.  

That might actually mean:

Mongo schema  
→ API
→ business logic
→ admin application
→ registration application
→ email notification
→ background job
→ tests

Historically that could mean several pull requests across several repositories. With a monorepo, an AI agent can at least see the entire change.

That doesn't mean I would blindly let it modify everything. But it can understand the dependency chain much better.

It can find where RegistrationTeam is created, where the API serializes it, which React components consume it and which tests are likely to break after the schema changes.

That's a lot more useful than asking an AI tool to modify one isolated piece and then discovering three repositories later that the change broke something else.

Types Become Part of the Context

I've always liked TypeScript mainly because it makes larger Javascript applications easier to maintain. With AI, I've started appreciating another benefit: types give the model clues about how the application is supposed to work.

For example:

type RegistrationStatus =  
  | "pending"
  | "accepted"
  | "waitlisted"
  | "cancelled";

is a lot more useful than having the model search through random strings in the codebase and try to figure out which values are valid.

If the frontend and backend share that type in a monorepo, even better.

The type starts acting like documentation that is harder to let drift because the compiler complains when something no longer lines up.

This is one of the reasons I think good typing, schemas and shared contracts matter even more with AI. The AI doesn't have years of context in its head, so anything you can make explicit in the repository helps.

More Context Isn't Always Better

There is an obvious downside to giving AI more context.

More context isn't necessarily better if the context is garbage.

If your monorepo looks like:

/helpers
/helpers2
/common
/shared
/shared-new
/old-api
/api-new
/utils
/utils-final

the AI is probably going to have the exact same reaction a new engineer would have:

Which one am I supposed to use?

This is one area where I think AI actually increases the importance of good architecture.

Packages need clear responsibilities. Dependencies should go in one direction. Shared code should actually be shared, and old code should eventually be removed instead of sitting around forever waiting for someone or some AI agent to accidentally use it.

We used to organize code mainly so another engineer could understand it.

Now we're organizing it so another engineer and an AI agent can understand it.

Tests Matter More When Changes Get Bigger

AI makes it very easy to change a lot of code quickly. That's both the good part and the scary part.

An AI agent might modify six packages in a few minutes. If the repository has good tests, that can be great because it can immediately run them and see what it broke.

If the repository doesn't have tests, then you basically have a very fast junior engineer making changes across the entire application.

Probably not ideal.

A monorepo can make testing cross-application changes easier because everything is available to the same CI system:

change package  
→ identify affected apps
→ build
→ unit tests
→ integration tests
→ E2E tests

Tools like Nx and Turborepo already do a lot of the dependency graph work needed to figure out what actually needs to run.

That becomes more useful when AI is generating more changes than engineers traditionally would. If the agent changes one shared package, the build system should be able to tell it exactly which applications and tests are affected.

The Build System Still Matters

The obvious downside of a monorepo is that eventually somebody is going to run:

npm test  

and accidentally test the entire company.

That doesn't scale.

If AI agents are going to work inside large repositories, the build tooling needs to understand what actually changed. If a shared UI component changes, maybe three applications need to rebuild. If an API-only package changes, the marketing website probably doesn't care.

This is where Nx, Turborepo, pnpm workspaces, Bazel and similar tooling become pretty important.

The AI should be able to make a change and run only the relevant builds and tests instead of treating the monorepo like one enormous application.

Otherwise the extra context comes with a huge performance penalty.

Boundaries Still Matter

One of the common arguments against monorepos is that developers can access too much.

I think that's actually an even bigger concern with AI.

If everything is sitting next to everything else, it's very easy for an agent to take a shortcut. Instead of calling the proper API, it might import something directly from another package. Instead of respecting a service boundary, it might reuse an internal database model because it happens to be available.

Technically the code might work.

Architecturally you just created something terrible.

So I don't think the lesson is:

Put everything in one repo  
and let AI figure it out.  

It's more like:

Put related things in one repo,  
but make the boundaries extremely obvious.  

AI needs guardrails just like developers do.

Probably more.

And Then There Are Layoffs...

There is also another slightly depressing argument for monorepos in the age of AI.

Companies have fewer engineers.

So... monorepos are better now?

I'm joking.

Mostly.

One traditional argument against monorepos was that with hundreds or thousands of engineers working in the same repository you need really good tooling, ownership rules and coordination. If you have fewer engineers touching the codebase, some of those problems naturally become smaller.

Meanwhile those same engineers are now using AI and potentially making changes across a much larger portion of the stack.

So we might end up with fewer humans touching more code.

Which weirdly makes the monorepo model make even more sense.

I don't know if that's progress or just the industry finding a creative way to make everyone responsible for more stuff.

Monorepos Still Aren't Always the Right Answer

I don't think AI suddenly means every company should move everything into one monorepo. There are still good reasons to keep repositories separate.

Completely independent services, different security requirements, different teams, different deployment models and different technology stacks can all justify separate repositories.

But I do think AI changes one part of the equation.

Repository boundaries aren't only organizational boundaries anymore.

They're also context boundaries.

And when you're working with AI, context is extremely valuable.

The more interesting question might not be whether monorepos are better than multiple repositories. It might be:

How much of the system does the developer  
and the AI working with them  
need to understand to make a correct change?  

If the answer is "most of it," then having most of it in one place starts looking pretty attractive.

One major difference is that we're used to application code being mostly deterministic. Given the same inputs we generally expect our code to do the same thing. AI isn't really like that. It can be slow, responses can be different for the same input and sometimes it can give you something completely unintended.

And of course human input can be... creative. If you give people a textbox they'll eventually paste things into it you never expected.

Here are some of the dependencies I've been running into or thinking about while building AI functionality.

AI Provider Outages and Availability

Once you integrate OpenAI, Anthropic or another provider into a workflow, it's basically another external service that can go down. We've dealt with this forever with Stripe, Cloudflare, Elasticsearch and pretty much any service we don't completely control, but with AI there's a tendency to make the model part of the main application flow.

For example:

User Request  
    ↓
Application API  
    ↓
OpenAI  
    ↓
Parse Response  
    ↓
Continue Workflow  

This works fine until OpenAI takes 45 seconds to return or returns a 500. If the application has a 30 second HTTP timeout then we now have a failed request even though technically the AI provider may eventually complete the work.

For anything that can take awhile, I've been leaning toward treating AI work more like a job than a normal request. I've built systems using Redis backed queues and workers for long running or scheduled work and the exact same pattern applies pretty naturally here. Put the work into a queue, let a worker process it and either poll for the result or push it back through a WebSocket when completed.

Retries also have to be handled carefully. Retrying a normal GET request is pretty harmless, but if the AI is calling another service that creates a payment, sends an email or modifies data then retrying the entire workflow can potentially execute the action twice. At that point things like idempotency become just as important as the AI call itself.

Prompts and Model Versions

Prompts are starting to feel like another form of application code. A pretty small change to a system prompt can completely change what comes back from the model.

For example:

Extract the information from this document.  

and:

Extract the information from this document.  
Only return information explicitly found in the document.  
Do not guess missing values.  
Return the result using this JSON schema...  

are technically asking for the same thing but can have very different results.

Because of this I think prompts should be kept in source control and changes should be tested similar to other application changes. I probably wouldn't bury an important production prompt as a random string inside a React component anymore.

The model version becomes part of this dependency too. You can have the same application code and the same prompt but get different behavior after changing models. This makes upgrading the model a little different from upgrading most libraries.

Traditionally we expect something close to:

input + code = output  

With an AI feature it's more like:

input + prompt + model + context = probably the output we want  

AI models are non-deterministic, although there are settings that can make the output more consistent. The important thing from an application perspective is that I wouldn't assume the same prompt and input will always produce exactly the same response. If I'm changing a model in production I want to run our real use cases against it first.

Data, Context and Other APIs

The model is only one part of most useful AI applications. Unless you're asking general questions, it needs some way to know about your application's data.

I've worked on a RAG platform where documents went through ingestion, ETL, normalization, metadata enrichment and source prioritization before the information ever got to the model.

Something roughly like:

Documents  
    ↓
Ingestion / ETL  
    ↓
Normalize + Metadata  
    ↓
Search / Retrieval  
    ↓
Context  
    ↓
AI  

Once you build something like this it becomes pretty obvious that improving the model doesn't automatically improve the application. If search pulls the wrong document or your ingestion process has bad metadata, the AI is working with bad information.

Garbage in, garbage out still applies. AI just makes the garbage sound more convincing.

This gets more complicated with agents because now the model can call other APIs as part of the workflow. Taking a sports registration application as an example, imagine someone asking:

"Refund the registration for Team A"

The actual operation could become:

Find Team  
  ↓
Find Registration  
  ↓
Find Payment  
  ↓
Stripe  
  ↓
Update Registration  
  ↓
Send Confirmation  

At that point OpenAI is only one dependency. MongoDB, authentication, Stripe, your own APIs and whatever you're using for email all have to work correctly too.

I would also be very careful about what decisions the model is actually allowed to make. Finding a payment is one thing. Deciding whether the user has permission to refund it or how much they're allowed to refund should still come from the application.

Latency

AI can be slow. Most normal API endpoints I've worked with are measured in milliseconds and if one consistently takes multiple seconds I would normally consider that a performance problem. With an AI request multiple seconds can be completely normal, and once you add retrieval and tool calls the request can easily get much longer.

This is where queues, Redis, Kafka and workers become much more useful.

Instead of keeping this open:

POST /generate

...wait...

...wait...

200 OK  

we can do something closer to:

POST /generate

202 Accepted  
jobId: abc123  

and let the worker handle:

retrieve context  
→ AI
→ call API
→ AI again
→ validate
→ save

I've built distributed job systems using Redis and have also used Kafka for event driven systems, and AI workloads feel like a pretty natural extension of those patterns. Once an AI operation starts making multiple calls it's really not just a request anymore, it's a workflow.

There are of course cases where keeping the request open makes sense. Chat is an obvious one since the response can be streamed and the user expects to see it generated. I just wouldn't design every AI operation like chat.

Cost Is Part of the Application

Cost is another dependency that I didn't really think about in the same way before AI.

If one of my traditional APIs suddenly gets 100x the traffic, I'm looking at CPU, memory, database usage, bandwidth and potentially adding more servers. With AI every request can also have a direct inference cost.

Something as simple as sending unnecessary context can get expensive:

requests × tokens × model cost  

If a feature is called 10,000 times and we're sending a huge document to the most expensive model every time, the feature can technically be working perfectly while still being a production problem.

This is one place where some pretty boring application optimizations become valuable again. Cache responses when it makes sense, don't send context you don't need, rate limit expensive functionality and don't use the most expensive model when a smaller model can do the job.

I've used Redis for years primarily to improve application and API performance. With AI the same cache can potentially improve response time and actually save money at the same time, which makes the tradeoff a little easier to justify.

Keep Deterministic Code Where It Matters

Even if AI is involved in a workflow I still want normal application code to own the important business rules.

For example, AI could extract:

{
  "playerName": "John Smith",
  "division": "Mens 4.0",
  "payment": 150
}

from a registration form or uploaded document. That's a great use case because extracting inconsistent human input is something AI is good at.

I don't want the model deciding whether $150 is the correct price though. The registration system already knows the price and that should remain the source of truth.

I would handle it more like:

AI extracts information  
    ↓
Validate schema  
    ↓
Load application data  
    ↓
Apply business rules  
    ↓
Perform action  

This is especially important around payments, permissions, authentication and destructive operations. I've worked with Stripe payments and ACL/permission systems and I wouldn't replace those rules with a prompt asking the model if a user is allowed to do something.

There's also another dependency here that isn't technical: the user.

Users misspell things, upload the wrong file, paste an entire email into an input, provide contradictory instructions and sometimes ask the AI to do something completely unrelated to the feature. With a normal form we can control most inputs with selects, checkboxes and validation. Once we give someone natural language input the number of possible inputs basically explodes.

The backend still needs to assume the input is wrong until it's validated.

Monitoring AI

Normal application monitoring tells me a lot about whether the application is healthy. I've used Sentry for production errors and have built monitoring around APIs, background jobs and application performance.

AI adds an unusual problem because everything can technically succeed and the feature can still fail.

For example:

OpenAI: 200  
Latency: 2.4 seconds  
Database: success  
Exceptions: 0  

Everything is green, but if the model tells the user the tournament is March 17 when it's actually March 18, the feature didn't work.

So on top of the normal metrics I think we need to start storing things like which model was used, prompt version, token usage, cost, latency, retries and validation failures. For important AI features it also makes sense to have a set of examples where we know what a good result looks like and run those again when prompts or models change.

We've always monitored whether a service is up. With AI we also need some way of determining whether it's actually doing a good job.

Conclusion

The funny part is most of the architecture around reliable AI applications isn't really new. Queues, Redis, Kafka, workers, retries, caching, rate limiting, monitoring, validation and fallback logic are all things we've already been using.

What's different is the thing in the middle is slower, non-deterministic, can be relatively expensive and accepts almost unlimited forms of user input. That puts more pressure on all of the boring infrastructure around it.

The AI model gets most of the attention, but I'm starting to think the reliability of an AI feature is going to depend much more on everything we build around the model.

Conceptually I really like the direction. Being able to make components server components by default and only push Javascript to the client where it's actually needed makes a lot of sense. At the same time I started using the App Router fairly early and ran into enough issues where I would still proceed with some caution, especially if you aren't deploying to Vercel.

Here are some of the issues I've run into so far.

Prisma and Serverless

One of the first things to be careful with is Prisma and database connections when running Next.js in a serverless environment.

Coming from a more traditional Node.js/Express application, I'm used to having a long running server with a database connection pool. Serverless changes that because the application can start multiple instances and each one can potentially create its own database connections.

This becomes really easy to overlook with the App Router because you can query the database directly from a Server Component.

export default async function Users() {  
  const users = await prisma.user.findMany();

  return (
    <div>
      {users.map(user => (
        <div key={user.id}>{user.name}</div>
      ))}
    </div>
  );
}

I actually really like being able to do this. There is much less boilerplate than creating an API endpoint just so the frontend can turn around and call it, but it also makes it easy to forget that the component is now doing backend work and has all of the same concerns as any other backend application.

If the application scales to a bunch of serverless instances you need to make sure your database can handle the connection behavior. This isn't specifically a Next.js problem but Next.js makes it extremely easy to run into.

Cloudflare Pages

Another issue I ran into was deploying Next.js to Cloudflare Pages.

Vercel obviously gets first class support for new Next.js features, but other platforms don't always support everything immediately. This was more noticeable with the App Router because there were a lot of new features being released at once.

Things like Server Components, Middleware, Route Handlers, SSR and the Edge Runtime may work differently depending on where you're hosting the application.

I've used Cloudflare quite a bit and like the platform, so my preference isn't automatically to move something to Vercel just because it's using Next.js. But it does mean I check compatibility before depending too heavily on a newer Next.js feature.

This is something I didn't think about as much with older versions of Next.js. A feature being supported by Next.js doesn't necessarily mean that feature is supported exactly the same way by the platform you deploy it to.

Server and Client Components

Probably the biggest adjustment with the App Router was getting used to where the server/client boundary should be.

By default components are Server Components, which is great until you start using a React library that expects things like state, context or browser APIs.

For example something like Material UI generally needs to run on the client:

"use client";

import { Button } from "@mui/material";

export default function MyButton() {  
  return <Button>Click Me</Button>;
}

Initially it's pretty tempting to just start adding "use client" whenever something doesn't work. That fixes the immediate problem but you can eventually end up making a huge portion of the application client-side again, which starts defeating one of the reasons for using Server Components in the first place.

I've found it better to push "use client" as far down the component tree as possible.

For example instead of:

Product Page (client)  
  Product Details
  Product Images
  Reviews
  Add To Cart

I would rather have:

Product Page (server)  
  Product Details (server)
  Product Images (server)
  Reviews (server)
  Add To Cart (client)

The Add To Cart component actually needs state and user interaction, while most of the rest of the product page doesn't.

This also seems like a good pattern for ecommerce since product pages are exactly where SEO and initial page performance matter.

Don't Move Everything to the Server

One thing I don't agree with is treating Server Components as meaning everything should now move to the server.

There is still plenty of functionality that makes more sense in the browser. Form interactions, autocomplete, modals, filters, drag/drop, realtime updates and other highly interactive functionality probably isn't improved by trying to force it into a Server Component.

I think the better way to look at the App Router is that we finally have more control over where code runs.

Before, a lot of React applications basically started with:

Everything runs in the browser  

and then we added SSR where needed.

The App Router feels closer to:

Run everything on the server  
until there is a reason for it to run in the browser  

I like this mental model much better.

Conclusion

Overall I think the App Router is the right direction for Next.js and React. Being able to fetch data directly on the server, reduce Javascript sent to the browser and decide exactly where client-side behavior starts is a big improvement.

At least when I first started using it though, I wouldn't migrate an application just because the App Router was the newest way of doing things. Prisma/serverless connections, hosting compatibility and third-party React libraries were all things I ran into that required more thought than they did with the Pages Router.

Most of those aren't reasons not to use it. They're just things I would want to figure out early instead of discovering them after the application is already in production.

Luckily for most coming from a functional programming background, (in JS, those familiar with lodash or underscore) the conceptual mental models and DSL's are relatively the same in Immutable.js.

First we have to understand the two main data structures: Map and List

Map

const map = Immutable.Map({ id: 1, name: 'John' });  
map.get('name') == 'John'; // true  
map.set('name', 'Mike');  
map.get('name') == 'Mike'; // true  

List

const list = Immutable.List([5, 20, 101];  
list.get(1) == 20; // true  
list.set(0, 9);  
list.get(0) == 9; // true  
list.set(4, 30);  
list.toJS(); // [9, 20, 101, undefined, 30]  

Converting to Immutable.js, fromJS magically detects the proper data structure to convert to. In this example, Immutable.js knows to create a List of Map from an Array of Objects.

const data = [ { id: 1, name: "John" }, { id: 2, name: "Adam" } ];  
const magic = Immutable.fromJS(data);

Immutable.List.isList(magic); // true  
Immutable.Map.isMap(magic.get(0)); // true

Of course, this can done manually as shown below

const result = [ { id: 1, name: "John" }, { id: 2, name: "Adam" } ];

const magic = Immutable.fromJS(result);

let list = Immutable.List();  
result.map((item, index) => { list = list.set(index, Immutable.Map(item))});  
Immutable.is(list, magic); // true,  

Okay, with these basic data structure building blocks, lets build a basic redux store using Immutable.js

Let's take a look at this Person reducer using List and Map

const initialState = Immutable.List([  
  Immutable.Map({ id: 1, name: "John Snow", title: "King of the North" }), 
  Immutable.Map({ id: 2, name: "Adam", title: "Butcher" })
]);
function personReducer(state = initialState, action) {  
  switch (action.type) {
    case FETCH_ALL_PEOPLE:  // O(n)
      action.payload.map((item, index) => { 
        state = state.set(index, Immutable.Map(item));
      });
      // OR state = Immutable.fromJS(action.payload);
      return state;
    case FETCH_ALL_KINGS: // O(n^2)
      action.payload.map((king, index) => {
        const index = state.findIndex((item) => {
          return item.get('id') === king.id;
        });
        if ( index >= 0 ) {
          state = state.set(index, Immutable.Map(king));
        } else {
          state.push(Immutable.Map(king));
        }
      });
      return state;
    case CREATE_PERSON: // O(1)
      return state.push(Immutable.Map(action.payload));
    case GET_PERSON: // O(n)
      const index = state.findIndex((item) => {
        return item.get('id') === action.payload.id;
      });
      if ( index >= 0 ) {
        return state.update(index, (person) => {
          return person.set('name', action.payload.name);
        });
      } else {
        state.push(Immutable.Map(action.payload));
      }
      return state;
    case DELETE_PERSON: // O(n)
      const index = state.findIndex((item) => {
        return item.get('id') === action.payload.id;
      });
      return state.delete(index);
    case UPDATE_PERSON: // O(n)
      const index = state.findIndex((item) => {
        return item.get('id') === action.payload.id;
      });
      if ( index >= 0 ) {
        state = state.set(index, Immutable.Map(action.payload));
      }
      return state;
    default:
      return state;
  }
}

Things are okay here except when we FETCH_ALL_KINGS and get O(n^2) by trying to combine an Array with a List. We also have the following sprinkled in the code to check for duplicates which makes those cases a minimum of O(n) complexity

const index = state.findIndex((item) => {  
  return item.get('id') === action.payload.id;
});

Set

Set duplicate checks are done very efficiently. Lets rewrite the above code using Set instead of List

const initialState = Immutable.Set([  
  Immutable.Map({ id: 1, name: "John Snow", title: "King of the North" }), 
  Immutable.Map({ id: 2, name: "Adam", title: "Butcher" })
]);
function personReducer(state = initialState, action) {  
  switch (action.type) {
    case FETCH_ALL_PEOPLE:  // O(nlogn)
    case FETCH_ALL_KINGS:  // O(nlogn)
      action.payload.map((item, index) => { 
        state = state.add(Immutable.Map(item));
      });
      return state;
    case CREATE_PERSON: // O(logn)
    case GET_PERSON: // O(logn)
      return state.add(Immutable.Map(action.payload));
    case DELETE_PERSON: // O(n)
      return state.delete(Immutable.Map(action.payload));
    case UPDATE_PERSON: // O(n)
      // This is a combo of DELETE_PERSON then CREATE_PERSON
      const found = state.find((person) => {
        return action.payload.id == person.get('id');
      });
      if (found) {
       state = state.delete(Immutable.Map(found));
       state = state.add(Immutable.Map(action.payload));
      }
      return state;
    default:
      return state;
  }
}

The code state.add(Immutable.Map(action.payload)); checks for duplicates and if it does't exist, it adds it to the Set. Similarly, state.delete(Immutable.Map(action.payload)) is able to find the same data objects and delete it properly.

With this, you'll notice that the worse efficiency is at O(nlogn) which is a great trade off vs O(n^2). The code is also more clean and readable. A drawback of Set is that it isn't ordered like List so if order isn't important, the tradeoffs are worth it.

Record

If you noticed with Map person.get('name') isn't nearly as elegant as person.name in vanilla javascript on top of also losing a lot of the object syntactic sugar ES6+ provides. Luckily Immutable.js provides the data structure Record, which is essentially Map but can be treated like a javascript object

const Person = Immutable.Record({ id: "", name: "" });  
const person = new Person({ id: 1, name: "John Snow" });

person.name // "John Snow"  
const { name } = person;  // name = "John Snow"  

We just covered the basics of Map, List, Set and Record. These data structures is just the tip of the iceberg but should be a great starting point for Immutable.js

A lot of these concepts are already pretty common in Javascript especially if you've used libraries like lodash, underscore, Immutable.js or even just methods like map, filter and reduce.

No Side Effects

One of the main concepts in functional programming is avoiding side effects. Basically given the same input, a function should return the same output without changing something outside of the function.

Instead of something like:

let total = 0;

function add(value) {  
  total += value;
}

we can do:

function add(total, value) {  
  return total + value;
}

The second function is much easier to follow because everything it needs is passed into it. We don't have to search somewhere else in the application to figure out who changed total, when it changed or what the current value is.

This sounds pretty basic but as an application grows and more things start changing the same state, figuring out what changed something can get difficult very quickly.

Less State

State is obviously unavoidable in an application. We need to store users, application settings, API responses and basically everything else the application needs to remember. The problem isn't really state itself but having too many places that can modify the same state.

For example instead of modifying an object directly:

user.name = "Taku";  

we can create a new object:

const updatedUser = {  
  ...user,
  name: "Taku"
};

Now we still have the original user object and we know exactly where the new object came from. This type of pattern becomes especially useful when working with Redux where we don't want reducers modifying the existing state.

Concurrency

Another interesting benefit is concurrency. Javascript in the browser is mostly single threaded but we already deal with a lot of asynchronous operations.

Promise.all([  
  getUsers(),
  getProducts(),
  getOrders()
]);

If these functions all depend on or modify some shared state, it becomes much easier to get unexpected results. On the other hand a function like:

function calculateTotal(items) {  
  return items.reduce((total, item) => {
    return total + item.price;
  }, 0);
}

doesn't really care what else the application is doing. We can call it whenever we want with the same data and should always get the same result.

I think this becomes more important as Javascript applications start doing more things asynchronously and potentially in parallel.

Testing

Pure functions also make testing a lot easier.

function multiply(a, b) {  
  return a * b;
}

There isn't much setup needed to test this.

multiply(2, 3) === 6;  

We don't need a database, browser, global variables or some complicated application state before running the test. Obviously an entire application can't be written this way since we still need I/O, APIs and databases, but separating as much of the business logic as possible into these types of functions makes testing much easier.

Reusing Code Between Frontend and Backend

This also works pretty well with isomorphic Javascript. If some of our Javascript is going to run on both the frontend and backend, it helps if the actual business logic isn't tightly coupled to either environment.

function calculateDiscount(price, percentage) {  
  return price - price * percentage;
}

There is nothing browser or Node specific about the above function. It can run on the frontend, backend or inside a test.

I think there is a lot of value in keeping business logic like this separate from the code responsible for actually getting or saving the data.

Composition

Another useful concept is building larger functionality by combining smaller functions.

function double(value) {  
  return value * 2;
}

function addTen(value) {  
  return value + 10;
}

function calculate(value) {  
  return addTen(double(value));
}

Each function is really simple by itself and we can test each one separately. More complicated functionality can then be built by combining these smaller functions instead of having one huge function managing a bunch of variables and state.

Javascript Is Already Pretty Functional

The nice thing is Javascript already gives us a lot of tools for doing this.

const activeUsers = users  
  .filter(user => user.active)
  .map(user => user.name);

Instead of manually creating an array, looping through users, checking each user and pushing the name into another array, we describe the transformations we want to make to the data.

Obviously I don't think Javascript applications need to be 100% functional. Applications have state, perform I/O, call APIs and save things into databases so side effects are going to happen.

But minimizing shared state, using pure functions where it makes sense and separating business logic from I/O seems like a good way to make larger Javascript applications easier to maintain.

We created a simple simulation where a "muncher" would randomly move either left, right or jump to eat the randomly placed falling food. Through many iterations, the muncher would figure out the most efficient way to eat the most amount of food.

In the beginning, the muncher would aimlessly move around as shown below (muncher is the green dot, food is the falling blue dot):

But after sometime, the muncher started to figure out a more efficient way to get more and more food:

Example of a shared JSON between the backend and frontend:

// file: shared/models/player.js
var Player {  
  league: { type: 'id', ref: 'League' },
  division: { type: 'id', ref: 'Division' },
  team: { type: 'id', ref: 'Team' },
  name: { type: 'string', default: '' },  
  created: { type: 'date', default: Date.now },
  updated: { type: 'date', default: Date.now }
};
export default Player;  

In case if you didn't notice, this looks exceptional similar to a Mongoose Schema Model. The main difference is the ObjectId is replaced with the string 'id' and all the other types are now relagated to strings too for consistency:

// file: api/utils.js
import mongoose from 'mongoose';  
var Schema = mongoose.Schema;  
import _ from 'lodash';

let mongooseify = function(json) {

  let result = {};
  _.map(Object.keys(json), (key) => {
    let property = _.cloneDeep(json[key]);
    let type;
    switch(property.type) {
      case 'id':
        type = Schema.ObjectId;
        break;
      case 'number':
        type = Number;
        break;
      case 'string':
        type = String;
        break;
      case 'date':
        type = Date;
        break;
      default:
        break;
    }
    result[key] = _.assign({}, property, {type});
  });

  return result;
};

Note: (This can be extended to add additional types)
And finally, create the Mongoose Model:

// file: api/models/player.model.js
'use strict';  
import mongoose from 'mongoose';  
var Schema = mongoose.Schema;  
import player from '../../shared/models/player';  
import utils from '../utils';

/**
 * Player Schema
 */
var PlayerSchema = new Schema(utils.mongooseify(player));

module.exports = mongoose.model('Player', PlayerSchema);

Given the simple object of a Sports Team

{
  "name": "Knights",
  "city": "Los Angeles",
  "state": "CA"
}

We want to remove all duplicates that have the same combination of name, city and state. To view all duplicates of this combination, run a map reduce in MongoDB:

db.getCollection('teams').aggregate(  
    { $match: { 
        name: { $ne: ''},
        city: { $ne: ''},
        state: { $ne: ''}
    }},
    { $group: {
        _id: { name: "$name", city: "$city", state: "$state"},
        count: { $sum: 1},
        dups: { $push: "$_id"}
    }},
    { $match: {
        count: { $gt: 1}
    }}
)

The results should show if there are any duplicate combinations.

To remove the duplicates run:

var duplicates = [];

db.getCollection('teams').aggregate([  
  { $match: { 
      name: { $ne: ''},
      city: { $ne: ''},
      state: { $ne: ''}
  }},
  { $group: { 
      _id: { name: "$name", city: "$city", state: "$state"},
      count: { $sum: 1},
      dups: { $push: "$_id"}, 

  }}, 
  { $match: { 
      count: { $gt: 1}
  }}
])               
.forEach(function(doc) {
    doc.dups.shift();      
    doc.dups.forEach( function(dupId){ 
        duplicates.push(dupId);
        }
    )    
})


db.getCollection('teams').remove({_id:{$in:duplicates}})  

A caution to note, this script does not check the dependencies before deleting. So use at your own risk.

Fetching for a list of teams then fetching for their list of players returns a list of promises in the below example:

async function getTeams() {  
  var teamList = _.map(await getTeamList(), async (team) => {
    team.players = await getPlayerList(team.teamId);
  });

  return teamList;
}

getTeams().then((data)=> {  
  console.log('Array of promises...', data);
});

This isn't too surprising since async functions returns a promise and mapping through them simple just returns the list of them. But the problem lies in the way Lodash/Underscore implements iterating through lists. If you need to run an await, it needs to be inside an async function and cannot be inside a normal function(or arrow function for that matter). So iterating through a list and handling promises through a callback function becomes much more of an issue.

The best way I found to handle this issue to to iterate without callback functions using the old school For Loops.

async function getTeams() {  
  var teamList = await getTeamList();
  for(let i=0; i<teamList.length; i++) {
    let team = teamList[i];
    team.players = await getPlayerList(team.teamId);
  }
  return teamList;
}

getTeams().then((data)=> {  
  console.log('Array of teams with players!', data);
});

Why we should

Writing tests help write more testable code which usually translates to more simple code and allows for easier refactoring. It also instills confidence in the developers to deploy their code that are unit tested.

• Reduce time to first "it"

• Maintainability

• Readability while being more declarative instead of imperative

Tooling

• Karma
• Jasmine

Ways to reduce boilerplate

• if using Jasmine, nested describes helps write clearer tests. By nesting describes, we can bundle similar tests as well as bundle similar boilerplate in the beforeEach and write leaner "it" statements. (http://devchat.tv/adventures-in-angular/026-aia-testing-tools)
• reduce mocks (refer to post on TDD is dead?)
  • Less global states
  • More modular code
• automate ways to run tests
  • karma TDD, by using PhantomJS. Setup to run on file save.

Plugins

• promote ng-html2js
• promote your ng-request2js
• promote your html-to-json-array

Testing directives (general)

//directive someDirective
angular.module('someDirective')  
  .directive('someDirective', someDirective);
function someDirective() {  
  return {
    restrict: 'E',
    scope: {
      personName: '='
    },
    template: '<div>{{welcomeMessage}}</div>',
    link: function(scope, element, attrs) {
      scope.welcomeMessage = 'Hello ' + scope.personName;
    }
  }
};

// typical Directive boilerplate should go here
describe('someDirective', function () {  
  beforeEach(module('app'));
  var $scope, $compile, $rootScope, element;

  beforeEach(inject(function($injector) {
    $rootScope = $injector.get('$rootScope');
    $compile = $injector.get('$compile');
    $scope = $rootScope.$new();

    element = angular.element('<some-directive person-name="John"></some-directive>');
    $compile(element)($scope);
  }));

  it('should welcome the user', function() {
      expect(element.html()).toContain('Hello John');
  });

});

Testing directives (controller)

// directive someDirective
angular.module('app', []);  
angular.module('app')  
  .directive('someDirective', someDirective);

function someDirective() {  
  return {
    restrict: 'E',
    scope: {},
    template: '<div>{{welcomeMessage}}</div>',
    controller: function($scope) {
      $scope.welcome = function(name) {
        $scope.welcomeMessage = 'Hello ' + name;
      }
    }
  }
}

test directive controller scope

describe('someDirective', function () {  
  beforeEach(module('app'));
  var $scope, $compile, $rootScope, element;

  beforeEach(inject(function($injector) {
    $rootScope = $injector.get('$rootScope');
    $compile = $injector.get('$compile');
    $scope = $rootScope.$new();

    element = angular.element('<some-directive ></some-directive>');
    $compile(element)($scope);
  }));

  it('should welcome the user', function() {
      var scope = element.isolateScope();
      scope.welcome('John');
      $scope.$digest();
      expect(element.html()).toContain('Hello John');
  });

test directive controller this

// directive someDirective
angular.module('app', []);  
angular.module('app')  
  .directive('someDirective', someDirective);

function someDirective() {  
  return {
    restrict: 'E',
    scope: {},
    template: '<div>{{welcomeMessage}}</div>',
    controller: function($scope) {
      this.welcome = function(name) {
        $scope.welcomeMessage = 'Hello ' + name;
      }
    }
  }
};

describe('someDirective', function () {  
  beforeEach(module('app'));
  var $scope, $compile, $rootScope, element, controller;

  beforeEach(inject(function($injector) {
    $rootScope = $injector.get('$rootScope');
    $compile = $injector.get('$compile');
    $scope = $rootScope.$new();

    element = angular.element('<some-directive ></some-directive>');
    $compile(element)($scope);

    $rootScope.$apply();
    controller = element.controller('someDirective');
  }));

  it('should welcome the user', function() {
      controller.welcome('John');
      $scope.$digest();
      expect(element.html()).toContain('Hello John');
  });

Testing Services

// someService code here
angular.module('app', []);  
angular.module('app')  
  .factory('someService', someService);

function someService() {  
  var welcomeMessage = '';
  var MessageCreator = function() {
    this.welcome = function(name) {
      welcomeMessage = 'Hello ' + name;
    };

    this.getWelcomeMessage = function() {
      return welcomeMessage;
    };
  }
  return MessageCreator;
};

// test code here
describe('someService', function() {  
  beforeEach(module('app'));
  var $rootScope, $scope, $scope;
  beforeEach(inject( function ($injector) {
    $rootScope = $injector.get('$rootScope');
    someService = $injector.get('someService');
    $scope = $rootScope.$new();
  }));

  it('should create new someService object', function() {
    var service = new someService();
    expect(someService).toBeDefined();
    expect(typeof someService).toBe('object');
  });

  it('should create a welcome message', function() {
    var service = new someService();
    service.welcome('John');
    expect(service.getWelcomeMessage()).toEqual('Hello John');
  });
}

Testing Controllers

// someController code here

angular.module('app', []);  
angular.module('app')  
  .controller('SomeController', SomeController);
function SomeController($scope) {  
  $scope.welcome = "Welcome " + $scope.name;
}

// test code here
describe('someController', function(){  
  beforeEach(module('app'));
  var scope, ctrl;

  beforeEach(inject(function($controller, $rootScope) {
    $cope = $rootScope.$new();
    ctrl = $controller(someController, { $scope: scope });
  }));

  it('should change welcome message when name is set', function() {
    scope.name = "John";
    scope.$digest();
    expect(scope.welcome).toBe("Welcome John");
  });
});

Arrow Function

Without a doubt, the arrow function is my favorite and probably one of the most commonly seen peppered around in github source code. It's pure syntactic sugar but it's simplicity in how it handles the clunkiness of the this keyword definitely makes this my favorite.

Before:

var User: {  
  name: "John",
  welcome: function() {
    var that = this;
    request.get(url, function(res) {
      that.name = res.name;
    });
  }
}

With ES6:

var User: {  
  name: "John",
  welcome: function() {
    request.get(url, res => this.name = res.name );
  }
}

Promises

There's a lot of libraries provide the promises functionality like Q, Bluebird and in AngularJS but I was hoping for a more native implementation to quiet all the naysayers in regards to callback hell. Finally, that day has come.

Before:

async1(function () {  
  async2(function () {
    async3(function () {
      async4(function () {
      })
    })
  })
})

With ES6:

var async1 = new Promise(function(resolve, reject) {  
  resolve(1);
});
var async2 = new Promise(function(resolve, reject) {  
  resolve(1);
});
var async3 = new Promise(function(resolve, reject) {  
  resolve(1);
});
var async4 = function() {console.log('async4');}

async1.then(nosync).then(async3).then(async4);

Let

Javascript has an uncanny valley effect for most developers coming from a C and Java background. It looks like Java but it doesn't behave like it. Most developers learn the hard way through hard to find bugs. One of the bugs that get most developers is scoping

Before:

for(var i=0; i<10; i++) {  
// some implementation
}

console.log(i);  
// 10;

With ES6:

for(let i=0; i<10; i++) {  
// some implementation
}

console.log(i);  
// i is not defined

Default parameters

Although I wasn't too fond of CoffeeScript (I prefer TypeScript), one feature I liked a lot about CoffeeScript was the ability to set default parameters. It was more declarative and reduced some plumbing when passing in parameters.

Before:

function handler(name, message) {  
  if (typeof name === "undefined") name = "John";
  if (typeof message === "undefined") message = "Hello";

  console.log(message + " " + name);
}

With ES6:

function handler(name = "John", message = "Hello") {  
  console.log(message + " " + name);
}

Destructuring

Once upon a time, I used to write in Perl. It was bashed for it's archaic and unreadable syntax (Write once, read never!). But quite honestly, if your developers had enough discipline, you can pump out pretty maintainable code. One such feature that I missed from Perl was Destructuring.

Before:

var list = [1,2,3];  
var a = list.shift();  
list.shift();  
var b = list.shift();  
console.log(a,b);  
// 1 3

With ES6:

var [a, , b] = [1,2,3];  
console.log(a,b);  
// 1 3

Show and rate schools K through elementary schools as well as language schools. Site built using the MEAN stack. Build with a CMS, scraper, OAuth login, search, rating and review features.

Leaguer [Node, Express, MongoDB, React, Reflux, Bootstrap]

Isomorphic web application built with both server-side rendering and a single page application. Display player and team trending strengths and other teams weaknesses.

NPM Modules

html-scripts-to-array

Extracts HTML scripts source links to a JSON array.

karma-ng-request2js-preprocessor

A Karma plugin. Save AngularJS $http JSON requests to JavaScript