Live data from Hacker News

Accidental database programming

sqlsync.dev

11–20 of 310 posts

Re: Accidental database programming

#11
The thing I've used for this kind of problem is fusejs which is a lightweight search index. You can load it with a list of JSON documents and do structured or fuzzy string searches. I find it pretty well-suited to the kind of frontend experiences I need a lot of data for.

Re: Accidental database programming

#12
post #9

Can someone explain me how it's syncing the state between two different devices without any activity in the Network tab in DevTools, not even WS traffic? I get that you can sync state between browser tabs, but I'm trying on two different devices (iPhone and Desktop). And as far as I can tell, the Wasm layer can't perform network requests directly. UPDATE: In the console tab I can see 'coordinatorUrl: 'wss://sqlsync.o…

Websockets tracking in the browser can be weird. Try refreshing the page while you have WS selected in the Network tab

Re: Accidental database programming

#14
post #3

Is this supposed to be run on the server? Then how does it really solve the frontend side of issues, I'm just trying to understand.

Not involved with the project but - this is a database which run client side and sync with a database on the server

Re: Accidental database programming

#16
Trying to synchronize state between client & server is a cursed problem.

You can sidestep it altogether if you make mild UX sacrifices and revert to something more akin to the PHP/SSR model. SPA is nice, but multipart form posts still work. Just the tiniest amount of javascript can smooth out most of the remaining rough edges.

Our latest web products utilize the following client-side state:

  3rd party IdP claims for auth
  1st party session id in query args
  The current document
For the first item, I genuinely don't even know where this is stored. It's Microsoft's problem, not ours. All other state lives on the server. We treat the client more or less like a dumb terminal that punches s all day. We don't even use first party cookies or local storage to get the job done. This dramatically improved our development experience for iOS/Safari targets.

So, I would ask this: What is the actual experience you are trying to offer, and why does it justify decoupling of client & server state?

Re: Accidental database programming

#17
post #16

Trying to synchronize state between client & server is a cursed problem. You can sidestep it altogether if you make mild UX sacrifices and revert to something more akin to the PHP/SSR model. SPA is nice, but multipart form posts still work. Just the tiniest amount of javascript can smooth out most of the remaining rough edges. Our latest web products utilize the following client-side state: 3rd party IdP claims for a…

It's a very common trend for consumer-facing GUI's to have optimistic rendering, and if you're doing that then you're juggling client/server state. I still see spinning loaders here and then but they're generally for initial content load; e.g., does Gmail make you wait when you archive an email?

Re: Accidental database programming

#18
post #9

Can someone explain me how it's syncing the state between two different devices without any activity in the Network tab in DevTools, not even WS traffic? I get that you can sync state between browser tabs, but I'm trying on two different devices (iPhone and Desktop). And as far as I can tell, the Wasm layer can't perform network requests directly. UPDATE: In the console tab I can see 'coordinatorUrl: 'wss://sqlsync.o…

Websockets tracking in the browser can be weird. Try refreshing the page while you have WS selected in the Network tab

I did that!

Re: Accidental database programming

#19
This looks interesting and i might give it a try, but after watching the talk i'm still a bit unclear why you choose for wasm-in-wasm for the reducer.

I suspect you would be better off by creating a rust reducer trait, and lifting that wasm-in-wasm complexity into a new crate implementing the reducer trait through wasm-in-wasm for the people who want that.

But maybe i'm missing something.

Re: Accidental database programming

#20
Anyone remember when "frontend applications" were actual applications and not web pages? I'm willing to bet we have reached that point where new devs literally do not remember that time.

  There comes a time [..] where we [..] need to cache data from an API. It might start off benign – storing a previous page of data for that instant back button experience, implementing a bit of undo logic, or merging some state from different API requests.
The browser is annoying to control, so you're trying to make javascript jump through hoops to do what you want...

  SQLSync is [..] designed to synchronize web application state between users, devices, and the edge.
So you want your stateless application to be stateful, to sync that state with some other state, so you can cache data easier, so you can make the browser pretend it's not a browser.

Can we not just admit the browser is a shitty client app? I get that like 50% of the software developers in the world have made the browser their literal livelihood and career, but jesus christ, we need to end this madness. Either make a full blown VM and just write normal client applications that run in it, or stop trying to make client applications out of javascript.

It's insane how much of the world's engineering effort and technology investment money has gone into putting lipstick on a pig. If we took all the money invested in browser ecosystems and put it towards spaceflight, we'd be living on Mars right now.

Post reply on HN