register a CableReady JSON MIME type

[existentialmutt]

Based on conversations I was having with @leastbad yesterday, it sounds like establishing a dedicated MIME type for CableReady JSON responses delivered via cable_car could have a lot of benefits. This PR registers the application/vnd.cable-ready.json MIME type as a cable_ready format within rails.

Generally speaking, it facilitates architecture patterns I've seen @hopsoft advocating of using one controller to deliver multiple formats. A dedicated content type will allow the same controller action to serve both cable_ready or traditional JSON API requests:

respond_to do |format|
  format.cable_ready { render operations: cable_car ... }
  format.json

More specifically, registering this content type within the cable_ready gem will facilitate some changes I'm proposing to the mrujs cable car plugin to have it use MIME type as the signal of whether to run CableReady operations. See the PR for more details.

Finally, if you want to see how all this stuff fits together, I've wired up a cablecar-based modal library I'm working on to use the MIME-type based cablecar mrujs plugin. Making these changes allows that code to focus on it's own domain and offload all operation fetching and processing to the mrujs cablecar plugin and CableReady's operation serializer.

Edit

In response to some feedback from @leastbad I've added a modification to render operations: to have it send the new content type by default.

[leastbad]

Maybe something like...

initializer "renderer" do
  ActiveSupport.on_load(:action_controller) do
    ActionController::Renderers.add :operations do |operations, options|
      render json: operations.dispatch
    end

    ActionController::Renderers.add :cable_ready do |operations, options|
      response.content_type ||= Mime[:cable_ready]
      render json: operations.dispatch
    end

    Mime::Type.register "application/vnd.cable-ready.json", :cable_ready
  end
end

Edit

Nope, this won't work. Move along, nothing to see, here.

[existentialmutt]

I ran a bunch of tests on this last night and the results were pretty encouraging. Changing the default response content type for render operations: doesn’t change existing behavior because browsers are pretty forgiving when request accept and response content type don’t match.

Details in the mrujs PR:

KonnorRogers/mrujs#64 (comment)

[leastbad]

LGTM!

[marcoroth]

Would it make sense to register both MIME-Types?

Mime::Type.register "application/vnd.cable-ready.json", :cable_ready
Mime::Type.register "application/vnd.cable-car.json", :cable_car

[existentialmutt]

thanks for the thought @marcoroth!

Functionally any CR operations that care about MIME types are going to be using cable_car under the hood, so I'm not
sure the value having two MIME types would actually provide.

I think establishing promoting a single MIME type is best for keeping things clear. The cool thing about cable_car is that it decouples "CableReady JSON (the format)" from "CableReady (the websocket broadcaster)." CableReady is already a term that's more well known than cable_car, and I think it's better to leverage that familiarity rather than elevating a competing term.

[leastbad]

I'm really glad @existentialmutt addressed this!

I am very convinced that cable_car should be a server-side concept. CableReady.perform() accepts CableReady JSON. It doesn't care how the sausage got made. Otherwise, I think we run the serious risk of confusing things.

Elephant in the room: I've already broken my own "rule" with the CableCar plugin for mrujs. The reasons are:

• the CableReady constant is already in play when declaring the plugin, so it has to be called something different
• mrujs CableCar plugin is designed to talk to end points that return JSON generated with cable_car, sooo...

Do as I say, not as I do! 😜

[marcoroth]

The cool thing about cable_car is that it decouples "CableReady JSON (the format)" from "CableReady (the websocket broadcaster)."

That's the thing. We are now using the term of the websocket broadcaster (CableReady) for the JSON format respectively the MIME-Type.

That's why I thought that it could make sense to register both so that you don't chose the wrong one because both work 😉

[leastbad]

When you put it that way, seems harmless enough and potentially even useful.

[existentialmutt]

Fair enough @marcoroth . What I really care about is having the library promote a standard MIME type(s), so I can get behind a second cable-car type.