V2 monaco rewrite - Needs Maintainers & Contributors! about graphql-playground

[timsuchanek]

Hey everyone, a quick update here:
GraphiQL 1 will soon have tabs.
We just had the GraphiQL WG meeting. Recording coming soon.

We have just agreed on a new design for the new GraphiQL 2, as proposed here.

With the tabs, we're basically getting to feature parity between GraphiQL and the Playground.

I suggest, that we leave the playground for now as it is, as GraphiQL will cover the same needs moving forward.
Once we have the GraphiQL 2 out, let's reassess, but I think it would make more sense to potentially launch a Playground v2, which is either re-exporting or reusing the GraphiQL implementation.

[BeauBouchard]

@acao and @jspizziri I am interested in being a maintainer.

If there are still opportunities to improve this repo and prioritize work I would be happy to help.

[asvishnyakov]

@timsuchanek While there is message about future of this project in README, I think it's unclear that this project is unmaintained and recommend to use GraphiQL instead. May you please move repository to "archived" / "no longer actively maintained" mode and add more visible project status indication in README?

[jspizziri]

GraphQL Playground & GraphiQL Are No Longer Merging

We've decided it no longer makes sense to merge the projects, though they will continue to use tons of shared logic in the form of the editor mode. It made sense at the time that Prisma offered playground to us, but it's clear the community wants to move this project forward.

Just for clarity (given the above linked issue)

[acao]

@dotansimha ^^ !! :)

[AaronNGray]

@acao, @timsuchanek is it possible to get Playground installing/building again theres multiple versioning issues, as I need a graphql queryer that does graphql-ws and I need it like yesterday. So if it would be possible to get it building again and with @ardatan's pull request #1295 even as a branch it would be great !

[acao]

One of the most confusing parts about maintaining this repository is that many issues are for forks of playground such as apollo’s fork (which has issues disabled), or embedded implementations in various frameworks or platforms with edge case or outdated implementations.

it deserves a dedicated team!

[dotansimha]

fyi @n1ru4l ;)

[spencerwilson]

I suggest, that we leave the playground for now as it is, as GraphiQL will cover the same needs moving forward.
Once we have the GraphiQL 2 out, let's reassess, but I think it would make more sense to potentially launch a Playground v2, which is either re-exporting or reusing the GraphiQL implementation.

Just an FYI, @timsuchanek , that GraphiQL 2 has been released: https://github.com/graphql/graphiql/releases/tag/graphiql%402.0.0

[dcunited001]

I understand that most of the GraphQL ecosystem tooling is cloud native to supports CI, collaboration and other use cases. However, I'm having some issues running queries on Github & Upwork.

Can someone in the GraphQL world consider allowing credentials for API tokens to be passed into a GraphQL IDE on initialization using either:

• environment variable
• file/descriptor redirection
• the UNIX pass tool?

