xlite VS spacedrive

There is similar open-source project for Google Sheets: https://github.com/0x6b/libgsqlite (SQLite extension), which is a fork of https://github.com/x2bool/xlite (same idea but for Microsoft Excel spreadsheets)

This project actually started as a fork of https://github.com/x2bool/xlite - SQLite extension for querying .xls and .xlsx spreadsheets.

Hey, author here, happy to answer any questions! Also checkout this notebook for a deeper dive into sqlite-lines, along with a slick WASM demonstration and more thoughts on the codebase itself https://observablehq.com/@asg017/introducing-sqlite-lines

I really dig SQLite, and I believe SQLite extensions will push it to another level. I rarely reach for Pandas or other "traditional" tools and query languages, and instead opt for plain ol' SQLite and other extensions. As a shameless plug, I recently started a blog series on SQLite and related tools and extensions if you want to learn more! Next week I'll be publishing more SQLite extensions for parsing HTML + making HTTP requests https://observablehq.com/@asg017/a-new-sqlite-blog-series

A few other SQLite extensions:

- xlite, for reading Excel files, in Rust https://github.com/x2bool/xlite

- sqlean, several small SQLite extensions in C https://github.com/nalgeon/sqlean

- mergestat, several SQLite extensions for developers (mainly Github's API) in Go https://github.com/mergestat/mergestat

In the video, Mo talked about a few packages like Cidre and StrOm, and we referred to SpaceDrive.

AGPLv3 (switched in 2022 https://github.com/spacedriveapp/spacedrive/commit/8e5c71dea... ) and FWIW I don't see any mention of CLA or other license assignment, so I don't believe they can currently rug pull containing contributed changes since they don't own the license for them: https://github.com/spacedriveapp/spacedrive/blob/main/CONTRI...

Already opened a bug report for that: https://github.com/spacedriveapp/spacedrive/issues/1481

While Electron wouldn't be on top of my wishlist, if it looked nice and was functional I wouldn't mind at all. I found this project https://github.com/spacedriveapp/spacedrive which uses Tauri and seems to be very interesting, but they haven't released yet

In Tauri (or Axum) the app compiles to a single binary. rspc is the key to this because it allows for multiple transports with the frontend. It supports both Tauri IPC, HTTP or websockets. Our core crate (at ./core) exports an rspc router that is transport agnostic then within the apps (at ./apps/desktop or ./app/server) we expose it with a transport. We use Tauri IPC for desktop and websockets for Axum because we use subscriptions. Then in the wrapper React project (at ./apps/desktop/src/App.tsx) we create the rspc client with the Tauri link, mount its React context and then mount the app package (). You can give the codebase a look if you want cause it’s all open source https://github.com/spacedriveapp/spacedrive

Taking a departure from REST and GraphQL, I'd suggest checking out rspc instead of GraphQL and Prisma Client Rust as your ORM. Both have been developed by a coworker and I for Spacedrive, the company we work for, and have provided what we believe is the best Rust + TypeScript stack that doesn't use GraphQL (new GrpahQL server incoming one day tho).

This might help https://github.com/spacedriveapp/spacedrive