Let's create one for `duckdb-nodejs-neo` ?

[cyrilchapon]

Hey dude, thanks for your awesome work on this.

New to DuckDB and having needs to put that into lambda functions, in here we felt like we had to use the "neo" package (the legacy duckdb one being actually deprecated by DuckDB team). On the other hand, your work here looks awesome; but is using that legacy connector.

I took time to create a "local" layer for my need with the neo connector, and documenting extensively how to do so in the relevant discussion (#184) inside the neo repo.

I now would like to package this up inside a repository and a published layer for the community, leading to basically the same thing as that current repository and layers; but for the new bindings release. Still, I don't have great experience with layers and even barely understand anything from AWS environments, si I feel like I wouldn't be able to do it by myself.

Would there be any chance we can converge all that work, possibly with the help of someone else, to make that happen ?

[tobilg]

First of all thanks for the feedback!

The neo package is not yet complete and a full replacement (see https://duckdb.org/docs/stable/clients/node_neo/overview#roadmap), while the old one was still maintained until v1.2.1, and now hasn't received an update to v1.2.2 unfortunately. I think this is a problem with the overall release management of DuckDB itself, as e.g. WASM hasn't had a non-dev release in months.

The standard Linux binaries that the neo client just wraps are to my latest knowledge not compatible with the Amazon Linux GLIBC versions. That's also the reason why the extensions need to be explicitly compiled for the Lambda runtime environment as well (see https://extensions.quacking.cloud)

In the other discussion you seem to have gotten it to run? If it works with the default binaries, why do you see a need for a layer at all? Couldn't you then just bundle it via esbuild?