How do you make sure that the spec is in sync with the implementation?
Show HN: REST Alternative to GraphQL and tRPC
51–60 of 76 posts
Re: Show HN: REST Alternative to GraphQL and tRPC
#52How do you make sure that the spec is in sync with the implementation?
The spec is used in runtime for routing and validation.
Re: Show HN: REST Alternative to GraphQL and tRPC
#53GraphQL is well over a decade old. I'm not sure "tried and tested" is a meaningful contrast between the two approaches at this point, especially as it relates to API requests from the frontend. It's okay for people to choose REST just because they like it better, and/or aren't interested in learning something different.
GraphQL's first draft release was 8 years ago. [1]
It's first non-draft release was 5 years ago. [2]
It's first release under community governance was 2 years ago. [3]
[1] https://github.com/graphql/graphql-spec/releases/tag/July201...
[2] https://github.com/graphql/graphql-spec/releases/tag/June201...
[3] https://github.com/graphql/graphql-spec/releases/tag/October...
Re: Show HN: REST Alternative to GraphQL and tRPC
#54How do you make sure that the spec is in sync with the implementation?
The spec is used in runtime for routing and validation. https://openapistack.co/docs/examples/building-apis/
Thanks. I missed this part https://openapistack.co/docs/openapi-backend/typescript/ so the types are generated for the backend to use. We’ve used API first approach before, but it was very painful to keep the types in sync. Now we’re transitioning to FastAPI which allows to more or less create the OpenAPI types in code (via pydantic which can export the python types into OpenAPI schema).
We now follow a kind of hybrid approach in which the routes and types are created in code first, without actual implementation (just return 404). This auto generates the spec.yaml as well as any vendor code we might need (via client generator). I think this is quite a productive workflow as well because the type generation in code is more convenient than typing yaml by hand and everything is always in sync
Re: Show HN: REST Alternative to GraphQL and tRPC
#55Earlier quoted context omitted.
The spec is used in runtime for routing and validation. https://openapistack.co/docs/examples/building-apis/
Thanks. I missed this part https://openapistack.co/docs/openapi-backend/typescript/ so the types are generated for the backend to use. We’ve used API first approach before, but it was very painful to keep the types in sync. Now we’re transitioning to FastAPI which allows to more or less create the OpenAPI types in code (via pydantic which can export the python types into OpenAPI schema). We now follow a kind of hybri…
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
Re: Show HN: REST Alternative to GraphQL and tRPC
#56Earlier quoted context omitted.
The spec is used in runtime for routing and validation. https://openapistack.co/docs/examples/building-apis/
Thanks. I missed this part https://openapistack.co/docs/openapi-backend/typescript/ so the types are generated for the backend to use. We’ve used API first approach before, but it was very painful to keep the types in sync. Now we’re transitioning to FastAPI which allows to more or less create the OpenAPI types in code (via pydantic which can export the python types into OpenAPI schema). We now follow a kind of hybri…
Maybe I didn’t explain the process correctly, we do generate the spec first, it’s just that the tool we use for creating the spec is the code that will later contain the implementation.
Re: Show HN: REST Alternative to GraphQL and tRPC
#57GraphQL is well over a decade old. I'm not sure "tried and tested" is a meaningful contrast between the two approaches at this point, especially as it relates to API requests from the frontend. It's okay for people to choose REST just because they like it better, and/or aren't interested in learning something different.
GraphQL's first draft release was 8 years ago. [1] It's first non-draft release was 5 years ago. [2] It's first release under community governance was 2 years ago. [3] [1] https://github.com/graphql/graphql-spec/releases/tag/July201... [2] https://github.com/graphql/graphql-spec/releases/tag/June201... [3] https://github.com/graphql/graphql-spec/releases/tag/October...
I think I shipped my first production GraphQL server around this time 8 years ago, but by all accounts it was in use at Facebook a couple of years before it was opened up. So overall ~10 years old sounds right, though the released spec is a little different to the internal version that predates it.
Re: Show HN: REST Alternative to GraphQL and tRPC
#58What I really like with graphql that IMO all the other spec lack is a nice human readable format. When as a team you design a new API no way I am going to write openapi spec, but I can reason in GraphQL schema. Then each side takes the contract and go implement the frontend and the backend and it just works.
Auto generate the contract. That might be easier in some languages like TypeScript or Java, but it’s just done as part of the build.
Re: Show HN: REST Alternative to GraphQL and tRPC
#59What I really like with graphql that IMO all the other spec lack is a nice human readable format. When as a team you design a new API no way I am going to write openapi spec, but I can reason in GraphQL schema. Then each side takes the contract and go implement the frontend and the backend and it just works.
Auto generate the contract. That might be easier in some languages like TypeScript or Java, but it’s just done as part of the build.
You don’t actually want that.
Code should not inform design.
Design informs code.
Re: Show HN: REST Alternative to GraphQL and tRPC
#60Earlier quoted context omitted.
Thanks. I missed this part https://openapistack.co/docs/openapi-backend/typescript/ so the types are generated for the backend to use. We’ve used API first approach before, but it was very painful to keep the types in sync. Now we’re transitioning to FastAPI which allows to more or less create the OpenAPI types in code (via pydantic which can export the python types into OpenAPI schema). We now follow a kind of hybri…
Maybe I didn’t explain the process correctly, we do generate the spec first, it’s just that the tool we use for creating the spec is the code that will later contain the implementation.
Ah nice! Mind sharing what you’re using to generate the spec?