Make "node id" in GraphQL and "id" identical

[fungc-io]

Problem

When communicating with Authgear, developers will see two versions of "id" in different scenario.

1. In the portal, webhook, userInfo from SDK, and the sub of JWT, users are identified by a uuid
2. In admin API, the users are referred by a node_id which is a base64URLencode("User:"+uuid)

Although a similar design is practiced by GitHub API, this is not natural to a developer, and developers may found it quite strange.

Proposed Changes

• For newer projects, user sub will be identical to node id, they will be directly interchangeable between different interfaces with Authgear, be it GraphQL or REST
• Existing projects will keep the current design of uuid and node_id, and remains unchanged for future sign-ups
• Project migrated from other auth system will store and report the old user ID as a custom attribute. Authgear will return this attribute in JWT and auth headers.

[chpapa]

Actually if all entities in Authgear are using uuid as ID, what if we make it simpler by:

1. Just replace UUID with node ID in graphQL
2. Migrated users DB will have user id as uuid as well, and old user id, if any, shall be put in custom attributes

[louischan-oursky]

All IDs are UUID, including user ID. But UUID is not enough for GraphQL because GraphQL define a node(id: ID) field that every GraphQL must implement. That means the ID must tell the type of the node and the ID of the node.

To solve this problem, I want to adapt a similar ID format used by Stripe. The IDs of Stripe looks like prod_NwKkamouCWQvls which is an ID of a particular Stripe Product. This format encodes the type and also URL safe. Of course this change only applies to new projects.

[chpapa]

To solve this problem, I want to adapt a similar ID format used by Stripe. The IDs of Stripe looks like prod_NwKkamouCWQvls which is an ID of a particular Stripe Product. This format encodes the type and also URL safe. Of course this change only applies to new projects.

So it's like user_[UUID]?

Ya that seems good enough and avoids the trouble/performance of overhead for us to build a global object index