How to handle active clients during re-deploys?

[rmosolgo]

Hi, thanks for sharing this repo! Looks like lots of good work.

I've been doing some thinking about persisted queries as well (but not much doing). I'm curious how you'd handle this situation:

• Many clients are out "in the wild" with persisted query IDs
• You refactor the application, changing the data requirements and the graphql queries
• You redeploy the application which now has new queries and new query IDs

For example, let's say you start with a .graphql file like

query getThing($id: ID!) {
  get(id: $id) {
    name
  }
}

And you run persistgraphql which generates a query map:

{"query getThing($id: ID!) {\n  get(id: $id) {\n    name\n  }\n}\n":1}

Then, later, you refactor the query:

  query getThing($id: ID!) {
    get(id: $id) {
-     name
+     title
    }
  }

And again, persistgraphql to get a map:

{"query getThing($id: ID!) {\n  get(id: $id) {\n    title\n  }\n}\n":1}

But now, ID 1 points at a new query, which may cause some clients to break! How should we avoid that?

The only thing I can think of is: never change or remove a persisted query until you're sure no outstanding clients depend on it. Instead of changing queries, always add new ones. Do we have any other tools to help in this case?

[stubailo]

I think the right approach is to keep around all queries that have ever been persisted, until you are really sure there are no old clients out there. So I would suggest taking the output of this tool and adding some large number to every ID.

Perhaps a PR to switch to UUIDs instead of numbers would be good, then people can just insert the IDs as-is.

[stubailo]

I think keeping them in a database would be reasonable. Are you planning on supporting a feature like this in Ruby?

[Poincare]

Agree with @stubailo. I think persistgraphql should probably allow you to do a "merge with existing" kind of thing where you can crawl an updated codebase but merge it with an existing persisted queries JSON file.

[stubailo]

Is that to avoid saving duplicate queries?

Actually, using a hash instead of an ID would probably solve that since you can just insert into your database of queries if the hash doesn't exist.

[Poincare]

In my mind, it would just be a convenience thing that allows you to handle multiple client versions rather than something that's meant to reduce the number of queries represented in the map.

[stubailo]

I guess I don't think anyone will actually be storing the queries in a JSON file, so if anything a more useful thing would be a function that saves the queries to some kind of storage.

[rmosolgo]

Yeah, I'm definitely interested in building a persisted query system for Ruby servers. I took a crack at it a while back and it left me with these questions:

• How to support outstanding clients? (This also applies to development: if you change the .graphql files, your currently-open browser is now stale, and at least for Rails, the only option is to reload the page. C-c-c-combo breaker!)
• Is storage in memory enough? I have two questions there: will some users ever have so many queries that storing them in memory is burdensome? And, for Ruby, will we have threadsafety issues? (That can be worked around, but it's something to keep an eye on.)

So, I didn't come up with any answers ... just questions 😆 thanks for sharing your thoughts!

[stubailo]

Oh, I think the server should accept all queries in development mode.

So the answers to your questions IMO are:

1. You never delete queries, only add them to a database; in development, the server should accept all queries and there's no need for persisting.
2. I think queries should be stored in a database and cached in memory, I can imagine people easily having many thousands of queries since you need to persist a new one every time you change just one field.

Let me know if I can help with a Ruby server addition!