Remix's Concurrent Submissions Are Fundamentally Flawed

Recorded live on twitch, GET IN

### Article
By: José Valim

### My Stream

### Best Way To Support Me
Become a backend engineer. Its my favorite site

This is also the best way to support me is to support yourself becoming a better backend engineer.

MY MAIN YT CHANNEL: Has well edited engineering videos

Discord

[heitorfreitas]

this article is: web devs discovers the many problems of distributed systems

[tedchirvasiu]

Databases have been dealing with concurrency and consistency issues since the 70s. I think understanding database isolation levels gives great insight into the fundamental problems and tradeoffs around consistency and performance.
I think in general people YOLO consistency for the sake of "scalability" and only care when something goes weird in 1 out of cases.

[mattymattffs]

Funny story, I started watching this having no idea what it was going to be about. I experienced the exact issue described in the article yesterday buying dog food. While checking out I added items to the cart then in the cart I increased the amount of specific items that I was ordering and then I saw the total price. The total price did not make sense and when I went to the next page to actually check out it read the correct data from whatever is happening server-side. Crazy to do this master service side in the first place, but they are

[stephenreaves]

10:00 "The third one, being the furthest, happens the thirdest"

[shellsterdude]

Timestamp could absolutely work for this problem. You let the database set the time stamp. On the client side whenever you get an update with a timestamp later than the last one you updated with, you update. If it is older you ignore. There are still gonna be issues with things that touch multiple rows, but if you want to do something complicated like that, then you probably shouldn't be trying to let some framework try to generically handle that for you.

[razajamil]

Is this theory or is there a repro? I think the author is mistaken because Remix cancels in flight requests when they're repeated. So for example if you have 3 mutations on the same screen, you will only ever see the results of the data refetch from the 3rd mutation. Mutation 1 completes, refetch 1 starts, mutation 2 completes, refetch 1 is cancelled, refetch 2 starts, mutation 3 completes, refetch 2 is cancelled, refetch 3 starts. I use Remix heavily everyday and haven't seen this issue even once.

[ruroruro]

38:33 that's a horrible explanation of idempotence. It sounds like he is talking about purity, which is almost completely orthogonal with idempotence. Idempotence isn't just about the return value, but more about side effects. Calling an idempotent function twice with the same arguments should only cause the intended side effects once.

[NoFkingUsername]

"The name the agen Prime is" would have been a funny conclusion to an article discussing possible issues with concurrency and race conditions.

[TheWalrus_]

I believe chargtp move to remix was more about moving away from vercel and towards azure.

[rign_]

I will use overly complicated architecture for my zero user website.

[hamm]

Offline support is the most dreadful thing to effectively implement with such a small user base need. Its the classic example of over optimizing for a small return. Change my mind.

[eptic-c]

I think what the remix team meant with the timestamp is something like: SQL`where updated_at > timestamp_from_client` if it returns then cancel the current request as it might be stale.

[hakuna_matata_hakuna]

solid start has single flight mutations

[ceigey-au]

Meteor (which uses websockets to run its DDP protocol on) also has the by-default in-order request handling feature, per connection. You can tell Meteor methods (≈ rpc handlers) to “unblock” the queue if it’s safe on the server side, but I’m not sure if that really does affect the ordering or just lets some other async stuff start in the meantime before the method returns.

But Meteor is on the opposite side of the frontend-backend spectrum to Liveview and is basically an SPA sharing a codebase with a node server.

(It also has to do sticky sessions because of websockets)

[thekwoka]

Realistically, this concurrency issue probably won't matter at all in real life, since such a kind of out of order is unlikely, especially presuming that the user is on a decent enough connection. It would be challenging to do requests so quickly.

[danieljenikovsky]

Server state should be on server, and client state should be on client! Guys come on! Why should my server know what second is my audio track currently at, unless I wanna come back to it? Or better, what transformations are applied to current selection in rich editor. My server don't care! What can be done, should be done with htmx/post, everything client side - vanilla js.

[emilemil]

The main reason to do client-side rendering is because your devs that only know JavaScript need something to do.

[paulvanzyl]

The benefit of thinking about it outside of JavaScript for me hasn’t been turning off is, but using the web platform and http as the fundamental apis, simplifying the DX massively. It feels like this article is mostly concerned with micro optimization, and concerns that are not really in the scope of your remix front end.

[shadowfaxenator]

Regarding consistency of revalidation, you always work with eventual consistent reads and strong consistent writes. To help with read consistency you can use server side events or websokets and only revalidate after you get a signal.

[SimGunther]

If only there was a mathy language that could save us...

OH WAIT, there's TLA+ and PlusCal for that!