Remove native client

[calavera]

This allows using the runtime interface on Windows or MacOS since it doesn't depend on the Linux native client anymore.

Signed-off-by: David Calavera [email protected]

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[calavera]

Can any of the maintainers help me debug the integration tests? I see an error in the log, but I have no idea how to reproduce it in isolation:

https://github.com/aws/aws-lambda-python-runtime-interface-client/pull/12/checks?check_run_id=1671731745#step:4:1218

[EDIT] I think I managed to solve the problem 🎉

[carlzogh]

Hey @calavera - thanks for your contribution!

The native client provides a significant performance boost for the function runtime, and thus we're reluctant to simply remove it.

One thing we would consider is an alternate strategy to use Python's built-in modules if the user explicitly wants it to be so. Potentially this could be implemented either as a fallback for when the native installation fails, or as a separate pip package from the same codebase.

I'm reluctant to automatically default to the built-in Python HTTP client version if the native installation fails, as that could be unintentional where users might have a couple of missing dependencies and don't realize that they ended up with the less performant installed version of the two variants. I'd rather this be a conscious decision for the user to make instead.

[calavera]

The native client provides a significant performance boost for the function runtime, and thus we're reluctant to simply remove it.

that's interesting. Do you have metrics about it? I understand your concerns, I'm curious because I've only seen this interface, and the javascript one using that same native client, while other runtimes, like ruby, rust, and go use their language http stack. To be honest, I'm not super familiar with Python.

Potentially this could be implemented either as a fallback for when the native installation fails, or as a separate pip package from the same codebase.

I'm going to take a look at what this could entail.

I'd rather this be a conscious decision for the user to make instead.

got it

[carlzogh]

Do you have metrics about it?

Performance test comparisons showed latency reductions of around 30% at p50 and 25% at p99.

I've only seen this interface, and the javascript one using that same native client, while other runtimes, like ruby, rust, and go use their language http stack.

The NodeJS Runtime Interface Client follows the same approach, yes - and a similar resolution for an alternative language-native client installation (without native cURL bindings) could be considered there as well! We've opted not to do this for the Ruby client for the time being, but it's surely something we could consider further down the line for similar performance improvements.

Thanks again for your interest in contributing to this library! :)

[calavera]

and a similar resolution for an alternative language-native client installation (without native cURL bindings) could be considered there as well!

😉 😄

aws/aws-lambda-nodejs-runtime-interface-client#8