How do I get back Guid's for Id´s and not Base64 string?

[sturlath]

Sorry if this is something way to basic but I´m new to GraphQL and am going through the workshop demo (and applying it to my own code/entities) and I just am not getting this base64 stuff.

My entities have Guid's for ids and I can query by id and there I pass in a Guid, but the resulting Id is base64 so I wouldn´t even be able to use that back into my query that got that result.

So my first question is basically how can I turn Guid conversion to base64 off?

And the second one is how would you use that base64 at all?

[sturlath]

I see that this "happens" when I use .AddType<MyType>()

[PascalSenn]

I guess you have .AddGlobalObjectIdentification() enabled.
This is used in combination with relay. The Id, which can be any scalar (int, string, guid etc), is encoded together with the type name.

This way you only need to know the id to refetch the data over the nodes enpoint.

[sturlath]

Hi @PascalSenn no I do not have .AddGlobalObjectIdentification()

This is basically my setup and I can´t figure out what is causing this. I hope you can glance something from this

public static IServiceCollection AddGraphQLIntegrations(this IServiceCollection services, IConfiguration configuration)
{
    //For GraphQL DataLoaders
    services.AddPooledDbContextFactory<CustomerContext>(
        options => options.UseSqlServer(configuration["Database:ConnectionString"]));

    _ = services
            .AddGraphQLServer()
            .AddQueryType(d => d.Name("Query"))
                .AddTypeExtension<CustomerQueries>()
            .AddType<AppliedBundleType>()
            .AddType<CustomerType>()
            .AddProjections()
            .AddFiltering()
            .AddSorting()
            .AddDataLoader<CustomerByIdDataLoader>();

    return services;
}

the query

 [ExtendObjectType("Query")]
    public class CustomerQueries
    {
        [UseCustomerContext]
        [UsePaging(typeof(NonNullType<CustomerType>))]
        [UseProjection]
        [UseFiltering] // [UseFiltering(typeof(CustomerFilterInputType))]
        [UseSorting]
        public IQueryable<Customer> GetCustomers(
            [ScopedService] CustomerContext context) =>
            context.Customers;
    }

The type

    public class CustomerType : ObjectType<Customer>
    {
        protected override void Configure(IObjectTypeDescriptor<Customer> descriptor)
        {
            descriptor
            .ImplementsNode()
            .IdField(t => t.Id)
            .ResolveNode((ctx, id) =>
                ctx.DataLoader<CustomerByIdDataLoader>().LoadAsync(id, ctx.RequestAborted));

        }

        private class CustomerResolvers
        {

        }
    }

The dataloader

public class CustomerByIdDataLoader : BatchDataLoader<Guid, Customer>
{

    public CustomerByIdDataLoader(
        IDbContextFactory<CustomerContext> dbContextFactory,
        IBatchScheduler batchScheduler,
        DataLoaderOptions options = null) : base(batchScheduler, options)
    {
        this.dbContextFactory = dbContextFactory ??
            throw new ArgumentNullException(nameof(dbContextFactory));
    }

    private readonly IDbContextFactory<CustomerContext> dbContextFactory;


    protected override async Task<IReadOnlyDictionary<Guid, Customer>> LoadBatchAsync(
        IReadOnlyList<Guid> keys,
        CancellationToken cancellationToken)
    {
        await using CustomerContext dbContext =
                dbContextFactory.CreateDbContext();

        return await dbContext.Customers
            .Where(s => keys.Contains(s.Id))
            .ToDictionaryAsync(t => t.Id, cancellationToken);

    }
}

Anything obvious here?

[tsinghammer]

I think (@PascalSenn correct me if I'm wrong) the conversion is automatically be done by HotChcocolate between Base64 and the original id value + meta information if you enable .AddGlobalObjectIdentification().
So inprinciple if you're just sending the ID back and forth, you shouldn't have to do anything.
If you need the ID unencoded, you could use two properties for instance like public Guid ID => MyId. ID will be the encoded one and MyID the original one.
If you need to create new encoded IDs on the client it is more difficult. In this case it would be better to have separate input types, one for a create mutation and one for an update mutation.

[sturlath]

the conversion is automatically be done by HotChcocolate between Base64 and the original id value + meta information if you enable .AddGlobalObjectIdentification().

Not quite understanding that one. Where would that conversion be done?

And if my Id´s are Guid´s (not strings) then I can´t take an Id from a earlier response (that is base64) and pass that down again to get something else with it.

And if I have a GetCustomerDetailsById(Guid id) method that takes in Guid I will need to pass down a Guid and no automatic conversion can be done there.

And for returning another Id, it feels strange to me having two unique Id´s returned, Id (base64 string) and then the real CustomerId I can use in my queries where I would need to pass CustomerId in for Id (little confusing).

So I kind of feel like I need the Id´s to be returned as Guid´s. For unique purpose that should be enough and base64 collision protection not needed, right?

And sorry if I´m misunderstanding your proposal.

[tsinghammer]

Sey, what I meant is if you pass the Base64 encoded ID back to HC and it is declared as an ID type, it should automatically reconvert it to the original GUID.

But yeah, if you don't need the Base64 encoded version, if you just not declare/annotate the type as ID, you should get the plain GUID on the client.

In my Scenario I'm using two properties because I get the original GUID from another service. And in my service I have my own type the in addition exposes an Id property that is declared as (Relay) ID. For convenience I'm just forwarding the ID => MyGuidId and let HC do the encoding/decoding work.

Can't you just remove this line in your case: .IdField(t => t.Id) or do you need it for Relay?

I also think that instead of passing GUIDs as a parameter IReadOnlyList<Guid> keys, you could use something like this [ID] int id. I'm not what is the Syntax to declare enumerables.
Maybe something like this: https://chillicream.com/docs/hotchocolate/defining-a-schema/scalars#id

[sturlath]

Thanks @tsinghammer I was not able to remove .IdField(t => t.Id) on its one but if I remove it completely and just add descriptor.Field(f => f.Id); I get Guids back. But I don´t know what other effect that might have....

[sturlath]

I then found these two here Support customizing Guid + IdType serialization format and Inconsistent GUID(UUID) rendering that might be helpful but I don´t know...

[tsinghammer]

Since Relay doesn't care about the format It could make sense to make the behavior configurable and tell HC to just pass thru the original value. Maby someone knows if this is already possible?

[tsinghammer]

Or use the IdSerializer:

public class Query
{
    public string Example([Service] IIdSerializer serializer)
    {
        string serializedId = serializer.Serialize(null, "Product", "123");

        IdValue deserializedIdValue = serializer.Deserialize(serializedId);
        object deserializedId = deserializedIdValue.Value;

        // Omitted code for brevity
    }
}

[tsinghammer]

There seems to have been a recent change I've missed. Properties attributed with ID do not automatically Base64 encode the value if nothing else is configured.
Can you confirm?

[sturlath]

If I remove all configuration and don´t put [ID] on the id property it returns guids

I tried adding [ID] and do all kinds of stuff but I can´t get it to work while also using the DataLoader setup you see there.

Do you @michaelstaib (or anybody else) have any feedback into this? Sounds like this should be fairly simple but isn´t....