Live data from Hacker News

Viewing profile — anttiviljami

anttiviljami

HN member
Joined
Mon, Oct 19, 2015, 6:02 AM UTC
HN karma
197
Public activity
50 items

About anttiviljami

Be kind.

[ my public key: https://keybase.io/anttiviljami; my proof: https://keybase.io/anttiviljami/sigs/t1R43rnvDVkV9HdB5wRu8bVo9DqubY9dd9LrjQZBHkM ]

Recent public activity

  1. story
  2. story
  3. story
  4. story
  5. story
  6. comment
    Comment #37836408

    Thank you for the kind words!

  7. comment
    Comment #37836013

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

  8. comment
    Comment #37835999

    You don’t actually want that. Code should not inform design. Design informs code.

  9. 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…

  10. comment
    Comment #37835469

    The spec is used in runtime for routing and validation. https://openapistack.co/docs/examples/building-apis/

  11. 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…

  12. 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’…

  13. 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…

  14. 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…

  15. 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 …

  16. 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…

  17. 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 …

  18. 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…

  19. 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.

  20. 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…

  21. comment
    Comment #37831423

    Agree. GraphQL is well mature by this point.

  22. comment
    Comment #37831159

    Yes! SOAP wsdl, but json

  23. 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 …

  24. story
  25. story