# WebSockets, caution required!

DevFeed: [WebSockets, caution required!](<https://devfeed.tech/articles/websockets-caution-required-41340.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2015/12/29/websockets-caution-required>)

Author: Sam Saffron

Published: 2015-12-29T23:25:05Z

Content type: opinion

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [WebSocket](<https://devfeed.tech/topics/websocket.md>), [realtime](<https://devfeed.tech/topics/realtime.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [middleware](<https://devfeed.tech/topics/middleware.md>)

Tags: [http](<https://devfeed.tech/tags/http.md>), [middleware](<https://devfeed.tech/tags/middleware.md>), [rails](<https://devfeed.tech/tags/rails.md>), [realtime](<https://devfeed.tech/tags/realtime.md>), [rest](<https://devfeed.tech/tags/rest.md>), [web-applications](<https://devfeed.tech/tags/web-applications.md>), [websockets](<https://devfeed.tech/tags/websockets.md>)

## AI overview

The article cautions that WebSockets are not automatically a clear win for most realtime web applications. It highlights operational and development concerns, including debugging, logging, profiling, rate limiting, database connection exhaustion, and the choice between WebSockets and REST for client-to-server communication. It suggests WebSockets are more appropriate for specialized high-concurrency cases such as managing 10k interactive console sessions.

## Source excerpt

When developers hear that WebSockets are going to land in the near future in Rails they get all giddy with excitement. minions.jpg492x219 23.2 KB But your users don't care if you use WebSockets: Users want "delightful realtime web apps". Developers want "delightfully easy to build realtime web apps". Operations want "delightfully easy to deploy, scale and manage realtime web apps". If WebSockets get us there, great, but it is an implementation detail that comes at high cost. Do we really need ultra high performance, full duplex Client-Server communication? WebSockets provides simple APIs to broadcast information to clients and simple APIs to ship information from the clients to the web server. A realtime channel to send information from the server to the client is very welcome. In fact it is a part of HTTP 1.1. However, a brand new API for shipping information to the server from web browsers introduces a new decision point for developers: When a user posts a message on chat, do I make a RESTful call and POST a message or do I bypass REST and use WebSockets? If I use the new backchannel, how do I debug it? How do I log what is going on? How do I profile it? How do I ensure it does not slow down other traffic to my site? Do I also expose this endpoint in a controller action? How do I rate limit this? How do I ensure my background WebSocket thread does not exhaust my db connection limit? If an API allows hundreds of different connections concurrent access to the database, bad stuff will happen. Introducing this backchannel is not a clear win and comes with many caveats. I do not think the majority of web applications need a new backchannel into the web server. On a technical level you would opt for such a construct if you were managing 10k interactive console sessions on the web. You can transport data more efficiently to the server, in that the web server no longer needs to parse HTTP headers, Rails does not need to do a middleware crawl and so on. But the majority of