On Linux (without a proper "desktop environment), things like gnome-keyring aren't guaranteed, which could be problematic when it comes to Electron Apps that handle API Tokens, see here on archwiki or this issue or the VS Code docs. After looking at that issue, I think would encounter that issue on my Guix install, but maybe not my Arch desktop. This is possible for Electron apps on other OS's where an app's developer doesn't use the keychain API's (like OSX Keychain or Android Key Storage.

I've now tried the following (and perhaps others). They are all electron apps or web apps.

• GraphiQL
• Altair
• Postman
• Insomia

Whether this API token storage is a problem depends on how an Electron app integrates with the desktop and what calls it uses to persist data. I don't want to persist data, but none of the docs for any app makes clear how data is stored. Also, I should definitely not have to store my API tokens on a server. I'm sure this would be abundantly obvious if you had copious experience with Electron... I got sick of the frontend world after learning Angular/Ionic/Grunt/Gulp/Webpack/etc/etc ... none of my knowledge remained relevant for long enough to ever get a job. I'm not looking forward to a deep dive on Electron because I know what it will be like: build customization everywhere and obfuscation of implementation. There are a few electron apps I use and I'd really prefer to not know how the sausage is made.

For each GraphQL IDE app (and even the GraphQL website), the docs and product structure are fairly confusing to me ... across the entire ecosystem. If you look at graphql/graphiql#3214 and it seems like "I'm doing it wrong", that's what I'm talking about. Youtube usually provides some good long-form surveys of an software/platform ecosystem, but there's not much on GraphQL. Your ecosystem's docs seem to not be aware of how much it depends on "social connection" in order for people to "just know" what everything means. And so the following isn't exactly obvious:

• just learning what tooling exists (like literally the app names i should google)
• where the apps store their secrets. they all use the same UI/UX: write a pre/post script where it can't exec shell scripts.
• whether the electron local session storage is cached/saved to the file system.
• where the Gitlab and Github GraphQL query-runner-app-things went? It usually takes me over an hour to find them.

I'm in the middle of hopping between like 7 different languages. Not having autocomplete is a bottleneck in learning GraphQL. Development seems to require like 20+ tabs and i'm also in the middle of learning Ansible -- given that each collection has it's own page, where the average margin/padding is too wide, then those are like 30+ very frustrating tabs. And learning Ansible led me /back to GraphQL/ ... to simplify docs search for Ansible, I need to start out getting all of the AnsibleCommunity repositories ... Then I don't have tabs, I have buffers and ripgrep handles everything xref doesn't.

I understand that some things are just more complicated in Emacs. view raw if not clear, but I tried every way I could think of until running into curl/quoting issues. If I can write the queries with features to facilitate learning the language, running the queries in a 100 different ways is simple.

[dcunited001]

I reopened Altair and the query & pre-script was still there. It didn't clear the state of the application, which usually indicates file storage.

I quickly searched electron to find references to settings.json and ran strace -e %file on the process. that showed me quite a bit of file access in XDG_CONFIG_HOME ... I didn't spend too much time, but it seems like /all/ of that electron app's data gets stored in XDG_CONFIG_HOME, which I'm assuming are electron defaults.

I ran yay -Rns to remove the app, but all of the application's data still remained. I'm assuming that most of the other apps are pretty much the same. Most of the data is in binary, and maybe it's protected like Firefox/Chrome. The problem here is that I could've put my API token in that query and if I did, then maybe it's recoverable using something like obsidianforensics/hindsight

I had never heard of that, but I am interested in forensics, so I thought I'd give it a try.

| site setting (hsts) | 2023-06-05 20:23:20.465 | Encoded domain: Ifty0kmGtBkqpzyRNEJ2iccvLpOffAEtEf72UjNCr0U= | HSTS observed | {'expiry': 1717557800.465995, 'host': 'Ifty0kmGtBkqpzyRNEJ2iccvLpOffAEtEf72UjNCr0U=', 'mode': 'force-https', 'sts_include_subdomains': True, 'sts_observed': 1686021800.465997} |   | /home/notme/.config/Altair |
| site setting (hsts) | 2023-06-05 20:23:26.249 | Encoded domain: nAuqgR4iEWti7SOdT3UHPl6rmZU/DeaIm38P2O2OkgA= | HSTS observed | {'expiry': 1717557806.249853, 'host': 'nAuqgR4iEWti7SOdT3UHPl6rmZU/DeaIm38P2O2OkgA=', 'mode': 'force-https', 'sts_include_subdomains': False, 'sts_observed': 1686021806.249854} |   | /home/notme/.config/Altair |
| site setting (hsts) | 2023-06-05 20:23:26.369 | Encoded domain: qaDeFdT1UTirY0OQe+c5LKw+zjx6vF/+3vFh7CgrAOY= | HSTS observed | {'expiry': 1717557806.369977, 'host': 'qaDeFdT1UTirY0OQe+c5LKw+zjx6vF/+3vFh7CgrAOY=', 'mode': 'force-https', 'sts_include_subdomains': True, 'sts_observed': 1686021806.369978} |   | /home/notme/.config/Altair |
| site setting (hsts) | 2023-06-05 20:31:03.518 | Encoded domain: E10e7Gwg5+phsYD4E8qNYFsQySXnIHPAfo4zloUPESc= | HSTS observed | {'expiry': 1701802263.518274, 'host': 'E10e7Gwg5+phsYD4E8qNYFsQySXnIHPAfo4zloUPESc=', 'mode': 'force-https', 'sts_include_subdomains': False, 'sts_observed': 1686022263.518275} |   | /home/notme/.config/Altair |

But then again, maybe it can't be recovered, since hindsight couldn't unmask data like this, meaning there is at least some data being shielded by the keyring. But with a dictionary of domains to compare against, these subdomains would unmask.

[acao]

@AaronNGray we have supported graphql-ws in graphiql since 2020! use createGraphiQLFetcher()