graphiql VS graphql-multipart-request-spec

> 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.

The GraphQL specification itself doesn't natively support file uploads, so the solution typically involves using extensions or additional libraries. The easiest and most straightforward way is by converting the file to Base64 before sending it to the server, you can include it as a string in the GraphQL request. This offcourse has a downside, it can increase the payload size, so it may not be the most efficient solution for large files. Other options that involve using extensions or additional libraries are using GraphQL multipart request specification and Apollo Server with Apollo Upload Client

Also, we manage to upload files via GraphQL just fine. Turns out nothing prevents you from putting a GraphQL query in a multipart form. Frameworks support this just fine, and if not, just write your own middleware, it's not even that hard.

There is a specification (and implementation) for sending files through GraphQL. https://github.com/jaydenseric/graphql-multipart-request-spec

We figured out that it was possible to reference a file several times by implementing the reference spec (https://github.com/jaydenseric/graphql-multipart-request-spec) for both a client and a server. We have no record of this vulnerability used in the wild, but we know for sure that a lot of popular projects on GitHub are vulnerable.

The GraphQL multipart specification describes how to implement file uploads in GraphQL. While usual GraphQL queries are sent as application/json, file uploads are sent as multipart/form-data. This means that the HTTP request body has multiple parts, and their functions, described in the specification, can be summarized as follows:

Hey, graphql-upload works on top of the graphql-multipart-request-spec, of which you can find the specification here.

In this article you will learn the widely accepted method of implementing file upload which is becoming increasingly popular in new apps. The technique follows the specification by @jaydenseric.

GraphQL-Multipart-Request: enables great file upload support.

Multipart File Uploads ✔️

One important thing which GraphQL Spec did not discuss about is a way to transmit files over the wire when using GraphQL. This is where GraphQL Upload comes in. While not an official spec from GraphQL foundation, Jayden had done a great job to put together a multi part spec to address exactly this problem.