[HN Gopher] Show HN: TypeAPI - An OpenAPI alternative optimized ...
___________________________________________________________________
Show HN: TypeAPI - An OpenAPI alternative optimized for code
generation
Author : k42b3
Score : 46 points
Date : 2023-04-16 10:44 UTC (12 hours ago)
(HTM) web link (typeapi.org)
(TXT) w3m dump (typeapi.org)
| manojlds wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| manojlds wrote:
| This one doesn't even mention .NET in the generators.
| klysm wrote:
| Yeah the .NET ecosystem around openapi is horrible. I at
| least want the typescript client story to be good
| jensneuse wrote:
| 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) 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.
| agluszak wrote:
| Seems similar to Smithy[1]. Amazon uses it to generate SDKs for
| AWS.
|
| 1 - https://smithy.io/2.0/index.html
| tough wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/inheritanc...
| klysm wrote:
| 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 wrote:
| This is reinventing the type introspection features of GraphQL.
| beardedwizard wrote:
| 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.
| zeedude wrote:
| 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/man...
|
| 2. https://github.com/manifold-
| systems/manifold/tree/master/man...
___________________________________________________________________
(page generated 2023-04-16 23:01 UTC)