@@heitorfreitas3662I agree that cs knowledge is under appreciated by many self taught devs and bootcampers. It is also true that a degree is not a necessary or sufficient condition to learn said knowledge.
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 100000 cases.
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
if it wasn't "master service side" then I guarantee you, that particular vendor would miss the case where your client is trying to buy the last dog food, just after someone else already did. Hence get the same negative effect but from the other extreme
@@mattymattffs the server also had all the data and you can’t use Js floats for currency. Just because it is easy af doesn’t mean it’s the right solution
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.
They are cancelled in the browser, but this does not mean they are cancelled in the server. The issue that the author is outline is that if submission 2 does not process until after the prefetch of submission 3, then you will not see the true current state of the system, you will only see the changes made from submission 1 and 3, since submission 2 was for whatever reason held up. The important takeaway here is to remember that a cancelled request from the browser does not mean the request magically stopped being processed on the server.
@@jdeanwaite Good response. However most devs (probably over 99%) just don't understand client/server technology. Data sync and state are impossible tasks when one party can disconnect in the middle of an operation and the other side has no idea what to do from that point. TCP/IP is a lot more fragile than most people realize. And web browsers can establish several connections to the same server and send requests out of chronological order.
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.
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.
@@avwie132 what are YOU on? Every pure function is idempotent, but not every idempotent function is pure. In fact, when people talk about idempotence, it's almost always about non-pure functions. It's about side-effects. That's the whole point of the concept. You might call the function twice (or more), but only get the side-effects once.
@@ruroruro Since an idempotent function causes the side effects only once, and a pure function has zero side effects. How can you be sure the zero side effects are only happening once? Mind blown!
@@orbik_fin Repeat after me. Every pure function is idempotent, but not every idempotent function is pure. Every pure function is idempotent, but not every idempotent function is pure Every pure function is idempotent, but not every idempotent function is pure Do you get it? It's not "How can you be sure the zero side effects are only happening once" it's "How can you be sure that the side effects that happened only once didn't actually happen at all".
@@ruroruro A whoosh moment. Let me explain then. How many times do the side effects of a pure function happen? Is it zero, one, or more? The correct answer is undefined, because zero times any finite number is still zero. And therefore the proper definition of idempotence cannot be that "the side effects only happen once". Upon realizing this contradiction you're supposed to laugh at the joke, not become mad at the internet.
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.
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)
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.
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.
Depends on the platform. Mobile apps benefit greatly from offline, because it's common for the connection to be unstable when folks take the train or something.
In my expierience no app works well in condition of bad connection. Its a matter of "app thinks there is connection but slow" while there is none. And "app thinks there is no connection" while there is connection but slow. Everything is unusable in situations like that. And I am running of LTE in Forrest, so I get this kind of things all the time. Btw, that's why I am using torrent streaming, as it's working just fine compared to streaming services.
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.
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.
Using the framework to deal with concurrent stuff is just a bad idea, if it was great we wouldn't use rabbit mq and other stuff like that, right? Remix favors optimistic UIs... all the problems are solved thinking about the happiest path and when it does not occur, we come back to the user saying: oh no, sorry buddy Though I agree with the guy that remix is baiting people on believe they would deal with concurrency for them
Prime showing hes quite disconnected from the Microsoft enshitification. You made the claim offline apps dont exist, I'm sorry this is outright wrong. Microsoft 365 has completely changed their app model to offline web apps. All of them. Teams, Outlook, Office are all becoming offline web apps.
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.
I’m not sure why people think you can’t use JavaScript on a server rendered app. Something like upcoming web awesome for ui components covers most of the building blocks beyond basic html. Keep state server side then add whatever js you need. Obviously we’re not talking the 1 percent of apps that are highly interactive like figma or something
This article: Hye numb nuts if you update apartial of a table but reload the table when the partial comes back it can backfire! Have you considered... oh idk... updating the partial when you do a partial update??? Oh you deleted that line from the table? Great delete that line from the table instead of trying to do some wacky workaround the very straightforward logic, magic I know!
Will optimistic updates be a solution for this issue? Updates happen instantly on the ui while request in the back. If request fails, ui goes back to latest cache data.
I'm clearly not understanding this one. In order to update the client dynamically without a network request then you must have some state that exists on the client which means it has to be duplicated from the server but are you suggesting that that isn't right? Or are you suggesting that you shouldn't duplicate the entire state from the server, in the client? Are there apps that actually do that? I've always worked on projects where the data sent to the UI was the data required to make a responsive UI. Have I just lucked out working on projects that don't do that or something?
i like gdocs because its automate saving in the gdrive so i dont have to worry about my computer error, but setting up complex pagination is nighmare as hell >< for this one, ms word is easier
@@_fuji_studio_I agree, I feel like with word I've almost always been able to find some trick to do what I need to do, but with gdocs some stuff is just impossible. I'm a perfectionist and idealist though, realistically gdocs can make almost any document well.
Just give every request a an “order number” and number every action 1, 2, 3, etc and have the backend wait until the next sequential number comes in and do that one ☝️
30:51 is Flip also dyslexic? artisan tortilla press right? I'm dyslexic and english is my third language, plz help me out :D. and also get this man a salary )
if the backend is properly developed, then you don't need 2 rounds for each request. Just response with a body, or in the case of the DELETE, you can put the deleted ID in a header x-deleted-item-id, and update everything on the client, you already have the rest of the data. Doing 2 rounds, indicates that you either don't trust the server, or you don't trust your front-end
yep! for simple applications composed mostly of forms it's easy to move everything to the server. it becomes harder when you have complex UI interactions with states that only make sense to exist on the client side. so there shouldn't be a go-to solution, people should stop for a moment and think about what makes sense for the BE to serve and what makes sense to keep on the FE. business logic definitely exists on the client side, unless you're dealing with a very simple app.
Overall... these are not significant problems in the real world. Mutate -> invalidate isn't a Remix thing; it's been around since at least early days of Apollo Client, probably earlier, and are the default approach used in React Query. You can try to come up with a "perfect" solution to this problem, but it's akin to premature optimization for vast majority of applications.
They are not using remix actions only initial page loaders. All the bugs that we're in nextjs are in the remix version too, they are not really using all of the features of remix. What i am trying to say is that what you are experiencing is placebo.
Php is like serverlesss. Nginx or Apache is the web server. Php handles a request end to end in a single worker thread. Each thread is isolated and short-lived. If you want shared mutable state between requests/threads you must do that through a db or the filesystem, you don't have shared memory the way you would in node or go or whatever. But for a web app typically you don't want that. Footgun gone. Just sayin.
The revalidation request is a great pattern, and if someone argues this it means he has not much experience. When you revalidate you ask for the data with the same state you expect based on an open page, for example you use a filtered table ?f=foo and you preserve it when doing revalidation, in other case you must somehow, maybe in a client side cookie transfer all these info during a post request.
My dude, read the article. The guy that wrote it is one of the core members of rubies rails framework and elixirs phoenix framework. He is also the creator of the elixir language. He has more experience than you will ever have. This article explains the shortcomings of the revalidation approach and what needs to be done additionally to guard from race conditions. Just because one problem that you describe greatly benefits from this pattern does not mean that it’s flawless.
![[LIVE] : ONE ลุมพินี 80 | คู่เอก "รักษ์ vs ยอดนำชัย"](http://i.ytimg.com/vi/ckLMRorsMeY/mqdefault.jpg)
this article is: web devs discovers the many problems of distributed systems
Jose Valim is the creator of Elixir… I guess he knows about distributed systems. He is not some web dev
@@avwie132 I now who Jose is, I was talking about the audience that is mainly react Andys who says that you don't need a degree to be a programmer
@@heitorfreitas3662I agree that cs knowledge is under appreciated by many self taught devs and bootcampers.
It is also true that a degree is not a necessary or sufficient condition to learn said knowledge.
why dont js devs know this? are they stupid?
He's basically outlining the basis of consensus algorithms and the basis for Lamport's Logical Clock. Interesting read for the curious.
10:00 "The third one, being the furthest, happens the thirdest"
Unburdened by what has been, he came the thirdest of them all
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 100000 cases.
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
if it wasn't "master service side" then I guarantee you, that particular vendor would miss the case where your client is trying to buy the last dog food, just after someone else already did. Hence get the same negative effect but from the other extreme
Why on earth would you do calculations in the front end??? Especially with money.
@@avwie132 because you have all the data and it's easy af
@@mattymattffs the server also had all the data and you can’t use Js floats for currency. Just because it is easy af doesn’t mean it’s the right solution
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.
They are cancelled in the browser, but this does not mean they are cancelled in the server. The issue that the author is outline is that if submission 2 does not process until after the prefetch of submission 3, then you will not see the true current state of the system, you will only see the changes made from submission 1 and 3, since submission 2 was for whatever reason held up. The important takeaway here is to remember that a cancelled request from the browser does not mean the request magically stopped being processed on the server.
@@jdeanwaite Good response. However most devs (probably over 99%) just don't understand client/server technology. Data sync and state are impossible tasks when one party can disconnect in the middle of an operation and the other side has no idea what to do from that point. TCP/IP is a lot more fragile than most people realize. And web browsers can establish several connections to the same server and send requests out of chronological order.
aborting a fetch doesn't necessarily mean the request didn't hit and is being processed by the server.
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.
Sure just make sure you're using a monotonic clock for the timestamps.
Already solved in http 1.1. Just google "http conditional requests"
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.
What are you on? Every pure function is idempotent by definition.
@@avwie132 what are YOU on? Every pure function is idempotent, but not every idempotent function is pure. In fact, when people talk about idempotence, it's almost always about non-pure functions. It's about side-effects. That's the whole point of the concept. You might call the function twice (or more), but only get the side-effects once.
@@ruroruro Since an idempotent function causes the side effects only once, and a pure function has zero side effects. How can you be sure the zero side effects are only happening once? Mind blown!
@@orbik_fin Repeat after me.
Every pure function is idempotent, but not every idempotent function is pure.
Every pure function is idempotent, but not every idempotent function is pure
Every pure function is idempotent, but not every idempotent function is pure
Do you get it? It's not "How can you be sure the zero side effects are only happening once" it's "How can you be sure that the side effects that happened only once didn't actually happen at all".
@@ruroruro A whoosh moment. Let me explain then. How many times do the side effects of a pure function happen? Is it zero, one, or more? The correct answer is undefined, because zero times any finite number is still zero. And therefore the proper definition of idempotence cannot be that "the side effects only happen once". Upon realizing this contradiction you're supposed to laugh at the joke, not become mad at the internet.
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.
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)
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.
I believe chargtp move to remix was more about moving away from vercel and towards azure.
Did they even use Vercel. AFAIK they did not.
Flip, the man, the legend
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.
Depends on the platform. Mobile apps benefit greatly from offline, because it's common for the connection to be unstable when folks take the train or something.
Yeah i should clarify, im primarily referring to PWAs/web-apps
In my expierience no app works well in condition of bad connection.
Its a matter of "app thinks there is connection but slow" while there is none.
And "app thinks there is no connection" while there is connection but slow.
Everything is unusable in situations like that.
And I am running of LTE in Forrest, so I get this kind of things all the time.
Btw, that's why I am using torrent streaming, as it's working just fine compared to streaming services.
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.
"The name the agen Prime is" would have been a funny conclusion to an article discussing possible issues with concurrency and race conditions.
solid start has single flight mutations
Using htmx to open a dropdown is something dumb, there are the popover api that works with JavaScript disabled
or just use alpine js. Alpine is so slept on. Literally 90% of the power of Vue with no build step.
Concurrent submissions? Netflix's resolved it more a decade ago.
so this all was dove to promote elixir
The main reason to do client-side rendering is because your devs that only know JavaScript need something to do.
Or you need anything more than a static blog site.
@@tinrab livewire has been a thing for a while now
Wrong
Dzieci i weeby głosu nie mają
Yooo Prime, what’s your take on Scala?? I am so curious bout that🙌
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.
If only there was a mathy language that could save us...
OH WAIT, there's TLA+ and PlusCal for that!
Using the framework to deal with concurrent stuff is just a bad idea, if it was great we wouldn't use rabbit mq and other stuff like that, right?
Remix favors optimistic UIs... all the problems are solved thinking about the happiest path and when it does not occur, we come back to the user saying: oh no, sorry buddy
Though I agree with the guy that remix is baiting people on believe they would deal with concurrency for them
Prime showing hes quite disconnected from the Microsoft enshitification. You made the claim offline apps dont exist, I'm sorry this is outright wrong. Microsoft 365 has completely changed their app model to offline web apps. All of them. Teams, Outlook, Office are all becoming offline web apps.
If you're reading this... you use Parallel and Concurrent interchangeably.
No, I'm not.
Nah, but my job doesn't really require me to think about either much
I fully understand when to parallel use when and concurrent use to
No
Bro thought he cooked.
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.
It's not Jose, it's Jose
I’m not sure why people think you can’t use JavaScript on a server rendered app. Something like upcoming web awesome for ui components covers most of the building blocks beyond basic html. Keep state server side then add whatever js you need. Obviously we’re not talking the 1 percent of apps that are highly interactive like figma or something
Offline support works for html games like Phaserjs (outside multiplayer)
This article: Hye numb nuts if you update apartial of a table but reload the table when the partial comes back it can backfire!
Have you considered... oh idk... updating the partial when you do a partial update??? Oh you deleted that line from the table? Great delete that line from the table instead of trying to do some wacky workaround the very straightforward logic, magic I know!
Will optimistic updates be a solution for this issue? Updates happen instantly on the ui while request in the back. If request fails, ui goes back to latest cache data.
And yet the implications that are independent of any ordering still tell a different story. And yet without support the only advantage is silence.
Server side react is fundamentally flawed
any general tips to solving difficult problems. Or it's pretty much a skill and time issue?
I'm clearly not understanding this one. In order to update the client dynamically without a network request then you must have some state that exists on the client which means it has to be duplicated from the server but are you suggesting that that isn't right? Or are you suggesting that you shouldn't duplicate the entire state from the server, in the client? Are there apps that actually do that? I've always worked on projects where the data sent to the UI was the data required to make a responsive UI. Have I just lucked out working on projects that don't do that or something?
Canadians need to get on board. We're all over here across the pond... join up.
Google Doc & Sheet has great offline support
i like gdocs because its automate saving in the gdrive so i dont have to worry about my computer error, but setting up complex pagination is nighmare as hell >< for this one, ms word is easier
and ms word has automatic save in cloud too, but gdocs is free so i like it more, just the pagination is hard if want to create complex pagination >
@@_fuji_studio_I agree, I feel like with word I've almost always been able to find some trick to do what I need to do, but with gdocs some stuff is just impossible. I'm a perfectionist and idealist though, realistically gdocs can make almost any document well.
The ChatGPT remix app is almost entirely client side
Just give every request a an “order number” and number every action 1, 2, 3, etc and have the backend wait until the next sequential number comes in and do that one ☝️
Now the problem is how do you make sure that no two requests get the same number for requests coming from distributed systems.
How about debounce and batch requests
that reminds me why we may be better off just leave the server side for PHP. 🙂
2:29 I clapped along with you
have jose on the stream!!!
30:51 is Flip also dyslexic? artisan tortilla press right? I'm dyslexic and english is my third language, plz help me out :D. and also get this man a salary )
if the backend is properly developed, then you don't need 2 rounds for each request.
Just response with a body, or in the case of the DELETE, you can put the deleted ID in a header x-deleted-item-id, and update everything on the client, you already have the rest of the data.
Doing 2 rounds, indicates that you either don't trust the server, or you don't trust your front-end
Why would you ever trust your frontend? The client can do whatever they want with that, it's on their computer.
Read again, slowly and pay attention
@@ionutale1950 off yourself, slowly, and pay attention, we don't want you to fail. Condescension is not required.
Flip actually took something out ?
This guy probably hasn't heard of conditional headers from HTTP 1.1. Please use an Etag!
Seems like literally no one remembers Etags exist
@@Rando7656 Most common wikis and CMS sites use it.
fuck me am using remix for my project
Remix is great - better to know issues/limitations and challenges so they can be managed
I'm not Canadian. What's wrong with "A Tomato"? Am I even a CS degree? I'm sorry. (wait that sounds Canadian)
Elixir mentioned!
Argument for client side: You want good UI
yep! for simple applications composed mostly of forms it's easy to move everything to the server. it becomes harder when you have complex UI interactions with states that only make sense to exist on the client side. so there shouldn't be a go-to solution, people should stop for a moment and think about what makes sense for the BE to serve and what makes sense to keep on the FE. business logic definitely exists on the client side, unless you're dealing with a very simple app.
Jose W
Overall... these are not significant problems in the real world. Mutate -> invalidate isn't a Remix thing; it's been around since at least early days of Apollo Client, probably earlier, and are the default approach used in React Query. You can try to come up with a "perfect" solution to this problem, but it's akin to premature optimization for vast majority of applications.
chatgpt's UI has been so buggy its insane, more than with when they were using nextjs
They are not using remix actions only initial page loaders. All the bugs that we're in nextjs are in the remix version too, they are not really using all of the features of remix. What i am trying to say is that what you are experiencing is placebo.
@@eptic-c fair point
Php is like serverlesss. Nginx or Apache is the web server. Php handles a request end to end in a single worker thread. Each thread is isolated and short-lived. If you want shared mutable state between requests/threads you must do that through a db or the filesystem, you don't have shared memory the way you would in node or go or whatever. But for a web app typically you don't want that. Footgun gone. Just sayin.
The revalidation request is a great pattern, and if someone argues this it means he has not much experience. When you revalidate you ask for the data with the same state you expect based on an open page, for example you use a filtered table ?f=foo and you preserve it when doing revalidation, in other case you must somehow, maybe in a client side cookie transfer all these info during a post request.
My dude, read the article. The guy that wrote it is one of the core members of rubies rails framework and elixirs phoenix framework. He is also the creator of the elixir language. He has more experience than you will ever have.
This article explains the shortcomings of the revalidation approach and what needs to be done additionally to guard from race conditions. Just because one problem that you describe greatly benefits from this pattern does not mean that it’s flawless.
st!Fir
Not first
6:20 Submision and Revalidation is easily fixed with GraphQL tho
First!
1st
4th