Viewing profile — anttiviljami
anttiviljami
HN member- Joined
- Mon, Oct 19, 2015, 6:02 AM UTC
- HN karma
- 197
- Public activity
- 50 items
- HN profile
- View on Hacker News ↗
About anttiviljami
[ my public key: https://keybase.io/anttiviljami; my proof: https://keybase.io/anttiviljami/sigs/t1R43rnvDVkV9HdB5wRu8bVo9DqubY9dd9LrjQZBHkM ]
Recent public activity
- story
- story
- story
- story
- story
-
comment
Comment #37836408
Thank you for the kind words!
-
comment
Comment #37836013
Ah nice! Mind sharing what you’re using to generate the spec?
-
comment
Comment #37835999
You don’t actually want that. Code should not inform design. Design informs code.
-
comment
Comment #37835718
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 benefit…
-
comment
Comment #37835469
The spec is used in runtime for routing and validation. https://openapistack.co/docs/examples/building-apis/
-
comment
Comment #37834778
> 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 t…
-
comment
Comment #37834719
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’…
-
comment
Comment #37834653
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 reque…
-
comment
Comment #37834381
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…
-
comment
Comment #37834321
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 …
-
comment
Comment #37834026
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 lib…
-
comment
Comment #37833623
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 …
-
comment
Comment #37831886
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. Imp…
-
comment
Comment #37831612
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.
-
comment
Comment #37831578
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 prod…
-
comment
Comment #37831423
Agree. GraphQL is well mature by this point.
-
comment
Comment #37831159
Yes! SOAP wsdl, but json
-
comment
Comment #37830762
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 …
- story
- story