Hacker News new | ask | show | jobs
by granshaw 1863 days ago
Yup. And as illustrated by OP's example links, avoid Stimulus Reflex (NOT stimulus.js) for production too. Apart from the stated reasons, the fact that websocket connections aren't scoped by User by default is a really, REALLY sharp edge!
2 comments

Im a little puzzled by this.

This is essentially like saying "Dont use Rails, the controllers arent scoped to the user by default"

There are plenty of valid reasons to use websockets not scoped to a user. Also how is SR supposed to know your user scheme?

What if you have a multi-tenant app and websockets should be scoped to an account and not a user? Im honestly confused by this statement.

Wouldn't you just override the defaults if you need to scope at the account level?

There are plenty of valid reasons to not scope it to a user. Having the default scoped to the most common case makes sense.

As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable.

As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly.

Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.

This is also true of REST requests. They're not scoped to the user by default. In fact, Rails doesn't even have the concept of a user by default.

The argument against using actioncable because it doesn't scope to users by default is roughly akin to arguing against rails in production because rails doesn't even know what a user is by default.