Deno compatible local client

[adoublef]

trafficstars

Hey I was very interested in learning how to use Turso on my most recent Deno project.

I resorted to making a Deno compatible client for local development as Deno only had support for the web version. This has allowed me to have a consistent API to use through our local and deployment stages & feel as though I'd like to have other Deno developers interested in using LibSql have the same experience.

What would be the recommended way that we could get something going? I am not sure if it would make more sense as a 3rd party module or one that could be integrated with the official repo but I'd be keen to help contribute if possible.

Thank you

[penberg]

@adoublef How different is the code from this repository? Is there a way to make this package work both on Node and Deno? If your code is open source, please share a link.

[adoublef]

The only difference is the removal of better-sqlite3 dependency. Everything else is is designed the same. There are two Deno packages both can work but with caveats:

• Denodrivers seem to be the officially supported one but makes use of ffi's meaning that as of today, can't be used on Deno Deploy (I am unsure if this restriction will exist on other cloud platforms)
• Dyedgreen's version uses WASM and so doesn't have the same deployment restrictions but as of today they don't have the ability to check it the db connection is open (which is needed here) though I may have another look at that.

My code is open but it is just linked inside a hobby project as I originally just wanted it to work for local development. Hadn't thought of moving it into a different package. The code can be viewed here. Most of the implementation imports directly from esm.sh which is great. It was only the ResultSetImpl that I needed to change to use a Deno compatible base64 encoder

[adoublef]

With regards to the second package they do have a private property here so may just be something I can ask the maintainers to expose.

I also was not able to get this test to pass, looks like it should be a string representation but I keep getting a number value. Something that isn't an issue for me but I'd imagine this needs to work if it is to be something others will want to use.

[penberg]

@adoublef Thanks for the information! How useful is local development option if you can't use it in Deno Deploy? From libsql perspective, perhaps a better integration strategy is to have the Deno runtime use the Rust crate and then expose via a TypeScript API? We're currently working on a Rust crate that could be used for this: https://github.com/libsql/libsql/tree/main/crates/core It's still work in progress, but will support local files, embedded replicas, and HTTP remote access.

[adoublef]

@penberg great question. I would say the benefit most definitely comes from consistent API. Both current SQLite packages are incomplete, although if the Dyedgreen's version would be the closest to being usable quickly as they only need to expose the this.#close property to allow me to implement the Transactions.

I think I also started working on this prior to learning the plans of a Rust crate so I suspect will have better support so will be eager to watch out for that. I will add this as I am currently unsure if it'll apply. We wouldn't be connecting to a SQLite connection locally, but I imagine the code will still be built in that environment.

Currently my use case is still hobbyist and so I have a separate main.ts and dev_main.ts file for local and deployment. Likely not the best solution for everyone but works for me. I am still looking to see if it's possible to not do this but I'm just learning about how Rust bindings, FFIs and Deno all work together.

[adoublef]

EDIT: I asked the question in the discord and apparently this is true

As long as you do not call Deno.dlopen it should be fine, even if there's a code path that could call it.

So this is my aim at the minute to see if this is true. If so then may additionally help when it comes to calling code written in external languages

[adoublef]

I just wanted to update that this may have resolved things for both local & public deployment, meaning can use the one entrypoint and not need to mantain separate main and dev_main entrypoint files, leading to better DX.

Here is a deployed application that just selects the number 42 from turso. I am using the deno-sqlite library, I just need to push a PR for that library.

• entrypoint link - playground/cmd/libsql/main.tsx at main · adoublef-js/playground (github.com)
• library link - playground/lib/libsql/dyedgreen/create_client.ts at main · adoublef-js/playground (github.com)

[adoublef]

Just wanted to bump this by saying I moved the example over to my main project as it's a bit cleaner.

Here is the application on Deno Deploy, just querying 42 from the Turso database. Here is the code to show that there is just one implementation now which works both in local dev and in deploy

@honzasp @penberg

[adoublef]

gentle bump

[BBennettChiba]

I am experiencing this issue now

[edard3v]

I stopped using Deno for this reason, totally screwed without being able to test my DB locally.