julienrf on master
Support Scala Native in algebra… Add Native projects to ci.yaml … Update Scala.js to 1.8.0 and 7 more (compare)
julienrf on master
Update scalajs-dom to 2.2.0 (compare)
julienrf on master
Update sbt-sonatype to 3.9.13 (compare)
BuiltInErrors
for a possible extension of the algebra and noticed that while the algebra is content type independent, the various interpreters always implement its methods with the application/json
content type. My thought then was: wouldn't it be better to use jsonResponse
from JsonEntities
for this to prevent repeating this pattern? It occurred to me that the reason might be because you then had to mix in JsonEntities
in BuiltInErrors
and the latter is used in all the Endpoints
interpreters it would enforce a possibly unwanted dependency on the user. Is that correct or is there some other reason?
/api/v1/users/
to /api/v1/users
) or vice-versa. This is often done with APIs to make the endpoints more discoverable (not fail on a single slash). Both use cases can be implemented in pure server code of course, but I think it would be cool to use the clean interface of endpoints4s for this if possible. What do you think?
handleClientErrors
only gets an instance of Invalid
?
handleClientErrors
to receive more information about the underlying request
The way i did that right now is by having an intermediate trait with
protected def authenticatedRequest[UrlP, BodyP, Out](
method: Method,
url: Url[UrlP],
entity: RequestEntity[BodyP]
)(implicit
tuplerUB: Tupler.Aux[UrlP, BodyP, Out]
): Request[ApiEndpoints.AuthenticatedMessage[Out]]
and that works fine for requests. but one of the issues of response logging is that the process of encoding a response is not effectful
implementedByEffect
works to accomodate this
authenticatedEndpoint[A, B]: Endpoint[A, Either[AuthError], B]
, endpointWithError[A, B]: Endpoint[A, Either[ClientError, B]]
and versionedEndpoint[A, B](version: ApiVersion): Endpoint[A, B]
. Because the Endpoint type is abstract, I cannot find a way to compose these like (pseudo-code): authenticateEndpoint(endpointWithError(versionedEndpoint(...)))
.Endpoints(request: A, response: B, url: String,...)
and then "rewrite" these in the interpreters to the corresponding instances (e.g. Route
for Akka HTTP server or A => Future[B]
for client). But I have a feeling this would involve a pretty fundamental change to the algebras so I'm certainly open to other ideas.
def uri
in the Akka HTTP interpreter? It doesn't seem to be used in any code, except via-via in a single line in one test. Could it be possible that the function is not needed? https://github.com/endpoints4s/endpoints4s/blob/master/akka-http/server/src/main/scala/endpoints4s/akkahttp/server/Endpoints.scala#L50
ChunkedEntities
is not supported by endpoints.xhr
. I don’t remember why I didn’t include it, to be honest. I also remember that I created #287 when I was working on it, so maybe I faced some limitations when trying to implement ChunkedEntities
in the xhr interpreter.
grpc-web
should eventually support this, but there is no clear timeline for client-side streaming support, and protobuf
model does seem unnecessarily limiting for traditional web API, compared to JSON. It would be an interesting endeavor to implement endpoints4s/endpoints4s#287, maybe I could give it a shot.