Change the default behavior of the encoder to use urlsafe versions

[gfx]

I believe this is the better default because it is safely used as a pagination parameter of web apps (maybe like single-page applications).

Anyway, I define a custom encoder to use urlsafe versions in my project, but it's my pleasure if it is useful for your projects. What do you think of it?

In addition, I think lib/graphql/schema/unique_within_type.rb should use G::S::Base64Encoder, although the PR does not include this idea. How about it?

compatibility

• ❌ .encode - The string changes
• ✅ .decode - it can decodes what is encoded by Base64.strict_encode64

[rmosolgo]

🤔 Hmm, this issue has come up a few times, but I was always opposed because of compatibility issues.

But, it sounds like this decoder would be backwards-compatible, is that right? I mean, let's say someone updates their gem version. Would any of their API clients have trouble with outstanding cursors?

[gfx]

@rmosolgo

I think there's no trouble on updating a new gem that includes this PR.

This is because there are only / and + included in the original Base64 (see https://en.wikipedia.org/wiki/Base64#Base64_table ), and the urlsafe_decode64 replaces - and _ to / and + respectively, but it still able to handle / and + that the cursors encoded by Base64.strict_encode64 might include.

[rmosolgo]

Thanks for your response, I want to include this change in GraphQL-Ruby soon, maybe 1.9, let me think about it a bit more! (Actually I'm trying to migrate GitHub to urlsafe_encode64 right now!)

[rmosolgo]

I noticed an interesting issue when I deployed a similar change in github.com. We got some encoding issues, but here's what happened:

• I updated the code to use urlsafe_{en|de}code64, knowing that it was backwards-compatible
• I started a deploy
• During the deploy, servers got the latest code and then restarted the app
• But some apps started faster than others...
• And in some cases, clients received new, url-safe cursors, but...
• Then sent those new servers back to our website, and those requests were routed to old servers who hadn't restarted yet
• Since they hadn't restarted yet, they tried to call .decode64 on url-safe cursors, which made a best-effort but incomplete conversion
• Then, parsing the decoded payload content failed

Of course, those requests succeded on retry, because by that time, the server had properly restarted.

So, there's still a small compatibility issue here, but probably not worth worrying about. Just thought I'd share!

[gfx]

That is an interesting report! Thanks for sharing it. It means that before this PR, graphql-ruby must be able to decode url-safe base64 cursors for forward compatibilities.

[rmosolgo]

I pushed a merge commit and changed the base to 1.9-dev, assuming the tests pass, I'll get this improvement to into 1.9.0 😄