На каком языке удобней писать websocket сервер?

Question

[MegaMufa]

Добрый день.
Стоит задача сделать web-приложение (на сайт). Если в общем, то что-то вроде тикет системы на стероидах с рядом особенностей. Приложение пишется для себя и своей команды разработчиков, поэтому особо сильной нагрузки не планируется.

Все под MIT лицензией, чтобы если встретится кто-то с такими же как у нас требованиями к процессу разработки, мог взять и запустить у себя, предварительно допилив если требуется.

Связь клиент-сервер через веб сокеты. Стандартный rest не подходит т.к. бОльшая часть всех действий происходит по инициативе сервера. На данный момент планируется только веб морда, но в дальнейшем нужна возможность к этому api прикрутить мобильное приложение.

Думаю не понадобиться fullstack фреймвок тип django, ror. Достаточно будет собрать несколько либ, чтобы не перегружать приложение: orm, роутинг, кеш. От последнего в случае scala/erlang можно вообще отказаться, а держать данные в памяти средсвами самого языка. Хотя если будет что-то легковесное, подходящее под требования, то можно воспользоваться.

База данных реляционная.

Сам я специализируюсь на php и о других языках знаю только в теории. Но опыт разработки позволяет сесть за новый язык и начать писать.

Для фронтенда выбрал angular - двухсторонний биндинг очень одобная штука, как по мне.

Но с серверным языком я несколько сомневаюсь. Писать демона на php можно, но лучше я возьму язык, у которого долгоживущие процессы являются частью его модели.

На данные момент я вижу такие варианты:
1. scala + akka. Акторная модель хорошо подходит под задачу. Плюс JVM позволяет запускать сервер на любой оси.
2. python.
3. Можно упороться и сделать на Erlang. Акторы. Виртуальная машина. Отсутствие тяжелых вычислений позволяет не бояться просадок производительности.
4. Go. Слышал краем уха. При беглом просмотре понравилась удобная многопоточность. Но что у него с экосистемой, я не знаю.

Nodejs подходит, но отказался сразу ибо терпеть не могу js. И если на клиенте это неизбежное зло (про typescript, coffescript и т.п. знаю), то на сервере можно избежать поедания кактусов.
Rust тоже имеет акторную модель, но, как по мне, черезчур сложный для этой задачи.

Важный момент: так как это личный проект, который я сам делаю для облегчения своей работы и работы своей команды, то меня не волнует легкость поисков разработчиков на выбраном языке. При этом для меня важна легкость запуска уже собраного приложения.

Я занимался разработкой rest серверов, а с реалтайм системами не работал и потому могу не до конца знать все подводные камни. У кого есть опыт в разработке таких систем, посоветуйте, какой язык будет удобней и быстрей для разработки сервера?

UPD: Всем спасибо за участие!
Решил писать на PHP, а для сокетов перед ним поставить центрифугу. Потому что:
1. PHP очень распространен. Т.к. код будет открытым, не хочеться создавать другим проблемы при допиливании под себя. Чем распространенней язык, тем проще другим будет использовать приложение.
2. Т.к. ображение к приложению остаеться по стандартной rest схеме, не придеться отдельно писать API. Центрифуга может обращаться к стандартному API приложения, к которому так же и другие приложения могут вязаться.

Answer 1

[index0h]

Вообще говоря быстрее/удобней таки на nodejs.

Если ваша цель - получить проект, который вы хотите быстро - пишите бизнес логику на PHP, для websockets юзайте habrahabr.ru/company/mailru/blog/266017/.

Можно линк на ваш проект?

Comments

[MegaMufa]

Хм. Занимательная штука. Не знал (точнее не задумывался) что для сокет соединений можно отдельную прослойку поставить на сервер. Спасибо.

Проект на стадии проектирования. Есть тз, схемы, прототипы интерфейса, описаны сценарии. К кодингу как раз только приступаю. Подбираю язык под задачу. Хоститься буду на гитхабе. Если хотите кину сюда ссылку, как начнется работа.

[index0h]

> Если хотите кину сюда ссылку, как начнется работа.
Было бы здорово)

[Сергей Протько]

HaruAtari: опенсурс это здорово, кидайте конечно, мне особо интересны описанные сценарии. Сам я планирую ближайшие пару недель стартануть в рамках опенсурса систему управления тест кейсами, так же для своей команды. Как-то существующие варианты показались убогими.

В целом да, наилучший вариант организовать WS-сервер на каком-нибудь socket-io и связать с php приложением через MQ и pub/sub для авторизации.

