John A. De Goes

Scalafix still failing:

@afsalthaj Let's work on it together, if you don't mind! Will be done twice as fast. 😆

In our first collaboration, we discussed making the following changes: 1. Adding a new type parameter to `In` to track how the `In` is generated. This would allow us to...

Here's the changes I was envisioning being made to `API`: ```scala final case class API[MiddlewareIn, MiddlewareOut, HandlerIn, HandlerOut]( middlewareIn: In[Query & Headers, MiddlewareIn], middlewareOut: Out[Headers, Unit], handlerIn: In[Route & Query...

cc @adamgfraser @afsalthaj

@adamgfraser I like that direction. To use my names, `MiddlewareSpec` cannot use `E` or `R`, and may only describe: 1. What the middleware requires from the request 2. What the...

Actually, `In` is already sufficient for Middleware by itself because it's invertible. So we can simplify to: ```scala final case class API[MiddlewareIn, MiddlewareOut, HandlerIn, HandlerOut]( middlewareIn: In[Query & Headers, MiddlewareIn],...

@guersam To accomodate this use case cleanly (i.e. without fiber ref), a middleware would have to be able to produce some value that can be consumed by the handler. I...

👍

It looks like middleware can fail and that these failures are not adequately handled by `++`.