I’m building an MCP service in Ruby on Rails called ninja.ai [1], which functions as an app store offering one-click installation of MCP servers. Ninja installs Model Context Protocol servers on client devices using Tauri [2], a lightweight framework for building cross-platform desktop apps.
I’m also using Rails to host MCP servers in the cloud.
I share the criticism of HTTP+SSE and the recent “Streamable HTTP” feature—WebSockets would have been a more appropriate choice for interactive, bidirectional communication. Rails’ native support for SSE via ActionController::Live is limited (blocking) and has led to significant scalability challenges, prompting me to migrate these endpoints to the Falcon web server, which is better suited to concurrent streaming workloads.
When I reviewed the pull request for “Streamable HTTP” (which allows streaming a single controller response via server-sent events), I noticed it was largely driven by engineers at Shopify. I’m curious why they opted for this approach instead of WebSockets, especially given that Rails already includes ActionCable for WebSocket support. My assumption is that their choice was informed by specific infrastructure or deployment constraints, possibly related to simplicity or compatibility with existing HTTP/2 tooling.
It’s worth noting that the transport layer in the Model Context Protocol is intentionally abstracted. Future implementations could leverage WebSockets or even WebRTC, depending on the needs of the host environment or client capabilities.
I’m also using Rails to host MCP servers in the cloud.
I share the criticism of HTTP+SSE and the recent “Streamable HTTP” feature—WebSockets would have been a more appropriate choice for interactive, bidirectional communication. Rails’ native support for SSE via ActionController::Live is limited (blocking) and has led to significant scalability challenges, prompting me to migrate these endpoints to the Falcon web server, which is better suited to concurrent streaming workloads.
When I reviewed the pull request for “Streamable HTTP” (which allows streaming a single controller response via server-sent events), I noticed it was largely driven by engineers at Shopify. I’m curious why they opted for this approach instead of WebSockets, especially given that Rails already includes ActionCable for WebSocket support. My assumption is that their choice was informed by specific infrastructure or deployment constraints, possibly related to simplicity or compatibility with existing HTTP/2 tooling.
It’s worth noting that the transport layer in the Model Context Protocol is intentionally abstracted. Future implementations could leverage WebSockets or even WebRTC, depending on the needs of the host environment or client capabilities.
[1] https://ninja.ai
[2] https://v2.tauri.app