Я в одном из проектов последних использовал JWT для аунтефикации, что позволило упрастить схему авторизации для соединений, так как токен нужно проверять только на валидность подписи, а для этого не нужно ничего форвардить в пых. Связать же пых и ноду и заставлять его пересылать пользователям сообщения не составляет труда.

Answer 2

[sim3x]

Для фронтенда выбрал angular - двухсторонний биндинг очень одобная штука, как по мне.

вопрос в другом, если у тебя большой поток, то как себя поведет ангуляр тебе могут сказать только гуру. Не спеши привязывать себя к фреймворку - лучше сделай прототип и посмотри как он работает в твоей схеме. Желательно сразу на второй версии или хотя б с использованием ES2015
Задумка Ангуляра в том, что он позволял верстальщикам делать интерактивность просто.

3. Можно упороться и сделать на Erlang

whatsUp не упоролся, а просто сделал и держит фб. Главное, что платформа берет на себя много вопросов по обслуживанию кода на множестве нод. И что твой код не уронит всю платформу при апдейте
Насколько я понимаю у го такой платформы нет

Comments

[MegaMufa]

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

[Сергей Протько]

Задумка Ангуляра в том, что он позволял верстальщикам делать интерактивность просто.

Это плюсы конкретно дата биндинга и только, остальное достигается за счет дробления UI на директивы, в этом случае за логику верстальщики (если у вас есть отдельная такая личность) не отвечают.

Проблем с производительностью у ангуляра особо нет, если не пихать все во view и разумно использовать этот самый дата биндинг. Конкретно работа с WS и т.д. всеравно ложится на плечи разработчика, это модель, ангуляр тут ни на что не влияет.

[sim3x]

HaruAtari: если не саас, то предпочтительность на беке будет,
го - собрал бинарник и все работает
питон - стоит везде и в третьей версии есть все что нужно для асинхронности
джава - потому что ентерпрайс
ерланг - надежно

"Коробочное решение" обязывает тебя плюнуть на свои хотелки и сделать все на том, что клиент больше любит. И выходит, что твоя связка скорее php-jq
Не уверен, что коробочное решение стоит вообще разрабатывать сейчас

Answer 3

[Дмитрий Авилов]

Nodejs подходит, но отказался сразу ибо терпеть не могу js.

А вы научитесь его правильно готовить, он очень вкусный, как раз именно для "реактивного" веб-приложения, асинхронность (которая вам, наверное, и не по нраву) даёт возможность работать сверхбыстро.

Comments

[MegaMufa]

С асинхронностью как раз все впорядке. Я заюзал icecoffeescript и с колбеками вообще все хорошо стало. Тут неприязнь чисто личная. Мне не нравится его система типов (частично помогает typescript), отсутсвие многопоточности, его модель ООП. Не очень хочется писать на языке, который лично мне отвратителен.

[Михаил Потанин]

Да и асинхронность там какая-то странная. Часто на события вешается один обработчик, который должен разбираться и с ошибками, и со штатным завершением операции.

Answer 4

[Andy]

Раз уж я услышал упороться… :-)
Другими словами, раз есть свободное время, зачем его тратить в пустоту. Давай посмотрим с другой стороны: PHP – говно, а JS – ок. Норм? :-)
Но над твоей системой и упарываться не надо. Максимализм? Кэши тебе подавай, Go, Scala?
Твоё приложение – это ивент машина пытающаяся поговорить с человеком через браузер :-)
n2o – просто почитай ридми и ты всё сам поймешь. И никаких JS фреймворков которые пытаются в данные, будешь писать SPA и отсылать DOM по WS с сервера как ты и хотел, в любое время, из одного микропроцессика обслуживающего пользователя.
И так же как JVM - на любой тачке, более того: компиляция на лету с горячим обновлением без потери соединений. noSQL из коробки, да ещё и распределенная. Выполнение кода на другой машине через TCP…
Да, большинство фишек для тебя просто избыточны, но они есть, изкаропки. Ты же о экосистеме говорил? Вот она.
Коллегам поиграться будешь давать в виде Юникернел-бандла который сам еще и рекомпиляться умеет.

Осталось выучить на этом проекте Эрланг за 10 дней и всё. Он же понятнее PHP в 10 раз. Энжой ))

Comments

[Даниил Колесниченко]

А ещё есть Elixir, он как Erlang, только с человеческим синтаксисом

[MegaMufa]

Эрланг я знаю на уровне "немного ниже среднего". И не в коем случае не хотел его грязью поливать. Говоря упороться и писать на нем, я имел в виду, заюзать язык, который врядли кто-нибудь посоветовал бы. Вон все ноду впаривают. Эрланг замечателен, но не мейнстрим. Из-за этого так выделил.

