search

tursodatabase / libsql-client-ts

TypeScript/JavaScript client API for libSQL
https://docs.turso.tech/sdk/ts/quickstart
MIT License
226 stars 32 forks source link

Local dev UX paired with edge hosting without node API #40

Closed 55lj closed 1 year ago

55lj commented 1 year ago

Sorry for the vague title, what I mean: If you host on a edge functions hoster without node you need the `/web' client. But latter doesn't work with local sqlite files (which you need for you local dev env), so you need to import also the normal node driver. Which again blocks deployment on the edge hoster.

Now you can try a dynamic import depending on the env but this again doesn't work with some frameworks such as vite (they have dynamic import support but it's a bit fragile and trouble-shooting is no fun).

IDK any better solution but maybe we need also to use the web version locally. But then we'd need sqld running in parallel which isn't super nice but not a dealbreaker either and it would reflect the poduction env more closely. Or do you have better ideas?

Edit: Also, the dynamic import takes 50ms, which is dealbreaker because it happens on every request on the edge,

55lj commented 1 year ago

Or another idea: You assume that users have their "local" dev environment also with you in the cloud. Planescale does this (mainly because of their fancy branching feature but it solves this problem as a bonus). It'd cost you more to provide these additional resource (1 dev instance without replicas) but the dev experience would be significantly smoother.

This could be also applied to D1 since you get already 10 dbs on the free tier, so you could just make one of them the dev version.

55lj commented 1 year ago

I've realized you offer 3 databases in the free tier, so problem solved and there's no need for a local sqlite. So closing this issue (but maybe the docs should address this).

CodingDoug commented 1 year ago

We spent a lot of time trying to get this scenario for local development to work out. To be frank, it just doesn't work as well as we'd like, for some of the reasons you mentioned. The variety of import options are a direct result of these difficulties, and you have to choose the one that best fits your situation.

Right now, running sqld locally is the best available local option when you can't use the @libsql/client import that can work with local files.

We're working on improving this any way we can, but as you can imagine, it's not a straightforward problem to solve!