Next.js working setup example

[nanoander]

Hello,
I spent hours trying to get deepkit working on a Next.js app (latest version) without success.
Considering the huge popularity of Next.js, can you please provide an example app with the right setup?

Thank you very much.

[marcj]

@nanoander I assume NextJS doesn't use the official TypeScript compiler anymore, so it's not compatible. Also Next and Deepkit share very different architecture philosophies, NextJS uses globals and heavy conventions, while Deepkit dependency injection and SOLID code, so I'd recommend not to mix both as it will lead to unmaintainable spaghetti code.
Generally the target audience of NextJS does not overlap at all with Deepkit's. One is targeted at beginners, the other is targeted at seniors (that come from Spring/Symfony). Mixing both means putting a Ferrari V12 engine into a Fiat Punto.

If you want to get a scaleable and fast backend with nice frontend/SSR, I recommend Deepkit+Angular 18 (zoneless). It's a dream team, but needs skill to handle it correctly.

[kkimdev]

One datapoint: Our company uses Next.js for well maintained out-of-box features and productivity. We have been using gRPC-web with NextJS, but are interested in evaluating Deepkit RPC.

[alpharder]

@marcj

IMO Deepkit should be as accessible as possible.

One is targeted at beginners, the other is targeted at seniors (that come from Spring/Symfony)

I can't agree with you here. It's just two different worlds – enterprise and non-enterprise, each has its own strengths and weaknesses. It has nothing to do with developer seniority and skill level.

I believe these two worlds do collide though.

NextJS (Nuxt, Remix, Astro, SvelteKit, etc.) are great for developer productivity and rapid development.
They also provide a rich toolset for building frontend applications.

All of these frameworks mentioned above are also being widely used by enterprise companies:

• sometimes as a full-stack solution (the whole product, including backend, is written using one of these frameworks);
• sometimes as BFF pattern implementation;

---

Now, let's try to differentiate what "integrating Deepkit with X" can actually mean.

Deepkit consists of two main entities:

• State-of-art Runtime type system for TypeScript which absolutely any TS project can take advantage of.
  However, it relies on altering TS compiler and thus introduces certain level of complexity when integrating with non-standard environments (anything more complex than using raw tsc, basically).

  Runtime type safety is a major trend nowadays, with tens of solutions available (Zod, TypeBox, etc.) and being heavily used, adopted and supported by major libraries and frameworks. Despite Deepkit's type system superiority (in terms of DX and runtime performance), it's not even closely popular to competing solutions, which is unfair and can be addressed.

  One of the ways to address it – is to make it more accessible, by providing reference integrations with the most popular existing frameworks, where possible. Once Deepkit's type system gets more popular, any further integrations are gonna be implemented by 3rd-parties (e.g. Zod is popular = everyone is trying to integrate with Zod);

• Server application framework which heavily relies on runtime type system and uses its advantages aiming to provide best-in-class DX, performance and type-safety.

  And yes, this framework is mostly ASP.net/Symfony/NestJS-alike, not Hono/Express-alike.

  I don't see any ways of directly integrating (embedding) it with Nuxt/Astro/Next.js/etc, because those use their own underlying HTTP frameworks.

  Indirect integration (service communication) is still a thing though, either RPC or HTTP:

  • Direct RPC integration (isomorphic TypeScript, e.g. code sharing within monorepo), similar to tRPC. Requires Deepkit's type system to be available at both ends – client and server, which is challenging due to the reasons described above;
  • Indirect RPC integration (generating RPC code) – makes it possible to not require Deepkit's type system at client, sometimes is preferred due to a better isolation between client and server codebases. Currently not supported by Deepkit;

I spent hours trying to get deepkit working on a Next.js app (latest version) without success.

@nanoander Have you been trying to adopt the runtime types system (@deepkit/type package)? Could you please share your use case?

Next.js uses SWC compiler instead of tsc, and Deepkit Types aren't currently integrated with SWC, which makes it currently impossible to use default Next.js with Deepkit Types.

In case of the need of consuming Deepkit Framework RPC endpoints, we could also elaborate on code-generation approach which wouldn't require altering TS compiler.

[marcus-sa]

I'm using Deepkit as the server for Remix

[timvandam]

Haven’t read any of this but I was also able to easily get deepkit DI working in Remix loaders and actions

[i-am-ian]

I was able to get validations using deepkit/type working by customizing the NextJS Webpack configuration. I had to configure the default Babel loader to ignore .ts* files and instead use ts-loader for them, and add the same Deepkit Webpack plugin I'm using for my NestJS-based APIs.