Add Ability to Add custom behavior

[BenCoffeed]

Start from the Use-case

I would like to be able to incorporate Lift into my existing pipeline by fully automating my CloudFront distributions. This includes the ability to add custom behaviors for my /api path which I would like to forward to an API gateway-hosted function. The simplest way to do this is to create a custom domain for my api gateway distribution that matches exactly my app URL without creating a DNS entry for it. For example: myservice.acme.com. By adding the custom domain without a DNS entry, I have added my domain to the allowed values of the origin header for requests hitting the API gateway endpoint. This means I can have a behavior on my cloudfront distribution that remaps all requests to the /api* path pattern to the api gateway internal default invoke URL such as https://${someRandomId}.execute-api.us-west-2.amazonaws.com/. Since the A record for myservice.acme.com is pointing to my distribution, the origin header allows the distribution to make the call this way. You can also accomplish this with some lambda@edge header rewriting, but it's not necessary for this simple setup.

Example Config

service: myService

constructs:
    landing:
      type: single-page-app
      path: ${param:frontendDist}
      domain: ${param:domainName}
      certificate: ${certificate(${self:custom.customCertificate.certificateName}):CertificateArn}
      behaviors:
         -  origin: 
              type: Custom
              target: !Ref HttpApiUrl
              OriginProtocolPolicy: https-only
            AllowedMethods: 
              - GET
              - HEAD
              - OPTIONS
              - PUT
              - PATCH
              - DELETE
            CachedMethods: 
              - GET
              - HEAD
              - OPTIONS
            CachePolicyId: abcd456a-a123-4567-89abc-defgh01234abc
            Compress: False
            DefaultTTL: 30
            FunctionAssociations: 
              - arn:aws:cloudfront:::function/MyFunction
            LambdaFunctionAssociations: 
              - arn:aws:lambda:us-east-1::function:myFunction:2
            OriginRequestPolicyId: abcd456a-a123-4567-89abc-defgh01234abc
            PathPattern: api*
            ViewerProtocolPolicy: https-only
      
      
functions:
  api:
    name: ${self:service}-api
    handler: api.php
    timeout: 28
    layers:
      - ${bref:layer.php-81-fpm}
    description: 'Care Team Ops HTTP API'
    reservedConcurrency: ${param:reservedConcurrencyApi}
    events:
      - httpApi: '*'
    tags:
      service: api

**Modified to highlight a more generic ability to add additional behaviors. These behaviors could be for an api endpoint, image storage, etc for different path patterns and generate/point to additional origin options.

Implementation Idea

Add an additional behavior with path pattern, forwarding all headers, etc to the provided invoke URL.

[mnapoli]

Hi, this looks similar to #82, is there a difference?

[BenCoffeed]

I think the use-case is similar, but I think my idea for implementation is somewhat more generic, though now that I review my "example config", I believe I drifted from my generic ideal. Originally, I was perusing to see if there was an output of the CloudFront distribution created by Lift that I could reference to add a custom behavior resource. However, if I'm reading the AWS CloudFormation documentation correctly, the membership of CacheBehavior objects occurs within the distribution object and there does not appear to be a way to associate a CacheBehavior object after the fact. I believe a better example configuration idea would be

service: myService

constructs:
    landing:
      type: single-page-app
      path: ${param:frontendDist}
      domain: ${param:domainName}
      certificate: ${certificate(${self:custom.customCertificate.certificateName}):CertificateArn}
      behaviors:
         -  origin: 
              type: Custom
              target: !Ref HttpApiUrl
              OriginProtocolPolicy: https-only
            AllowedMethods: 
              - GET
              - HEAD
              - OPTIONS
              - PUT
              - PATCH
              - DELETE
            CachedMethods: 
              - GET
              - HEAD
              - OPTIONS
            CachePolicyId: abcd456a-a123-4567-89abc-defgh01234abc
            Compress: False
            DefaultTTL: 30
            FunctionAssociations: 
              - arn:aws:cloudfront:::function/MyFunction
            LambdaFunctionAssociations: 
              - arn:aws:lambda:us-east-1::function:myFunction:2
            OriginRequestPolicyId: abcd456a-a123-4567-89abc-defgh01234abc
            PathPattern: api*
            ViewerProtocolPolicy: https-only
      
      
functions:
  api:
    name: ${self:service}-api
    handler: api.php
    timeout: 28
    layers:
      - ${bref:layer.php-81-fpm}
    description: 'Care Team Ops HTTP API'
    reservedConcurrency: ${param:reservedConcurrencyApi}
    events:
      - httpApi: '*'
    tags:
      service: api

The implementation would be to simply create a CloudFormation CacheBehavior object definition for the listed behaviors and include them in the distribution. The origin object could first test if origin already existed before attempting to create simply based on target. Additionally, I left most of the default CloudFormation parameter names here just as a quick reference, but I suspect many could be removed and/or renamed to simplify/standardize the config.

[BenCoffeed]

@mnapoli. Mentioning you only because I don't remember if GH automatically notifies on issue response.

[BenCoffeed]

But now I'm wondering if this is already just covered in the extensions object.

[revanhernandy]

Hi @BenCoffeed, I have to set a server-side website that contains all assets to S3 and then used CloudFront. I need to change the ViewerProtocolPolicy to allow HTTP and HTTPS. Do you have an idea of where the CloudFront config is supposed to be placed?

constructs:
website:
type: server-side-website
assets:
'/css/': css
'/js/': js
'/experiment/': experiment
'/images/': images
'/scss/': scss
'/views/': views

[BenCoffeed]

@revanhernandy I see how this looks more like a server-side request. However, in my specific use-case, I'm actually using a fully-functioning single-page application for my front end. I'm not processing or generating any HTML/CSS in lambda. I'm simply using a lambda-powered api to return application/data state for the frontend to display. All of the site rendering happens via a javascript SPA.

However, reading through the server-side docs, I think step 1 would be to add a custom domain so that SSL communication is enabled. See: Adding Custom Domain. Next, I would assume the default behavior would be to allow HTTP and HTTPS but automatically redirect HTTP to HTTPS as I believe this is the default state in AWS. However. . . if you wanted to modify, you would need to use the extensions to modify the distribution. You can reference the CloudFormation CloudFront Distribution Docs to dig in and find the particular settings you need.

[revanhernandy]

@BenCoffeed it's still not working on my side with additional extensions for distribution

       distribution:
            Properties:
                DistributionConfig: 
                    CacheBehaviors:
                        ViewerProtocolPolicy: allow-all
                    DefaultCacheBehavior:
                        ViewerProtocolPolicy: allow-all
                    Origins:
                        CustomOriginConfig:
                            OriginProtocolPolicy: match-viewer

[gilliardmacedo]

@BenCoffeed did you get success adding behaviors? I want to do the same but if I add origins and behaviors, I get "One or more of your origins or origin groups do not exist", and ids between behaviors and origins are correct. So I guess extensions for origin and behavior don't work properly. I only want to add the API origin and its bahavior.