Unification of tooling between apollo-codegen and persistgraphql

[leoasis]

There's been a lot of conversation around the need for some unification regarding apollo-codegen and persistgraphql tools, as they serve different purposes but at the same time duplicate quite a bit of work that would be nice to keep in one place, both for avoiding duplication and for consistency. Particularly regarding persistgraphql's choice of using auto incrementing numbers instead of query hashes for the queries ids. Here are some of the issues and PRs that discuss about this:

• Add hash_ids flag to override default integer values persistgraphql#35
• Retain previously persisted queries for a number of subsequent builds[feature request] persistgraphql#17
• Generate Swift operation IDs and operation <--> operation ID mapping file #147
• Align persistgraphql output file format with proposed apollo-codegen operation ID mapping file persistgraphql#34

Since the idea of unification of both tools is scattered among all these issues (and probably others I may have missed), I think it's a good idea to have an issue to discuss what would be needed to achieve this.

In particular I'd be interested in unifying all the logic for serializing and generating a hash of an operation, so that the same hash can be generated no matter which tool is used. Since the hashing logic already exists here for the Swift client, maybe we can reuse this in persistgraphql.

I can start creating a list of things that need to be unified in these tools (maybe that should live in a separate repo or maybe in this one and make persistgraphql depend on it) so this issue can become an umbrella for this effort.

Let me know if this issue is useful to focus this effort, and feel free to give feedback on how to make this better in order to move forward to that goal.

Tasks List

• TODO

[martijnwalraven]

Thanks for opening this issue. There is definitely a need to unify tooling around persisted queries, and a more general need to unify schema and query loading across tools.

For persisted queries specifically, we also want to make sure static hash generation works well with automatic persisted queries. An existing project for this implemented as a Webpack loader is graphql-persisted-document-loader.

[lewisf]

I'd like a little more definition around this task soonish. Can we schedule a conversation around this for sometime next year? @martijnwalraven @leoasis

I personally haven't used persisted queries in my production apps, so I'm keen on listening to the concerns y'all have.

[leoasis]

Sure! We can discuss about it and come back with concrete action items.

[kevinjalbert]

I'm curious if https://github.com/apollographql/apollo-tooling will be solving this? Seems like this issue was closed as a result of #697.

@leoasis has there been some offline discussion related to this since the last comment. Should a new ticket be made over on the apollo-tooling repo?

[jbaxleyiii]

@kevinjalbert we now have a new language server and better support for persisted queries! What features are you looking for?

[jbaxleyiii]

And a new issue to track features on apollo-feature-requests would be great :)

[kevinjalbert]

@jbaxleyiii from what I had experienced in the past:

I'd be interested in unifying all the logic for serializing and generating a hash of an operation, so that the same hash can be generated no matter which tool is used.

I haven't been in the space for a little while though, so I'm not sure if that has been resolved.