openapi-typescript VS nestjs-openapi3

OpenAPI TypeScript

I'll preface all of this with a couple esoteric design goals that I had in mind:

1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.

2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.

---

With that in mind, some specific packages that I highly recommend:

1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model

2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue — which has been _tremendously_ useful.

3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.

Glad to see alternatives but disappointed that Bruno does not support OpenAPI specification.

At my company, we hand-edit OpenAPI specs in YAML and it gets consumed by many tools that generate types[0], static analysis and dynamic checks[1]. The OpenAPI spec itself is linted[2]. And of course, Postman consumes OpenAPI.

Tools that are built on open standards will naturally see greater adoption over those that use proprietary formats.

[0]: https://openapi-ts.pages.dev

Another great library to generate TS types from OpenAPI is https://github.com/drwpow/openapi-typescript . It provides the types as single objects you access via indexing, which is pretty nice. There's a partner library to generate a typed fetch client.

If you're willing to document your API with an OpenAPI schema, then it should be possible to generate TypeScript types based on the OpenAPI schema with something like openapi-typescript. Also, Typebox can generate JSON schemas, maybe it can be used to generate something that the front-end can also use?

REST

In this sample, we'll achive it using openapi-typescript and openapi-typescript-fetch.

So I spent a lot of time in the Nest ecosystem, and I wrote some nontrivial libraries with a little (not a lot) of uptake (and neither are actively maintained at this point, so these are here mostly for completeness):

https://github.com/eropple/nestjs-auth

https://github.com/eropple/nestjs-openapi3

I was pretty excited by NestJS when I ran into it because, well--I don't mind magic, when it's done right. I quite like Spring Boot, for example. But NestJS's magic is...incorrect, in a lot of ways. The DI container is a little bit scary, with oddly hardcoded ways to register interceptors into request scope (itself necessary because NestJS's logging facilities aren't--or weren't at the time--decorating requests with X-Request-Id or similar, so you had to register your own) and no way to then define interceptor order.

It also has a lot of really overlapping nouns; guards are interceptors but less capable (and @eropple/nestjs-auth didn't use them at all) and the "pipe" concept for validation was itself inscrutable. To make it usable, I ended up just doing everything with decorators and interceptors, all living in request scope. And once I'd gotten it going, it was pretty nice. But it also meant broad incompatibilities with much of the NestJS ecosystem.