Рамка Scala для сервера API API? [зачинено]

105

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

У мене є такі варіанти:

  • побудувати сервер Rest API з нуля
  • використовуйте крихітний веб-фреймворк Scala на зразок Scalatra
  • використовувати ліфт

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

Що б ти порадив?

api  rest  scala  lift 
— феся
джерело

Відповіді:

87

Ні в якому конкретному порядку:

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

Я порекомендую Unfiltered . Це ідіоматична веб-рамка, яка робить речі "шляхом Scala" і дуже красива.

— Макс А.
джерело
15

Погляньте на Xitrum (я його автор), він містить усе, що ви перерахували. Документ його досить великий. Від README:

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

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

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

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

Погляньте на Фінча , бібліотеку комбінаторів Scala для створення HTTP-сервісів Finagle . Finch дозволяє будувати складні кінцеві точки HTTP з числа попередньо визначених базових блоків. Аналогічно комбінаторам парсера, кінцеві точки Фінча легко використовувати повторно, складати, тестувати та обґрунтовувати.

— Володимир Костюков
джерело
3

Всі хороші відповіді поки що. Одним моментом на користь Lift є його RestHelper , завдяки якому можна досить легко писати короткі, елегантні методи API. Крім того, всі інші речі, які ви хочете зробити, повинні бути досить зрозумілими для впровадження в Lift. Коли це говориться, Memcache, можливо, не знадобиться.

— pr1001
джерело
Дякую! чому ти не вважаєш, що пам’яті потрібні? Це, звичайно, залежить, але у нас є кілька запитів, які, ймовірно, будуть виконуватися постійно, тому пора перемагати і менше завантажувати базу даних.
— fesja
Я справді просто відмовляюся від того, що вчора сказав Девід Поллак. По суті, кешування в ліфті видаляє багато випадків використання пам’яті. Ось його повідомлення, і є кілька інших публікацій у темі про memcache: groups.google.com/group/scala-base/msg/4b11cbd357bfecf0
— pr1001
2

Трохи запізнюємось на сцену, але я б точно рекомендував використовувати рамку Боулера для створення API REST. Це невелика, до суті і автоматична підтримка перетворення класу випадку!

— cracked_all
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.