Use Mongo _id instead of UUID for primary key

[vnugent]

We use UUID as the unique ID for climb, area, user, media object, etc, both in external resources (url slugs) and internal primary keys. It's difficult to work with UUID in the backend since we need convert UUID-dash-format <--> Internal binary.

Todo:

Investigate migration paths (converting _id to ObjectID, incrementally update GQL layers and data sources

[CocoisBuggy]

I'd love to see this happen! to expand a little on the motivation provided above, here are the quick benefits

• A very minute speed boost
• All documents have an _id field by default, and developers will be used to dealing with them
• no more calls to muuidToString 🥇
• GQL layer will have a consistent id -> document mapping.

Why is this a challenging migration to make?

The main ticket item here is that some of our collection objects are currently ID'd by a MUUID data type.

export interface IClimbProps {
  _id: MUUID
...
}

export interface ExperimentalUserType {
  _id: MUUID
...
}

A corollary of that same issue is that areas have been pricipally keyed by their MUUID from the users perspective. It is trivial to migrate the areas since no new ID's need to be generated and, for the most part, the collections we deal with should maintain relational integrity if we were to do a deletion of the metadata.area_id field in all the collections.

Mongo doesn't give us relational integrity out of the box and we will need to such a migration with a little care to prevent data from becoming magically orphaned. Given that this is a technical risk in mongo, it might be prudent to smack any MUUID into the metadata for a few development cycles in case anyone spots something strange.

• Recall metadata for relationships. (Source and target)

The second challenge that all data types will face is that if there are links sitting out there that still use the MUUID, (/climb/<some muuid> those url's will immediately rot. I don't have stats on hand that suggest what the actual risk here is, and if you forced me to make a guess I would have to say it's probably a minimal risk. Even so, we could check the given id to the GQL endpoint and use a parse-heuristic to check which kind of id is landing on the doorstep. We would then create a corresponding event for analysis about whether or not this feature is being used or not.

• (optional) Support users using the deprecated link. If there are links on blogs or some other unforseen place where a link may rot, pre-resolve the ObjectId in the gql layer so that the rest of the business logic remains unaware.]
• Check existing URL references to make sure none of our backlinks use the deprecated logic
  • Open Tacos static links?
  • OpenBeta-API README static links?
  • Docs?
• The growing Android app

The thorny case of users

This may well be an opportunity to harden the users implementation in our API, but the problem is as follows

The reason we cannot just sweep through these and generate new IDs for all these types and function interfaces is that there is a hidden foreign key restraint that needs to be addressed. OAuth is the primary store for our users, and it isn't really possible to re-key the users in that store (as far as I know). it could be argued here that there is no reason to migrate these particular entities since it will complicate the foreign relation. If there were to be an effort here, it would be to key the objects in the collection by an ObjectId and retaining an external reference to the OAuth store. The JWT that the API uses to authenticate users will carry the UUID which can then resolve a user profile object in the collection.

Advantages

This may seem like needless work, but it does have one pretty major thing going for it: User auth source agnosticism.

Without getting too into the weeds, this would make it easier to support something like a 'Login With Google' or 'Login with Github' or the like. A user profile can be handled with support for connecting a singular profile to any (or multiple) auth source(s) which could be argued to be more robust in the long run.

Disadvantages

It's work to do these things, and some architechture will need to be critically looked at to ensure that the integration goes smoothly with open-tacos.

Workbill

• gql api
  • Retain old UUID in object metadata
  • Generate new IDs for entities
  • Resolve this new ID from the gql layer (This will allow progressive migration to the new id field)
• Open-tacos
  • Add a whoAmI resolver. OAuth will always give us a UUID, but it is stored in the JWT payload so we need a way to get our own profile off the gql layer.
  • Change type definitions to expect a string for all identifiers

Conclusion

Lots to do, some steps easier than others. Probably worth tackling it one piece at a time? @vnugent I could make some sub issues to do all the non-disruptive changes first?