1. Inicio
  2. Pregunta y respuesta
  3. Marco de Scala para un servidor API Rest?

Marco de Scala para un servidor API Rest?

2010-09-09 5 views
95

Estamos pensando en trasladar nuestro servidor Rest API (está dentro del servicio web, en Symfony PHP) a Scala por varias razones: velocidad, sin sobrecarga, menos CPU, menos código, escalabilidad, etc. No sabía de Scala hasta varios días, pero he podido disfrutar de lo que he estado aprendiendo en estos días con el libro Scala y todas las entradas de blog y preguntas (que no es tan feo!)Marco de Scala para un servidor API Rest?

tengo las siguientes opciones:

  • construir el servidor de la API de reposo desde cero
  • utilizar un pequeño marco web de Scala como Scalatra
  • uso Ascensor

Algunas cosas que tendrá que utilizar: las solicitudes HTTP, la salida JSON, MySQL (datos), OAuth, Memcache (caché), Registros, carga de archivos, tal vez Estadísticas (Redis).

¿Qué recomendarías?

Fuente

2010-09-09 fesja

Respuesta

79

En ningún orden en particular:

Fuente

2010-09-09 17:38:25 oluies

+1

gracias! Comprobaré AKKA, ya que parece ser muy ligero y escalable – fesja

+1

N.B Espero que alguien se las arregle para integrar o migrar http://restfulie.caelum.com.br/ a Scala. Una opción ahora es usar Restfulie como interfaz para Scala en JRuby. – oluies

+3

+1, uso Akka en el trabajo para alimentar un servidor de API de alto rendimiento. La desventaja de usar JAX-RS con Akka es que JAX-RS viene cargado con una tonelada de idiosincrasias de Java que no encajan muy bien en un proyecto de Scala puro. Aún así, Akka lo vale todo. –

22

Voy a recomendar Unfiltered. Es un marco web idiomático que hace las cosas "a la manera de Scala" y es muy hermoso.

Fuente

2010-09-09 17:27:20

7

Agregaría dos opciones más: akka con soporte incorporado JAX-RS, y simplemente usando JAX-RS directamente (probablemente la implementación de Jersey). Aunque podría decirse que es menos "Scala-y" que otros (basándose en anotaciones para vincular parámetros y rutas), JAX-RS es un placer de usar, ya que resuelve limpiamente todos los problemas de la codificación del servicio web con un espacio mínimo. No lo he usado a través de akka, hubiera anticipado que sería excelente allí, obteniendo una escalabilidad impresionante a través de su implementación basada en la continuación.

Fuente

2010-09-09 17:36:55

+0

gracias! Comprobaré en AKKA con JAX-RS como @Brent y usted dijo. Realmente parece ser muy liviano con un espacio mínimo que es realmente importante para una API, si quieres ir realmente rápido. – fesja

+1

Deberá usar JAX-RS 2.0 (que actualmente es beta) para obtener la escalabilidad, ya que las versiones anteriores dependen de threadlocal desagradable (esto es, la pausa de subprocesos y la reanudación no son compatibles). –

3

Todas las buenas respuestas hasta ahora. Un punto a favor de Lift es su RestHelper, que puede hacer que sea bastante fácil escribir métodos API cortos y elegantes. Además, todas las demás cosas que desee hacer deberían ser bastante sencillas de implementar en Lift. Dicho esto, Memcache podría no ser necesario.

Fuente

2010-09-09 17:56:17 pr1001

+0

gracias! ¿Por qué no crees que Memcache es necesario? Depende, por supuesto, pero tenemos varias consultas que es muy probable que se realicen de forma constante, por lo que es hora de que ganemos y carguemos menos en la base de datos. – fesja

+0

Realmente me estoy saliendo de lo que David Pollak dijo ayer. Básicamente, el almacenamiento en caché dentro de Lift elimina muchos casos de uso de Memcache. Aquí está su mensaje y hay algunas otras publicaciones en el hilo sobre Memcache: http://groups.google.com/group/scala-base/msg/4b11cbd357bfecf0 – pr1001

15

Eche un vistazo a Xitrum (soy su autor), proporciona todo lo que enumeró. Its doc es bastante extenso.De README:

Xitrum es un asíncrono y agrupado Scala framework de desarrollo web y el servidor web en la parte superior de Netty y Hazelcast:

  • anotación se utiliza para las rutas de URL, en el espíritu de JAX-RS. No tiene que declarar todas las rutas en un solo lugar.
  • Async, en el espíritu de Netty.
  • Las sesiones se pueden almacenar en cookies o en grupos Hazelcast.
  • Caché en proceso y en clúster, no necesita servidores de caché separados.
  • Comet en proceso y agrupado, no necesita un servidor Comet por separado.

Fuente

2011-09-22 05:48:18

2

Un poco tarde en la escena, pero definitivamente recomendaría usar Bowler marco para la creación de API REST. ¡Es pequeño, al punto y compatible con la conversión de clases de cajas automáticas!

Fuente

2011-12-28 11:10:04

4

Eche un vistazo a Finch, una biblioteca combinadora Scala para la construcción de servicios HTTP Finagle. Finch le permite construir puntos finales HTTP complejos a partir del número de bloques básicos predefinidos. De forma similar a los combinadores de analizadores, los puntos finales de Finch son fáciles de reutilizar, componer, probar y razonar.

Fuente

2014-05-18 05:11:33

Cuestiones relacionadas

 Cuestiones relacionadas