Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 07 21:11
    scala-steward opened #427
  • Dec 07 16:08
    julienrf closed #75
  • Dec 07 16:08
    julienrf commented #75
  • Dec 07 12:26
    julienrf closed #43
  • Dec 07 12:26
    julienrf commented #43
  • Dec 07 09:56
    codecov[bot] commented #426
  • Dec 07 09:36
    julienrf closed #20
  • Dec 07 09:36
    scala-steward opened #426
  • Dec 07 09:33

    julienrf on ujson-bias

    (compare)

  • Dec 07 09:33

    julienrf on master

    Provide JSON codecs in client a… Reuse `JsonEntitiesFromCodec` t… Consistently use plural for alg… and 3 more (compare)

  • Dec 07 09:33
    julienrf closed #420
  • Dec 07 09:33
    julienrf closed #399
  • Dec 07 09:30
    codecov[bot] commented #420
  • Dec 07 09:11
    julienrf edited #420
  • Dec 07 09:11

    julienrf on master

    Implement uuidJsonSchema in `al… Make some methods final Implement decoders in `ujson.Js… and 1 more (compare)

  • Dec 07 09:11
    julienrf closed #419
  • Dec 07 09:09
    codecov[bot] commented #419
  • Dec 07 09:07
    codecov[bot] commented #420
  • Dec 07 09:07
    julienrf synchronize #420
  • Dec 07 09:07

    julienrf on ujson-bias

    Provide JSON codecs in client a… Reuse `JsonEntitiesFromCodec` t… Consistently use plural for alg… and 2 more (compare)

Julien Richard-Foy
@julienrf
@plokhotnyuk Indeed, jsoniter-scala looks great! Sorry for not having mentioned it. We won’t be able to use the auto-derived codecs, though, because we need to derive schemas. Are there still benefits over jawn?
So, we would use the parser, decoders and encoders.
bmeesters
@bmeesters

Hello all, I just started using endpoints and am hitting a bit of a hiccup so I hope someone here can help me. I am using a setup similar to the Use Cases page from the documentation. However, I want to use the play-json support. This seems to clash since the openapi json and play json are (obviously) not the same type:

Error:(27, 7) trait ApiEndpoints inherits conflicting members:
  type JsonRequest in trait JsonSchemaEntities, which equals [A]ApiEndpoints.this.JsonSchema[A]  and
  type JsonRequest in trait JsonEntitiesFromCodec, which equals [A]endpoints.algebra.Codec[String,A]
(Note: this can be resolved by declaring an override in trait ApiEndpoints.);
 other members with override errors are: JsonResponse
trait ApiEndpoints

Have you seen this before and any pointers on how I can fix this? I cannot drop play-json easily because our domain is pretty huge and we have pretty strict constraints on how the JSON should actually look, so auto-derivation is not possible.

Georgi Krastev
@joroKr21
Are you mixing both openapi and play json at the same time?
You should stay abstract as long as possible and in the end create two/three objects, one for openapi and one for your server/client
bmeesters
@bmeesters
I am trying to use them at the same time, since I need to use the JSON as created by play json in the documentation. We don't control the exact JSON (based on an open standard), we only control the code structures that represent that JSON.
Maybe I am on the wrong path, but some pointers would be nice. I would like to make use of the automatic OpenAPI functionality from Endpoints, and I would like to have control on how the JSON exactly looks like.
Georgi Krastev
@joroKr21
The JSON representation and the OpenAPI schema are inherently linked
You can control how they look like but you would have to use the methods provided by the library to define the encoders / decoders
It doesn't really make sense to derive schemas automatically but codecs manually because then you risk mismatch
bmeesters
@bmeesters
Right, that is what I figured.
But can I use the manually created codecs in combination with OpenAPI, or is that not possible?
Georgi Krastev
@joroKr21
I don't think it was intended to mix them together in a trait
You might be able to define your own interpreter which would be a tuple (OpenAPI, PlayJson)
But I don't know how much work that would be and why you would want to do that
You could also define object MyOpenApiEndpoints and object MyPlayEndpoints and then use them concretely together
I'm not sure in what way you want to combine them
bmeesters
@bmeesters
Well to be honest I was just trying stuff out. I generally don't really like to write swagger docs by hand, so it would be nice to generate those based on the code. However I didn't realize that they both rely on different JSON formatting.
So I guess the only alternative is to change the code structure so that the formatting stays the same without relying on play-json.
Anyway, thanks for the quick replies, much appreciated!
Georgi Krastev
@joroKr21
Do you mean the formatting of the OpenAPI specification itself?
I think there was an issue about that
Not quite what I thought it was but looks like there is a lot of activity in this area
bmeesters
@bmeesters
Alrights, thank again for the pointer :)
Julien Richard-Foy
@julienrf
Hello @bmeesters to be able to produce the OpenAPI documentation for your JSON entities, you will have to translate your existing Format instances into JsonSchema instances.
Then you will be able to derive the Format instances from the JsonSchema (so that your server will be able to decode and encode JSON entities using play-json)
The solution suggested in the discussion of #399 should simplify the way we will produce the OpenAPI JSON document for a set of endpoints, and will probably remove the confusing situation you are in (with error messages such as “conflicting members”)
It should not be too hard to manually define JSON schemas. You can see the documentation here: http://julienrf.github.io/endpoints/algebras/json-schemas.html
Julien Richard-Foy
@julienrf

