Как стать автором
Обновить

Комментарии 15

А чем вам akka.net не подошла, учитывая, что у вас бэкграунд в C#?
После создания прототипа на IIS & С# решили что гораздо больше бесплатных библиотек и фреймворков для разработки подобных масштабируемых сервисов на Java. Функциональные языки программирования очень хорошо подходят для подобных сервисов, поэтому решили взять Scala. Плюс Scala что она прекрасно работает с Java. Ну и соответсвенно использовалась Akka — тут уже ни о каких .NET речь не могла идти :)
А зачем вам там какие-то фреймворки кроме акки?
Мы используем Play Framework для самого сервиса. Например, для работы с Mongo используется ReactiveMongo, для работы с Redis — RedisScala. Сам Play предоставляет удобный механиз для написания сервиса, сериализацию в JSON, есть возможность добавлять различные типы аутентификации, использовать кеш, поддержка куков и тд. Для него есть множество плагинов, недавно я добавил механизм бакендов, чтобы можно было постить клипборды в различные бакенды, просто помечая их тегом. Для аутентификации в бакендах используется библиотека Pac4J. Если планируется развитие продукта, то всегда очень важно насколько развиваются фреймворки, использованные в продукте. Play развивается очень динамично, большое комьюнити и тд.
Если планируется развитие продукта, то всегда очень важно насколько развиваются фреймворки, использованные в продукте.

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

Переформулирую вопрос: что такого вам дает Play Framework, что вам не дал бы asp.net WebAPI + SignalR + akka.net?
По поводу фреймворков спорить не буду — тут есть разные мнения :)

Не уверен, что могу сравнить Play и ASP.NET WebAPI + SignalR + Akka.net, тк никогда не работал с последним.
Но вы же тем не менее утверждаете, что «гораздо больше бесплатных библиотек и фреймворков для разработки подобных масштабируемых сервисов на Java». Вот и хотелось бы узнать, чего вам не хватило в .net.

Да, а еще вы пишете, что «использовалась Akka — тут уже ни о каких .NET» — хотя есть akka.net.
под последней фразой «использовалась Akka — тут уже ни о каких .NET» имелось в виду, что раз была выбрана Scala + Java, то было бы странно использовать с ними Akka.NET

Не готов спорить по поводу фреймворков и приводить какие-то плюсы и минусы .NET и Java (опыт разработки сервисов на .NET у меня небольшой и он касался в основном очень простых сервисов на WCF). Мое субъективное мнение, что выбор инструментов для создания серьёзных сервисов на Java/Scala больше и больше крупных компаний которые строят свои сервисы на Java. В начале разработки мы изучали, к примеру, стек технологий которые использовались в Twitter — я упоминал эту статью
Повторю свой вопрос: каких именно инструментов вам не хватило в вашем прототипе, что вы решили перейти на Scala?
+1
Вместо Akka.Net на мой взгляд проще использовать Orleans
О, спасибо за ссылку на Orleans, я его как-то упустил из внимания.

У akka.net есть то достоинство, что у оригинальной акки уже есть достаточно большое сообщество с наработанными шаблонами, которые легко переносимы и применимы.
А где-нибудь есть разумное сравнение akka.net и orleans?

(статьи я почитать и сам могу, там видно концептуальное различие, но мне интересно, что по этому поводу думают сами разработчики)
НЛО прилетело и опубликовало эту надпись здесь
Mongo любит терять данные при нетсплитах (https://aphyr.com/posts/284-call-me-maybe-mongodb). Как предполагается обеспечивать консистентность данных?
Какого рода авторизация между компонентами, зачем и почему pac4j (есть же несколько отличных scala-модулей по авторизации в Play)?..
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.