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

AWS Context not exposed #18

Open
moeriki opened this issue Mar 20, 2020 · 4 comments
Open

AWS Context not exposed #18

moeriki opened this issue Mar 20, 2020 · 4 comments
Labels
enhancement New feature or request

Comments

@moeriki
Copy link
Contributor

moeriki commented Mar 20, 2020

The default AWS handler has two arguments: event, and context.

It seems like context is not used in curveball, which is fine. But it would be convenient to have it available on the ctx.request.

Right now if I want to access the AWS context I have to do this before forwarding the event to Curveball.

export function handle(event: any, context: Context): Promise<any> {
  context.callbackWaitsForEmptyEventLoop = false;
  return handler(app)(event);
}

Additionally there are internal types for AwsRequest and AwsResponse that are not exposed. I had to type them as any in the code above.

Would you accept PR to:

  • add AWS context under ctx.request.awsContext, or other suggestions?
  • expose types AwsRequest and AwsResponse
@evert
Copy link
Member

evert commented Mar 20, 2020

Sounds like a great idea.

I think I would like the property to live on ctx, not ctx.request.

Since the last curveball version Context is now an interface, so it's possible to also get full typing for it via declaration merging.

So maybe ctx.aws.context and ctx.aws.event ?

@evert evert added the enhancement New feature or request label Mar 20, 2020
moeriki added a commit to moeriki/aws-lambda that referenced this issue Mar 21, 2020
@moeriki
Copy link
Contributor Author

moeriki commented Mar 21, 2020

Oh yeah ctx.aws makes total sense.

I made a WIP PR to get the idea across. Is that what you had in mind?

I set the context for now to any. I was wondering if you know about @types/aws-lambda? It's got types for the AWS context, event (request), response, and context. At the moment these are typed within this package. Is there a reason for not using it? And would you mind using aws-lambda types instead.

@evert
Copy link
Member

evert commented Mar 22, 2020

I'm very down with using @types/aws-lamba! I recently worked on https://github.com/curveball/azure-function/ , and did the same there.

Makes total sense.

@moeriki
Copy link
Contributor Author

moeriki commented Mar 22, 2020

Great. I will make the PR for that first then. So I can immediately use the existing aws Context interface.

moeriki added a commit to moeriki/aws-lambda that referenced this issue Mar 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants