what - java scala framework

akka http: Akka transmite los actores para crear un servicio de descanso

Question

Cuando se trata de crear un servicio web REST con más de 60 API en akka http. ¿Cómo puedo elegir si debo ir con transmisiones akka o actores akka? En su post , Jos muestra dos formas de crear una API en akka http, pero no muestra cuándo debo seleccionar una sobre la otra.

Answer 1

¡No olvide los futuros!

Un addendum que haría a la fina respuesta de Rudiger Klaehn es considerar también el caso de uso de un Future . La capacidad de composición de los futuros y la gestión de recursos de ExecutionContext hacen que los futuros sean ideales para muchas, si no la mayoría, de las situaciones.

Hay una excelente publicación en el blog que describe cuándo los futuros son una mejor opción que los actores. Además, la contrapresión proporcionada por Streams viene con una overhead bastante considerable.

El hecho de que esté en el agujero del conejo utilizando akka-http no significa que toda la concurrencia dentro del controlador de su solicitud deba limitarse a Actores o Streams.

Ruta

Route acomoda inherentemente los futuros en la definición de tipo :

type Route = (RequestContext) ⇒ Future[RouteResult]

Por lo tanto, puede hornear un futuro directamente en su ruta utilizando solo funciones y futuros, sin directivas:

val requestHandler : RequestContext => HttpResponse = ???

val route : Route = 
  (requestContext) => Future(requestHandler(requestContext)) map RouteResult.Complete

Directiva onComplete

La directiva onComplete permite "desenvolver" un futuro dentro de su ruta:

val route = 
  get {

    val future : Future[HttpResponse] = ???

    onComplete(future) {
      case Success(httpResponse) => complete(httpResponse)
      case Failure(exception)    => complete(InternalServerError -> exception.toString)
    }
  } 

Answer 2

Esta es una pregunta dificil. Obviamente, ambos enfoques funcionan. Así que, hasta cierto punto, es una cuestión de gusto / familiaridad. Así que todo lo que sigue ahora es solo mi opinión personal.

Cuando es posible, prefiero usar akka-stream debido a su naturaleza de alto nivel y seguridad de tipos. Pero si este es un enfoque viable depende mucho de la tarea de la API REST.

Akka-stream

Si su API REST es un servicio que, por ejemplo, responde preguntas basadas en datos externos (por ejemplo, una API de tipo de cambio), es preferible implementarlo utilizando akka-stream.

Otro ejemplo donde akka-stream sería preferible sería algún tipo de interfaz de base de datos donde la tarea de la API REST es analizar los parámetros de consulta, traducirlos a una consulta de base de datos, ejecutar la consulta y traducir el resultado según el tipo de contenido solicitado por el usuario. En ambos casos, el flujo de datos se asigna fácilmente a primitivas akka-stream.

Los actores

Un ejemplo en el que sería preferible utilizar actores si su API permite consultar y actualizar un número de actores persistentes en un clúster. En ese caso, puede ser preferible una solución basada exclusivamente en actores o una solución mixta (analizar los parámetros de consulta y traducir los resultados utilizando akka-stream, haga el resto utilizando actores).

Otro ejemplo en el que una solución basada en actores podría ser preferible sería si tuviera una API REST para solicitudes de larga ejecución (por ejemplo, websockets), y desea implementar el proceso de procesamiento de la API REST en un clúster. No creo que algo como esto sea posible actualmente utilizando akka-stream.

Resumen

Para resumir: mire el flujo de datos de cada API y vea si se asigna de manera clara a las primitivas ofrecidas por akka-stream. Si este es el caso, implementarlo usando akka-stream. De lo contrario, implementar utilizando actores o una solución mixta.