Data API Builder RunAsExecutable

[tommasodotNET]

Related to an existing integration?

Yes

Existing integration

DataAPIBuilder

Overview

Running DAB as an executable could be a valuable option for developers to avoid dealing with a container. There is a known issue at the moment in Aspire when sending telemetry from a container.

Usage example

var dab = builder.AddDataAPIBuilder("dab").RunAsExecutable();

Where RunAsExecutable would check for the Context.IsPublishMode and if the app is running locally, it would run the same dab config using the local CLI.

Breaking change?

No

Alternatives

Current alternative is to run DAB as an executable using the standard Aspire AddExectuable method.

var dab = builder.AddExecutable("dab", "dab", "../../dab/", "start")
    .WithReference(sqlDatabase)
    .WithHttpEndpoint(targetPort: 5000)
    .WaitFor(sqlServer)
    .WithOtlpExporter();

Additional context

No response

Help us help you

Yes, I'd like to be assigned to work on this item

[tommasodotNET]

cc. @JerryNixon @FBoucher

[aaronpowell]

I think dotnet/aspire#7756 is a more accurate issue to link to

[tommasodotNET]

I think dotnet/aspire#7756 is a more accurate issue to link to

Fixed

[aaronpowell]

I'm a little unconvinced that this is something that should be native in the Toolkit, given that it'd really be a stopgap until there's a "proper" fix in the container that's being used. The concern I see is that you need to have another Resource type that you're having to manage and interact with, but we probably don't want it exposed, so there's a lot of mapping code that might be required.

Something that would be worth exploring is whether we can use docker cp and docker exec to copy the certificate in (I'm sure there's a way we can find and download it), then run the command to update the certificates for the container. That could be done via events, and we could also leverage it with #444.

It'd require some exploration though.

[yorek]

This makes a lot of sense to me. Just like there is no need to run Node in a container, there should not be the need to run DAB in a container if that is already installed on the machine

[aaronpowell]

That's a valid point @yorek and DAB is an interesting case because it's (using Aspire terminology) kind of a project (.NET/Node/Python/etc.) while also being kind of an external service (db, redis, etc.).

One of the risks that exists in going to an executable directly is that we can't be sure that the version used is going to match the version of the container being deployed, since Aspire integrations pin a container image but can't for executables, but this is also a problem with Node/Python/etc.

[tommasodotNET]

Good point, @aaronpowell
We could highlight this in the documentation.

[aaronpowell]

That could be an option, since it's only really of impact for local dev if you want to view the OTEL logs out of the DAB container (which is a rather specific scenarion IMO)

[JerryNixon]

It also makes it so HTTPS is easier to use in local development. Today HTTPS is basically impossible.