Earlier quoted context omitted.
There is a literal SQL store in the browser its the sqlite Wasm port. Its just panning out a little differently.
Which works only on Chrome, IIRC.
Not true, it is supported in all the major browsers.
Accidental database programming
301–310 of 310 posts
Re: Accidental database programming
#302Earlier quoted context omitted.
I'm on the fat client train with my company and I nudge my clients that way if they're open. It's just a great way to build a system.
Ohh can't wait for the inevitable next step of dropping the "web" part of web assembly and doing, ya know, native fat clients again.
Basically what proper mobile OS applications are.
Re: Accidental database programming
#303Earlier quoted context omitted.
> 1. always refetch data. always in sync, but needs a server request, so it's slow Except you're not fetching data in htmx, you're fetching hypertext . This is an important distinction. With a JS app you fetch data, integrate it into some local data structure that is then rendered into some form that generates HTML that the browser then renders. With htmx, all of those steps happen in the (faster) server, and the cli…
i get that, and it's a good distinction, but it's not the same as removing a server/network request
If apps are structured differently as I said, then that does change the pattern and possibly even the total number of network requests. I've seen a few anecdotal reports of reductions in complexity and latency. I would like to see a more systematic study of this to eliminate the possibility that this may be due to second iterations typically being better engineered than the first when the problem was not fully understood.
Re: Accidental database programming
#304Author here. Finally got through most of the questions, will keep checking periodically for ones I've missed (has someone built a better way to track HN discussions?). I'm very happy to see the discussion thus far. This first post focused on the parts of frontend engineering that motivated me to create SQLSync rather than specifically how SQLSync works. I'll be addressing that in my next post. Thanks for all the grea…
Any plans to support mobile? That’s where I’d consider using this most.
Yes! I'm looking at how to evolve this into a native SQLite extension which would dramatically improve distribution.
Re: Accidental database programming
#305> writing all the data mutation logic within a reducer that can be easily shared on both the client and the server This part… makes me feel odd. Is it actually realistic? Reducers for everything, keeping WASM and backend code in sync. Sounds like a lot of work and cognitive overhead.
The idea is that the reducer is your backend code. Think about it like writing your normal API layer. You handle requests and make changes to the database. Since it's Wasm, SQLSync automatically runs it on both the client and the server. Thus you've written your backend once but ran it everywhere.
As for the question of "what if my backend should access stuff that the client doesn't have access to" - the answer is that the reducer doesn't need to do the same thing in both environments. It's easy to call out from the Reducer into an Auth API which only runs on the server. SQLSync will guarantee that everyone reaches a consistent state even if the same mutation results in different outcomes when run locally vs remotely.
Re: Accidental database programming
#306Earlier quoted context omitted.
Any plans to support mobile? That’s where I’d consider using this most.
Yes! I'm looking at how to evolve this into a native SQLite extension which would dramatically improve distribution.
Hey, finally got around to reading the article. I have been grappling with the convoluted, fucked up mess that is offline first over the last 6 months. I really truly thought that this was a solved problem which the likes of facebook, instagram, etc have solved a long time ago and that there was some open source version copying whatever underlying mechanism they created.
As for the prior art, I was surprised you didn't mention watermelonDB. It sounds like what you are building but specifically for react native. I tried to use it but there were lots of really annoying api choices regarding how the querying works in the front end and their choices on how their ORM works. But the sync methodology they use seems to be sound, and as they say, they've thought long and hard about. https://watermelondb.dev/docs/Sync/Intro
The project as it is seems pretty low level. Are you planning on adding and ORM layer, or leave that up to someone else?
The last question that I always have is, how would this project create a facebook app clone? IE the user will almost always have subsets of tables that are much much smaller than the full tables the the backend has.
IE, a user should have various posts from the feed, and various users, photos, comments and liked tables downloaded for the next 30 minutes of offline activity lets say. In this system, it seems like we are syncing entire databases. But syncing small slivers of the entire system seems to be what a lot of your typical REST based apps do. Yet it is a problem I haven't been able to solve cleanly or with a unified plan of attack
Thanks
Re: Accidental database programming
#307> writing all the data mutation logic within a reducer that can be easily shared on both the client and the server This part… makes me feel odd. Is it actually realistic? Reducers for everything, keeping WASM and backend code in sync. Sounds like a lot of work and cognitive overhead.
The idea is that the reducer is your backend code. Think about it like writing your normal API layer. You handle requests and make changes to the database. Since it's Wasm, SQLSync automatically runs it on both the client and the server. Thus you've written your backend once but ran it everywhere. As for the question of "what if my backend should access stuff that the client doesn't have access to" - the answer is th…
Sounds pretty cool on paper.
Re: Accidental database programming
#308This seems to be one of those problems that entirely disappears by ditching SPAs. Using solutions from the Hotwire or htmx family would mean that a query is just a server query - making those fast is a better-understood problem.
But , if I can be honest, solutions such as Hotwire or Livewire are not as snappy as a SPA. I personally prefer InertiaJs [1], which is some kind of front-end router system with its state synced with the server in an "old style" fashion. [1] https://inertiajs.com
+1
We're also using Inertia in a pretty large project and we're super happy with it.
Re: Accidental database programming
#309Earlier quoted context omitted.
> What is exactly hard about sql? - No non-nullable types (at the expression level). No way to express e.g. normal boolean logic - No real data structures (at the expression level), unless you count rows, which are not first-class values. Even collections aren't first-class - Very awkward control flow constructs. E.g. look at how you write recursive queries. Even if/else is weird. It's a classical Turing Tarpit: ever…
What are your thoughts on the prql language?
Sounds promising. I haven't had the chance to actually use it though.
Re: Accidental database programming
#310Earlier quoted context omitted.
I agree, most SPA's are very poorly designed. But others work so well that you don't even notice it. Random examples: Gmail, Notion.
> Well designed > gmail I too, enjoy satire.
Why? Gmail is one of the most used webapps in the world, surely it shows its age, but it's doing its job pretty well, and way better than all the other commercial webmail clients I've tried.