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
With the release of #402, we now have two closures serializeres.
V1 - closure serializer based off of Pulumi's closures serializer. It uses the debugger API and is heavily limited, for example not properly serializing free variables such that mutations can be observed, cannot capture this, cannot serializer Proxies or bound functions, and has no source map support and therefore produces code that is not production worthy. The code for this serializer is also a spaghetti nightmare, making it impossible to maintain. Finally, the implementation is extremely SLOW and asynchronous, making it a bad fit for use within CDK Constructs.
V2 - our own serializer that takes advantage of the ast-reflection pre-processing step. We decorate all of a user's code with its AST information to support features such as IAM policy inference and the Functionless interpreteres. We now also use this information to provide a fast and synchronous closure serializer with out any of the aforementioned limitations. Our ast-reflection package can always be updated to inject more information to help support the serializer, meaning we are not constrained by the limitations of the V8 debugger API.
As of now, we still default to the V1 serializer - users must opt-in to use V2 to get all of its benefits. This task is to go through the process of thoroughly testing the new serializer so that we are confident in moving over to it first class. V2 has been tested against all of the test cases in functionless but this does not give us the confidence we need.
This task can be achieved int he following steps:
thoroughly explore test cases for the new serializer in serializer-cloures.test.ts - tests are pretty good but not thorough enough yet
update the default serializer to V2 but still allow users to opt-out and go back to V1
once we are confident enough, remove V1, delete the SerializerImpl enum, deprecate the @functionless/nodejs-closure-serializer package and delete the repository/change it to private.
The text was updated successfully, but these errors were encountered:
With the release of #402, we now have two closures serializeres.
V1
- closure serializer based off of Pulumi's closures serializer. It uses the debugger API and is heavily limited, for example not properly serializing free variables such that mutations can be observed, cannot capturethis
, cannot serializer Proxies or bound functions, and has no source map support and therefore produces code that is not production worthy. The code for this serializer is also a spaghetti nightmare, making it impossible to maintain. Finally, the implementation is extremely SLOW and asynchronous, making it a bad fit for use within CDK Constructs.V2
- our own serializer that takes advantage of the ast-reflection pre-processing step. We decorate all of a user's code with its AST information to support features such as IAM policy inference and the Functionless interpreteres. We now also use this information to provide a fast and synchronous closure serializer with out any of the aforementioned limitations. Our ast-reflection package can always be updated to inject more information to help support the serializer, meaning we are not constrained by the limitations of the V8 debugger API.As of now, we still default to the V1 serializer - users must opt-in to use V2 to get all of its benefits. This task is to go through the process of thoroughly testing the new serializer so that we are confident in moving over to it first class. V2 has been tested against all of the test cases in functionless but this does not give us the confidence we need.
This task can be achieved int he following steps:
serializer-cloures.test.ts
- tests are pretty good but not thorough enough yetSerializerImpl
enum, deprecate the @functionless/nodejs-closure-serializer package and delete the repository/change it to private.The text was updated successfully, but these errors were encountered: