5 ms·

Show HN: TypeAPI – An OpenAPI alternative optimized for code generation

55 points by k42b3 3y ago

luminati 3y ago
Check out Fern / my software friend was raving about. It solves some of the problems around OpenApi around codegen but maintains compatibility with open api https://news.ycombinator.com/item?id=34346428 https://news.ycombinator.com/item?id=34346428
tough 3y ago
Looks interesting My current way of achieving codegen sdk w openapi is using the readme/api sdk framework maker, if you have good specs it works pretty great. Add tests to the sdk, and you're both testing your openapi implementation, docs, and sdk in one test
- digdugdirk 3y ago
  I searched for what you're describing here, and I don't believe I found the service you're describing - I'm not seeing how it could generate code. Would you mind expanding on what you're talking about here? It sounds intriguing, I'm just not following.
  - tough 3y ago
    https://github.com/readmeio/api https://github.com/readmeio/api In my case I had a backend with annotatted swagger docs, which generated the OpenAPI spec from it using https://www.npmjs.com/package/next-swagger-doc https://www.npmjs.com/package/next-swagger-doc but basically it will take any openapi spec url, and generate an SDK for it. So you'll get your named routes for free as sdk a la mySDK.allUsers() or mySDK.findUser(id) or whatever your openapi spec exposes
lyjackal 3y ago
I see this is an alternative to open api, but reading through the site docs, I’m not clear on what it’s adding. There’s a number is code gen tools already for open api.
solarkraft 3y ago
What does this do better than OpenAPI? OpenAPI has many code generators. And more importantly: Many servers support it, making it really easy to implement. So why would I chose this? How do I even implement it on the server? There's a lot of talk about client libraries, even with OpenAPI as an output format (nice!), but what about the server side?
- lyu07282 3y ago
  Don't see much of a reason to use it, its also important to mention that code generation goes both ways. You can generate the schema from a service in FastAPI or Spring and generate the client code from that schema. There are already existing code and schema generators for almost every strongly typed language and web framework, including Go, Scala, Typescript, Java and Rust. You never have to actually write any OpenAPI schema yourself nowadays. This also doesn't seem to address the one problem I always had with OpenAPI: Polymorphic types. Mapping an OpenAPI schema between strongly typed languages like Scala or TypeScript. OpenAPI 3 supports this now with discriminators but most code or schema generators aren't supporting this very well or at all yet. https://swagger.io/docs/specification/data-models/inheritance-and-polymorphism/ https://swagger.io/docs/specification/data-models/inheritanc...
  - klysm 3y ago
    I share the pain of things not supporting discriminated unions. I had to do some very hacky things to make it work for the API I’m developing at the moment. When it does work though it is very very nice
eurasiantiger 3y ago
This is reinventing the type introspection features of GraphQL.
beardedwizard 3y ago
Do we really need another api spec? What does this do better than swagger? Very disingenuous to compare this to an LLM, it has none of the advantages and fails to differentiate itself from many preceding peers.
manojlds 3y ago
> Our goal is to remove the need to develop custom client SDKs for an REST API. Aren't there enough tools already for OpenAPI to do this?
- pixelrevision 3y ago
  Yes. And the tooling is pretty straightforward to plug into generally if you need to tweak things. I’ve found that the biggest barrier here is generally not in openapi tooling, but in getting people to take time out to leverage it. This is one of those places that having lots of options and alternatives typically makes things worse.
- throwawaymaths 3y ago
  to be fair a lot of them are absolutely terrible. The top .NET one seems to be maintained by very unprofessional amateurs, has ~> 1000 open issues, some open for years, and definitely doesn't do multipart encoding correctly. Not that problem would be solved by having yet another spec.
  - klysm 3y ago
    Yeah the .NET ecosystem around openapi is horrible. I at least want the typescript client story to be good
    - solarkraft 3y ago
      > Yeah the .NET ecosystem (...) is horrible :-) That's how it felt when I was developing for it. But that's because I was interested in cool new things, not decade-old, establish enterprise stuff. I suppose it has changed a bit in recent years, but it still doesn't exactly follow trends very enthusiastically. Which can be a good thing. But also means tooling around legitimately useful new things can be quite lacking.
      - klysm 3y ago
        I wouldn’t consider REST API tech to be very trendy, it’s kind of old wave and I would expect a good story for it.
agluszak 3y ago
Seems similar to Smithy[1]. Amazon uses it to generate SDKs for AWS. 1 - https://smithy.io/2.0/index.html https://smithy.io/2.0/index.html
- Kinrany 3y ago
  Anyone tried using it, HN?
