Remix's concurrent submissions are fundamentally flawed

https://dashbit.co/blog/remix-concurrent-submissions-flawed

by bo0tzz • 2 years ago

106 14 2 years ago

hyeomans• 2 years ago

José Valim nails it: Remix's concurrent submissions have a fundamental flaw. Without causal ordering, you're stuck with race conditions and stale data, leading to poor UX. They need to rethink their approach or embrace causal ordering to fix this.

pheeney• 2 years ago

Is there a GitHub issue or discussion to subscribe for updates from the Remix team on this topic?

aerox_zero2• 2 years ago

You can check the ChatGPT frontend source code that they do not use Remix's actions (submission and revalidate mechanism). And the fe does only one request to receive the data for chat. The mechanism has benefits like working without javascript and issues but you can avoid it if you dislike it. Did the author has checked it's own theories about why ChatGpt may be slow before making such arguments?

elicksaur2• 2 years ago

chatgpt .com does not work at all without JavaScript enabled.

For me, there are 11 network requests from sending 1 chat message. 2 appear to be related to the convo, /memories and /conversation.

For an example of what he is talking about, you can try deleting a chat from your chat history. It performs a PATCH to remove the single chat, then a GET with the full list of chats. Doing this multiple times can lead to the problems he’s outlining.

With wrangling, it’s probably also unnecessary in any given JS framework, but you have to be very intentional about it. With Phoenix LiveView minimal, efficient, and correct updates are included using the recommended patterns.

The video he put out related to these concepts is super helpful to visualize the process: https://www.youtube.com/watch?v=fCdi7SEPrTs

_lvbh• 2 years ago

There’s also funcaptcha (arkose labs) which definitely won’t let you use ChatGPT without JavaScript.

aerox_zero2• 2 years ago

as i mentioned the source code does not contain Remix actions (ofc <form> will not work without js in this case), so the reason why it makes two request on chat delete could be intentional or this is how they designed their api. Also the mentioned issues with actions by author are valid the only nitpick i have are the statements against chatgpt website and the fact that you can avoid actions if you dislike them. Most probably /backend-api/ that chatgpt's fe is calling is the go or java backend and has nothing with Remix.

mtndew4brkfst• 2 years ago

José seems to be far far far more enamored with ML than Elixir these days. Burnout and boredom happens, I get it, but it's still a bummer to see.

bcardarella• 2 years ago

He's literally building a type system for Elixir. What the hell are you talking about?

klysm• 2 years ago

Embracing the platform can hurt when the platform sucks

azangru• 2 years ago

Which part of the problem described in the post, would you say, is caused by the platform?

hollerith• 2 years ago

Wikipedia say, "Remix is an open source full stack web framework. The software is designed for web applications built with front-end JavaScript frameworks like React and Vue.js. . . . Remix has been presented as an alternative to the popular React framework Next.js."

giovannibonetti• 2 years ago

Regarding causal ordering, it's worth remembering that a convenient way of implementing way is with Lamport clocks, since there is only a single variable to keep track of – the single monotonic clock that comes from the combination of all the parties involved.

By the way, Martin Kleppmann's Designing Data-Intensive Applications book has a very good explanation of this subject.

d0100• 2 years ago

All my API's have a "context" query string, if you use it to send a incrementing integer, you can ignore all late, out of order results

Remix's concurrent submissions are fundamentally flawed

Related Stories