Nx: Serverless (via AWS SAM) support?

[studds]

Hello there

Love nx, very brilliant.

We're a serverless shop, using AWS SAM . Would you consider a PR adding schematics for serverless? Or is it better to do it as an independent lib?

Cheers

Daniel

[FrozenPandaz]

1, I think that would be an amazing tool.

I think it would be better if it is an independent library for now. I'm not sure if we would be able to maintain it well at the moment. If it works well, we'd love to recommend. 👍 We can help you make it happen.

@vsavkin What do you think?

[studds]

Thanks @FrozenPandaz :-)

I've made a start with this here: https://github.com/studds/nx-aws

Feedback would be very welcome :-) I'm starting with the builder first, so far just building on top of the nx node builder. I'll need to add new builders to run the package / deploy steps. Then the schematics. I assume that's a sensible way to approach it?

A couple of questions:

• Is it possible to export the run function from https://github.com/nrwl/nx/blob/4bf61ed695e394e13770e487f106538ec4f20265/packages/node/src/builders/build/build.impl.ts so that I can reuse it rather than rewriting it?
• My existing build has some codegen, generating ts validation functions from typescript interfaces. And / or hints on how best to approach this as a ng builder? Any prior art you can point me to?

[vsavkin]

Thank you for your work.

Exporting the run function is an interesting idea. @FrozenPandaz do you know if there is a way to invoke a builder without doing it? Similar to externalSchematic?

[alfaproject]

Isn't it what the e2e task does? It builds another target

[studds]

@vsavkin @alfaproject quick update, tried to use context.scheduleBuilder but it fails because context.target.project is undefined at:

https://github.com/nrwl/nx/blob/e51c7a4069874d7da3f876cf3a33610f38d9649c/packages/node/src/builders/build/build.impl.ts#L80

I assume scheduleTarget would work, but that would mean adding an additional target to angular.json, which might not be so bad in the scheme of things... but it would be kinda nice to be able to 'extend' the existing builder. This seems to be what the angular-cli builders do (or at least enable): https://github.com/angular/angular-cli/blob/8e97df38889b201aebf361ce7e8e07673411cb31/packages/angular_devkit/build_angular/src/browser/index.ts#L170 (I think I recall coming across a clear example where the full builder was reused in the angular source, but I can seem to find it now.)

[FrozenPandaz]

Fantastic work @studds!

scheduleBuilder should be the way to go. @nrwl/node:build should consider the fact that target is optional. We use it in the following places:

1. https://github.com/nrwl/nx/blob/4bf61ed695e394e13770e487f106538ec4f20265/packages/node/src/builders/build/build.impl.ts#L80
   a. It's a bit awkward but we can accept a sourceRoot option instead of using the context.target to get it.
2. https://github.com/nrwl/nx/blob/4bf61ed695e394e13770e487f106538ec4f20265/packages/node/src/builders/build/build.impl.ts#L44
   a. This one is simple, we can send undefined

I do wish that the context would be inherited... I'll reach out to the Angular CLI team.

[studds]

@FrozenPandaz thanks for the feedback. For now, I've copied and pasted the node build.impl.ts to my project, in anticipation of being able to use scheduleBuilder down the track. By the by, any reason this project doesn't use strictNullChecks, which would've made these issues apparent immediately?

I'd offer to do a PR for the changes you've outlined, but I'm guessing there would also need to be a migration done, and I haven't learnt that part yet. I've very limited time to work on this builder at all, over my breakfast :-)

[studds]

I've published a rough version as https://www.npmjs.com/package/@nx-aws/sam with builders for building, packaging, and deploying.

Note the lack of a readme :-) Early days.

[wickstargazer]

Hi i have published a simple version to use with serverless framework...it works with the angular only currently...
https://www.npmjs.com/package/@flowaccount/nx-serverless thankz to @studds for inspiring the project, this one through the serverless framework :)

[FrozenPandaz]

Hi, sorry about this.

This was mislabeled as stale. We are testing ways to mark _not reproducible_ issues as stale so that we can focus on actionable items but our initial experiment was too broad and unintentionally labeled this issue as stale.

[ajhool]

In the ínterim, can aws sam (or cloudformation templates) be manually integrated into the nx deployment process?

[studds]

It's possible to manually integrate sam / cloudformation manually using https://nx.dev/angular/workspace/builders/run-commands-builder - I use run-commands quite a bit. That said, I wasn't satisfied with this myself, so I've invested a bit of time creating builders specifically for sam.

I'm using https://www.npmjs.com/package/@nx-aws/sam daily, and it's working well for my use case (which is quite complex - stacks in multiple regions, inter-dependencies, dev and prod deployments). There's also a deploy builder for s3. The documentation is not really up to snuff, though - something I've been meaning to find the time to work on. If you've got any questions, raise an issue here: https://github.com/studds/nx-aws/issues

[ajhool]

Thanks @studds. One more question... when you were "not satisfied," was it because the nx integration was causing an additional burden or is it the same burden that exists when managing cloudformation stacks outside of nx?

Basically, if I can manually add SAM / cloudformation deployments in the same way that I am currently doing, then I don't mind. It would only be a new problem if nx actually interfered with normal ways of adding SAM. One concern is if the nx typescript build / packaging tools will cause too many dependencies to be pulled into a lambda dist file. I have been using webpack for tree-shaking and minification of lambda deployments and am worried that nx might break webpack treeshaking.

I will check your tools out!

[studds]

@ajhool definitely no additional burden. You can run the same webpack and Sam commands as you’re using now. So really, if you’ve only got a single stack and everything is working fine, then run-commands is probably all you need.

A few of the main differences: @nx-was/sam inspects your cloudformation template and generates an appropriate webpack build, and saves a step there. It also has some smarts around parameter overrides when deploying. It makes managing nested stacks easier, by modelling them as separate nx projects. It also makes it easier to manage “soft” dependencies between stacks (as opposed to “hard” dependencies using exported stack outputs).

[github-actions[bot]]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[bryantbiggs]

noooooooo!