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

Splitting Lambda specific parts out of llrt_core #351

Open
KaanMol opened this issue Apr 30, 2024 · 1 comment
Open

Splitting Lambda specific parts out of llrt_core #351

KaanMol opened this issue Apr 30, 2024 · 1 comment

Comments

@KaanMol
Copy link
Contributor

KaanMol commented Apr 30, 2024

After splitting LLRT up in 2 parts llrt and llrt_core the next step would be to look for a way to split lambda logic out of LLRT to its own thing.

Options would be:

  • llrt, llrt_core and llrt_lambda or something like it;
  • llrt (with a feature flag lambda) and llrt_core;

The AWS libraries would also be stripped out of llrt_core.
@richarddavison gave the solution for that here.

The ConsoleModule will require the most effort to split in two parts, in issue #341 it was stated that this module could be rewritten. @richarddavison would you happen to know when this is planned?
My current solution for this would be to put the default ConsoleModule without the Lambda logic in llrt_core and in the Lambda feature flag/lambda package it would contain its own version of the module that would be used instead of the default one, since the module builder would allow for that now. We could make the utils for the console modules public, so the other package could just use the methods it needs.

If you have any other ideas on how to do this, please let me know :)

@richarddavison
Copy link
Contributor

After splitting LLRT up in 2 parts llrt and llrt_core the next step would be to look for a way to split lambda logic out of LLRT to its own thing.

Options would be:

  • llrt, llrt_core and llrt_lambda or something like it;
  • llrt (with a feature flag lambda) and llrt_core;

The AWS libraries would also be stripped out of llrt_core. @richarddavison gave the solution for that here.

The ConsoleModule will require the most effort to split in two parts, in issue #341 it was stated that this module could be rewritten. @richarddavison would you happen to know when this is planned? My current solution for this would be to put the default ConsoleModule without the Lambda logic in llrt_core and in the Lambda feature flag/lambda package it would contain its own version of the module that would be used instead of the default one, since the module builder would allow for that now. We could make the utils for the console modules public, so the other package could just use the methods it needs.

If you have any other ideas on how to do this, please let me know :)

I will rewrite console after and it should not affect this. The only thing the differs Lambda console from the regular console is how it's formated before output. My suggestion here would be to have two console implementations. The base console and the Lambda console. That implement ConsoleModule trait which contains all the methods.

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

No branches or pull requests

2 participants