jensneuse 3y ago
We went into another direction, leveraging the existing ecosystem instead of re-inventing the wheel. Although I appreciate the effort of improving the DX for REST APIs, I think the OpenAPI ecosystem is very strong and established. Contrary to this approach, we (https://WunderGraph.com https://WunderGraph.com) ingest one or more OpenAPI and GraphQL apis and combine them into a backend for frontend. We have code generators for all major frontend frameworks, like react, svelte, Vue, solid, astro, etc... These don't just make calling APIs type-safe but also handle authentication, etc... The BFF approach allows us to securely inject API keys or add a middleware using Typescript. I'm curious what people think of this approach. Our users don't usually integrate one or two APIs but rather 20 or more. I guess it would be quite expensive if you had to write a custom specification for each service.
zeedude 3y ago
The manifold project integrates code gen directly into the compiler. The GraphQL[1] module is amazing. The JSON[2] module for REST looks similarly impressive, but I haven’t personally used it. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-graphql https://github.com/manifold-systems/manifold/tree/master/man... 2. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-json https://github.com/manifold-systems/manifold/tree/master/man...

55 points by k42b3 3y ago

Check out Fern / my software friend was raving about. It solves some of the problems around OpenApi around codegen but maintains compatibility with open api https://news.ycombinator.com/item?id=34346428 https://news.ycombinator.com/item?id=34346428

tough 3y ago

Looks interesting My current way of achieving codegen sdk w openapi is using the readme/api sdk framework maker, if you have good specs it works pretty great. Add tests to the sdk, and you're both testing your openapi implementation, docs, and sdk in one test

digdugdirk 3y ago
I searched for what you're describing here, and I don't believe I found the service you're describing - I'm not seeing how it could generate code. Would you mind expanding on what you're talking about here? It sounds intriguing, I'm just not following.
- tough 3y ago
  https://github.com/readmeio/api https://github.com/readmeio/api In my case I had a backend with annotatted swagger docs, which generated the OpenAPI spec from it using https://www.npmjs.com/package/next-swagger-doc https://www.npmjs.com/package/next-swagger-doc but basically it will take any openapi spec url, and generate an SDK for it. So you'll get your named routes for free as sdk a la mySDK.allUsers() or mySDK.findUser(id) or whatever your openapi spec exposes

lyjackal 3y ago

I see this is an alternative to open api, but reading through the site docs, I’m not clear on what it’s adding. There’s a number is code gen tools already for open api.

solarkraft 3y ago

What does this do better than OpenAPI? OpenAPI has many code generators. And more importantly: Many servers support it, making it really easy to implement. So why would I chose this? How do I even implement it on the server? There's a lot of talk about client libraries, even with OpenAPI as an output format (nice!), but what about the server side?

lyu07282 3y ago
Don't see much of a reason to use it, its also important to mention that code generation goes both ways. You can generate the schema from a service in FastAPI or Spring and generate the client code from that schema. There are already existing code and schema generators for almost every strongly typed language and web framework, including Go, Scala, Typescript, Java and Rust. You never have to actually write any OpenAPI schema yourself nowadays. This also doesn't seem to address the one problem I always had with OpenAPI: Polymorphic types. Mapping an OpenAPI schema between strongly typed languages like Scala or TypeScript. OpenAPI 3 supports this now with discriminators but most code or schema generators aren't supporting this very well or at all yet. https://swagger.io/docs/specification/data-models/inheritance-and-polymorphism/ https://swagger.io/docs/specification/data-models/inheritanc...
- klysm 3y ago
  I share the pain of things not supporting discriminated unions. I had to do some very hacky things to make it work for the API I’m developing at the moment. When it does work though it is very very nice

eurasiantiger 3y ago

This is reinventing the type introspection features of GraphQL.

beardedwizard 3y ago

Do we really need another api spec? What does this do better than swagger? Very disingenuous to compare this to an LLM, it has none of the advantages and fails to differentiate itself from many preceding peers.

manojlds 3y ago

> Our goal is to remove the need to develop custom client SDKs for an REST API. Aren't there enough tools already for OpenAPI to do this?

pixelrevision 3y ago
Yes. And the tooling is pretty straightforward to plug into generally if you need to tweak things. I’ve found that the biggest barrier here is generally not in openapi tooling, but in getting people to take time out to leverage it. This is one of those places that having lots of options and alternatives typically makes things worse.
throwawaymaths 3y ago
to be fair a lot of them are absolutely terrible. The top .NET one seems to be maintained by very unprofessional amateurs, has ~> 1000 open issues, some open for years, and definitely doesn't do multipart encoding correctly. Not that problem would be solved by having yet another spec.
- klysm 3y ago
  Yeah the .NET ecosystem around openapi is horrible. I at least want the typescript client story to be good
  - solarkraft 3y ago
    > Yeah the .NET ecosystem (...) is horrible :-) That's how it felt when I was developing for it. But that's because I was interested in cool new things, not decade-old, establish enterprise stuff. I suppose it has changed a bit in recent years, but it still doesn't exactly follow trends very enthusiastically. Which can be a good thing. But also means tooling around legitimately useful new things can be quite lacking.
    - klysm 3y ago
      I wouldn’t consider REST API tech to be very trendy, it’s kind of old wave and I would expect a good story for it.

agluszak 3y ago

Seems similar to Smithy[1]. Amazon uses it to generate SDKs for AWS. 1 - https://smithy.io/2.0/index.html https://smithy.io/2.0/index.html

Kinrany 3y ago
Anyone tried using it, HN?

jensneuse 3y ago

We went into another direction, leveraging the existing ecosystem instead of re-inventing the wheel. Although I appreciate the effort of improving the DX for REST APIs, I think the OpenAPI ecosystem is very strong and established. Contrary to this approach, we (https://WunderGraph.com https://WunderGraph.com) ingest one or more OpenAPI and GraphQL apis and combine them into a backend for frontend. We have code generators for all major frontend frameworks, like react, svelte, Vue, solid, astro, etc... These don't just make calling APIs type-safe but also handle authentication, etc... The BFF approach allows us to securely inject API keys or add a middleware using Typescript. I'm curious what people think of this approach. Our users don't usually integrate one or two APIs but rather 20 or more. I guess it would be quite expensive if you had to write a custom specification for each service.

zeedude 3y ago

The manifold project integrates code gen directly into the compiler. The GraphQL[1] module is amazing. The JSON[2] module for REST looks similarly impressive, but I haven’t personally used it. 1. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-graphql https://github.com/manifold-systems/manifold/tree/master/man... 2. https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-json https://github.com/manifold-systems/manifold/tree/master/man...