[Alias] best practices for binding domain to gateway

[unix]

Describe the solution you'd like

Now we can get an endpoint after deploying Lambda using Nitric, but this is the default domain resource for AWS, and it would be nice to be able to automatically add aliases according to the existing resources. (Maybe Nitric already contains such a feature but I don't know...)

Why is this needed? What challenge will it help you solve? Please describe.

For users using nitric to manage multiple lambda services, it would take a lot of time to manually configure the domains on AWS each time, and it would save them a lot of time if we could do it automatically by following the YAML configuration or checking for existing resources. (Some services like apex/up or vercel ever.)

We shouldn't need to validate the domain name or deal with SSL, just configure the resources that already exist on the cloud platform.

1. For common configuration needs, we can use configuration files to specify subdomains:

name: <name>
provider: aws
alias: *.api.example.com

2. Or allow the user to programmatically specify a resource:

const mainApi = api('main')
mainApi.alias('main.api.example.com')

3. Or provide a terminal command for users to bind:

nitric domain add *.example.com -s <name>

Describe alternatives you've considered

If there are obstacles to the implementation of the above functionality, perhaps we could open up a lifecycle or code block and let users add some Pulumi configurations themselves:

main.context.append((pulumiConfig) => {
  // pulumiConfig.something()
})

Brief description of your project

I am using Pulumi to manage multiple serverless, but still need to add very much extra code for each Lambda, and I would like to move to Mitric tools to reduce duplication of work. (If there is a solution to the problem of automated aliases)

Additional context

[tjholm]

@unix thanks for raising this, and also for the proposals.

An older version of the nitric framework used to support this, and we removed it temporarily when we did a large refactor of our framework to support the infrastructure from code you're using now (everything used to be yaml).

We had a resource we would create called an Entrypoint, this was an abstraction over existing load balancing services for example:

• AWS Cloudfront
• Google Cloud Load Balancer
• Azure Front Door

My question is when using pulumi are you applying these aliases directly to your API gateways or using something like cloud front to use custom domains?

[unix]

@tjholm I use CloudFront with Route 53 on a few services, most of them alias directly to the Gateway, but that's not a problem, and I'm sure if you could roll out a best practice, users would be happy to assemble their own services according to your architectural design.

Maybe my issue wasn't clear, I think it would be great to have a best practice guideline for custom domains when using Nitric, all following the design of Nitric, thus helping users to keep the whole project consistent and automated.

[tjholm]

@unix Thanks for clarifying.

I think for now we could write a best practice guide on extending the pulumi resources deployed by nitric with your own pulumi scripts and I'm currently trying this out myself to see if we can do this without making a changes to the framework which I should be able to provide a gist or sample repo for soon.

Eventually I do see this being implemented directly into the framework, so I'll leave this issue open to continue a discussion around what that might look like as well :smile:.

[tjholm]

@unix I've made a rough example of deploying custom domains for nitric deployed API gateways at: https://github.com/tjholm/nitric-pulumi

It uses the pulumi automation API to retrieve the existing nitric stack state, locate the deployed API gateway resources and create new domain names for each deployment based on their name for a custom base domain. There is code for two options in there:

1. Externally managed domain (partially automated)
2. Route53 managed domain (fully automated) (this example is commented out).

for example:

const mainApi = api('main'); // => main.example.com
const testApi = api('test'); // => test.example.com

Let me know if this example is helpful, and I can look at creating better examples/guides for this.

[unix]

@tjholm I appreciate your support very much, I have completed the first project and everything works well.

It will be even easier if Nitric can support domain resources directly in the future, and I look forward to you sharing these efforts with the community!

---

BTW, perhaps as a reference: In our usage scenario, we usually already have a certificate for a wildcard domain, so every time we create a DNS record it's under the same zone, which is enough for me.

/**
* There is already a certificate for '*.example.com', which may be sufficient for most businesses
* "service-a" shares a hosting area with other services, there is no particular need to change the route53 traffic 
* configuration requirements here.
* */

const selectedZone = await aws.route53.getZone({
  name: 'example.com',
  privateZone: false,
})
const dnsRecord = new aws.route53.Record('api-dns', {
  zoneId: selectedZone?.zoneId,
  type: 'A',
  name: 'serviec-a.example.com',
   aliases: ...
})

[tjholm]

@unix This is currently being implemented in our AWS provider: https://github.com/nitrictech/nitric/pull/468