@dns / @domain pragma

[ryanblock]

Is your feature request related to a problem? Please describe.
Currently, Arc 6 is missing support for the @dns pragma; this is in part due to the fact that HTTP infra underwent some changes during the 6 buildout, in addition to adding @cdn pragma.

@dns (or alternately @domain) should come back to Architect, enabling users to define a domain they'd like to use for their app, and have it easily set up on their behalf.

Describe the solution you'd like
Users should be able to define @dns (or alternately / preferably (imo) @domain), which would enable them to define a domain, and wire that domain into their existing stack.

Considerations include origins (@http vs @cdn), origin paths, and cert provisioning (and region consideration for cert provisioning for CDN support), among other things.

Describe alternatives you've considered
This can be done manually today if one knows what to do (and how to do it). It's not a great alternative.

[ryanblock]

Note to update docs:

• https://arc.codes/guides/upgrade
• https://arc.codes/guides/domains (new)
• https://arc.codes/reference/cli/domain
• https://arc.codes/reference/arc/domain

[brianleroux]

Note to self: publish domains prototype macro here asap!

[jgallen23]

@brianleroux do you have a work in progress version of the macro? Would be willing to help take it over the finish line

[brianleroux]

put some thought into the ideal declarative config

@app
foo

@domains
staging
  http qa.foo.com
  static static-qa.foo.com
  ws ws-qa.foo.com

production
  http foo.com
  static static.foo.com
  ws ws.foo.com
  
@http
post /graphql

@static
fingerprint true
spa false

@cdn
@ws

[ryanblock]

Yo, that is really nice. I like it a lot.

[brianleroux]

certificates is one problem. another is how we want to model how this works.

my assumption is:

http qa.foo.com ................ (route53->cloudfrontdist->apigateway)
static static-qa.foo.com ....... (route53->s3)
ws ws-qa.foo.com ............... (route53->cloudfrontdist->apigateway)

though when I look at it like that maybe we create a cloudfront dist always for symmetry. this is also totally glossing over the need for a certificate for these. ideally we want to guide the end user to have an apex domain on http and sub domains for static assets and the web socket connection upgrade endpoint. this way an app shares an origin which means all these things can share an httpOnly session cleanly without CORs hacks or (worse) client readable cookies.

[juliedavila]

I think to just have a cloudfront dist always makes sense. Even for static assets it's better to have the cloudfront option. The thing that would be needed in that case is some amount of config with regard to status code handling at the CloudFront level. For SPAs in CloudFront that typically means sending 404/3s to ./index.html. Maybe this can just pick up the attribute from the @static pgragma

[brianleroux]

One other detail: think this will be a whole separate CloudFormation stack. DNS just doesn't change all that much (nor do CloudFront distributions) so it makes sense to make this a totally discreet operation with isolated artifacts.

[brianleroux]

Ok! thx for hanging in there folks. We have a prototype in macro form ready for testing: https://github.com/brianleroux/arc-macro-dns