Essentially, a Play Format like the following:

implicit val fooFormat: Format[Foo] = (
  (__ \ "x").format[Int] ~
  (__ \ "s").format[String]
)(Foo.tupled _)(foo => (foo.x, foo.s))

Can be translated to a JsonSchema like so:

implicit val fooSchema: JsonSchema[Foo] = (
  field[Int]("x") zip
  field[String]("s")
).xmap(Foo.tupled _)(foo => (foo.x, foo.s))
Let me know if you have special cases that can’t be easily translated.
bmeesters
@bmeesters
Hello @julienrf . I'll try to rewrite the Formats to JsonSchemas. We have some custom code on top of play-json to deal with sum types, but I'll check if I can reuse that for JsonSchemas as well (if it is really necessary at all). Thanks for the quick reply and providing me with this extra information. Looking forward to reap the benefits of Endpoints :)
Julien Richard-Foy
@julienrf
OK. Our support of sum types might be too limited. Let me know if you are stuck.
Georgi Krastev
@joroKr21
If you have custom ways of handling sum types you might find that OpenAPI is not flexible enough to describe them :disappointed:
It requires a discriminator field for sum types
Julien Richard-Foy
@julienrf
Hey @/all I’ve just released endpoints 0.12.0: https://github.com/julienrf/endpoints/releases/tag/v0.12.0
Georgi Krastev
@joroKr21
Nice :+1:
bmeesters
@bmeesters
Cool! The way EndpointDocs work is a nice improvement
Funnily enough I also implemented a .named on records. It did show how easy it was to extend an algebra without changing the original source code
Binh Nguyen
@ngbinh
Hi, is there a way to mix circe.JsonSchemas and openapi.JsonSchemas in an endpoint? I am seeing The members with defaults are defined in trait JsonSchemas in package circe and trait JsonSchemas in package openapi. compile error when doing so.
Julien Richard-Foy
@julienrf
you cannot mix both
the will provide conflicting implementations
can you elaborate on your need?
bmeesters
@bmeesters
I have been working with Endpoints over the last week to introduce it in our services. It had a bit of a learning curve, but it is well worth the effort. I have rarely encountered a library that was this extensible by design. I want to give a shout out to all the contributors. Well done, and keep up the good work!
Julien Richard-Foy
@julienrf
Thank @bmeesters ! I’m sorry for the “learning curve” part… I believe we need more docs. Don’t hesitate to share with us your pain points!
bmeesters
@bmeesters
I don't think the learning curve is really a problem. When I started using Akka Actors, or the IO monad there also was a learning curve. Unavoidable if you start to work with something different. Object Algebras were new for me, and even though the simple examples quickly clicked, it took a while to see it used with real world production code.
More docs always help, I found the slides you made also pretty useful. Maybe those can be distilled and put on the website?
Maybe an FAQ can help? It seems @ngbinh and me both encountered the same problem. That if you want OpenAPI you need to rewrite your json formatters to use JsonSchema instead. Which is logical once you think about it, but might not be obvious if you are new to Endpoints.
I'll be using it more in the coming weeks, so I'll try to keep track of everything that might help others as well
Julien Richard-Foy
@julienrf
I see, thanks for the feedback!