Платформа Scala для сервера Rest API? [закрыто]

105

Мы думаем о переносе нашего Rest API Server (он находится внутри веб-службы на Symfony PHP) на Scala по нескольким причинам: скорость, отсутствие накладных расходов, меньшее количество ЦП, меньше кода, масштабируемость и т. Д. Я не знал Scala до тех пор, пока несколько дней назад, но мне нравится то, что я изучал в эти дни, с помощью книги Scala, всех сообщений и вопросов в блогах (это не так уж и некрасиво!)

У меня есть следующие варианты:

  • построить Rest API Server с нуля
  • использовать крошечный веб-фреймворк Scala, например Scalatra
  • использовать Лифт

Некоторые вещи, которые мне придется использовать: HTTP-запросы, вывод JSON, MySQL (данные), OAuth, Memcache (кеш), журналы, загрузка файлов, статистика (возможно, Redis).

Что бы вы порекомендовали?

api rest scala lift Fesja
источник

Ответы:

87

В произвольном порядке:

вложений
источник
1
Спасибо! Я проверю AKKA, так как она кажется очень легкой и масштабируемой
fesja
1
NB. Я надеюсь, что кто-нибудь удастся интегрировать или перенести restfulie.caelum.com.br на Scala. Один из вариантов сейчас - использовать Restfulie в качестве интерфейса для Scala на JRuby.
oluies
3
+1, я использую Akka на работе для обеспечения высокопроизводительного сервера API. Обратной стороной использования JAX-RS с Akka является то, что JAX-RS содержит массу особенностей Java, которые не очень хорошо вписываются в проект на чистом Scala. Тем не менее, Akka стоит того.
Макс А.
2
Акка - хороший выбор. Если вы обслуживаете JSON, обратите внимание на Lift JSON. Вы можете смешивать и сочетать, без проблем.
andyczerwonka
1
@santiagobasult Я бы сказал, что Play! 2.0 и Play-mini! 2,0 произошло
oluies
23

Я буду рекомендовать Unfiltered . Это идиоматический веб-фреймворк, который делает все "по-Scala" и очень красив.

Макс А.
источник
15

Взгляните на Xitrum (я его автор), он предоставляет все, что вы перечислили. Его документ довольно обширен. Из README:

Xitrum - это асинхронный кластерный веб-фреймворк и веб-сервер Scala поверх Netty и Hazelcast:

  • Аннотация используется для URL-маршрутов в духе JAX-RS. Необязательно объявлять все маршруты в одном месте.
  • Асинхронный, в духе Нетти.
  • Сеансы могут храниться в файлах cookie или в кластеризованном Hazelcast.
  • Внутрипроцессный и кластерный кеш, вам не нужны отдельные кеш-серверы.
  • Внутрипроцессная и кластерная Comet, вам не нужен отдельный сервер Comet.
Нгок Дао
источник
7

Я бы добавил еще два варианта: akka со встроенной поддержкой JAX-RS и просто использование JAX-RS напрямую (вероятно, реализация Jersey). Хотя JAX-RS, возможно, менее «Scala-y», чем другие (полагающийся на аннотации для привязки параметров и путей), использование JAX-RS доставляет удовольствие, поскольку оно решает все проблемы кодирования веб-сервисов с минимальными затратами. Я не использовал его через akka, я ожидал, что он будет отличным, получая впечатляющую масштабируемость за счет реализации на основе продолжения.

Дэйв Гриффит
источник
Спасибо! Я проверю AKKA с JAX-RS как @Brent, и вы сказали. Он действительно кажется очень легким и занимает минимум места, что действительно важно для API, если вы хотите работать очень быстро.
fesja 09
1
Вам придется использовать JAX-RS 2.0 (который в настоящее время является бета-версией), чтобы получить масштабируемость, поскольку более старые версии полагаются на неприятный threadlocal (то есть приостановка и возобновление потоков не поддерживаются).
Адам Гент,
4

Взгляните на Finch , библиотеку комбинаторов Scala для создания HTTP-сервисов Finagle . Finch позволяет создавать сложные конечные точки HTTP из числа предопределенных базовых блоков. Подобно комбинаторам парсеров, конечные точки Finch легко повторно использовать, составлять, тестировать и обдумывать.

Владимир Костюков
источник
3

Пока все хорошие ответы. Одним из плюсов Lift является его RestHelper , который позволяет легко писать короткие элегантные методы API. Кроме того, все остальное, что вы хотите сделать, должно быть достаточно простым для реализации в Lift. При этом Memcache может и не понадобиться.

pr1001
источник
Спасибо! почему вы не думаете, что кэш памяти необходим? Это зависит, конечно, но у нас есть несколько запросов, которые, скорее всего, будут выполняться постоянно, поэтому пришло время победить и уменьшить нагрузку на базу данных.
fesja 09
Я действительно просто отклоняюсь от того, что вчера сказал Дэвид Поллак. По сути, кеширование в Lift устраняет многие варианты использования memcache. Вот его сообщение и еще несколько сообщений в ветке о memcache: groups.google.com/group/scala-base/msg/4b11cbd357bfecf0
pr1001
2

Немного поздно, но я определенно рекомендую использовать среду Bowler для создания REST API. Он небольшой, по существу, и поддержка автоматического преобразования case class!

cracked_all
источник