anttiviljami

Thank you for the kind words!

Ah nice! Mind sharing what you’re using to generate the spec?

You don’t actually want that.

Code should not inform design.

Design informs code.

The code first approach is surely enticing and miles better than manually keeping the openapi spec up to date.

But I’d always advocate for going schema first. This has huge benefits for collaboration between frontend and backend engineers and results in better designed APIs and generally better software in my experience.

Wrote a full blog post some time ago explaining why the API First approach works: https://dev.to/epilot/why-we-design-apis-first-e85

The spec is used in runtime for routing and validation.

https://openapistack.co/docs/examples/building-apis/

> The average GraphQL API is definitely in better shape than the average REST API

Totally agree.

GraphQL tooling is generally just better. It enforces a Schema first workflow and thus more emphasis on conventions and design.

OpenAPI tends to be an after thought with teams building REST APIs. Swagger started out as a way to add docs and generate SDKs.

That was exactly my motivation for building openapi-stack. GraphQL-like tooling, but for teams using REST.

Cheers! Going from code first to schema first is definitely worth it in my experience! Especially when working in a team.

The nice thing is you already have an openapi spec, so it’s pretty trivial to eject from fastify swagger and switch to openapi-backend if you want!

Here’s an example of openapi-backend running on Fastify

https://github.com/openapistack/openapi-backend/tree/main/ex...

I think the point is, graphql apis tend to be so flexible that it’s easy to accidentally ship an API that allows clients to craft excessively heavy nested queries in a single request.

Supporting nested queries isn’t really a common thing in REST, and it’s simpler to rate limit clients by resource than query complexity.

I don’t really agree GraphQL is somehow more ”future proof” because it doesn’t use as many HTTP features.

It’s not like HTTP is going to go away in a while.

I find that AsyncAPI is a nice extension of OpenAPI/REST ideas if you need to go beyond request / response.

Speaking personally as a full stack engineer, unless the backend is completely trivial to implement I find it much faster and more efficient to write and iterate JSON schema while implementing frontend features than actually implement backend logic first.

Thank you for your encouraging words and insights!

There are indeed popular DSLs and code to openapi solutions out there. Many of which are easy to plug in to the openapi-stack libraries btw!

I guess I personally always found it frustrating to try to control the generated OpenAPI output using additional tooling and ended up preferring yaml + a visualisation tool as the api design workflow. (e.g. swagger editor)

But something like https://buildwithfern.com, or using zod as substitute for json schema may indeed be worth a try as a step before emitting openapi.

Thanks for the feedback!

There is a full interactive sandbox example on the front/landing page https://openapistack.co

But point taken, will make sure code examples are visible on the overview page

This project is precisely for devs who dislike codegen and want to just ship products fast.

1. Design your API in yaml 2. Run a mock API 3. Develop the App, iterate mock API 4. Implement backend and ship

No code generation needed. Generate types if you want.

Thanks for the encouraging words! So far it’s already nice to see these libraries being adopted slowly by more and more companies. Not nearly as big as graphql and trpc of course.

Love tRPC! For full stack typescript teams it’s the obvious way to go. Super simple and straightforward. OpenAPI or GraphQL are great though if you’re investing into APIs as a product

Agree. GraphQL is well mature by this point.

Yes! SOAP wsdl, but json

Good idea to add to the comparisons page!

The openapi-typescript package is a library for generating types from openapi spec, similar to the openapicmd typegen command provided by openapi-stack.

The new openapi-typescript-fetch seems similar to openapi-client-axios, but using fetch instead of axios for a more lightweight approach.

Both libraries are great and well aligned with goals of openapi-stack!

In addition to type generation and consuming APIs, https://openapistack.co provides tools for building and mocking API backends with the openapi-backend library, as well as a general cli tool to work with openapi files and invoke APIs via the command line.

The core mission of https://openapistack.co is to bring together tools for an end to end full stack toolkit for building and consuming typesafe REST APIs.