Scala framework dla Rest API Server? [Zamknięte]


105

Zastanawiamy się nad przeniesieniem naszego Rest API Server (znajduje się w serwisie WWW, na Symfony PHP) do Scali z kilku powodów: szybkość, brak narzutów, mniej procesora, mniej kodu, skalowalność itp. Nie znałem Scali aż do kilku dni temu, ale cieszę się tym, czego nauczyłem się ostatnio dzięki książce Scala i wszystkim postom na blogu i pytaniom (nie jest tak brzydki!)

Mam następujące możliwości:

  • zbuduj serwer Rest API od podstaw
  • użyj niewielkiego frameworka internetowego Scala, takiego jak Scalatra
  • użyj windy

Niektóre rzeczy, których będę musiał użyć: żądania HTTP, wyjście JSON, MySQL (dane), OAuth, Memcache (pamięć podręczna), logi, przesyłanie plików, statystyki (może Redis).

Co byś polecił?

Odpowiedzi:


87

W przypadkowej kolejności:


1
dzięki! Sprawdzę na AKKA, bo wydaje się być bardzo lekka i skalowalna
fesja

1
NB Mam nadzieję, że ktoś poradzi sobie z integracją lub przeniesieniem restfulie.caelum.com.br do Scala. Jedną z opcji jest teraz użycie Restfulie jako nakładki na Scala na JRuby.
oluies

3
+1, używam Akka w pracy do zasilania wydajnego serwera API. Wadą używania JAX-RS z Akka jest to, że JAX-RS zawiera mnóstwo idiosynkrazji Java, które nie pasują do czystego projektu Scala. Mimo to Akka sprawia, że ​​cała transakcja jest tego warta.
Max A.

2
Akka to dobry wybór. Jeśli obsługujesz JSON, spójrz na Lift JSON. Możesz mieszać i dopasowywać, nie ma problemu.
andyczerwonka

1
@santiagobasult Powiedziałbym, że Play! 2.0 i Play-mini! 2.0 stało się
oluies

22

Mam zamiar polecić Unfiltered . To idiomatyczny framework sieciowy, który robi rzeczy „na sposób Scali” i jest bardzo piękny.


15

Spójrz na Xitrum (jestem jego autorem), zawiera wszystko, co wymieniłeś. Jego dokumentacja jest dość obszerna. Z README:

Xitrum to asynchroniczna i klastrowana platforma internetowa Scala i serwer sieciowy na bazie Netty i Hazelcast:

  • Adnotacje są używane do tras URL, w duchu JAX-RS. Nie musisz deklarować wszystkich tras w jednym miejscu.
  • Async, w duchu Netty.
  • Sesje mogą być przechowywane w plikach cookie lub w klastrze Hazelcast.
  • Pamięć podręczna w procesie i klastrowana, nie potrzebujesz oddzielnych serwerów pamięci podręcznej.
  • Comet w procesie i klastrowany, nie potrzebujesz oddzielnego serwera Comet.

7

Dodałbym jeszcze dwie opcje: akka z wbudowaną obsługą JAX-RS i po prostu używając bezpośrednio JAX-RS (prawdopodobnie implementacja Jersey). Chociaż prawdopodobnie mniej "Scala-y" niż inne (poleganie na adnotacjach do wiązania parametrów i ścieżek), JAX-RS jest przyjemny w użyciu, rozwiązując wszystkie problemy związane z kodowaniem usług internetowych przy minimalnym obciążeniu. Nie używałem go przez akka, spodziewałbym się, że jest tam doskonały, uzyskując imponującą skalowalność dzięki implementacji opartej na kontynuacji.


dzięki! Sprawdzę AKKA z JAX-RS jako @Brent i powiedziałeś. Wydaje się, że jest bardzo lekki i zajmuje niewiele miejsca, co jest naprawdę ważne dla API, jeśli chcesz działać naprawdę szybko.
fesja

1
Będziesz musiał użyć JAX-RS 2.0 (który jest obecnie w wersji beta), aby uzyskać skalowalność, ponieważ starsze wersje opierają się na nieprzyjemnych wątkach lokalnych (to znaczy, że wstrzymywanie i wznawianie wątku nie są obsługiwane).
Adam Gent,

4

Spójrz na Finch , bibliotekę kombinatorów Scala do tworzenia usług HTTP Finagle . Finch pozwala na tworzenie złożonych punktów końcowych HTTP z liczby predefiniowanych podstawowych bloków. Podobnie jak w przypadku kombinatorów parsera, punkty końcowe Finch są łatwe do ponownego użycia, tworzenia, testowania i uzasadniania.


3

Jak dotąd wszystkie dobre odpowiedzi. Jednym z punktów na korzyść Lift jest RestHelper , który może ułatwić pisanie krótkich, eleganckich metod API. Ponadto wszystkie inne rzeczy, które chcesz zrobić, powinny być dość proste do wykonania w Lift. Biorąc to pod uwagę, Memcache może nie być konieczne.


dzięki! dlaczego nie uważasz, że memcache jest konieczne? To oczywiście zależy, ale mamy kilka zapytań, które z dużym prawdopodobieństwem będą wykonywane w sposób ciągły, więc nadszedł czas, abyśmy wygrywali i mniej obciążali bazę danych.
fesja

Naprawdę odchodzę od tego, co powiedział wczoraj David Pollak. Zasadniczo buforowanie w Lift usuwa wiele przypadków użycia memcache. Oto jego wiadomość i kilka innych postów w wątku na temat memcache: groups.google.com/group/scala-base/msg/4b11cbd357bfecf0
pr1001

2

Trochę późno na scenie, ale zdecydowanie polecam użycie frameworka Bowler do tworzenia REST API. Jest mały, rzeczowy i obsługuje automatyczną konwersję klas przypadków!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.