Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 30 23:37
    codecov[bot] commented #967
  • Nov 30 23:21
    scala-steward opened #967
  • Nov 30 19:41
    codecov[bot] commented #966
  • Nov 30 19:28
    scala-steward opened #966
  • Nov 29 20:58
    codecov[bot] commented #965
  • Nov 29 20:41
    scala-steward opened #965
  • Nov 29 14:35
    julienrf commented #889
  • Nov 29 14:32
    harpocrates commented #889
  • Nov 28 18:40
    ptrdom commented #964
  • Nov 28 18:28
    ptrdom opened #964
  • Nov 28 11:52
    julienrf closed #958
  • Nov 28 11:48

    julienrf on master

    Scala.js client interpreter bas… (compare)

  • Nov 28 11:48
    julienrf closed #934
  • Nov 28 11:48
    julienrf closed #287
  • Nov 28 11:45
    codecov[bot] commented #934
  • Nov 28 11:34
    codecov[bot] commented #934
  • Nov 28 11:34
    ptrdom synchronize #934
  • Nov 28 10:59
    ptrdom review_requested #934
  • Nov 28 09:31
    codecov[bot] commented #934
  • Nov 28 09:19
    codecov[bot] commented #934
Julien Richard-Foy
@julienrf
@ptrdom That would be a great contribution, although it might require some significant work! By the way, I’ve just found this old attempt at implementing an xhr interpreter for streaming: https://github.com/endpoints4s/endpoints4s/compare/streaming-support#diff-fe8014ca568bf3fc852541330ae13649cf8d4e298abea4ce777f73ddeabd33e2.
I don’t fully remember if eventually I didn’t include it in my final work on streaming because it was not working, or because I didn’t have the resources to finalize the implementations
See also the PR that introduced streaming support, where I give some implementation details: endpoints4s/endpoints4s#465
Domantas Petrauskas
@ptrdom
@julienrf Neat, I can also see that you attempted implementing WebSocket endpoints. I'll check these references out before I start, hoping this will result in an actual contribution.
Rohan Sircar
@rohan-sircar
does the http4s server interpreter also not supprt ChunkedEntities/ChunkedJsonEntities?
Simon Parten
@Quafadas
Is endpoints4s compatible with https://github.com/com-lihaoyi/cask ?
Simon Parten
@Quafadas
Conclusion: no. I'm going to assume adding it is also a non trivial task!
Mark de Jong
@Fristi
Hiya, I added sttp3 support in a PR
Coverage dropped by 0,07% :roller_coaster:
Build failed due that reason :see_no_evil:
Julien Richard-Foy
@julienrf
Hello! I’ve just released endpoints4s 1.4.0 with your latest contributions! https://github.com/endpoints4s/endpoints4s/releases/tag/v1.4.0
Dominic Egger
@GrafBlutwurst
Thanks for the release Julien!
Adriaan Groenenboom
@agboom
Great news, thanks for the release and all the effort!
Milos Nedeljkovic
@minedeljkovic

It seems that format is not generated for parameters in openapi docs , but it is for request and response body content.
For example, this definition

  val foo: Endpoint[(Long, Long, Long), Long] =
    endpoint(
      request = put(
        path / "foo" / segment[Long]("id") /? qs[Long]("long"),
        jsonRequest[Long]
      ),
      response = ok(jsonResponse[Long])
    )

generates parameters without format

  "parameters": [
    {
      "name": "id",
      "in": "path",
      "schema": {
        "type": "integer"
      },
      "required": true
    },
    {
      "name": "long",
      "in": "query",
      "schema": {
        "type": "integer"
      },
      "required": true
    }
  ],

but request and response body content with format

  "content": {
    "application/json": {
      "schema": {
        "type": "integer",
        "format": "int64"
      }
    }
  }

Is this intended?

Julien Richard-Foy
@julienrf
Good catch @minedeljkovic, this is an issue that should be fixed, IMHO. Do you mind filing an issue description in the repository?
Milos Nedeljkovic
@minedeljkovic
Milos Nedeljkovic
@minedeljkovic

Encoding of heterogenous arrays (tuples) in OpenApi docs seems against OpenApi spec.
Example, this definition

  val foo: Endpoint[Unit, (String, Long)] =
    endpoint(
      request = get(path / "foo"),
      response = ok(jsonResponse[(String, Long)])
    )

produces this OpenApi definition for response content (items is an array of SchemaObject)

"content": {
  "application/json": {
    "schema": {
      "type": "array",
      "items": [
        {
          "type": "string"
        },
        {
          "type": "integer",
          "format": "int64"
        }
      ]
    }
  }
}

