[RFC] nx-serverless version 2.0

[wickstargazer]

Abstract

We have come a long way with ups and downs for this plugin. It has climbed onto 2k-ish download and with buggy releases climbs down to 500-ish downloads.

It has been a journey through which some might say its a waste of time to write the initiator and calling the run command manually for serverless deploy,sls functions. sleepless nights I tell ya.

Reaping the benefits The magical part of the plugin is it does dependency checks,

• compiles a package.json from yarn/npm dependency list or typescript dep-checks. It just makes working on workspace a breeze because it creates .serverlessPackage in the dist folder and manages everything there.
• node_modules per application making just deleting the whole folder having no effect on your workflow.
• all the options for deploy, sls is set through the workspace.json file! making it very clean for managing configurations.
• it can use fileReplacement option in build section to replace environment files
• copying assets is done by using assets option with glob pattern. Just like the @nrwl/node config inside workspace.json

That made today kind of a relief spending so much time on this plugin itself.

Problems!

The first version is already buggy in trying to hack these factors around serverless packaging and deployment.
Instead of using it's plugin I dug into wrapping it around

• Because of maintainability that we couldn't commit to, we did not migrate the versions of serverless and nx workspace making it out of date for the pattern and hard to maintain/collaborate
• Once we decided to migrate, it took a while and we were left with a bug that is because of lack of understanding on how Serverless works with deploying function and deploying the whole serverless app itself.
• This resulted in a long beta period until recently that we had to utilize and decided to fix it once and for all.

Finally the version 1.0.0 is running deploy per function and deploying application well and stable enough. This version however still lack the testing of the sls and destroy function. And the unit tests are BROKEN since migration.

However we had no choice but to release it because we have to start migrating the main workspace!

Idea!

During these months we also had the time to HACTH out

• @flowaccount/nx-aws-cdk
• @flowaccount/aws-cdk-stack

These two are the long term driving force for us.
The @flowaccount/aws-cdk-stack is very powerful. It is basically the cdk (cloud-formation-stack) written in typescript. It uses StackProps which are the properties of each infrastructure stack and inject into the stack constructor. Like so

source file

export class PolicyStack extends Stack {
  public readonly output: {
    policy: Policy;
  };
  constructor(scope: Construct, id: string, _props: PolicyStackProperties) {
    super(scope, id, _props);
    /// stack code to build policy
   }
 }

Allowing us to write environment.xx.ts files to be our Infrastructure Configurations. Which is so amazing because we can have different configuration in one folder and one set of source code to run it against the config. Here is a sample

policies: [
          {
            name: `${_stage}-${_app}-lambda-policy`,
            statements: [
               {
                  actions: [
                    "logs:CreateLogGroup",
                    "logs:CreateLogStream",
                    "logs:PutLogEvents",
                  ],
                  resources: [ "*" ],
                },
                {
                  actions: [
                    "ec2:DescribeInstances",
                    "ec2:CreateNetworkInterface",
                    "ec2:AttachNetworkInterface",
                    "ec2:DescribeNetworkInterfaces",
                    "ec2:DeleteNetworkInterface",
                    "autoscaling:CompleteLifecycleAction"
                  ],
                  resources: [ "*" ],
                }
              ]
            }
          ]

and we just hook it up in the cdk main.ts like so

   const policy = (new ManagedPolicyStack(app, `${policyProps.name}`, { ...policyProps, roles: [ lambdaRoleStack.output.role ] })).output.policy

Idea is that we could use a TypeScriptAssetCode to compile typescript, run node_modules using the packager.ts refactoring them somehow and deploy the function using aws-cdk

This would give amazing controls over aws resources but will need some implementations.

We have started playing around with schematics in the branch feat/nx-aws-cdk_1 and it could be very powerful tool to template Infrastructure Stacks.

It has its benefits and the flaws that it wont have any of the serverless perks! But it could grow in time to be bigger than serverless since the controls over development in typescript is amazing!

Proposal

The proposal is that in version 2.0.0 we implement a migration path towards the cdk in which we also will be looking into how to integrate dotnet serverless into the plugin.

The dotnet serverless needs a big of investigation into @nx-dotnet since that might already cover all the case, but i doubt it and maybe we can do a contribution instead.

But the goal is towards open-sourced infrastructure templates on aws-cdk and the dotnet serverless adoption.

Would love your guys comments and will be happy to elaborate with sessions/discussions/drawings!