[HN Gopher] Stop using REST for state synchronization (2024)
___________________________________________________________________
Stop using REST for state synchronization (2024)
Author : Kerrick
Score : 28 points
Date : 2025-05-15 17:30 UTC (5 hours ago)
(HTM) web link (www.mbid.me)
(TXT) w3m dump (www.mbid.me)
| jemmyw wrote:
| While I superficially agree with the point, the article author
| states that they haven't tried the alternatives they suggest.
| Implementing CRDT or OT can be a complex endeavour, especially if
| you're retrofitting on an existing system that already has a REST
| or similar API. Use case is ever important, don't spend your all
| important time implementing a complex state sync if it turns out
| your customers don't do the kind of collaboration that requires
| it.
| yakshaving_jgt wrote:
| The article told us we should stop using REST for state sync, yet
| it didn't really tell us what to do instead.
| sansseriff wrote:
| Curious to her other people's opinion of this. I arrived at a
| similar conclusion after making web apps for research control
| software in my PhD. I went through a Yjs tutorial and looked into
| integrating it with fastapi websockets. But this seems like a
| pretty unusual thing; there just isn't enough people doing this.
|
| Nice user-friendly libraries and tutorials don't exist for
| smoothing the transition from REST to CRDTs, should your app need
| that.
| coolhand2120 wrote:
| If you're hesitating to use YJS take the word of someone who
| took the plunge, it's totally worth it on the other side.
|
| I've written several apps now with it now. Very easy to use and
| quite robust to failures. It's a bit of a mental load to take
| on at first but it's totally worth it for the problems it
| solves out of the box. I've tried other things too from rolling
| my own ES stack to OT and more.
|
| Lately I've got it running on AWS API Gateway V2 over
| websockets to lambdas + DynamoDB with a small army of daily
| users. The only expensive part is the event audit logs I keep
| due to my inherent mistrust of all computers.
| AtlasBarfed wrote:
| This is right smack in the territory of the CAP theorem, which a
| lot of distributed databases using highly reliable networks can
| now somewhat functionally ignore.
|
| But in the land of highly variable reliability of clients, you
| got to think about it you are CP or AP. You HAVE to be partition
| tolerant because clients are so unreliable.
| kokanee wrote:
| It seems like the author has never worked on an interface that
| uses realtime UI syncing. The points about cumbersome and mundane
| issues when working with REST UIs are not wrong, but the
| challenges of working with realtime synced UIs are substantially
| more difficult. And I'm not talking about conflict resolution,
| which can be abstracted by many existing solutions. I'm talking
| about the intricacies of UI behaviors that are specific to each
| application, when suddenly every interactive element can
| potentially be interacted with by multiple parties
| simultaneously.
|
| For most applications, the status quo whereby a little bit of
| recent state is maintained locally, and periodically pushed to a
| centralized store, seems to provide the best overall balance of
| complexity and functionality. One exception is that most
| applications do a poor job of actually maintaining the local
| state (e.g. most forms clear when you refresh the page, which is
| not hard to fix).
| coolhand2120 wrote:
| What part of this implementation is ReST? I see a CRUD API that
| uses HTTP verbs. State transfer implies multiple steps at least,
| where I call the initial API which then returns several other API
| endpoints "transfering the state" typically in a HATEOAS style -
| perhaps that part isn't required.
|
| https://en.wikipedia.org/wiki/REST
|
| > ... although this term is more commonly associated with the
| design of HTTP-based APIs and what are widely considered best
| practices regarding the "verbs" (HTTP methods) a resource
| responds to, while having little to do with REST as originally
| formulated ...
|
| Ah, I see, the industry has taken to just calling HTTP ReST for
| no apparent reason.
|
| As far as not being sure about CRDTs, these protocols were made
| to overcome the obvious and terrible shortcomings of CRUD APIs
| (lack of communicability and idempotency). Who ever wants to see
| "the data on the server has changed, do you want to overwrite the
| data on the server or overwrite your local copy". If you're not
| doing some sort of event sourcing for state management (ES, OT,
| CRDT) you're probably doing it wrong or doing it for a simple
| project.
| WhitneyLand wrote:
| Not sure why you think that's not rest. Because Douglas
| Crawford wrote a paper that most people don't care about?
|
| Language isn't controlled by a single authority or the first
| person to use a term. Words mean what people use them to mean.
| You can complain that it's not the 'proper' definition, but if
| the majority of people use it a certain way, that becomes the
| definition in practice.
| gxs wrote:
| Maybe if the headline said Stop using REST for state
| synchronization in these scenarios, I would have been on board
|
| Dismissing something outright is usually the wrong answer, and
| for the same reason I did read the article
|
| Using REST for synchronization isn't some huge transgression and
| is fine in a lot of scenarios, silly in others.
|
| Keeping record updates that a user makes in one system in sync
| with a single record in another system that uses those updates is
| fine
|
| Trying to sync giant databases in bulk on the other hand might
| not be
| qudat wrote:
| State synchronization is a bit of a hot topic for front end
| development since most of the "middle end" deals squarely with
| solving that problem.
|
| I also agree that the way many APIs are built are pushing
| complexity to the FE: https://bower.sh/dogma-of-restful-api
|
| However, virtually every company I've joined has needed to serve
| multiple clients. In those cases REST is the status quo. Some
| people have opted for graphql but even that makes some uneasy
| because tuning gql is non trivial. CRDTs are completely foreign
| to most organizations unless they deal specifically with
| multiplayer modes.
|
| So while it sounds nice to ditch REST it's just not realistic for
| most orgs. This is why I've been developing a side effect and
| state sync system that can easily interface with REST,
| websockets, graphql, etc because it's built off of structured
| concurrency.
|
| https://starfx.bower.sh/
|
| https://bower.sh/why-structured-concurrency
| cgio wrote:
| REST as the author finds out is not for state synchronisation.
| CRDTs are also not about state synchronisation, only so in an
| eventual sense, so similar to REST, you can make it work, but you
| are twisting the approach with assumptions and sticky tape. State
| synchronisation is a "solved" problem, in the form of distributed
| data stores, or in some more relaxed sense, database replication,
| CDC etc. Not an expert, so this is just an opinion even if it
| sounds assertive.
| 4b11b4 wrote:
| Electric SQL and their various packages looking pretty. Can't
| comment on actually using them though
___________________________________________________________________
(page generated 2025-05-15 23:00 UTC)