Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the Hrana protocol #28

Open
Ehesp opened this issue Oct 30, 2024 · 3 comments
Open

Support the Hrana protocol #28

Ehesp opened this issue Oct 30, 2024 · 3 comments

Comments

@Ehesp
Copy link
Collaborator

Ehesp commented Oct 30, 2024

Is your feature request related to a problem? Please describe.

The hrana protocol specification is a standard protocol which allows communication over a network to an SQLite DB. It's developed by Turso for their own platform solution.

Describe the solution you'd like

It'd be great to explore whether this spec fits into the DO SQLite model, as some tools out there such as ORMs are developed again this spec for communication.

Describe alternatives you've considered

N/A

Additional context

  • The spec allows for stored SQL statements, which would fit great with a DO too given we can use kv/transaction storage.
  • The spec is provided in protobuf format, so we'd need to generate a static client (via the protobuf API) to use in a worker environment (runtime API requires eval).
@notrab

This comment has been minimized.

@Ehesp
Copy link
Collaborator Author

Ehesp commented Oct 31, 2024

opportunity to formalise a "standard" for SQLite over HTTP

Isn't this exactly the Hrana spec? For example using https://github.com/libsql/hrana-client-ts in TS adheres to it. I think what your suggesting is that it might be a little too "low level" than say the GQL spec

@notrab
Copy link

notrab commented Oct 31, 2024

opportunity to formalise a "standard" for SQLite over HTTP

Isn't this exactly the Hrana spec? For example using https://github.com/libsql/hrana-client-ts in TS adheres to it. I think what your suggesting is that it might be a little too "low level" than say the GQL spec

For sure yeah, but what I was suggesting is actually more abstract. What you linked to almost would be a reference implementation.

I've been told there's an effort in the industry to push something more formal for SQL over HTTP, so that's probably better.

Disregard my suggestion heh 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants