5 ms·
If you generate TypeScript types from OpenAPI specs then you get contracts for both directions. There is no problem here for GraphQL to solve.
by lateforwork 10mo ago
If you generate TypeScript types from OpenAPI specs then you get contracts for both directions. There is no problem here for GraphQL to solve.
- komali2 10mo agoDiscovering Kubb was a game changer for me last year.
- HumanOstrich 10mo agoThanks for mentioning this. I always find it unsettling when I've researched solutions for something and only find a better option from a random HN comment. Site: https://kubb.dev/ https://kubb.dev/
- bakugo 10mo agoThis project seems to be mostly AI generated, so keep that in mind before replacing any existing solutions.
- 0x696C6961 10mo agoNo it doesn't
- bakugo 10mo agoDid you see the repo? https://github.com/kubb-labs/kubb https://github.com/kubb-labs/kubb Most of the commits and pull requests are AI. Issues are also seemingly being handled by AI with minimal human intervention.
- JAlexoid 10mo agoAI assisted, not necessarily generated. And yes, current models are amazing at reducing time it takes to push out a feature or fix a bug. I wouldn't even consider working at a company that banned use of AI to help me write code. PS: It's also irrelevant to whether it's AI generated or not, what matters is if it works and is secure.
- bakugo 10mo ago> what matters is if it works and is secure. How do you know it works and is secure if a lot of the code likely hasn't ever been read and understood by a human?
- JAlexoid 10mo agoThere are literally users here that say that it works. And you presume that the code hasn't been read or understood by a human. AI doesn't click merge on a PR, so it's highly likely that the code has been read by a human.
- komali2 10mo agoI've had a PR on Kubb that was taken over by a human maintainer. They then closed my PR and reimplemented my fix in their own PR. So, the project is human enough to annoy me, anyway.
- WickyNilliams 10mo agoFwiw I tried every tool imaginable a few years ago including kubb, (which I think I contributed to while testing things out) The only mature, correct, fast option with a fixed cost (since it mostly exists at the type level meaning it doesn't scale your bundle with your API) was openapi-ts. I am not affiliated other than a previous happy user, though I did make some PRs while using it https://openapi-ts.dev/ https://openapi-ts.dev/
- c-hendricks 10mo agoWhat about the whole "graph" part? Are there any openapi libraries that deal with that?
- lateforwork 10mo agoOpenAPI definition includes class hierarchy as well. You can use tools to generate TypeScript type definitions from that.
- c-hendricks 10mo agoAnd the fetching in a single request?
- lateforwork 10mo agoThe question I answered was regarding contracts. Fetching in a single request can be handled by your BFF.
- iterateoften 10mo agoSo make things more complicated than gql?
- 0x696C6961 10mo agogql is clearly the more complicated of the two ...
- iterateoften 10mo agoa gql server in python is about as simple as you can possibly go to exposing data via an API. You can use a raw http client to query it.
- JAlexoid 10mo ago
- deleted 10mo ago[deleted]
- iterateoften 10mo agoGraphql solves the problem. There is no problem here for openapi to solve. See how that works?
- thayne 10mo agoOpenapi is older than graphql. But the point is that that benefit is not unique to graphql, so by itself, that is not a compelling reason to choose graphql over something else.
- tt_dev 10mo agoplus now you have 2 sources of truth
- iterateoften 10mo ago? I have a single source of truth in the gql schema. My frontend calls are generated from backend schema and type checked against it.
- iterateoften 10mo agoYeah that was one point of many of the benefits of the parent.
- WickyNilliams 10mo agoThis is very much possible, and I have done it, and it works great once it's all wired up. But OpenAPI is verbose to the point of absurdity. You can't feasibly write it by hand. So you can't do schema first development. You need an open API compatible lib for authoring your API, you need some tooling to generate the schema from the code, then you need another tool to generate types from the schema. Each step tends to implement the spec to varying degrees, creating gaps in types, or just outright failing. Fwiw I tried many, many tools to generate the typescript from the schema. Most resulted in horrendous, bloated code. The official generators especially. Many others just choked on a complex schema, or used basic string concatenation to output the typescript leading to invalid code. Additionally the cost of the generated code scales with the schema size, which can mean shipping huge chunks of code to the client as your API evolves The tool I will wholeheartedly recommend (and which I am unaffiliated beside making a few PRs) is openapi-ts. It is fast and correct, and you pay a fixed cost - there's a fetch wrapper for runtime and everything else exists at the type level. I was kinda surprised how bad a lot of the tooling was considering how mature OpenAPI is. Perhaps it's advanced in the last year or so, when I stopped working on the project where I had to do this. https://openapi-ts.dev/ https://openapi-ts.dev/
- 0x696C6961 10mo agoI write all of my openapi specs by hand. It's not hard.
- WickyNilliams 10mo agoI imagine you are very much in the minority. A simple hello world is like a screen full of yaml. The equivalent in graphql (or typespec which I always wanted to try as an authoring format for openapi https://typespec.io/ https://typespec.io/) would be a few lines
- 0x696C6961 10mo agoBeing verbose doesn't make it difficult.
- bastawhiz 10mo agotRPC sort of does this (there's no spec, but you don't need a spec because the interface is managed by tRPC on both sides). But it loses the real main defining quality of gql: not needing subsequent requests. If I need more information about a resource that an endpoint exposes, I need another request. If I'm looking at a podcast episode, I might want to know the podcast network that the show belongs to. So first I have to look up the podcast from the id on the episode. Then I have to look up the network by the id on the podcast. Now, two requests later, I can get the network details. GQL gives that to me in one query, and the fundamental properties of what makes GQL GQL are what enables that. Yes, you can jam podcast data on the episode, and network data inside of that. But now I need a way to not request all that data so I'm not fetching it in all the places where I don't need it. So maybe you have an "expand" parameter: this is what Stripe does. And really, you've just invented a watered down, bespoke GraphQL.
- lateforwork 10mo agoIs dealing with GQL easier than implementing a BFF? There may be cases where that is true, but it is not always true.
- bastawhiz 10mo agoI think BFF works at a small scale, but that's true with any framework. Building a one off handful of endpoints will always be less work than putting a framework in place and building against it. GQL has a pretty substantial up front cost, undeniably. But you hopefully balance that with the benefit you'd get from it.
- mixedCase 10mo agoIf you generate OpenAPI specs, and clients, and server type definitions from a declarative API definition made with Effect's own @effect/platform, it solves even more things in a nicer, more robust fashion.