RFC: Add secondary keys

[nandorojo]

Summary

In our product, we very often query items by fields other than their id. It's usually using a slug or shortId. The main motivation is prettier URLs: /@djkhaled for slugs or /invoices/AD34DDAB6 for /invoices/[invoiceShortId]

While our database does (of course) enforce that these slugs are unique, they aren't globally unique. For example, an artist and a venue could have the same slug.

Proposed Solution

While I don't know the right implementation, it would be very useful to approach some sort of clean solution that lets me use secondary keys to access an entity.

For instance, I want artistBySlug(slug: <slug>) to be look for Artist:slug=<slug> without needing to set slug as the key.

Setting slug itself as the key makes me a bit concerned as it isn't truly the unique ID of the item. For instance, if URQL ever adds globally-unique identifiers across objects in the future, I'd want to keep using Artist.id as the actual unique key.

Additionally, we also query directly by ID often (it's either slug or ID) so we'd want the option to do either.

Requirements

This concept has been discussed all over the URQL repo over the years, but I was hoping to bring it up and see if it's something that's actually possible.

The main motivation is simple:

I want to set a query resolver that gets an item from the cache based on a field other than the key:

resolvers.Query.artistBySlug = (result, args, cache, info) => {
  return cache.resolve({ __typename: 'Artist', slug: args.slug })
}

[JoviDeCroock]

The thing I fear here is that we'd be duplicating a lot of data unless we create some mapping like secondary key --> primary key 😅 I do understand the need for this and how it would simplify a lot of things with querying different facets.

[nandorojo]

Yeah I’m definitely sympathetic to that. I think a mapping of some kind could work too.