You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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
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!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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,
package.json
from yarn/npm dependency list or typescript dep-checks. It just makes working on workspace a breeze because it creates.serverlessPackage
in thedist
folder and manages everything there.node_modules
per application making just deleting the whole folder having no effect on your workflow.deploy
,sls
is set through theworkspace.json
file! making it very clean for managing configurations.fileReplacement
option inbuild
section to replace environment filesassets
option withglob
pattern. Just like the@nrwl/node
config inside workspace.jsonThat 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
Finally the version
1.0.0
is runningdeploy per function
anddeploying application
well and stable enough. This version however still lack the testing of thesls
anddestroy
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
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 usesStackProps
which are the properties of each infrastructure stack and inject into the stack constructor. Like sosource file
Allowing us to write
environment.xx.ts
files to be ourInfrastructure 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 sampleand we just hook it up in the cdk
main.ts
like soIdea is that we could use a
TypeScriptAssetCode
to compile typescript, run node_modules using thepackager.ts
refactoring them somehow and deploy the function usingaws-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 integratedotnet
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 thedotnet
serverless adoption.Would love your guys comments and will be happy to elaborate with sessions/discussions/drawings!
Beta Was this translation helpful? Give feedback.
All reactions