anttiviljami
Joined 11 years ago
Karma
197
Submissions
50
Member since
Oct 19
Recent submissions
Comment · 3 years ago
Thank you for the kind words!
Comment · 3 years ago
Ah nice! Mind sharing what you’re using to generate the spec?
Comment · 3 years ago
You don’t actually want that.
Code should not inform design.
Design informs code.
Comment · 3 years ago
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
Comment · 3 years ago
The spec is used in runtime for routing and validation.
Comment · 3 years ago
> 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.
Comment · 3 years ago
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...
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
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.
[ my public key: https://keybase.io/anttiviljami; my proof: https://keybase.io/anttiviljami/sigs/t1R43rnvDVkV9HdB5wRu8bVo9DqubY9dd9LrjQZBHkM ]