Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

V2 monaco rewrite - Needs Maintainers & Contributors! #1366

Open
acao opened this issue Feb 2, 2022 · 12 comments
Open

V2 monaco rewrite - Needs Maintainers & Contributors! #1366

acao opened this issue Feb 2, 2022 · 12 comments

Comments

@acao
Copy link
Member

acao commented Feb 2, 2022

I apologize how neglected this repository has been! We have many co-maintainers who are all busy with work and maintaining other graphql ecosystem tooling. 馃サ

We had planned on merging graphiql and playground projects, but it no longer seems to be a good idea. At the time I was a paid open source maintainer for GraphiQL, Vscode Graphql and the language server, however the pandemic has changed all of that.

The best we can hope for is that they can share some react components & utilities via our forthcoming @graphiql/react sdk! Most importantly, whatever is in playground鈥檚 future, it will be using our new monaco-graphql! 馃挮

Our focus now is on the graphiql rewrite, but there is nothing stopping anyone from starting with monaco-graphql and react on a new playground.

Proposals that convert the existing playground to use monaco-graphql are also welcome. We don鈥檛 have a roadmap for this approach.

If anyone has been particularly helpful and knowledgeable helping with issues, creating PRs for important bugs, etc, feel free to nominate them as potential maintainers in the comments! Self nominations are also of course welcome.

@acao acao pinned this issue Feb 2, 2022
@acao
Copy link
Member Author

acao commented Feb 2, 2022

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

it deserves a dedicated team!

@jspizziri
Copy link
Contributor

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)

@BeauBouchard
Copy link

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

@acao
Copy link
Member Author

acao commented Mar 7, 2022

@dotansimha ^^ !! :)

@timsuchanek
Copy link
Member

timsuchanek commented Mar 8, 2022

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.

@dotansimha
Copy link
Member

fyi @n1ru4l ;)

@AaronNGray
Copy link

AaronNGray commented Apr 7, 2022

@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 !

@spencerwilson
Copy link

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
Copy link

dcunited001 commented Jun 6, 2023

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
Copy link

dcunited001 commented Jun 6, 2023

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
Copy link
Member Author

acao commented Jul 17, 2023

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

@asvishnyakov
Copy link

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants