search

JetBrains / js-graphql-intellij-plugin

GraphQL language support for WebStorm, IntelliJ IDEA and other IDEs based on the IntelliJ Platform.
https://jimkyndemeyer.github.io/js-graphql-intellij-plugin/
MIT License
880 stars 97 forks source link

GraphQL Java dependency #695

Open andimarek opened 11 months ago

andimarek commented 11 months ago

Hi ... I am one of the GraphQL Java maintainer and I can see that GraphQL Java sources are copied and not a normal dependency.

I would love to know why and depending on the answer what we can do to make your life easier somehow and avoid coping sources.

Thanks, Andi

vepanimas commented 11 months ago

@andimarek Hello! Thank you for considering this issue. The main difficulty with using the graphql-java library as is, lies in its design for very different use cases. From the IDE perspective, we need a library that can build a schema quickly and frequently. It should offer ways to extend types, fine-tune the schema-building and validation process, and crucially, handle schemas that are broken 90 percent of the time during editing in the editor.

The situation is further complicated because we use graphql-java not only for validation, but also for reference resolution, and completion. If a schema is not completely accurate, it can create various issues. For instance, all queries and types in the IDE might be marked as read, and there might be no autocompletion.

I have a list of the changes I've made over the past years. However, not all of these modifications have been implemented, or I may forget to mention some of them here:

  1. We need the ability to extend both types and nodes. Consider the constructor of AbstractNode. Since additionalData is a String map, it can't store IDE's data. Therefore, I've extended the constructor to accept a PSI node and a collection of other source nodes. This is useful when a node is built from multiple nodes with the same name. Additionally, I've overridden the method to calculate source location based on this information.
  2. You deprecated type constructors some time ago. I've seen an issue where you were resistant to changing that, but it's also necessary to extend types.
  3. Defensive copying creates substantial pressure on the GC when editing a schema file and continuously building new schemas in the background.
  4. We need to configure the schema print output format flexibly, as our GraphQL formatter is not yet implemented.
  5. Likely, we need the ability to construct a schema and replace type references lazily.
  6. Instead of throwing errors and making assertions, we need to store the error and continue with schema building and validation. Many assertions, see a commit 08d08c441829f8ffc23c3827dafec5e204918da5, have been removed to achieve this. For example, https://github.com/JetBrains/js-graphql-intellij-plugin/commit/08d08c441829f8ffc23c3827dafec5e204918da5#diff-2f22382be9e83bd8a1812df273f85a43588a78d79d49cfc859853889aff9ffd2R43, https://github.com/JetBrains/js-graphql-intellij-plugin/commit/08d08c441829f8ffc23c3827dafec5e204918da5#diff-6c2708a17808e6d4e8f811dfa0be99a25fd3d4dec518e4241cd3a30e2d6cdd96R20, https://github.com/JetBrains/js-graphql-intellij-plugin/commit/08d08c441829f8ffc23c3827dafec5e204918da5#diff-2243acc5cc1120d48dbd9896dbb03a4644b562edfef35ba426d50f94fd546662R120, and many more.
  7. We need the ability to customize error messages. For example, see https://github.com/JetBrains/js-graphql-intellij-plugin/commit/41fc0b8dc388e5b99b1cc890e484564c064c2761.
  8. Tolerate schema errors, such as:
    1. Missing types.
    2. Duplicate types with the same names (provide a merge strategy for them, but retain the original types with all related information).
    3. Incomplete syntax. For example, type Query { id: ID name: <caret> } should be a valid type in the schema with an id field and a name field without a type (and this also will cause an assertion in the current implementation of graphql-java).
  9. The schema building process should be cancellable. In IntelliJ IDEA, this is achieved using ProgressIndicator, for instance, through a call like ProgressManager.checkCanceled(). This function should be called frequently to cancel an ongoing schema building operation if the user changes a syntax tree concurrently and the schema is requested again.

I'm eager to participate in this activity and contribute. However, I'm not sure if this aligns with your priorities and vision for the future of graphql-java. If not, my plan is to completely rewrite both the resolve and completion from scratch, using graphql-java solely for query validation, and finally remove it from the repository to be able to update it regularily.