graphql-request VS graphql-spec

The aws-sigv4-fetch package can be integrated into GraphQL libraries like graphql-request. For example, you can pass the signedFetch function as the custom fetch option:

For Next.js projects, one of the options can be the typescript-graphql-request plugin. Under the hood this plugin works with the graphql-request library — a minimal, flexible, and easy-to-use GraphQL client. With typescript-graphql-request, we generate an SDK that is fully typed and allowing us to make strongly-typed GraphQL requests. This nicely integrates with data fetching in Next.js Server Components, enabling us to pre-render pages with data from Storyblok.

but i don't want to use that external library

An example of a Snowflake API request using JavaScript. This example uses the graphql-request library to issue the actual GraphQL request. Install the dependency:

I mentioned already we can use just about any client want when fetching GraphQL data. Prisma's graphql-request is a simple and lightweight option, and that is what I’ve used here.

To do this, you will make use of a tool called GraphQL Codegen to generate TypeScript types based on the GraphQL schema Sanity provides. You will then use graphql-request to actually fetch the data.

What about https://github.com/prisma-labs/graphql-request that has 4.8k starts / 254 forks?

If you don't want to use Apollo, I suggest using codegen + graphql-request. There is a codegen plugin for graphql-request that auto generates a typesafe client sdk with all your queries as methods on the graphql-request client. Super clean and lightweight. https://github.com/prisma-labs/graphql-request

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.