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

Add ScalaNative version of AwsLambdaRuntime #2906

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

WojciechMazur
Copy link
Contributor

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)
  • Cats-Effect does not provide a runUnsafeSync() method for IO. We can workaround it by usage of Scala Promise and integration with SN internal queue execution context.
  • We cannot use directly AWS SDK 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.

@WojciechMazur WojciechMazur force-pushed the serverless/add-scala-native-runtime branch from 26cb0a0 to 9021fe0 Compare May 19, 2023 21:48
@adamw
Copy link
Member

adamw commented May 21, 2023

I didn't yet read the whole PR, but maybe there is a JS/Native version of slf4j? then we could use that instead.

@kciesielski
Copy link
Member

@WojciechMazur thanks a lot for this contribution!

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)

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.

Cats-Effect does not provide a runUnsafeSync() method for IO. We can workaround it by usage of Scala Promise and integration with SN internal queue execution context.

The workaround looks interesting, are there any drawbacks we should be aware of?

We cannot use directly AWS SDK 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)

Do I understand correctly, that we'd like to be able to expose the Context to tapir endpoints, so that devs can use it in their handling logic?

@kciesielski
Copy link
Member

@WojciechMazur Could you take a look at my questions?

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

Successfully merging this pull request may close these issues.

3 participants