И это не максимализм. Я говорил, что привык писать системы, которые не живут между запросами. А там даже для простого приложения нужен кэш, чтобы по каждому чиху в бд не бегать. В долгоживущий, я понимаю, что по другому, но на сколько, пока не знаю.

[Andy]

если Elixir имеет человеческий синтаксис (зашкрвар головного мозга рельсо-yoba) то я тот олень с пикчи: goo.gl/1f8429
to HaruAtari
Жаль что ты не понял мой настрой :) В твоём посте я увидел негатив только про JS. Но смотри-ка как нодо-бои расхвалили тебе, ты уже забыл что говорил о том, что мейнстрим тебе не нужен :))

[MegaMufa]

Andy: Там мне мейнстрим и не нужен. Я объяснил, почему я так упомянул эрланг.
Собственно, сейчас выбираю между erlang и php. Первый вариант интересней и стимулирует доучить язык. Второй не так интересен, но больше шанс получить поддержку со строны (те де коллеги).

Answer 5

[Super User]

Nodejs подходит, но отказался сразу ибо терпеть не могу js.

Go. Слышал краем уха. При беглом просмотре понравилась удобная многопоточность. Но что у него с экосистемой, я не знаю.

Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.

Бьерн Страуструп.

Comments

[MegaMufa]

И что? Про go, я написал лишь то, что я с ним не работал. Ноду я ни в коем случае не ругал, а сказал, что мне лично она не нравится. В общем ваш коммент не сильно полезен для решения вопроса.

[Super User]

HaruAtari: Это не мой коммент, а цитата создателя С++. И вы написали "терпеть не могу js", а это не тоже самое, что просто "не нравится". Неприязнь к каким-либо языкам программирования это не то, о чем следует думать, когда речь идет о реализации конкретной задачи. Нужно выбирать инструмент, который максимально подходит под задачу, а под ваши "нравится"/"не нравится".

[MegaMufa]

Super User: Кто такой Страуструп я знаю. И приведение его цитаты было бесполезно.

Надо выбирать не максимально подходящий, а оптимально. Работая над проектом в свободное от работ время, очень важно чтобы это приносило удовольствие. Я не просто так обратил внимание, на то, что это не комерческая разработка, а личный проект.

К тому же ноду нельзя назвать максимально подходящей. Тот же экланг и акка умеют то же самое, только через акторы, что удобней на мой взгляд, плюс многопоточность. Если бы ответ был однозначным, я бы не спрашивал.

[Михаил Потанин]

Pascal к какому типу относится?

[Super User]

potan: Pascal думаю относится к обоим типам.

Answer 6

[Renat Ibragimov]

Ничего не мешает на CoffeeScript под Node.js - потому лучше возьмите, то что знаете - быстрее напишите. А взлетит проект перепишите уже на чем-нибудь серьезном как Erlang, Go, Scala.
А не взлетит - ну и ладно, зато не убили кучу времени и не потеряли проект.

Answer 7

[Михаил Потанин]

Scala и Play Framework вполне подходят. Когда потребовались web-сокеты, мне их удалось прекрутить без труда.
Правда, сама Scala - не самый простой язык, может потребоваться некоторое время, что бы с ним разобраться.

Answer 8

[Виктор]

Если хотите реализовать как можно быстрее можете попробовать saas сервис для работы с websocket вместо написания своего сервиса. К примеру вот https://comet-server.ru/
Тогда остальную часть можно писать на php и у результирующего приложения будут низкие требования к хостингу так как работа с websocket будет выполнятся не на ваших серверах и не будет нагружать вашу инфраструктуру.

Comments

[MegaMufa]

Это слишком. Во первых сетевые задержки грубо говоря удваиваются. Во вторых зачем использовать сторонний сервис, если можно поставить ту же центрифуга. Плюс не пожходит для установки в закрыторй сети без доступа к интеренту.

Answer 9

[UA3MQJ]

А мне близки Erlang и по работе применяю AngularJS. Поэтому n2o не сильно заинтересовал. Надо изучать. А ангуляр я уже знаю более менее. Недавно я тоже задался вопросом создания вебсокет сервера, и остановился на YAWS (ковбой тоже поддерживает, но на винде не собрался). На винде YAWS запустился нормально. Причем, я смог запустить его и как встроенный сервер в свое Erlang приложение. По сути дела всё то же самое, как и в случае с обычным сервером и ангуляром, только тут устанавливаем соединение не с rest а с ws. На стороне сервера YAWS нормально отдает странички, а в случае перехода на WS вызывает написанный на ерланге коллбек. Все прозрачно, понятно. Разобрался за час.