Replies: 29 comments 3 replies
-
|
Other potential avenues:
|
Beta Was this translation helpful? Give feedback.
-
|
Great start, @orta. I'll be writing up my thoughts in the next couple weeks when I get a chance. |
Beta Was this translation helpful? Give feedback.
-
|
This looks great so far! import { GraphiQLContext } from 'graphiql'
import GraphiQL from 'graphiql-components'
import MyGraphiQLComponent from 'graphiql-component-custom'
// configure store
GraphiQLContext.configure({
storage: window.localStorage,
namespace: 'myGraphiQLExample'
})
const myTheme = {
main: 'red',
secondary: 'blue',
fontFamily: 'Helevtica',
}
export default = () => (
<GraphiQL theme={myTheme} {...configOptions}>
{({ currentQuery })=> {
<GraphiQL.Wrapper logo={'ourlogo.png'}>
<GraphiQL.Tabs />
<MyGraphiQLComponent />
<DocExplorer />
<QueryHistory />
</GraphiQL.Tabs>
<QueryEditor >
<ResultViewer >
</GraphiQL.Wrapper>
}}
</GraphiQL>
)
// MyGraphiQLComponent.js
import React, { useContext } from 'react'
import { GraphiQLContext } from 'graphiql'
import { styled } from 'styled-components'
const MyGraphiQLComponent = () => {
const { currentQuery } = useContext(GraphiQLContext)
return <div>{currentQuery}</div>
}
export default styled.MyGraphiQLComponent`
background: black;
`With our underlying components already utilizing the same default context |
Beta Was this translation helpful? Give feedback.
-
|
IoT is a platform to connect the things which have an internet. A connected device is a complex solution, with various potential entry doors for an attacker. A connected device pentest IoT includes tests on the entire object ecosystem. That is electronic layer, embedded softwares, communications protocol, servers, web and mobile interface. The pentest on the electrical side,embedded softwares, and communication protocol concern vulnerabilities more specifically the IoT.
|
Beta Was this translation helpful? Give feedback.
-
|
On second thought, I'm inclined towards a lightweight plugin interface, as per benjie's comments on #828 |
Beta Was this translation helpful? Give feedback.
-
|
(Comments were in #828) |
Beta Was this translation helpful? Give feedback.
-
|
@benjie in addition to your own experience with postgraphile, and my own experience with a microservices-based plugin system, here's some good prior art, via our friends at insomnia: plugins: https://github.com/getinsomnia/insomnia/tree/develop/plugins I still vote for I also like your idea of the eslint-style configuration, so that the server or browser-level config can be composed as presets or line-by-line plugins with optional configuration. Also, to counterpoint my other suggestions further, we can obviously export components from the plugins themselves. So, if you had a project where you wanted just the doc explorer component, you could do: |
Beta Was this translation helpful? Give feedback.
-
|
I think another well implemented plugin system would be the gatsby plugin system: I wonder if there is a way to allow plugins to be installed at runtime, rather than at build time, assuming all I want is just a way to test graphql queries, as opposed to having to build my own GraphiQL mix and running it on a server somewhere. PS: I am trying to explore that in Altair at the moment, although it would be less efficient than a plugin added at build time. |
Beta Was this translation helpful? Give feedback.
-
|
@imolorhe maybe this at-runtime idea could be realized by finding a way to load plugins from external sources dynamically and hooking them into specific workflows, although that might become very hacky. Another idea could be to simplify the steps of setting up a graphiql instance with your plugins of choice so lowering the entry barrier of setting up a new server instance running graphiql w/ plugins, maybe some tooling. |
Beta Was this translation helpful? Give feedback.
-
|
Another plugin system worth researching is that used in the https://unified.js.org/ family of text (markdown, HTML, natural language) utilities - it's very comfortable for users to consume. |
Beta Was this translation helpful? Give feedback.
-
|
One addition I think we should make to the "Plugins should be able to" list is changing the target schema and/or triggering a reload of the schema. At Shopify we have several use cases for a GraphiQL plugin that could e.g. change which schema or which version of a schema is being hit. The actual request is probably covered under "act on making a request (customizing request, changing headers, keeping query history)" but it's equally important to be able to make sure the correct schema is loaded for documentation, autocomplete, etc. |
Beta Was this translation helpful? Give feedback.
-
|
@BrunoScheufler @imolorhe agreed with installing plugins at runtime! that said, there will be a default build of |
Beta Was this translation helpful? Give feedback.
-
|
Update: As per an email discussion, it looks like @schickling is interested in the new His words are:
He's very busy ATM and will be participating in these discussions more after Prisma Day. But this is exciting, it looks like we have almost the entire third party GraphQL IDE ecosystem on board with the new plugin interface concept! |
Beta Was this translation helpful? Give feedback.
-
|
What do folks prefer in terms of state management? React Hooks? Apollo |
Beta Was this translation helpful? Give feedback.
-
|
Whatever we use for state should be simple and have good longevity. We don’t want to have to update our state store when a vendor updates their library. Before we can make a proper decision we need to understand how plugins may affect state - i.e. should GraphiQL Explorer have a separate state store, or should it extend GraphiQL’s built in state with it’s own concerns? I loke shared state as it means plugins can build on other plugins, but care needs to be taken about namespacing. |
Beta Was this translation helpful? Give feedback.
-
|
Hey all, I'm super excited about the plans of having a monorepo for IDE + GraphiQL. Unfortunately I missed the GraphiQL WG, but was at the GraphQL WG... I love the idea of a plugin architecture! Here at FB we had to remove the GraphQL LSP, since it does not have a configurable way to load the schema. Here I echo @eapache's comment that it would be good if this aspect is pluggable. If I recall correctly in the WG group @acao mentioned that the plugin system will be implemented in GraphiQL. Would it be possible to implement it for the LSP as well to support other forms of schema loading? As a side note, the current way the LSP loads the schema is particularly slow due to usage of |
Beta Was this translation helpful? Give feedback.
-
|
It's not yet clear where the plugin system lives or what it does, but it is clear that different people want different things from GraphiQL, and a plugin system is a great way of achieving this whilst keeping a stable core. I've been thinking that we need to dip into underlying systems for plugins too, however this doesn't necessarily need to be part of one over-arching plugin system at the GraphiQL level; for example the need that you describe @Neitsch could probably be achieved with some kind of "adaptor" in a similar way to how Express has various session adaptors (stores) to store sessions into different places. It's not yet clear what the correct direction is, so surfacing these kinds of needs is extremely valuable for helping us figure out what's needed from the plugin system before we get too deep into architecting it. Your input is greatly appreciated, @Neitsch, as is your offer to help! 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
@Neitsch thats a really great point. Would be great to have you and others here at the next GraphiQL WG next tuesday: I'm relatively new to maintaining this ecosystem, so pardon me if I need too much explanation. Do you mean making the LSP GraphQLCache pluggable? I could see that being done at the interface level. I could see how cacheing the schema by reading/writing to an SDL file wouldn't scale very well for large schemas like FBs. Are there other parts that you would like to make pluggable? @lostplan what do you think? @asiandrummer at the the first GraphiQL WG meeting last month gave us a summary of these scaleability and performance issues on the facebook side, maybe we can do a more in-depth study of how we can learn from this for other large scale schemas? I doubt Facebook is the only company running into this issue, and it's a natural consequence of the GraphQL best practice design patterns, so we'd better account for it! It also seems like there's a need for either or I could see us making this confirgurable at the graphql-language-service-interface level, and then exposing that configuration when configuring graphiql? As a side note, do you think it could also be compounded by fetching the entire introspection query over the wire when graphiql didMount, and calling |
Beta Was this translation helpful? Give feedback.
-
|
Hot schema loading already works with GraphiQL, FWIW, you just feed the |
Beta Was this translation helpful? Give feedback.
-
|
I often use GraphiQL to make a request, copy the response from the API into browser console to do some data massaging to get what I was looking for. A plugin that I will be interested in would be a JavaScript code editor that allows me to do that data massaging without having to copy/paste often large payloads. Hope the plugin API allows such plugins |
Beta Was this translation helpful? Give feedback.
-
|
A plugin that manipulates the data received from the server before displaying definitely seems in scope. I think you can achieve this with the current GraphiQL by changing what the const fetcher = async params => {
const response = await fetch(GRAPHQL_ENDPOINT, {
method: 'POST',
headers: {
Accept: 'application/json',
'Content-Type': 'application/json',
},
body: JSON.stringify(params),
});
let result = await response.json();
// TODO: mangle result here
return result;
}Be careful not to mangle the introspection results (should be easy to avoid - just don't mangle any properties that start with two underscores |
Beta Was this translation helpful? Give feedback.
-
|
Let me clarify: I want to write code in the browser UI. Not modifying any of my own application code. Like a 3rd panel that I can manipulate the response and print it out or copy it for my use. |
Beta Was this translation helpful? Give feedback.
-
|
Adding additional panels such as OneGraph’s explorer, header editor, etc is definitely in scope 👍 |
Beta Was this translation helpful? Give feedback.
-
|
One of the most important developments for this has been our work with the vscode team to adopt monaco for GraphiQL. Part of that is mounting the LSP in the browser, which allows us to add a plugin system much like Typescript's built in LSP plugin system. This LSP already offers many features folks have requested of GraphiQL or Codemirror GraphiQL, for example being able to insert custom fragments in diagnostics and declarations using graphql config files. Adding a plugin system to that, we will be able to allow folks to introduce these plugins at any layer - when invoking the LSP server, when instantiating a monaco editor using our mode, or when creating or configuring a GraphiQL instance. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the roadmap to get here: |
Beta Was this translation helpful? Give feedback.
-
|
Should we consider adjusting it to the mobile screen? |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone, I am Vijay Gorfad from India. |
Beta Was this translation helpful? Give feedback.
-
|
@gorfadvijay ask in discord channel, Team is very helpful over there. |
Beta Was this translation helpful? Give feedback.
-
|
do folks want to start proposing the literal interfaces for GraphiQL plugins they'd like to use for upvotes here? I've been prototyping a few different ones, using object literals and functional components and such. Would like to see what folks have in mind! |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone. I'm currently searching for a way to extend GraphiQL and I came across this thread. What's the update on this? I don't know if this has been implemented. If not, and we have a formal spec, I'm happy to comtribute |
Beta Was this translation helpful? Give feedback.
-
|
see the existing plugins in the repo and read e to see how! we are about to rewrite the underlying implementation to use a different state management approach, but the existing hooks API will remain mostly the same, and we will be adding more types of plugins, such as renderless (non presentational), toolbar and per-pane plugins instead of only sidebar plugins. You can find userland plugins in the wild, including one that uses chatgpt! |
Beta Was this translation helpful? Give feedback.
-
|
Here is probably the most replete example: Here is an early stage example of a toolbar button plugin, that will soon be more easily available by adding a there should be a lot more activity in the coming month, and there are open PRs to add shared tooling and more plugin docs, I can ping you if you'd like to contribute and/or help review! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
This does not aim to be definitive, but to start discussion based on some rough ideas based on safe design assumptions.
Someone can probably think a bit more about how it can architecturally work, but using this as a general reference:
I think each sidebar tab should be owned by a plugin e.g. the documentation :
Is a system default plugin. Which is where this could be first built out, as a part of refactoring the current graphiql.
Systems owned by graphiql core
All the UI to the right hand side.
Plugins should be able to
Beta Was this translation helpful? Give feedback.
All reactions