search

Effect-TS / effect

An ecosystem of tools for building production-grade applications in TypeScript.
https://effect.website
MIT License
7.04k stars 222 forks source link

From Discord: AWS Lambda environment fail with `.toWebHandler` #3129

Open effect-bot opened 2 months ago

effect-bot commented 2 months ago

Summary

Summary

The conversation revolves around implementing an AWS Lambda function using effect-http, similar to how it's done with the hono framework. The user aims to create a "fat lambda" that handles all requests. Here's a summary of the key points and takeaways:

  1. Initial Inquiry:

    • The user is looking for a way to implement an AWS Lambda handler using effect-http, similar to the hono example provided.

  2. Community Input:

    • Suggestions were made to look into effect-aws and @effect/platform for potential solutions.
    • The toWebHandler function from @effect/platform was suggested as a possible solution.

  3. Code Examples:

    • An example was provided using HttpApp.toWebHandler and HttpApp.toWebHandlerLayer to create the handler.
    • The importance of using HttpApp.toWebHandlerLayer for performance reasons was highlighted.

  4. Issues Encountered:

    • The user encountered errors when trying to use the provided code with SST Ion.
    • Errors included issues with addEventListener and missing files (ENOENT).

  5. Root Cause Analysis:

    • The errors were traced back to the Request object missing the AbortController API support.
    • It was suggested that AWS Lambda's Node.js 18 runtime might not fully support the Fetch API, specifically the AbortController.

  6. Potential Solutions:

    • Adding /* global fetch */ to the start of the file was suggested but deemed insufficient.
    • Using a polyfill for AbortController was considered but might not resolve the issue since the Request object comes from AWS.

Key Takeaways

  1. Compatibility Issues:

    • AWS Lambda's Node.js runtime may not fully support the Fetch API, particularly the AbortController and AbortSignal.

  2. Performance Considerations:

    • Use HttpApp.toWebHandlerLayer to avoid performance issues related to reading files from disk on every request.

  3. Error Handling:

    • Be prepared to handle errors related to missing API features and file paths in the AWS Lambda environment.

  4. Community Support:

    • The effect-http project is community-driven, and solutions may require collaboration and experimentation.

  5. Documentation and Examples:

    • There is limited documentation and examples available for integrating effect-http with AWS Lambda, indicating a need for more community contributions and shared knowledge.

By addressing these key points, the user can better navigate the challenges of implementing effect-http with AWS Lambda and potentially contribute to the community's knowledge base.

Discord thread

https://discord.com/channels/795981131316985866/1256526365008728097

datner commented 2 months ago

when using SST Ion and calling HttpApp.toWebHandler the following error pops Cannot read properties of undefined (reading 'addEventListener') It points to request.signal.addEventListener("abort", ...) the issue is that in aws lambdas the fetch API spec is not complete meaning that the Request is missing AbortController api support, the kind that would give it the .signal property. Supposedly aws lambda support it in their nodejs 18 lambdas but according to everyone else besides aws thats not true and you must add /* global fetch */ to the start of the file, but even then it seems that it's not enough and it does not make AbortController and AbortSignal available There is a suggested polyfill but it won't help us because the the Request is coming straight from the lambda

mikearnaldi commented 2 months ago

Well, calling it a platform bug is quite a stretch given it's AWS that is not spec-compliant. BTW make sure comments are not removed in the build pipeline, otherwise /* global fetch */ has no effect

datner commented 2 months ago

@mikearnaldi Ah, I am not the one impacted lol I think it's a bug because it breaks in /platform, not /platform-node or something.. In general Request is not a platform-agnostic concept. node can't produce a server that speaks in Request and Response for example. It only knows IncomingMessage and OutgoingMessage which also have different semantics (for the node-native http and https they inverse at the boundaries, you send OutgoingMessage and receive it as an IncomingMessage, send back an OutgoingMessage and it arrives as an IncomingMessage), It can be 'fixed' (mitigated) with a simple check for the existence of the signal. Not fixing this means that even if we were to release a theoretical /platform-aws, it'll be inoperable unless it ships it's own AwsHttpApp.toWebHandler

mikearnaldi commented 3 weeks ago

cc @tim-smart