TypeId Feature Discussion

[drusellers]

I was reading Designing APIs for humans: Object IDs looking at TypeId and wondered if there was any appetite for this library to add a concept like this.

Specifically this idea of the type_ prefix to whatever the underlying type is.

[ValueObject<Guid>(Prefix = "cust")]
public partial struct CustomerId {
}

I've really been enjoying using the idea of CustomerId over Guid in my code base, and the idea of going back to even something as nice as TypeId feels like a step backwards from Vogen.

So before I go down a path of either writing it myself, or looking at extending vogen I thought I would just ask and see what y'all thought first.

Cheers.

[SteveDunn]

Thanks for the link to that article, it's an interesting read. I certainly think this would be useful in Vogen. I initially thought Vogen would just be useful in the domain layer, but it's also very popular in the infrastructure layer for things like IDs.

The prefix suggested would mean that the underlying type would no longer be a (.NET) GUID, much like the examples given in the article also aren't .NET GUIDs.

So, we'd want something like this, but trimmed down (controlled :

[ValueObject<string>]
public partial struct CustomerId
{
    private static Validation Validate(string input) => 
        input.StartsWith("cus_") ? Validation.Ok : Validation.Invalid("Customer IDs start with cus_");

    public static CustomerId NewUnique() => From($"cus_{Guid.NewGuid()}");
}

... or using TypeId...

[ValueObject<TypeIdDecoded>]
public partial struct CustomerId
{
    private static Validation Validate(TypeIdDecoded input) => 
        input.Type.StartsWith("cus") ? Validation.Ok : Validation.Invalid("Customer IDs start with cus_");

    public static CustomerId NewUnique() => From(TypeId.New("cus"));
}

Assuming this solution was adequate, we might still have issues with serialization.

I'll continue to think about this and find an elegant solution.

[drusellers]

The prefix suggested would mean that the underlying type would no longer be a (.NET) GUID, much like the examples given in the article also aren't .NET GUIDs.

Agreed, I would end up storing them in the database as text fields (PG)

I've thought of an alternate where in the database they are still persisted as uuid, and the prefix is stripped off. But that might be more effort than its worth, and might be confusing to others when they don't see the expected uuid.

[ValueObject<string>(Prefix = "cus")]
public partial struct CustomerId
{
    // source generated would be preferred
    private static Validation Validate(string input) => 
        input.StartsWith("cus_") ? Validation.Ok : Validation.Invalid("Customer IDs start with cus_");

    // source generated preferred, but yes.
    public static CustomerId NewUnique() => From($"cus_{Guid.NewGuid()}");
}

Additionally, I'm also interested in, but not a hard requirement at all, in variable length random numbers rather than the longer Guid. So that I could have something like cus_deadbeef where I know the over all number of items is low and I want the id to be used in a URL