Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(nextjs-cdk-construct): add runtime options to regeneration #2050

Merged
merged 3 commits into from
Nov 20, 2021

Conversation

mathisobadia
Copy link
Contributor

fixes issue #2048
The regeneration function was the only function where the runtime could not be modified through setttings prop
This can cause the regeneration lambda function to time out an fail
The pull request adds the option to configure the regeneration runtime (memory, timeout, role, and node version)

as a note I have not modified the nomenclature for this function but it is the only lambda handler that is named as Function instead of Lambda for the others (nextApiLambda, nextDefaultLambda, nextImageLambda) but the regeneration lambda is named RegenerationFunction. I can modify that also if needed.

…unction so that it can be modified from options props
role: this.edgeLambdaRole,
runtime:
toLambdaOption("regenerationLambda", props.runtime) ??
lambda.Runtime.NODEJS_12_X,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should remain NODEJS_14_X?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% sure why it was hardcoded as NODEJS_14_X but I think it's unintuitive that the regeneration function is the only one with a fixed nodejs version. This might result in some weird bugs if it is the regeneration function uses a different runtime than the default function because they use the same js page bundles. This line I added is the same as for the other functions and it makes sure that all functions use the same nodejs version except if the user really wants to set something different throught props

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we want the regeneration lamda have the same role as the other functions? I know in my case I need this because the role grants access to dynamo to get the date necessary for generating a page

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @mathisobadia to be clear I think what @dmsolutionz is saying is that the "default should remain as NODEJS_14_X" rather than it shouldn't be editable. If you change to NODEJS_12_X as the default that's a breaking change.
Having it as editable like the others is exactly the desired outcome here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah that makes perfect sense! I've updated my pull request accordingly.

Copy link
Contributor

@afenton90 afenton90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good aside from the change mentioned by @dmsolutionz

@mathisobadia
Copy link
Contributor Author

Looks good aside from the change mentioned by @dmsolutionz

Thank you for the feedback! I can change my pull request but I'm wondering why this function should be the only one with fixed node 14 runtime while all the other ones can be set with props? it doesn't make sense to keep the props as they are with the possibility to set the runtime version of the regeneration function since we now have

  /**
   * Lambda runtimes(s)
   */
  runtime?: LambdaOption<Runtime>;

and

export type LambdaOption<T> =
  | T
  | {
      defaultLambda?: T;
      apiLambda?: T;
      imageLambda?: T;
      regenerationLambda?: T;
    };

this means that the user can use a prop like

runtime: {
   regenerationLamda: Runtime.NODEJS_12_X
}

this would be valid typescript prop but it would not change the runtime of the function. This would be highly deceptive.
In my opinion if we keep the line as NODEJS_14_X then we also need to update the props so that it reflects the fact that the runtime is the only option that cannot be changed for the regeneration function.

As an alternative, so that we don't change the runtime of current users unexpectedly we could keep the option to set the runtime but keep as a default the NODEJS_14_X instead of the default NODEJS_12_X that we have for all the other lambdas

@mathisobadia
Copy link
Contributor Author

mathisobadia commented Nov 19, 2021

I just noticed that the tests fail because of the snapshots I've updated the pull request to put back the previous default memory (undefined) and remove the unnecessary role that I added by mistake. This should now pass the tests

@slsnextbot
Copy link
Collaborator

Handler Size Report

No changes to handler sizes.

Base Handler Sizes (kB) (commit f63406e)

{
    "Lambda": {
        "Default Lambda": {
            "Standard": 1523,
            "Minified": 668
        },
        "Image Lambda": {
            "Standard": 1487,
            "Minified": 801
        }
    },
    "Lambda@Edge": {
        "Default Lambda": {
            "Standard": 1533,
            "Minified": 673
        },
        "Default Lambda V2": {
            "Standard": 1525,
            "Minified": 670
        },
        "API Lambda": {
            "Standard": 634,
            "Minified": 318
        },
        "Image Lambda": {
            "Standard": 1495,
            "Minified": 806
        },
        "Regeneration Lambda": {
            "Standard": 1183,
            "Minified": 544
        },
        "Regeneration Lambda V2": {
            "Standard": 1253,
            "Minified": 572
        }
    }
}

New Handler Sizes (kB) (commit c4bc4cf)

{
    "Lambda": {
        "Default Lambda": {
            "Standard": 1523,
            "Minified": 668
        },
        "Image Lambda": {
            "Standard": 1487,
            "Minified": 801
        }
    },
    "Lambda@Edge": {
        "Default Lambda": {
            "Standard": 1533,
            "Minified": 673
        },
        "Default Lambda V2": {
            "Standard": 1525,
            "Minified": 670
        },
        "API Lambda": {
            "Standard": 634,
            "Minified": 318
        },
        "Image Lambda": {
            "Standard": 1495,
            "Minified": 806
        },
        "Regeneration Lambda": {
            "Standard": 1183,
            "Minified": 544
        },
        "Regeneration Lambda V2": {
            "Standard": 1253,
            "Minified": 572
        }
    }
}

@codecov
Copy link

codecov bot commented Nov 20, 2021

Codecov Report

Merging #2050 (827a925) into master (f63406e) will increase coverage by 0.02%.
The diff coverage is 100.00%.

❗ Current head 827a925 differs from pull request most recent head c4bc4cf. Consider uploading reports for the commit c4bc4cf to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2050      +/-   ##
==========================================
+ Coverage   83.51%   83.53%   +0.02%     
==========================================
  Files         102      102              
  Lines        3658     3663       +5     
  Branches     1154     1159       +5     
==========================================
+ Hits         3055     3060       +5     
  Misses        592      592              
  Partials       11       11              
Impacted Files Coverage Δ
...rless-components/nextjs-cdk-construct/src/index.ts 93.26% <100.00%> (+0.26%) ⬆️
...s/nextjs-cdk-construct/src/utils/toLambdaOption.ts 100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f63406e...c4bc4cf. Read the comment docs.

@dphang dphang merged commit dd69323 into serverless-nextjs:master Nov 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants