swagger-typescript-api VS graphql-spec

RESTful APIs via swagger-typescript-api

TypeScript API generator via Swagger scheme

You said it yourself — the “official” generator is awful and very hard to modify or extend (well, you didn’t say that, but I’m saying it) and while there are many alternatives, they’re not always easy to find. I had some success with swagger-typescript-api[1], but eventually got tired of it and wrote my own generator. Despite looking around quite a bit at what’s available, I never heard of openapi-codegen, which looks quite good.

[1]: https://github.com/acacode/swagger-typescript-api

A lot of APIs nowadays have a Swagger / OpenAPI spec. You can autogenerate types from that using tools like swagger-typescript-api.

With such a contract your BE team should provide a https://swagger.io/tools/swagger-ui/ where the API definition can easily be viewed and tested. Also you can use generators to basically generate a boilerplate (types for all models, functions for all requests) for the entire API based on a contract: https://github.com/acacode/swagger-typescript-api This his already saved me months of work.. great tool.

If your backend is using Swagger, I'd highly recommend using the package swagger-typescript-api. It auto-generates your types and endpoints for you, based on a swagger.json file, which then simplifies where I store my API calls. The flexibility of this is that I can use these API calls in components, classes, Vuex, etc., and I'm not tied to something that I have to maintain as a UI dev.

If your backend is able to generate Swagger/OpenAPI JSON, you can use https://github.com/acacode/swagger-typescript-api to generate both TypeScript interfaces and an API client from the Swagger JSON.

GraphQL's first draft release was 8 years ago. [1]

It's first non-draft release was 5 years ago. [2]

It's first release under a community foundation was 2 years ago. [3]

[1] https://spec.graphql.org/July2015/

[2] https://github.com/graphql/graphql-spec/releases/tag/June201...

[3] https://github.com/graphql/graphql-spec/releases/tag/October...

I'm a big believer in GraphQL (in fact, at time of writing I'm #2 contributor to the GraphQL spec itself) so it pains me that a tool I built doesn't always have easy ways to achieve the "versionless schema" design that GraphQL encourages when it comes to making significant breaking changes to your underlying database tables. (Personally, I think you should aim for your database schema itself to be versionless, but this is not always possible.) Of course you can build your PostGraphile schema over views instead of tables, but views have their own problems that I won't go into here…

I created a proposal for Map type but didn’t make it through.

https://github.com/graphql/graphql-spec/pull/888

The issue with GraphQL is it tries to appease too many masters.

Similar to jsx. The language isn’t evolving.

The good thing is the spec is (almost) frozen, so there’s many implementations, the bad is it can encompass the flexibility of json schema can do.

Longer thread - Subscriptions RFC: Are Subscriptions and Live Queries the same thing?

https://github.com/graphql/graphql-spec/issues/284

You’ve probably figured it out by now, but for others who may be in a similar position; GraphQL is a specification (with various implementations) and you can read up on the spec here: https://spec.graphql.org/

If you're asking whether GraphQL supports anonymous objects that can be arbitrarily nested then no, it doesn't.

show this feature request some love https://github.com/graphql/graphql-spec/issues/174

* Performance: It's just hard to track down what makes an operation slow. The waterfall nature of resolvers is a big contributor

[1] https://github.com/graphql/graphql-spec/issues/488

:::note GraphQL Union is available for Types only, not for Inputs. However, the oneOf directive will bridge the gap in the future.