From what I read, I cannot really understand how L...
# ktor
o
From what I read, I cannot really understand how Lambda and #ktor can really work together. Can you explain it to me?
d
Both Lambda and servlet containers manage invoking a function in response to an HTTP request.
o
Well, abstractly, yes. But then there is an HTTP server (AWS_PROXY api gateway), that gets http request, wraps it into an AwsProxyRequest data object, sends it to Lambda, which would unpack it and pretend it’s a real http request, wrap it into servlet request, and invoke servlet handler. Why wouldn’t you put servlet handler in the first place?
d
Both manage simultaneous execution and routing. If I can invoke a servlet (or Ktor handler etc) inside Lambda then AWS will effectively run up servers on demand, and I'll only pay for CPU time. Why not just use the standard Lambda interfaces? Because then I can't deploy and test locally. And because the routing will then be in the hands of API Gateway, and again not deployable locally
My reason for wanting Ktor is that I'd like to route all requests to one endpoint and then invoke different handlers depending on the route.
I could write that behind a single servlet, but why reinvent a nice routing mechanism (and other nice features of Ktor)
o
I see. Though I don’t really know AWS API, from what I read today I can say that it is possible to create a ktor host for AWS Lambda, without servlet at all, but that has few drawbacks. One is that writing a host is relatively complex 🙂 Second is that all ktor suspendable async capabilities is of no use here and we will probably need a prototype to if it actually makes sense, might require some changes in ktor. Third is that API is quite limited, so some of the ktor functions will have to throw exceptions, e.g. websockets, cookies, etc. But may worth it, if it is economically makes sense and helps in local testing and development.
Unfortunately, I don’t have much time these days, but I can help anyone who can prototype it.
d
I agree with your analysis. I don't know whether Lambda will come to be seen as a usual deployment model for whole apps, or really just for injecting bits of code into more traditional pipelines.
I'm experimenting to find out what works for a whole app - but given that Amazon provide Spark bindings I'll go that way for now.
Let's compare notes in a couple of months.
o
Right, spark would be probably a better choice right now. It’s sync all around, and has existing adapter for Lambda. However, all the issues I mentioned above still stand.