This looks like it’s already at least 80% there, great work!
Architecture-wise I’m wondering whether the handler can be further decoupled from the handler by linking it as a prebuilt shared library (in the base layer).
As it stands this would be compiling (and statically linking) its own handler for each packaged set. I don’t know the runtime API well enough to be sure this is avoidable but seems like it should be able to have one binary running the runtime as called initially by bootstrap and running the infinite loop. And then maybe use dlopen to open the handlers dynamically in a sort of “plugin” pattern. Or just run each handler as invocations of separately-built handler binaries. I’m not sure what the performance implications would be of running a binary vs opening a shared library- if it makes no difference just running the handlers as individual binaries would be easiest to reason about and test.
That architecture has the disadvantage of having no static safety that the handler actually exists, but this is no different to js/python etc. But it has the advantage of having faster compile times, smaller binaries, less overhead, faster starts, and also running multiple handlers on a single layer - as it stands it seems like the handleName is hardcoded on init?
The only uncertain part about this architecture is that it would still need a way of sharing datatypes for event input and output between runtime and handler, or a manual coding/decoding of the input and return types in the handler. It could also be a function imported from the runtime shared library-
runLambdaFunctionHandler(_ handler: (Codable) -> Codable) which just thinly decodes stdin and encodes the handler’s return value to an IOStream (stderr?). But I’m not sure- I’m pretty new to IPC. Architecting handlers as “plugins” would make these decisions unnecessary and allow the handlers to be called directly with real error handling etc.
Sorry for the long message, I don’t expect you to actually do any of this. It’s just as much a notepad for my own ideas about it. I’m excited about the prospect of using Swift on Lambda but I don’t have a lot of time to play around with it myself at the moment so this is in case I do. But feel free of course to try any of these ideas out of you’re interested.