نظرة عامة على إجراء الربط في ريلز
ستتعرف في هذا الدليل على كيفية عمل إجراء الربط (Action Cable) وكيفية استخدام WebSockets لدمج ميزات الوقت الفعلي في تطبيق ريلز.
بعد قراءة هذا الدليل، ستتلعم:
- ماهية إجراء الربط وكيفية دمج الواجهة الخلفية والأمامية الخاصة به.
- كيفية إعداد إجراء الربط (Action Cable).
- كيفية إعداد القنوات.
- النشر وإعداد المعمارية لتشغيل إجراء الربط.
المقدمة
يدمج إجراء الربط مقابس الويب WebSockets مع باقي تطبيق ريلز بسلاسة. يسمح ذلك بكتابة الميزات في الوقت الحقيقي في روبي بنفس الأسلوب والشكل كبقية تطبيقات ريلز، مع الاستمرار في الأداء وقابلية التطوير. إنه عرض كامل يوفر كلًا من إطار عمل JavaScript من جانب العميل وإطار عمل روبي من جانب الخادم. لديك حق الوصول إلى نموذج المجال الكامل الخاص بك المكتوب مع السجل الفعال أو تقنية ORM الخاص بك في الاختيار.
ماهو Pub/Sub
يشير Pub / Sub أو Publish-Subscribe إلى نموذج قائمة انتظار الرسائل حيث يرسل مرسلو المعلومات (الناشرون) البيانات إلى صنف مجرد من المستلمين (المشتركين) دون تحديد مستلمين فرديين. يستخدم إجراء الربط هذا الأسلوب للتواصل بين الخادم والعديد من العملاء.
مكونات من جانب الخادم
الاتصالات
تشكل الاتصالات أساس العلاقة بين العميل والخادم. لكل مقبس ويب WebSocket مقبول من قبل الخادم، تُنشأ نسخة من كائن الاتصال. يصبح هذا الكائن الأب لكل اشتراكات القناة (channel subscriptions) التي أُنشأت من هناك. لا يتعامل الاتصال نفسه مع أي شيفرة تطبيق معين يتجاوز الاستيثاق والترخيص. يسمى عميل اتصال مقبس الويب WebSocket مستهلك الاتصال (connection consumer). سينشئ مستخدم فردي زوجًا واحدًا لمستهلك الاتصال في كل لسان أو نافذة أو جهاز يفتحه المتصفح.
الاتصالات هي نُسخ من ApplicationCable::Connection
. في هذا الصنف، أنت تسمح بالاتصال الوارد، وتشرع في تأسيسه إذا كان من الممكن التعرف على المستخدم.
إعدادات الاتصال
# app/channels/application_cable/connection.rb
module ApplicationCable
class Connection < ActionCable::Connection::Base
identified_by :current_user
def connect
self.current_user = find_verified_user
end
private
def find_verified_user
if verified_user = User.find_by(id: cookies.encrypted[:user_id])
verified_user
else
reject_unauthorized_connection
end
end
end
end
يكون ident_by
هنا هو معرف اتصال يمكن استخدامه للعثور على اتصال محدد في وقت لاحق. لاحظ أن أي شيء مُيز كمعرف سيُنشِئ تلقائيًا مفوَّضًا (delegate) بنفس الاسم على أي نُسخة قناة أُنشأت خارج الاتصال.
يعتمد هذا المثال على حقيقة أنك ستتولى بالفعل الاستيثاق من المستخدم في مكان آخر في التطبيق الخاص بك، ويُعيِّن ذلك الاستيثاق الناجح ملف تعريف ارتباط موقّع مع معرف المستخدم.
بعد ذلك، يُرسَل ملف تعريف الارتباط تلقائيًا إلى نسخة الاتصال عند محاولة إجراء اتصال جديد، ويمكنك استخدام ذلك من تعيين current_user
. من خلال تحديد الاتصال بواسطة هذا المستخدم الحالي نفسه، فإنك أيضًا تتأكد من أنه يمكنك في وقت لاحق استرداد جميع الاتصالات المفتوحة من قبل مستخدم معين (ومن المحتمل فصلها كلها إذا حذف المستخدم أو كان غير مصرح به).
القنوات
تغلف القناة وحدة منطقية من العمل، مشابهة لما تفعله وحدة التحكم في إعداد MVC عادي. بشكل افتراضي، ينشئ ريلز الصنف الأب ApplicationCable::Channel
لتغليف شيفرة مشتركة بين قنواتك.
إعداد القناة الأصل
# app/channels/application_cable/channel.rb
module ApplicationCable
class Channel < ActionCable::Channel::Base
end
end
ثم يمكنك إنشاء أصناف قناتك (channel classes) الخاصة. على سبيل المثال، قد يكون لديك ChatChannel
و AppearanceChannel
:
# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
end
# app/channels/appearance_channel.rb
class AppearanceChannel < ApplicationCable::Channel
end
يمكن بعد ذلك أن يشترك المستهلك في أي من هاتين القناتين أو كليهما.
الاشتراكات
يشترك المستهلكون في القنوات، كمشتركين (subscribers). اتصالهم يسمى «الاشتراك» (subscription). ثم توجه الرسائل التي أُنتجت إلى اشتراكات القنوات هذه استنادًا إلى معرّف أُرسل بواسطة مستهلك الوصل (cable consumer).
# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
# يُستدعى عندما يصبح المستهلك مشتركًا بهذه القناة
def subscribed
end
end
مكونات من جانب العميل
الاتصالات
يحتاج المستهلكون إلى نسخة من الاتصال على جانبهم. ينشأ هذا باستخدام شيفرة JavaScript التالية، والتي تُولَّد افتراضيًا بواسطة ريلز:
مستهلك الاتصال
// app/assets/javascripts/cable.js
//= require action_cable
//= require_self
//= require_tree ./channels
(function() {
this.App || (this.App = {});
App.cable = ActionCable.createConsumer();
}).call(this);
هذا سوف يُجهِّز مستهلكًا سيتصل بـ /cable على الخادم الخاص بك بشكل افتراضي. لن يُنشَأ الاتصال حتى تحدد أيضًا اشتراكًا واحدًا على الأقل ترغب في الحصول عليه.
المشترك
يصبح المستهلك مشتركًا عن طريق إنشاء اشتراك لقناة معينة:
# app/assets/javascripts/cable/subscriptions/chat.coffee
App.cable.subscriptions.create { channel: "ChatChannel", room: "Best Room" }
# app/assets/javascripts/cable/subscriptions/appearance.coffee
App.cable.subscriptions.create { channel: "AppearanceChannel" }
بينما يُنشِئ هذا الاشتراك، ستوصف الوظيفة المطلوبة للرد على البيانات المستلمة في وقت لاحق.
يمكن للمستهلك التصرف كمشترك في قناة معينة في أي عدد من المرات. على سبيل المثال، يمكن للمستهلك الاشتراك في غرف دردشة متعددة في نفس الوقت:
App.cable.subscriptions.create { channel: "ChatChannel", room: "1st Room" }
App.cable.subscriptions.create { channel: "ChatChannel", room: "2nd Room" }
تفاعلات الخادم والعميل
المجاري
توفر المجاري آلية توجه القنوات عبرها المحتوى المنشور (البث) لجميع المشتركين في ذلك المجرى.
# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
def subscribed
stream_from "chat_#{params[:room]}"
end
end
إذا كان لديك مجرًى مرتبطًا بنموذج، فيمكن توليد البث المستخدم من النموذج والقناة. سوف يشترك المثال التالي في بث مثل comments:Z2lkOi8vVGVzdEFwcC9Qb3N0LzE:
class CommentsChannel < ApplicationCable::Channel
def subscribed
post = Post.find(params[:id])
stream_for post
end
end
يمكنك بعد ذلك البث إلى هذه القناة كما يلي:
CommentsChannel.broadcast_to(@post, @comment)
البث (Broadcasting)
البث هو رابط pub / sub حيث يوجه أي شيء أُرسل من قبل ناشر مباشرة إلى المشتركين في القناة الذين يقومون ببث تلك الإذاعة المسماة. يمكن لكل قناة أن تبث بثًا أو أكثر من بث.
البث هو طابور على الإنترنت يعتمد على الوقت. إذا كان المستهلك لا يجري بثًا (اشترك في قناة معينة)، فلن يحصل على البث إذا اتصل به لاحقًا.
تُستدعَى عمليات البث في أي مكان آخر في تطبيق ريلز:
WebNotificationsChannel.broadcast_to(
current_user,
title: 'New things!',
body: 'All the news fit to print'
)
يضع الاستدعاء WebNotificationsChannel.broadcast_to
رسالةً في قائمة انتظار الاشتراك في محول الاشتراك الحالي (بشكل افتراضي redis للإنتاج و التزامن لبيئات التطوير والاختبار) تحت اسم بث منفصل لكل مستخدم. بالنسبة لمستخدم ذي المعرف 1، سيكون اسم البث web_notifications:1
.
توجه القناة لبث كل شيء يصل إلى web_notifications:1
مباشرة إلى العميل عن طريق استدعاء رد النداء received
.
الاشتراكات
عندما يشترك المستهلك في قناة، يكون بمثابة مشترك (subscriber). هذا الاتصال يسمى الاشتراك (subscription). ثم توجه الرسائل الواردة إلى اشتراكات القنوات هذه استنادًا إلى مُعرّف أُرسل بواسطة مستهلك الربط (cable consumer).
# app/assets/javascripts/cable/subscriptions/chat.coffee
# افترض أن طلبت مسبقًا الإذن لإرسال تنبيهات ويب
App.cable.subscriptions.create { channel: "ChatChannel", room: "Best Room" },
received: (data) ->
@appendLine(data)
appendLine: (data) ->
html = @createLine(data)
$("[data-chat-room='Best Room']").append(html)
createLine: (data) ->
"""
<article class="chat-line">
<span class="speaker">#{data["sent_by"]}</span>
<span class="body">#{data["body"]}</span>
</article>
"""
تمرير المعاملات إلى القنوات
يمكنك تمرير المعاملات من جانب العميل إلى جانب الخادم عند إنشاء اشتراك. فمثلًا:
# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
def subscribed
stream_from "chat_#{params[:room]}"
end
end
يصبح الكائن الذي مُرر ليكون الوسيط الأول إلى subscriptions.create
المعاملات params
(التي هي جدول Hash) في قناة الربط (cable channel). الكلمة المفتاحية channel
مطلوبة:
# app/assets/javascripts/cable/subscriptions/chat.coffee
App.cable.subscriptions.create { channel: "ChatChannel", room: "Best Room" },
received: (data) ->
@appendLine(data)
appendLine: (data) ->
html = @createLine(data)
$("[data-chat-room='Best Room']").append(html)
createLine: (data) ->
"""
<article class="chat-line">
<span class="speaker">#{data["sent_by"]}</span>
<span class="body">#{data["body"]}</span>
</article>
"""
# يُستدعَى هذا في مكان ما في تطبيقك
# NewCommentJob ربما من
ActionCable.server.broadcast(
"chat_#{room}",
sent_by: 'Paul',
body: 'This is a cool chat app.'
)
إعادة بث رسالة
حالة الاستخدام الشائعة هي إعادة رب (rebroadcast) رسالة أُرسلت بواسطة عميل واحد إلى أي عملاء آخرين متصلين.
# app/channels/chat_channel.rb
class ChatChannel < ApplicationCable::Channel
def subscribed
stream_from "chat_#{params[:room]}"
end
def receive(data)
ActionCable.server.broadcast("chat_#{params[:room]}", data)
end
end
# app/assets/javascripts/cable/subscriptions/chat.coffee
App.chatChannel = App.cable.subscriptions.create { channel: "ChatChannel", room: "Best Room" },
received: (data) ->
# data => { sent_by: "Paul", body: "This is a cool chat app." }
App.chatChannel.send({ sent_by: "Paul", body: "This is a cool chat app." })
سيُستلَم إعادة البث من قبل جميع العملاء المتصلين، بما في ذلك العميل الذي أرسل الرسالة. لاحظ أن params
هي نفسها كما كانت عند الاشتراك في القناة.
أمثلة كاملة
خطوات الإعداد التالية متماثلة في كلا المثالين:
- إعداد الإتصال الخاص بك.
- إعداد قناتك الأصل.
- الإتصال بالمستهلك.
مثال 1: ظهور المستخدم
في ما يلي مثال بسيط لقناة تتعقب ما إذا كان المستخدم متصلاً أم لا وما هي الصفحة التي يستخدمونها. (يفيد ذلك في إنشاء ميزات التواجد مثل إظهار نقطة خضراء بجانب اسم المستخدم إذا كان متصلاً بالإنترنت).
إنشاء قناة تظهر جانب الخادم:
<nowiki>#</nowiki> app/channels/appearance_channel.rb
class AppearanceChannel < ApplicationCable::Channel
def subscribed
current_user.appear
end
def unsubscribed
current_user.disappear
end
def appear(data)
current_user.appear(on: data['appearing_on'])
end
def away
current_user.away
end
End
عند بدء الاشتراك، يلغى الاتصال المشترك، وننتهز هذه الفرصة لنقول "لقد ظهر المستخدم الحالي بالفعل". يمكن دعم واجهة برمجة التطبيقات التي تظهر / تختفي بواسطة Redis أو قاعدة بيانات أو أي شيء آخر.
إنشاء اشتراك قناة تظهر العميل:
<nowiki>#</nowiki> app/assets/javascripts/cable/subscriptions/appearance.coffee
App.cable.subscriptions.create "AppearanceChannel",
# Called when the subscription is ready for use on the server.
connected: ->
@install()
@appear()
# Called when the WebSocket connection is closed.
disconnected: ->
@uninstall()
# Called when the subscription is rejected by the server.
rejected: ->
@uninstall()
appear: ->
# Calls `AppearanceChannel#appear(data)` on the server.
@perform("appear", appearing_on: $("main").data("appearing-on"))
away: ->
# Calls `AppearanceChannel#away` on the server.
@perform("away")
buttonSelector = "[data-behavior~=appear_away]"
install: ->
$(document).on "turbolinks:load.appearance", =>
@appear()
$(document).on "click.appearance", buttonSelector, =>
@away()
false
$(buttonSelector).show()
uninstall: ->
$(document).off(".appearance")
$(buttonSelector).hide()
تفاعل خادم - العميل
1 - يتصل العميل بالخادم عبر
App.cable = ActionCable.createConsumer("ws://cable.example.com"). (cable.js).
يحدد الخادم هذا الاتصال بواسطة current_user.
2 - يشترك العميل في ظهور القناة عبر
App.cable.subscriptions.create(channel: "AppearanceChannel"). (appearance.coffee)
3 - يتعرف الخادم على بدء اشتراك جديد لظهور القناة ويشغل الاستدعاء المشترك الخاص به، مع استدعاء طريقة الظهور على current_user.
(appearance_channel.rb)
4 - يدرك العميل أنه أُنشأ الإشتراك واستدعى appearance.coffe) connected ) والتي بدورها تستدعي @install و appear@. و appear@ تستدعي (AppearanceChannel#appear(data على الخادم. وتزود تجزئة البيانات من { appearing_on: $("main").data("appearing-on") }. هذا ممكن لأن طبقة القناة من جانب الخادم تكشف تلقائيًا كل التوابع العامة المعلنة في الفئة (ناقص عمليات الاسترجاعات)، بحيث يمكن الوصول إليها كإستدعاء إجراء بعيد عن طريق تابع perform الاشتراك.
5 - يتلقى الخادم طلب الإجراء appear في قناة الظهور الخاصة بالاتصال المحدد بواسطة (current_user (appearance_channel.rb. يسترد الخادم البيانات باستخدام المفتاح :appearing_on من تجزئة البيانات ويعينها كقيمة :on على المفتاح الذي يمرر إلى current_user.appear.
مثال 2: تلقي إشعارات ويب جديدة
كان المثال مظهر كل شيء عن تعريض وظائف الخادم إلى استدعاء العميل عبر اتصال WebSocket. ولكن الشيء العظيم في WebSockets هو أنه شارع ذو اتجاهين. لذا دعونا الآن نعرض مثالاً حيث يستدعي الخادم إجراءً على العميل.
هذه قناة إخبارية على الويب تسمح لك بتشغيل إشعارات الويب من جانب العميل عند البث إلى مجموعات البث الصحيحة:
إنشاء قناة إشعارات الويب من جانب الخادم:
<nowiki>#</nowiki> app/channels/web_notifications_channel.rb
class WebNotificationsChannel < ApplicationCable::Channel
def subscribed
stream_for current_user
end
End
إنشاء اشتراك قناة إشعارات الويب من جانب العميل:
<nowiki>#</nowiki> app/assets/javascripts/cable/subscriptions/web_notifications.coffee
<nowiki>#</nowiki> Client-side which assumes you've already requested
<nowiki>#</nowiki> the right to send web notifications.
App.cable.subscriptions.create "WebNotificationsChannel",
received: (data) ->
new Notification data["title"], body: data["body"]
بث المحتوى إلى نسخة قناة إعلام عبر الإنترنت من مكان آخر في التطبيق الخاص بك:
<nowiki>#</nowiki> Somewhere in your app this is called, perhaps from a NewCommentJob
WebNotificationsChannel.broadcast_to(
current_user,
title: 'New things!',
body: 'All the news fit to print'
)
يجري اتصالًا WebNotificationsChannel.broadcast_to بوضع رسالة في قائمة انتظار pubsub لمحول الاشتراك الحالي تحت اسم بث منفصل لكل مستخدم. بالنسبة لمستخدم ذي معرف 1، سيكون اسم البث web_notifications: 1.
توجه القناة لبث كل شيء يصل إلى web_notifications: 1 مباشرة إلى العميل عن طريق استدعاء received الاتصال المتلقاة. البيانات التي تُمرر كوسيطة هي البعثرة المرسلة كمعامل ثاني لمكالمة البث من جانب الخادم، JSON تشفرها للرحلة عبر السلك وتفككها لوسيطة البيانات عند الوصول كـ received.
المزيد من الأمثلة الكاملة
راجع مستودع ريلز / actioncable-examples لمثال كامل عن كيفية إعداد كابل الإجراء في تطبيق ريلز وإضافة قنوات.
إعدادات التكوين
يحتوي "كبل الإجراء" على تهيئتين مطلوبتين: مهايئ اشتراك وأصول طلب مسموح بها.
محول الاشتراك
بشكل افتراضي، يبحث Action Cable عن ملف تكوين في config / cable.yml. يجب أن يحدد الملف محولًا لكل بيئة ريلز. انظر قسم التبعيات للحصول على معلومات إضافية حول المحولات.
development:
adapter: async
test:
adapter: async
production:
adapter: redis
url: <nowiki>redis://10.10.3.153:6381</nowiki>
channel_prefix: appname_production
إعدادات تكوين محول
فيما يلي قائمة بمحولات الاشتراك المتاحة للمستخدمين النهائيين.
- محول متزامن : المحول المتزامن هو من أجل التطوير / الاختبار ويجب عدم استخدامه في الإنتاج.
- محول Redis : يتطلب محول Redis من المستخدمين توفير عنوان URL يشير إلى خادم Redis. بالإضافة إلى ذلك، قد يوفر channel_prefix لتجنب تضارب اسم القناة عند استخدام خادم Redis نفسه لتطبيقات متعددة. راجع وثائق Redis PubSub لمزيد من التفاصيل.
- محول PostgreSQL : يستخدم محول PostgreSQL تجمع اتصال Active Record، وبالتالي تكوين قاعدة بيانات التكوين / database.yml للتطبيق، للاتصال به. هذا قد يتغير في المستقبل. # 27214
طلب اصول مسموح بها
يقبل كابل الإجراء فقط الطلبات من الأصول المحددة، والتي مُررت إلى تهيئة الخادم كمصفوفة. يمكن أن تكون الأصول عبارة عن نسخ من السلاسل أو التعبيرات العادية، والتي يقابلها إجراء فحص متطابق.
config.action_cable.allowed_request_origins = ['<nowiki>http://rubyonrails.com'</nowiki>, %r{[[about:blank|http://ruby.*]]}]
لتعطيل والسماح بالطلبات من أي مصدر:
config.action_cable.disable_request_forgery_protection = true
بشكل افتراضي، يتيح لك Action Cable جميع الطلبات من localhost: 3000 عند التشغيل في بيئة التطوير.
إعدادات تكوين المستهلك
لتهيئة عنوان URL، أضف استدعاء إلى action_cable_meta_tag في تنسيق HTML HEAD. يستخدم هذا عنوان URL أو مسار يُعين عادةً عبر config.action_cable.url في ملفات تهيئة البيئة.
إعدادات تكوينات اخرى
الخيار المشترك الآخر للتكوين هو علامات التسجيل المطبقة على مسجل الاتصال. في ما يلي مثال يستخدم معرف حساب المستخدم إذا كان متاحًا، أو "بدون حساب" آخر أثناء وضع العلامات:
config.action_cable.log_tags = [
-> request { request.env['user_account_id'] || "no-account" },
:action_cable,
-> request { request.uuid }
]
للحصول على قائمة كاملة بجميع خيارات التكوين، راجع فئة ActionCable :: Server :: Configuration.
لاحظ أيضًا أن الخادم الخاص بك يجب أن يوفر على الأقل نفس عدد اتصالات قاعدة البيانات كما تعمل لديك. يُعين حجم تجمع العامل الافتراضي إلى 4، وهذا يعني أن عليك إجراء ذلك على الأقل المتوفرة. يمكنك تغيير ذلك في config / database.yml من خلال سمة pool.
تشغيل خوادم الكابلات المستقلة
في التطبيق
يمكن تشغيل كبل الإجراء مع تطبيق ريلز الخاص بك. على سبيل المثال، للاستماع لطلبات WebSocket على / websocket، حدد ذلك المسار إلى config.action_cable.mount_path:
<nowiki>#</nowiki> config/application.rb
class Application < Rails::Application
config.action_cable.mount_path = '/websocket'
End
يمكنك استخدام () App.cable = ActionCable.createConsumer للاتصال بملقم الكبل إذا استدعى action_cable_meta_tag في التخطيط.
يحدد مسار مخصص كوسيطة أولى createConsumer مثل
(("App.cable =ActionCable.createConsumer ( "/ websocket.
لكل نسخة من خادمك تنشأه ولأي عامل ينتج عن خادمك، سيكون لديك أيضًا نسخة جديدة من كبل اإجراء، ولكن استخدام Redis يبقي الرسائل متزامنة عبر الاتصالات.
مستقل
يمكن فصل خادم الكبل عن خادم التطبيق العادي. لا يزال تطبيق Rack، ولكنه تطبيق Rack الخاص به. الإعداد الأساسي الموصى به هو كما يلي:
<nowiki>#</nowiki> cable/config.ru
require_relative '../config/environment'
Rails.application.eager_load!
run ActionCable.server
ثم يبدأ الخادم باستخدام binstub في bin / cable ala:
<nowiki>#</nowiki>!/bin/bash
bundle exec puma -p 28080 cable/config.ru
ما ورد أعلاه سيبدأ خادم كابل على المنفذ 28080.
ملاحظات
لا يمتلك خادم WebSocket إمكانية الوصول إلى الجلسة، ولكن لديه حق الوصول إلى ملفات تعريف الارتباط. يمكن استخدام هذا عندما تحتاج إلى التعامل مع الاستيثاق. يمكنك رؤية طريقة واحدة للقيام بذلك باستخدام Devise في هذه المقالة.
التبعيات
يوفر "كبل الإجراء" واجهة محول اشتراك لمعالجة عمليات pubsub الداخلية الخاصة به. بشكل افتراضي، تتضمن محولات غير متزامنة و مضمنة و PostgreSQL و Redis. المحول الافتراضي في تطبيقات ريلز جديد هو محول غير متزامن (async).
تم بناء جانب روبي من الأشياء على قمة websocket-driver، nio4r، and conjurrent-ruby.
النشر
يعمل كبل الاجراء من خلال مزيج من WebSockets و threads. يتعامل مع كل من أعمال أنابيب الإطار وعمل القناة المحددة من قبل المستخدم داخليًا من خلال الاستفادة من دعم روبي الأصلي. هذا يعني أنه يمكنك استخدام جميع نماذج ريلز المنتظمة الخاصة بك دون أي مشكلة، طالما أنك لم ترتكب أي خطأ في سلامة الصفحات.
يقوم خادم كبل الاجراء بتنفيذ اختطاف حامل المقبس لواجهة برمجة تطبيقات، مما يسمح باستخدام نمط مؤشرات ترابط متعددة لإدارة الاتصالات داخليًا، بغض النظر عن ما إذا كان خادم التطبيق متعدد الخيوط أم لا.
وفقًا لذلك، تعمل شركة Action Cable مع خوادم شائعة مثل Unicorn و Puma و Passenger.