-
Notifications
You must be signed in to change notification settings - Fork 410
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
Add ScalaNative version of AwsLambdaRuntime
#2906
base: master
Are you sure you want to change the base?
Add ScalaNative version of AwsLambdaRuntime
#2906
Conversation
…e.scalalogging cross compiled for native and unsafeRunSync in CE
26cb0a0
to
9021fe0
Compare
I didn't yet read the whole PR, but maybe there is a JS/Native version of slf4j? then we could use that instead. |
@WojciechMazur thanks a lot for this contribution!
There's no JS/native version of slf4j. The only interesting approach I found was in log4s where they basically rewrote a part of the API, but I don't think we should go this way. I guess we'll leave your proposed logging implementation for now.
The workaround looks interesting, are there any drawbacks we should be aware of?
Do I understand correctly, that we'd like to be able to expose the |
@WojciechMazur Could you take a look at my questions? |
This PR adds a Scala Native implementation of AwsLambdaRuntime. I've used a similar implementation in my local experiments outside tapir.
There are still 3 problems with cross-compilation:
org.typesafe.scalalogging
is available only for JVM, it's usage on Scala.js and Scala Native would fail at link-time. PR contains a workaround allowing to use of a custom implementation in the form stdout logger. I'm not sure should it be included in the final version (Scala.js might not be tested currently because of the same reasons)runUnsafeSync()
method forIO
. We can workaround it by usage of Scala Promise and integration with SN internal queue execution context.lambda.Context
. That could be worked around by introducing another layer of abstraction allowing to either use AWS SDK LambdaHandler's or custom ones with Native/JS specific Context implementation. Alternatively, we could reimplement that part as a third-party library and publish only nir/sjir without bytecode (that's how Java stdlib is published to workaround double definitions on classpath)The tests have been adjusted to run with native. I'm not sure it there is some built-in support for sharing sources between jvm-native without js, which might clean this up a bit.