but, OpenApi spec is explicitly against that. In this part, it's stated:

items - Value MUST be an object and not an array. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. items MUST be present if the type is array.

Now, OpenApi 3.0 does not have a proper encoding for heterogenous arrays, unfortunately, afaik.
But the question is, is producing definition against the spec the right choice, or it might be better to produce (not perfectly precise) approximation that conforms spec?

Julien Richard-Foy
@julienrf
@minedeljkovic I used this source to model the schema of tuples: https://json-schema.org/understanding-json-schema/reference/array.html#tuple-validation but now I learn about prefixItems. Unfortunately, OpenAPI 3.0 does not support them, as you noticed, so yes, I agree that it is better to produce something else, that conforms to the spec.
Milos Nedeljkovic
@minedeljkovic
Dominic Egger
@GrafBlutwurst
Good day everyone, I was wondering if I'm right in the assumption that chunked encoding for files is not yet a thing on http4s-server?
Julien Richard-Foy
@julienrf
Hi @GrafBlutwurst, indeed we didn’t implement it yet. See endpoints4s/endpoints4s#510 We had one issue with the strategy used by the other interpreters
If we fix that issue, we need to update all the other interpreters to be consistent
Would you be interested in contributing to this effort?
Dominic Egger
@GrafBlutwurst
ahhh I looked into the issues but not the PRs, sorry about that.
Yeah I might have a crack at it, gotta check with my co-workers. But imo it would be the best solution for what we need.
Dominic Egger
@GrafBlutwurst
so i merged lucas' branch to mine and got the tests passing, but I must be understanding something wrong with chunking. What does it mean that implementedByEffecttakes a parameter of Stream[IO, Req] => IO[Resp]?
server tests that is
Julien Richard-Foy
@julienrf
It’s for the case of the request entity is streamed, but not the response
Dominic Egger
@GrafBlutwurst
right so it can be assumed that by the time the stream hits implementedByEffect it has been reassembled and the stream only ever contains one element?
Julien Richard-Foy
@julienrf
Yes, that’s the problem we have with the current way of framing chunks
Dominic Egger
@GrafBlutwurst
right, now I understand the conversation much better.
Dominic Egger
@GrafBlutwurst
but that issue is not specific to the http4s implementation is it? it seems to be the same in akka where we get Source[Req, _]
Julien Richard-Foy
@julienrf
Yes
Well, we do the same assumptions on all the interpreters
It turns out that the akka-http interpreters work well with this assumption (chunks are not reframed)
same for play-server
Dominic Egger
@GrafBlutwurst
you wouldn't happen to have a log/dump of the particular errors you encountered due to reframing anywhere?
Julien Richard-Foy
@julienrf
No :( it seems that Travis CI does not have the logs of the tests either
but if you managed to get the tests pass, then it means that it works, no?
Dominic Egger
@GrafBlutwurst

weeeell. the server ones are but there's an exception that doesn't fail the test somehow. client tests are not passing. I just got them compiling. I suspect this bit from http4s docs might be pertinent though:

Next, we want streaming JSON. Because http4s is streaming in its bones, it relies on jawn for streaming JSON support. Most popular JSON libraries, including Circe, provide jawn support, as the code below shows. What’s left is to integrate jawn’s streaming parsing with fs2’s Stream. That’s done by jawn-fs2, which http4s’ Circe module depends on transitively.

I think you hit the nail on the head with what you wrote in the PR
I don't see a way to address this without baking in circe or at least jawn-fs2 into the http4s-client
Julien Richard-Foy
@julienrf
Ah, if that’s a problem we can create separate modules (e.g., http4s-streaming-server)
but I guess there is a high chance that most of the users of http4s also use the http4s-circe module?
Dominic Egger
@GrafBlutwurst
I would suspect most. I'll do some more tinkering to confirm if that's the issue
Dominic Egger
@GrafBlutwurst
hahaha I think we lazified ourselfs to death because we have an F[Stream[F,Resp]] within a Resource.use i just wrote some truly heretical code, but all tests are green. maybe someone smarter than I knows how to do this properly
Dominic Egger
@GrafBlutwurst
https://github.com/rivero-ag/endpoints4s/blob/http4s-chunked-encoding/http4s/client/src/main/scala/endpoints4s/http4s/client/ChunkedEntities.scala#L55 this is some truly cursed code but makes the tests green. If somebody has some good input on how to address this, I'd be very glad. I'm out for the day though
Dominic Egger
@GrafBlutwurst
PR is up to be looked at. It has a couple open points that I don't know how to tackle so I'd be extremely happy for some help
Julien Richard-Foy
@julienrf
@GrafBlutwurst great, I will have a look ASAP, thanks!