5 ms·
We are heavy into REST and HATEOAS. This, coupled with React SPAs has worked really well for us. The HATEOAS client we use/build has an cache/event system that
by treve 6y ago
We are heavy into REST and HATEOAS. This, coupled with React SPAs has worked really well for us.
The HATEOAS client we use/build has an cache/event system that will emit to subscribers (via react hooks) when a resource is stale, and needs to be refreshed.
After putting this all in place, I realized that now I just need the server to emit those 'stale' events via Websockets, and suddenly my SPA + API is a real-time multi user system with nearly no changes required in either server or client.
This made me wonder, why aren't we just always pushing the entire resource state over websockets. Use websockets to let clients indicate which resources they are interested in, and let the server keep pushing state back to the client.
This solves a number of problems that plain HTTP has:
1. We can't really push/subscribe well. It's not very natural.
2. The HTTP cache kinda sucks, because we don't have programmatic access. Simple example: Doing a DELETE on a resource should expire the cache of the parent collection. There's a good HTTP header to indicate this, but no good way to tell the browser cache to delete the cache entry, so we end up building our own caching layer.
3. Compound requests suck because HTTP caches and clients don't understand them.
But we can still keep using REST fundamentals. Things have URIs, features are discoverable, relationships are expressed with links.
Something about this also feels terribly wrong though. Do we really want to reinvent parts of HTTP over websockets? HTTP is highly optimized, what kind of performance problems are we gonna run into?
- Tenal 6y agoComing from a game networking side, why wouldn't you want to embrace a WebSockets world for everything? The upsides seem so incredibly intuitive for someone looking at it from the outside of traditional web development.
- afavour 6y agoScaling is almost always the answer.
- mathgladiator 6y agoScaling not just technically either, it's also the engineers. Most Web engineers have had their minds bent to the request response model with databases. The key reason is that a game lasts... minutes to hours (ignoring most MMOs), so the state machine makes sense and the risk of failure low. Web devs have to use a database which has state for years.
- ric2b 6y agoPlus most games are awful at handling connection issues, you'll be dropped from the game and have to reload the entire map and assets again, often taking 30 seconds or more to rejoin. I'm not sure we should be taking advice about how to load information on mobile devices with spotty connections from the gaming industry.
- deleted 6y ago[deleted]
- Nullabillity 6y agoTraditional SQL databases aren't very streaming-friendly, so you more or less end up building an entire secondary push system just to figure out when to send what updates to who.
- munchbunny 6y agoMostly just the intuitiveness of the architecture. I don't need bi-directional if I'm mostly just showing you some forms in a CRUD app, and client-initiated request/response is simpler to reason about. Bi-directional gives you more power, but you also have to think harder about the protocol and application state once the server is also pushing events to the client unprompted.
- clusterhacks 6y agoWas your use of REST/HATEOAS mostly internal to your company or dev team? I ask because I rolled out a REST/HATEOAS api for a multi-org project and got zero uptake on the HATEOAS aspect of responses. The devs hardcoded URL resource links and totally ignored any links in responses . . . After that experience, I am always interested to hear about more successful REST/HATEOAS projects.
- krainboltgreene 6y ago> This made me wonder, why aren't we just always pushing the entire resource state over websockets. Because this won't respect HTTP caching and you'll end up sending way more data than you need. Best instead to just send up URI and `GET/DELETE` verbs to indicate intent. I wrote about this: https://github.com/krainboltgreene/pubway.js#pubway https://github.com/krainboltgreene/pubway.js#pubway Actually every HTTP benefit is a reason why you wouldn't want to send resources over websocket. What if the websocket connection is slower than changes to the resource? Instead of simply telling the client what to fetch, you just gave them stale data.