Websockets

[gregschmit]

There is already a branch for this, but basically I want to dynamically construct ::Channel classes on each controller to allow subscribing to updates for a particular collection, and interacting with controller endpoints via action cable (or anycable).

[westonganger]

Why wouldn't you use webhooks for this instead? Seems like that's what your after. Websockets in an API seems wierd.

[gregschmit]

Well, "webhooks" is just a description of a system hitting an API when an event happens. This project already assists developers in building APIs, and libraries like HTTParty already exist to help people make API requests whenever they want. However, sometimes people want to have a more real-time API, and websockets (Action Cable in Rails) is a solution for providing both two-way communication (so the API can "push" information to you), and also faster data (faster than the request/response cycle). With a traditional API, there is no way for the API to "push" information to consumers. Webhooks would not be sufficient because the consumer would have to register a publicly addressable IP with the service so the data can be pushed.

So, the idea for this feature would be to dynamically generate ::Channel objects for controllers which would allow clients to subscribe to the channel, where they could make requests (just like using the Web API, but faster), and the channel could broadcast object updates to subscribers. For example, if there is a MoviesController, then we could dynamically generate a MoviesController::Channel class using all the metadata in the MoviesController, so that would take care of things like data serialization and then the consumer could send requests to request data, and the backend could broadcast updates to push movie changes to consumers.

[gregschmit]

One other thing to note is that this would all be opt-in. We would not make the normal controller mixins generate this behavior.