5 ms·

I'm also a heavy websocket user, and agree with most points. I have previously used websockets on top of a traditional web app, and have been disappointed with

I'm also a heavy websocket user, and agree with most points. I have previously used websockets on top of a traditional web app, and have been disappointed with the results. My opinion now is that websockets are an all-or-nothing proposition. And I have gone all-in. My latest project has: - websockets-only api (except a some image uploads and oauth/login) - https-only - single page app, central store with observable data, using a single connection servicing the whole application - using SignalR (supports fallbacks for IE9 and old Android) - Actor-based backend (Orleans) This stack feels like the future to me, but I've had to learn a lot of new things. It's quite different from the web development that I've done over the past 15 years. Overcoming the connectivity issues mentioned in the article is only the first step. Websockets need another type of backend to make sense: Actors. I've had many challenges with the async realtime behaviour of the system, deadlocks, etc. But now that everything is working and I have some grip on it, I can't imagine going back to a rest/database/cache web architecture.

skrebbel 11y ago
> My opinion now is that websockets are an all-or-nothing proposition. Interesting. Why? Why can't you get some not-so-realtime data via a classic REST API?
- Maarten88 11y ago
  Of course you can mix two styles, but it makes little sense as websockets does all the things REST can do, only faster and with state on the server. Clientside there is little difference between $.ajax(api, data) and conn.send(api, data). And it's just nicer to keep the api together serverside in (in my case) one SignalR controller instead of putting some parts in a Nancy module. I do have some REST endpoints, i.e. for image upload and oauth, I did not know how to make that work otherwise on IE9.
orf 11y ago
> My latest project has... Taken you a long time to get started. What does it do? I hope the time investment is worth it and you're not trying to make a blog or some CRUD app.
- XorNot 11y ago
  Implementing a common idea with new tech is pretty good way to get a handle on where your understanding needs patching up though.
  - userbinator 11y ago
    I don't think that's a good idea since it very easily leads to overengineering and becoming accustomed to overengineered solutions. The way to use new tech is when it gives a clear advantage, not just for the sake of using it. There's nothing wrong with a lot of older, simpler, more compatible solutions. It's good the parent mentioned blogs, since I think they're one example where much ridiculous complexity has taken hold for little gain; please don't turn what should be nothing more than a widely-accessible, simple static page with minimal bandwidth and processing requirements into an elephantine multiple-layered monstrosity requiring tons of serverside infrastructure and only accessible with the latest browsers. Always keep in mind YAGNI, KISS. (This comes from the experience of someone whose work has involved replacing countless overbuilt systems with far simpler ones.)
    - icebraining 11y ago
      Not sure what XorNot meant, but the way I've heard it, and it makes sense to me, is that it should be done with toy projects which are not intended to stick around.
- Maarten88 11y ago
  > Taken you a long time to get started. Certainly it cost extra time, but it was mostly for learning. In the end it's not much more complex, just different. Some things that used to be easy are harder, but things that were very hard are now very easy. Cache-invalidation no more... > What does it do? I hope the time investment is worth it and you're not trying to make a blog or some CRUD app. It's a social network with push notifications and time registration. Users can share realtime location and status. I confess the scalability of the tech is not needed currently, but a fast ui even on very little hardware is still a benefit.
jacquesm 11y ago
This is roughly how every regular socket based client-server application pair works.
- Maarten88 11y ago
  Correct, but for web apps this is rather different. I found that my thinking was very much request-response. Probably game devs would pick this up much quicker than I did.
ape4 11y ago
So load .js files with websockets?
- Maarten88 11y ago
  No, the web app itself consists mostly of static files, generated with old fashioned bundling. There's even a few serverside pages, public content for marketing. I did not trust Google to index single page websocket api's properly yet.
amirouche 11y ago
> I can't imagine going back to a rest/database/cache web architecture. What do you mean? You don't have a database? how is it related to websocket? no cache?
- Maarten88 11y ago
  The backend is distributed Actors. Instead of bringing the data to the (web)request, the Actor model brings the request to the data (which may be on another server). Actor objects are loaded in memory and kept there while needed, so its very fast by itself and there's no need for caching at all. Storage can be very simple, it is possible to use SQL but I'm using Table Storage which is cheaper and more scalable. For searching we use ElasticSearch. This server model fits very naturally with websockets.

skrebbel 11y ago

> My opinion now is that websockets are an all-or-nothing proposition. Interesting. Why? Why can't you get some not-so-realtime data via a classic REST API?

Maarten88 11y ago
Of course you can mix two styles, but it makes little sense as websockets does all the things REST can do, only faster and with state on the server. Clientside there is little difference between $.ajax(api, data) and conn.send(api, data). And it's just nicer to keep the api together serverside in (in my case) one SignalR controller instead of putting some parts in a Nancy module. I do have some REST endpoints, i.e. for image upload and oauth, I did not know how to make that work otherwise on IE9.

orf 11y ago

> My latest project has... Taken you a long time to get started. What does it do? I hope the time investment is worth it and you're not trying to make a blog or some CRUD app.

XorNot 11y ago
Implementing a common idea with new tech is pretty good way to get a handle on where your understanding needs patching up though.
- userbinator 11y ago
  I don't think that's a good idea since it very easily leads to overengineering and becoming accustomed to overengineered solutions. The way to use new tech is when it gives a clear advantage, not just for the sake of using it. There's nothing wrong with a lot of older, simpler, more compatible solutions. It's good the parent mentioned blogs, since I think they're one example where much ridiculous complexity has taken hold for little gain; please don't turn what should be nothing more than a widely-accessible, simple static page with minimal bandwidth and processing requirements into an elephantine multiple-layered monstrosity requiring tons of serverside infrastructure and only accessible with the latest browsers. Always keep in mind YAGNI, KISS. (This comes from the experience of someone whose work has involved replacing countless overbuilt systems with far simpler ones.)
  - icebraining 11y ago
    Not sure what XorNot meant, but the way I've heard it, and it makes sense to me, is that it should be done with toy projects which are not intended to stick around.
Maarten88 11y ago
> Taken you a long time to get started. Certainly it cost extra time, but it was mostly for learning. In the end it's not much more complex, just different. Some things that used to be easy are harder, but things that were very hard are now very easy. Cache-invalidation no more... > What does it do? I hope the time investment is worth it and you're not trying to make a blog or some CRUD app. It's a social network with push notifications and time registration. Users can share realtime location and status. I confess the scalability of the tech is not needed currently, but a fast ui even on very little hardware is still a benefit.

jacquesm 11y ago

This is roughly how every regular socket based client-server application pair works.

Maarten88 11y ago
Correct, but for web apps this is rather different. I found that my thinking was very much request-response. Probably game devs would pick this up much quicker than I did.

ape4 11y ago

So load .js files with websockets?

Maarten88 11y ago
No, the web app itself consists mostly of static files, generated with old fashioned bundling. There's even a few serverside pages, public content for marketing. I did not trust Google to index single page websocket api's properly yet.

amirouche 11y ago

> I can't imagine going back to a rest/database/cache web architecture. What do you mean? You don't have a database? how is it related to websocket? no cache?

Maarten88 11y ago
The backend is distributed Actors. Instead of bringing the data to the (web)request, the Actor model brings the request to the data (which may be on another server). Actor objects are loaded in memory and kept there while needed, so its very fast by itself and there's no need for caching at all. Storage can be very simple, it is possible to use SQL but I'm using Table Storage which is cheaper and more scalable. For searching we use ElasticSearch. This server model fits very naturally with websockets.