Future of Blitz

Blitz is not becoming less opinionated. It’s just the implementation that is changing.

The internals are significantly less complex now. Before, Blitz was a fork of Next.js, and dealing with that was a nightmare. Contributions dropped off significantly because of that.

Now features are nicely packaged and isolated. Much easier to reason about and contribute too.

> Next pushes towards serverless functions and API routes that I didn't really enjoy using for more than just a trivial endpoint.

By default (through `next start`) Next.js uses a Node.js server. You don't need to use Next.js serverless: https://nextjs.org/docs/deployment#self-hosting

Most large applications don't use API Routes for large workloads. These teams likely have a completely separate backend/API, and Next.js is the connecting piece for their frontend. For smaller teams, or solo devs, it's more common to see their entire backend built with API Routes (most commonly used with something like Prisma): https://github.com/vercel/nextjs-subscription-payments

Why are you tired of the React ecosystem?

It’ll be similar. Same result, but very different DX flavor.

Also, new Blitz includes a plugin system, that allows you to easily integrate multiple modules, for example auth and RPC and have them work together seamlessly. And have things just work like you’d expect, such as query cache being deleted on log out, and queries refetched on log in.

Huh - interesting. I built something similar at work. I didn't do a perfect job - you need to manually write in an endpoint spec that points to each controller method. For example:

    /**
     * Add new survey answer.
     */
    // prettier-ignore
    export type AddSurveyAnswer = PostEndpoint<`/survey/survey-answer/${string}`, never, Validators.SurveyAnswerBody, ResponseDataType<typeof SurveyController, "addSurveyAnswer">>;

But really the only duplicated information is the HTTP verb and the path. And those won't change very often - if at all.

Then in the front end you import the file containing all of the endpoint types:

    import * as API from "@copy-ai/endpoints";

And you're good to make requests:

    const response = await request<API.AddSurveyAnswer>({
      url: `/survey/survey-answer/${questionId}`,
      method: "post",
      data: surveyAnswerBody,
    });

You might wonder - why are you making me retype the URL/method? You don't really have to. Your editor will auto-fill that as the method can be extracted from the endpoint type as the type "post". Not a string - "post". Same for the path, but we use parameterized string types.

There's no magic here. What's happening is pretty transparent to the programmer. We just tuck away the PostEndpoint etc. types as those don't ever need to get changed. You can even easily YOLO an API request by passing in the any type.

The zero-API model doesn’t prevent specialization at all. You can add as many distinct domain layers as you want with different teams responsible for different layers.

> for larger ones, the ”zero-API” model seems to prevent team member specialization and force everyone into full-stack mode.

What is "full-stack mode" specifically? Do you mean the fact that each dev needs to run all parts of the application locally? You'd want that for most small and medium size web projects anyway, even if it e.g. consisted of stricly separated SPA and REST backend parts.

With very large projects/teams there are obviously challenges. My gut feeling is that a project started with a framework like Blitz would probably naturally evolve into some kind of a monorepo, which of course comes with both strengths and challenges. If you get that far though it'd seem to me that the full-stack architecture worked really well for the problem.

What reliability issues did you have with Blitz?

SvelteKit is way too good- anything React based feels like too much of a downgrade.