Rest API 서버용 Scala 프레임 워크? [닫은]


105

속도, 오버 헤드 없음, CPU 감소, 코드 감소, 확장 성 등 여러 가지 이유로 Rest API 서버 (웹 서비스 내부, Symfony PHP에 있음)를 Scala로 이동하려고 생각하고 있습니다. 몇 가지 전까지 Scala를 몰랐습니다. 며칠 전부터 저는 스칼라 책과 모든 블로그 게시물과 질문을 통해 요즘 제가 배운 것을 즐기고 있습니다 (그렇게 못 생겼습니다!).

다음과 같은 옵션이 있습니다.

  • Rest API 서버를 처음부터 구축
  • Scalatra 와 같은 작은 Scala 웹 프레임 워크 사용
  • 리프트 사용

내가 사용해야 할 몇 가지 : HTTP 요청, JSON 출력, MySQL (데이터), OAuth, Memcache (캐시), 로그, 파일 업로드, 통계 (아마도 Redis).

어떤 것을 권 하시죠?

답변:


87

특별한 순서없이 :


1
감사! 매우 가볍고 확장 성을 보인다 나는 AKKA에 확인합니다
fesja

1
NB 누군가가 restfulie.caelum.com.br 을 Scala 로 통합하거나 이식하기를 바랍니다 . 이제 한 가지 옵션은 Restfulie를 JRuby에서 Scala의 프런트 엔드로 사용하는 것입니다.
oluies

3
+1, 저는 직장에서 Akka를 사용하여 고성능 API 서버를 구동합니다. Akka와 함께 JAX-RS를 사용할 때의 단점은 JAX-RS가 pure-Scala 프로젝트에 매우 깔끔하게 맞지 않는 수많은 Java 특이성을 제공한다는 것입니다. 그럼에도 불구하고 Akka는 전체 거래를 그만한 가치가 있습니다.
Max A.

2
Akka는 좋은 선택입니다. JSON을 제공하는 경우 Lift JSON을 살펴보십시오. 믹스 앤 매치가 가능합니다. 문제 없습니다.
andyczerwonka

1
@santiagobasult 나는 그 놀이라고 말할 것입니다! 2.0 및 Play-mini! 2.0 발생
oluies

22

Unfiltered 추천하겠습니다 . 이것은 "스칼라 방식"을 수행하는 관용적 인 웹 프레임 워크이며 매우 아름답습니다.


15

Xitrum (저는 저자입니다) 을 살펴보면 나열된 모든 것을 제공합니다. 그 문서 는 상당히 광범위합니다. README에서 :

Xitrum은 Netty 및 Hazelcast를 기반으로하는 비동기 클러스터형 Scala 웹 프레임 워크 및 웹 서버입니다.

  • 어노테이션은 JAX-RS의 정신으로 URL 경로에 사용됩니다. 한 곳에서 모든 경로를 선언 할 필요는 없습니다.
  • Netty의 정신에 따른 비동기.
  • 세션은 쿠키 또는 클러스터 된 Hazelcast에 저장 될 수 있습니다.
  • In-process 및 클러스터형 캐시는 별도의 캐시 서버가 필요하지 않습니다.
  • In-process 및 클러스터형 Comet, 별도의 Comet 서버가 필요하지 않습니다.

7

두 가지 옵션을 더 추가 할 것입니다. 기본 제공 JAX-RS 지원이있는 akka와 JAX-RS를 직접 사용하는 것입니다 (아마 Jersey 구현). (매개 변수와 경로를 바인드하기 위해 어노테이션에 의존하는) 다른 것보다 "Scala-y"가 덜하지만 JAX-RS는 사용이 즐겁고 최소한의 풋 프린트로 웹 서비스 코딩의 모든 문제를 깔끔하게 해결합니다. 나는 akka를 통해 그것을 사용하지 않았으며, 연속 기반 구현을 통해 인상적인 확장 성을 얻을 수있을 것으로 예상됩니다.


감사! @Brent로 JAX-RS를 사용하여 AKKA를 확인하겠습니다. 정말 빨리 가고 싶다면 API에 정말 중요한 최소한의 풋 프린트로 정말 가볍습니다.
fesja

1
JAX-RS 2.0 (현재 베타 버전)을 사용해야 이전 버전이 불쾌한 threadlocal (즉, 스레드 일시 중지 및 재개는 지원되지 않음)에 의존하므로 확장 성을 확보해야합니다.
Adam Gent 2012

4

Finagle HTTP 서비스 를 구축하기위한 Scala 콤비 네이터 라이브러리 인 Finch를 살펴보십시오 . Finch를 사용하면 미리 정의 된 기본 블록 수에서 복잡한 HTTP 엔드 포인트를 구성 할 수 있습니다. 파서 결합 자와 마찬가지로 Finch 엔드 포인트는 재사용, 구성, 테스트 및 추론이 쉽습니다.


3

지금까지 모든 좋은 답변. Lift가 선호하는 한 가지 포인트는 RestHelper 이며, 짧고 우아한 API 메서드를 작성하기가 매우 쉽습니다. 또한, 당신이하고 싶은 다른 모든 일은 Lift에서 구현하기가 매우 간단해야합니다. 즉, Memcache가 필요하지 않을 수 있습니다.


감사! 왜 Memcache가 필요하다고 생각하지 않습니까? 물론 상황에 따라 다르지만 지속적으로 수행 될 가능성이 매우 높은 쿼리가 여러 개 있으므로 이기고 데이터베이스에 대한 부하가 줄어 듭니다.
fesja

어제 데이비드 폴락이 말한 것에서 벗어나고 있습니다. 기본적으로 Lift 내의 캐싱은 Memcache의 많은 사용 사례를 제거합니다. 다음은 그의 메시지이며 memcache에 대한 스레드에 몇 가지 다른 게시물이 있습니다. groups.google.com/group/scala-base/msg/4b11cbd357bfecf0
pr1001

2

현장에서 조금 늦었지만 REST API 생성을 위해 Bowler 프레임 워크를 사용하는 것이 좋습니다 . 작은, 포인트 및 자동 케이스 클래스 변환 지원!

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.