Future (if it's really required) somewhere on the very edge of the application where the actual I/O happens
@nebulorum there is no simple answer here, especially on "correctness" of abstraction.
Personally I'd prefer to use F[_] inside the application instead of fixing on a specific monad, would it be Future, IO or Task.
Speaking of Twitter Future, the only "killer feature" comparing to cats.effect.IO is LocalContext that is somewhat similar to Java's ThreadLocal and might be quite handy to use. I.e. monix Task provides similar capabilities.
We use ReaderT[IO, RequestEnv, *] monad instead to have the same set of capabilities but also keep referential transparency.
Future outside of your application logic, there is no difference from your app perspective on what happens outside
Endpoint[User
finch artifacts or the new finchx artifacts that make use cats effect? If you are using the ones with cats effect you can do something like this https://github.com/finagle/finch/blob/master/examples/src/main/scala/io/finch/middleware/Main.scala#L32
@sentenza are you using the old
finchartifacts or the newfinchxartifacts that make use cats effect? If you are using the ones with cats effect you can do something like this https://github.com/finagle/finch/blob/master/examples/src/main/scala/io/finch/middleware/Main.scala#L32
I'm using the new ones (finchx) so I guess that will solve my problem, but now I'm wondering how exactly I should take advantage of that middleware in my endpoints.
val auth: Endpoint.Compiled[IO] => Endpoint.Compiled[IO] // where should I put the auth middleware?
val authFilter = Function.chain(Seq(auth))
val compiled = filters(Bootstrap.serve[Text.Plain](myEndpoint).compile)
// Endpoint.toService(compiled) ??Is there any way to directly apply the authFilter on my endpoints?
myEndpoint) will be the subject of filtering once it's passed to the function
If you don't like the case I mentioned and don't care about applicative nature of :: composition and the fact, that all the endpoints in this composition are evaluated to accumulate the errors, you can implement your own endpoint:
val auth: Endpoint[IO, HNil] = new Endpoint { .. } //or just header.mapOutputAsync depending on how you handle authAnd then compose it with those you need to protect:
get("foo" :: "bar" :: auth) { Ok("protected") }:: composition all the endpoints evaluated unless one of them returns NotMatched. Since authentication for you is effectful, meaning it returns IO, you can't return NotMatched outside of IO. Therefore, you will have to return Matched result with failed output IO[Output] in case of authentication failure. In that case the rest of :: endpoints in the same composition scope are still evaluated for the sake of error accumulation. Say, you have JSON body to parse, then it'll be checked instead of failing fast. Nevertheless, Ok("protected") is never evaluated & returned if at least one of the endpoints in the corresponding composition fails with error, so in that context it's safe
item instead of removing it, sorry :P
its it possible to do?
for example
val svc1: Service[Request, Response] = ???
val svc2: Service[Request, Response] = ???
Http.server.serve(":8080", svc1 :+: svc2)