graphql-over-http VS graphiql

Another major pain is the fact that operation names and HTTP codes are often hidden in request bodies which makes it really hard to see what is going on in standard monitoring tools. It's possible to write some converter but it's beyond me why some people decided that requests which failed on the server respond with status 200. GraphQL spec doesn't define how it should behave, there's only a proposal (https://github.com/graphql/graphql-over-http)

The GraphQL over HTTP specification states the following:

However, if you are doing GraphQL subscriptions over Server Sent Events (HTTP) (which is currently not part of the GraphQL over HTTP specification), the data flow is only from server to client. So each operation must be a separate request, which should be no problem when using HTTP/2, as the browser connection limit is not hit so fast (There are also workarounds to this if you cannot ise HTTP/2).

Complementary to the note, you can learn more about GraphQL over HTTP in the specification over here: https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md

GraphQL-spec, GraphQL-over-HTTP: guarantees your GraphQL API to work with all existing GraphQL clients (Apollo, Relay, URQL, and more).

Note: While GraphQL can be done over almost any protocol, this article focuses on the most commonly used protocol GraphQL over HTTP. However, most knowledge can be transferred to other protocols such as GraphQL over WebSockets or other more exotic ones.

There is also the GraphQL over HTTP Specification repository https://github.com/graphql/graphql-over-http

graphql-sse is a reference implementation of the GraphQL over Server-Sent Events Protocol aiming to become a part of the GraphQL over HTTP standard.

With no further ado - I humbly introduce graphql-ws. A coherent, feature-full, zero-dependency, plug-n-play, lazy, simple, server and client implementation of the new, security first GraphQL over WebSocket Protocol with full support for all 3 GraphQL operations: Queries, Mutations and Subscriptions. The protocol aims to be standardised and become a part of GraphQL with the help of the foundation’s GraphQL over HTTP work group.

You could additionally also choose a specific HTTP code for that scenario (although that would contradict the official GraphQL over HTTP spec https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md).

> FYI, GraphiQL is deprecated, GraphQL Playground is a good alternative.

You have this backwards.

https://github.com/graphql/graphql-playground/issues/1366#is...

https://github.com/graphql/graphiql

GraphQL is declarative and self-documenting by nature. There’s a single endpoint, and all available data, relationships, and APIs can be explored and consumed by client teams (via the GraphiQL interface or just Introspection) without constantly going back and forth with backend teams.

GraphiQL is one of the most well-known GraphQL IDEs. Originally developed by Facebook, it is an in-browser tool that enables developers to write, validate, and test GraphQL queries. It is open-source and can be integrated into any project that uses GraphQL. Recently, GraphiQL has been revamped with a new UI and several new features as you can read in ths blog post I wrote earlier.

Nice! I think you might like it.

Ah yeah, that does take a while to unpack. I think a lot of the complexity there is dealing with a non-react library and the dynamic import(s). Binding non-react libraries can be a bit rough.

I do think it's a good example to show the big advantage of hooks, if you look at the use of the hook, super clean: https://github.com/graphql/graphiql/blob/50674292c55eadf0e61...

Great way to contain complexity and make usage really clean and simple!

Graphiql: https://github.com/graphql/graphiql

After GraphQL Playground became part of the GraphQL Foundation, the need for having just one GraphQL IDE became more important. So the GraphQL Foundation decided to merge GraphiQL and GraphQL Playground into one tool. GraphiQL 1 relied on major tech debt and multiple dependencies that were outdated and hard to maintain. With the merge of GraphiQL and GraphQL Playground, the GraphQL Foundation decided to create a new version of GraphiQL, which is now called GraphiQL 2. The design and creation of GraphiQL 2 was all documented in Github.

#3: As I mentioned above, we use GraphQL Code Generator for generating TypeScript types and composables, as well as type checking our queries against the schema. This results in fully type-safe code from the back-end all the way to the front-end. As far as editor extensions go, the GraphQL: Language Feature Support VSCode extension should work fine, I use the language server part of that extension with Neovim. It provides autocompletion based on the schema and diagnostics. It looks like it might not work in .vue files though.

OneGraphiQL is a data explorer that allows us to build up our GraphQL queries and mutations. It is the OneGraph implementation of GraphiQL, which can be used with any GraphQL endpoint. GraphiQL is the perfect way to discover the different things we can request. It is generated from the GraphQL schema and provides helpful documentation for the graph's queries, mutations and types. Additionally, it can intelligently suggest options while we are building our queries and mutations.

If this is a critical functionality, you could raise an issue (with proper reasons why it is important) for sort support either in graphql-js or GraphiQL (guessing this would be a better place) repositories.