Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A bit of a tangent:

I have been experimenting with replacing REST style backend interaction with websockets an having the state manipulation round-tripping through the server.

Instead of setting values on mutable objects and telling the server about it postfact (having to deal with errors like ba validation and connectivity somehow), I would send a change command to the server, which would decide what to do, and push an updated state back. Once I detect this change of state, I update the UI.

This simplifies error handling a lot, since the user simply can't update state if an error occurs. And I get cuncurrent multi user editing for free.

Unless you want offline editing (which is hard), it's a big win.



I'm not sure if this is good API design, but it definitely sounds like a fun thing to try. I'll keep it in mind for a personal project.

Edit: Actually when you pass all state as props, this will even apply to typing in a textarea. Better make sure the roundtrip is pretty short!


I let the textarea take care o itself. I hate when they try to change the text while I type.

The update wouldn't be sent until it is unfocused or possibly after a set delay after the last keypress.


That introduces a noticeable delay. It's acceptable in some situations but in others less so. Having immediate feedback on button press or text entry makes the UX much more pleasant.


This is still rather easy. You can change the UI (i.e. set the button into a "Loading..." state) directly after the click and when the server sends back the response act accordingly. An error would reset the button and prompt an error message.


Exactly. The difference is, this becomes the default behavior (minus the spinner), and simple to implement.

With rest, it would be a much more manually implemented feature. The default would be to just fail silently and potentially drop important data on the next page load.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: