openapi-typescript VS springdoc-openapi

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.

The issue is that the springdoc-openapi BOM brings an old version of the Spring Framework 6.0, which is incompatible with Spring Boot 3.2. There are several ways to solve this problem: update springdoc, change the order of BOM imports, but the best, in my opinion, is to avoid using the io.spring.dependency-management plugin.

I would suggest using Springdoc

The SpringDoc library comes with lots of annotations to tune your REST API specification precisely. Anyway, that's out of context of this article.

I found SpringDoc, a library that automates the generation of the spec from the source code. It relies on annotations for textual bits (like tags and descriptions), but it also infers stuff from Spring annotations.

This is an API made with Spring Web, uses springdoc-openapi-ui to expose a swagger-ui on http://localhost:8080/swagger-ui/index.html

Libraries like Springdoc or Springfox can do this. These libraries generate the OpenAPI documentation based on your controllers (+ you can apply the OpenAPI annotations on your controllers). This documentation is then exposed as a REST API, for Springdoc these can be found at /v3/api-docs.

Retrieving all endpoints of a service isn't the goal of a service registry like Eureka, so no, you can't get all endpoints of a service. You can use a library like Springfox or Springdoc to enable Swagger/OpenAPI for your project. These libraries generate a JSON REST API (and a user interface) to view all your endpoints. You can even provide additional information (eg. default values, descriptions, ...) by adding some additional annotations on your controllers.

The springdoc-openapi helps automating the generation of API documentation using Spring Boot projects GitHub - springdoc/springdoc-openapi

Our microservice accept http requests: For swagger used Swagger OpenAPI 3. The bank account REST controller, which accept requests, validate it using Hibernate Validator, then call command or query service. The main reason for CQRS gaining popularity is the ability to handle reads and writes separately due to severe differences in optimization techniques for those much more distinct operations.