Рубиновые приложения в реальном времени: CRAMP vs NODE.JS - PullRequest
10 голосов
/ 07 мая 2010

Мне было интересно, имел ли кто-нибудь из вас представление о том, какой из них лучше, и какие факторы следует учитывать при использовании одного из этих

Ответы [ 5 ]

5 голосов
/ 07 октября 2010

Я могу говорить больше с другой стороны (Node.js). Я только что написал гем, который интегрируется с Rails 3, который использует серверную часть Node.js для прослушивания сообщений Redis PUBSUB и соответствующим образом обновляет интерфейсную часть Rails.

Socket.IO + Node не сложно интегрировать с приложением Rails (особенно если вы работаете с jQuery), но в зависимости от вашей целевой базы браузера (например, IE7), может быть сложно работать правильно во всех случаях, а именно из-за некоторых странных случаев использования Flash Socket в качестве запасного варианта (обычно когда WebSockets не работают).

Тем не менее, я настоятельно рекомендую Node.js + Socket.IO. Он очень легкий, с множеством опций и возможностью расширения, чтобы сделать практически все, что вы могли. На мой взгляд, Rails - это фантастическая веб-инфраструктура для создания больших приложений, которым необходим вычислительно насыщенный интерфейс. Я бы не стал использовать его для небольших приложений, управляемых событиями, просто потому, что он использует так много памяти только для платформы. Я люблю Ruby / Rails, но когда дело доходит до необходимости что-то для быстрой и чистой обработки событий / обработки сообщений, у Node есть мой голос.

Если вам нужны более конкретные примеры, мой проект Kthxbye (клон Resque-esque) связывается с Redis, который, в свою очередь, прослушивается Node.JS, который, в свою очередь, может обновлять веб-приложение.

Плагин : http://github.com/plukevdh/kthxbye (см .: http://github.com/plukevdh/kthxbye/blob/master/lib/generators/kthxbye/templates/kthxbye.js)

Узел Backend : http://github.com/plukevdh/kthxbye-node (см .: http://github.com/plukevdh/kthxbye-node/blob/master/poll.js)

(Извинения за полное отсутствие документации по проекту узла.)

3 голосов
/ 17 сентября 2010

Я играл с судорогой и рельсами 3 некоторое время назад. Пытался создать представление с динамическими обновлениями, используя WebSockets для передачи данных между клиентами и сервером. Он отлично работал с Chrome, но Safari 5 и FF реализуют более новую версию протокола websocket, а Cramp нет, поэтому я не смог заставить его работать там.

Я согласен, что использование Ruby для всего стека это хорошо, но я считаю, что Cramp сейчас немного отстает от кривой в некоторых аспектах.

Я решил укусить пулю и использовать node.js (и пакет SocketIO) для своих вещей.

Удачи!

2 голосов
/ 29 мая 2010

Я сейчас пишу несколько нетривиальное веб-приложение, использующее Rails (3) и Cramp вместе.У меня нет опыта работы с Node.js, и я только начал использовать Cramp как есть, но он выглядит многообещающе.И, на мой взгляд, возможность использовать Ruby - большой плюс!(Я начал с Tornado (Python) и не мог вынести язык. Извините фанатов Python!)

Недостатком является то, что я нашел очень, очень маленький сторонний материал на Cramp,Думаю, это не удивительно, учитывая, насколько это ново, но вы более или менее сами по себе.Если вам нужна рука, вы, вероятно, не должны использовать Cramp.

1 голос
/ 20 сентября 2010

Проверьте различные репо судороги. WebSockets - движущаяся цель, и жить на грани не так просто. github.com/maccman/cramp fork работает с новой версией веб-сокетов, в то время как оригинальная сборка не обновлена ​​и не подвергается рефакторингу Также взгляните на eventmachine-websockets. В любом случае - будьте готовы использовать thin + eventmachine на стороне сервера. Со спазмом вы должны истощиться в производственном режиме, судороги пока не так хороши.

0 голосов
/ 01 апреля 2015

Почему вы ограничиваете себя Судорогой на рубиновой стороне?

Вы также можете использовать Rails для приложений реального времени с websocket-rails .

Вы также можете использовать фреймворки в реальном времени, такие как Plezi или Вольт ... Вольт и Плези работают лучше, чем Cramp, по моему мнению (но я пристрастен как я написал каркас плези).

Вот простой эхо-сервер веб-сокета с Plezi :

require 'plezi'

class EchoCtrl
    def index
        redirect_to 'http://www.websocket.org/echo.html'
    end
    def on_message data
        # to broadcast the data add:
        # broadcast :_send_message, data
        _send_message data
    end
    def _send_message data
        response << data
    end
end

listen 

# you can add, a socket.io route for JSON with socket.io
route '/socket.io', EchoCtrl
route '/', EchoCtrl

# exit the irb console to finish the setup and start the Plezi server
exit
...