0
votes

Is it abuse or somehow dangerous to use akka-http like this?

On server

def source(consumerOffset: UUID) = 
  readJournal.eventsByTag(“MyTag", consumerOffset).map(_.asJson)

pathPrefix("stream" / Segment.map(UUID.fromString)) { offset =>
  pathEndOrSingleSlash {
    get {
      complete {
        HttpResponse(
          StatusCodes.OK,
          entity = HttpEntity(ContentTypes.`application/json`, source(offset))
        )
      }
    }
  }
}

Then on client side

Source.single(HttpRequest("http://localhost:9000/stream"))
  .mapAsync(1) { r =>
    Http().singleRequest(r).map { res =>
      res.entity.dataBytes.map(_.parse[Event])
    }
  }
  .flatMapConcat(identity).mapAsync(processEvent)

UPD:

  1. Is it guaranteed that chunks I send will be the same on client side.
  2. Is it ok to have response with possibly endless number of chunks?
  3. What is the right Content-Type for this kind of response?

UPD 2:

Akka 2.4.9 added ability to respond with streams. And basically does exactly the same, providing some syntax sugar. See the docs.

1
Which part are you concerned about? It all appears to be boiler plater at first glance...Ramón J Romero y Vigil
1. Is it guaranteed that chunks I send will be the same on client side.Denis Mikhaylov
2. Is it ok to have response with possibly endless number of chunks?Denis Mikhaylov
I've updated question.Denis Mikhaylov
@DenisMikhaylov In addition to this, What happens if the Client closes the connection in b/w, but server has no possible way to know it, server thinks the client is just slow in consuming and it keeps buffering the response. How to handle these scenarios?curious

1 Answers

1
votes

Answering your questions in order:

  1. Yes, the client will receive BytesString representations of your objects encoded in json.
  2. Yes, it is fine to have a stream source on the server side which never terminates.
  3. The content you've specified in the question (application/json) is correct.