explore.opensauced.pizza VS graphiql

Following up on my post last week about the first aspect of a PR contribution to explore.opensauced.pizza, I'm going to talk about the second aspect of that PR - joyfully implemented as an HTML element (I really like these). So as I mentioned in the post before: We also wanted to let users quickly reproduce the queries we use in Open Sauced... this way, when its time to iterate on an existing feature, there's very little friction to finding that starting point. About a week before this, I had been working on a PR for tabulating the GraphQL API calls in the Open Sauced docs, so a lot of the details about API calls were pretty fresh. Side note, if you want line breaks inside a table in markdown, you'll need to use a element, but don't forget to use a self closing tag in the event your markdown file is parsed and used by a tool like Docusaurus, :cough, cough:. Shout out to @0vortex for cleaning up my messes! Anywho, after looking around at GraphiQL implementations, I came to the belief that most define a fetcher with the correct API endpoint/headers and otherwise things just work out of the box. Once the introspection query is run and the schema parsed and validated, the combination of the Explorer pane and the Query Editor pane make it really easy to build up and run valid queries. There's also a common pattern of using a default query so when the client first loads up, the query is pre-populated. What these two don't help with is reproducing and working with multiple queries. The approach I wound up taking was to store all of the dynamic queries in an object, and then generate a element in the toolbar, which updates the query contents and query name with the onchange event. Here's the piece of code that does the job...

Flow state is a rare treat for me these days. The last time I can remember being in that zone was working on a GraphiQL implementation for Open Sauced, https://explore.opensauced.pizza. The Open Sauced project makes use of OneGraph, to handle authentication and persisted query features in working with the GitHub GraphQL API. This was the first I had worked on any kind of GraphiQL implementation, so for those of you at the point I was at then, GraphiQL is an Open Source project that can be used to interact with a GraphQL API in an ad-hoc and dynamic way, allowing a developer to iterate quickly on features from a data retrieval standpoint. This post is about the PR #2 in the repo.

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