.WithHttpEndpoint for ResourceWithEndpoints

[tommasodotNET]

We have NodeJS and Golang resources which are of type IResourceWithEndpoints. This kind of resource lets the dev reference directly the resource without the need to get an endpoint. This works assuming the referencing resource can handle a multi protocol url (http/https).
NodeJs declares the .WithHttpEndpoint() method inside the AddViteApp, while Golang lets the user declare the use of an Http or Https endpoint in the AppHost.

I think the Golang way of handling this should also be adopted by Vite, since we cannot take for granted that a certain project can run with http locally or that the environment variable it uses for the port is actually PORT.

In this case, for instance, I had to handle the fact that the Vite app can use a https endpoint when running locally but not in deployment, since it was conflicting with the already existing http one which is marked as external inside the AddViteApp(). Moreover, I could not use the standard VITE_PORT env var for the port because the http port was declared inside the AddViteApp() method and cannot be overwritten.

Anyway, I think the behaviour of Golang and NodeJs should be standard in this case, so I'd like to open a discussion before creating an issue in a direction or the other.

[tommasodotNET]

cc. @aaronpowell

[tommasodotNET]

One way to handle this would be to configure the name of the port as an optional param for AddViteApp() and AddGolangApp().

If we had something like

public ... AddViteApp(string resourceName, ...., string? portName)
{
  ....
  resource.WithHttpEndpoint(env: portName);
}

Then we could use it like this:

var vite = builder.AddViteApp("vite"); // sets the port env var name to "PORT"
var vite = builder.AddViteApp("vite", "VITE_PORT"); // sets the port env var name to "VITE_PORT"

We might also want to consider having a user-assigned port for our integrations. There are some instances in which the Vite project is configured to use a certain port and it would easier for the dev to integrate avoiding the dynamic port assignment.

[aaronpowell]

I'm less concerned about the design of the AddGolangApp as a Go app isn't always going to need an endpoint configured, it can, but it could also be running a background service that is doing something like monitoring a queue or running a batch job, unlike Vite which is always for running a web frontend.

Some kind of design in which we can provide a callback function as the last argument might work a bit better in the case of Vite, as it would provide a lot more flexibility in terms of what can be done while also being optional.

[tommasodotNET]

Agree for Golang.

Could you show me some pseudo-code for the callback function so I can better understand what you have in mind?

[aaronpowell]

Something like this:

builder.AddViteApp("vite-demo", options => {
        options.EnableHttp = false;
        options.EnableHttps = true;

        options.WithEnvironment("VITE_PORT", options.HttpPort);
    })
    .WithNpmPackageInstallation();

This would receive a ViteAppOptions that is set with some default values, and then once the callback is called, it'll do things like WithHttpEndpoint or not, depending what is set.

[tommasodotNET]

Nice!