Regex based custom scalas + automatic discovery

[andimarek]

Idea: we could add another custom scalar spec which is a subclass of the string template, which is regex based.

This means the input and output would be fully described with a regex (or two different regex for different input and output).

The main goal of this would be to offer some kind of automatic discovery of the regex. For example via dedicated URL. This would allow tools like GraphiQL to dynamically discover custom scalar specs and validate them and offer code completion.

Example:

spec for LocalDate. The format is "yyyy-mm-dd"

regex for input and output is: "\d{4}-\d{2}-\d{2}".

The patterns for input and output could be reachable via: scalars.graphql.org/andimarek/local-date/input-regex scalars.graphql.org/andimarek/local-date/output-regex

Both endpoint would just return HTTP text with "\d{4}-\d{2}-\d{2}". Nothing else.

One implementation detail I am not sure is how we automatically could get the patterns from the template or maybe we just expect contributors to specify them in extra files?

@dondonz @leebyron what do you think? Would love to hear some ideas how to implement this. Maybe spec-md could help here even?

[dondonz]

100% I think we should do this.

Most exciting bit for me is validation & code completion in a tool like GraphiQL!! I use GraphiQL all the time.

Maybe to start with, we manually add the patterns? Can automate later if there ends up being many regex based specifications

[leebyron]

It's very interesting at surface but it presents a bunch of problems. I had considered this for custom scalars when we first introduced the ability to have them, but decided not to.

A few reasons:

• It's surprisingly tricky to define a runtime agnostic regex grammar, and the last thing I want to do is embed a regex specification inside the GraphQL specification. There are a ton of subtle differences and corner cases in every host regex engine, and I imagine this would be a frustrating source of bugs and incompatibilities.

• Regex is often "good enough" but not fully correct in a frustrating way. Developers will prefer a simpler regex over a more correct one, but that often causes problems. For the example you provided above, 2023-30-10 fits the regex, but what does this mean? Is it invalid? Is it Oct 30th? Does it parse but you expect a later part of the system to throw an error?

• A regex is insufficient to describe the semantics. Even just the idea that this should be interpreted as YYYY-MM-DD is implicit if all you get is a regex. Ultimately you need something that describes what the value means so that you can use it in the expected way.

[andimarek]

I think the challenges you pointed out are true @leebyron.

The question would be: how much value does the automatic discovery of regex patterns provide or none at all?

For example if there is indeed no standard of regex engine or at least popular enough implementation that we could leverage, I would argue it is not worth it.