by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 28 05:58
    julienrf commented #577
  • May 28 05:58

    julienrf on master

    Extend Info with description in… Add description to hashcode as … Merge pull request #577 from bm… (compare)

  • May 28 05:58
    julienrf closed #577
  • May 27 13:58
    bmeesters commented #577
  • May 27 13:54
    codecov[bot] commented #577
  • May 27 13:37
    bmeesters ready_for_review #577
  • May 27 13:37
    codecov[bot] commented #577
  • May 27 13:36
    bmeesters synchronize #577
  • May 27 13:08
    julienrf commented #577
  • May 27 13:05
    bmeesters commented #577
  • May 27 11:28
    codecov[bot] commented #577
  • May 27 11:10
    bmeesters opened #577
  • May 26 04:48
    julienrf commented #574
  • May 26 04:41

    julienrf on master

    More precise supertype to `Endp… Merge pull request #575 from ha… (compare)

  • May 26 04:41
    julienrf closed #575
  • May 26 02:57
    scala-steward opened #576
  • May 25 23:18
    codecov[bot] commented #575
  • May 25 23:00
    harpocrates opened #575
  • May 25 22:18
    mleclercq opened #574
  • May 22 21:15
    julienrf commented #571
Julien Richard-Foy
@julienrf
@jkobejs Awesome!
No algebra for websockets. I used to experiment with something (here) but took a different approach eventually, and never finished the websocket support
I’d be happy to include an algebra for WebSockets :)
Josip Grgurica
@jkobejs
It would be great to have it
I’ll experiment with your code and let you know if I find out something useful :)
Assets: I agree ;) I had designed this Assets algebra for a very specific purpose. It would require some changes to be easier to use
why do you think that it is hard to use it?
Julien Richard-Foy
@julienrf
It requires that all the assets have an associated digest
I implemented that to have infinitely cached assets for an audio application (where the audio samples could be a bit heavy)
megri
@megri

How can I "propagate" codecs/schemas into services? I have a database-service, where I read a JSON column and want to transform the data into the type the endpoint is expected to return.
The only way I've been able to work around this so far is to add a(n implicit) parameter to the service method, which becomes pretty ugly fast.

It seems one way around this would be to keep my endpoints implementation as an abstract class and the service layer as a trait, and then layer them together with the proper implementation (so more cake), but I'm curious if there's a better approach I'm not seeing.

OlegYch
@OlegYch
i do this by replacing endpoints.generic.JsonSchemas with magnolia based non-path-dependent thingy
this allows me to put codec/schemas instances in companions, and consequently maintain coherence, improve compile/idea performance, and improve derivation error messages
megri
@megri
Thank you, I'll have a look at that!
Julien Richard-Foy
@julienrf
@megri I’m not sure to fully understand your case. One thing you can also do is to apply a JSON codecs interpreter to your schemas:
trait MyJsonSchemas extends endpoints.algebra.JsonSchemas {
  implicit def dataTypeSchema: JsonSchema[DataType] = ...
}

object MyCodecs extends MyJsonSchemas with endpoints.circe.JsonSchemas

// And then
import MyCodecs._
val dataType: DataType = ...
dataType.asJson
@OlegYch I’d be interested to see how it looks like!
OlegYch
@OlegYch
OlegYch
@OlegYch
(we are not actually using ujson, but derive play-json instances alongside schema and use that)
Julien Richard-Foy
@julienrf
Interesting. Is there a difference between using shapeless-based derivation and Magnolia-based derivation, besides compilation times?
OlegYch
@OlegYch
better error messages
eg it says which field is missing an instance
Julien Richard-Foy
@julienrf
Awesome!
megri
@megri
@OlegYch I have a few questions regarding the magnolia derivation, if you have time :)
  1. Why is the "base deriver" using Openapi?
  2. It seems automatic derivation of "container" types like Option/List doesn't work. So if I have defined a MagnoliaSchema.Derived[MyType], it won't automatically derive Derived[List[MyType]] when requested like jsonResponse[List[MyType]]
Maybe it would be nice to have a separate module for magnolia made to work like endpoints.generic. At the moment, using both scala-refined, generic (shapeless) derivation and doobie-derivation of Meta and family, makes compile times pretty insane, even with bloop. I'm up to about 5 seconds for a simple query and auto completion breaks all the time in VS Code/metals.
OlegYch
@OlegYch
@megri 1. do you mean MagnoliaDeriver? 2. that was a conscious decision to force endpoints to use case classes, you can change MagnoliaSchema.Derived to MagnoliaSchema.Typeclass in JsonEndpoints if you don't want that
megri
@megri
@OlegYch For 1., the part I'm curious about is
object Openapi extends endpoints.openapi.JsonSchemas {
…
}

trait MagnoliaSchema[T] extends MagnoliaSchema.Input[T] {
…
}

object MagnoliaSchema extends MagnoliaDeriver {
  type Input[T]     = Openapi.JsonSchema[T]
  …
OlegYch
@OlegYch
Openapi part is just for making schema instances path-independent
so that you can move them to companions and reuse in 'services'
megri
@megri
Sorry, I'm not being clear. What I'm wondering about is why it's extending endpoints.openapi.JsonSchemas. It seems to me that this "couples" all derived schemas to openapi, but it may well be my ongoing confusion with the "cakiness" of Endpoints (the library)
I've been coding—enthusiastically—Scala for well over five years and I'm still dumbfounded by all varieties of abstraction :P
OlegYch
@OlegYch
yeah cakiness can be confusing
coupling to openapi/whatever else interpreter is inevitable if you don't go with it
i just think coherence and better incremental recompilation behaviour is a better tradeoff
megri
@megri
So basically what's done up there is coupling to the "lowest common denominator", ie having usable schemas that can also generate openapi documentation?
OlegYch
@OlegYch
that could work, but we also derive play codecs at the same time and use them in server interpreter
megri
@megri
You don't use the ujson-parts?
OlegYch
@OlegYch
no
megri
@megri
I see. Thanks for taking your time explaining this :)
OlegYch
@OlegYch
np
Dominic Egger
@GrafBlutwurst

I still have a bit of a hard time figuring out in what order and how to exactly mix the different traits and where to define endpoints. e.g. I now use all of these

endpoints.http4s.server.Endpoints[M]
endpoints.http4s.server.JsonEntitiesFromCodecs
endpoints.circe.JsonSchemas
endpoints.generic.JsonSchemas
endpoints.algebra.JsonEntitiesFromSchemas

over a couple different files so the scala compiler isn't yelling at me. but i got to that point more by trial and error and it's now getting hard to get openapi into the mix. Does anyone have a good read on trait mixin for this type of composition?

Julien Richard-Foy
@julienrf
@GrafBlutwurst I was hoping that http://julienrf.github.io/endpoints/algebras/json-entities.html would clarify how to mix compatible things together, but maybe it’s not detailed enough?
Dominic Egger
@GrafBlutwurst
I'll have another read. maybe i was just going through it too quick
Josip Grgurica
@jkobejs

here is implementation of basic algebras for uzhttp lib
https://github.com/jkobejs/endpoints-uzhttp
can some take a look at it and see if something can be improved? :)

I think that it would be good to create Gitter8 template that will have everything setup so that we can easily create libs that will be inside endpoints org, something like https://github.com/alexandru/typelevel-library.g8

Rustam Sultanov
@RustamSultanov
Hi all, I try to introduce endpoints in my scala.js client, and I have some problem. for local development I need set base address of my server REST API like https://github.com/julienrf/endpoints/blob/408d50fb596abd8bf739fbbdd310dcf85f24e541/scalaj/client/src/main/scala/endpoints/scalaj/client/Urls.scala or sttp client, no matter. But in xhr client I doesnt find this (
Julien Richard-Foy
@julienrf
hello, this is a limitation of the current xhr client interpreter. We should clearly add a base URL as a setting. In the meantime, a workaround could be to override the request operation to prefix the URL produced by url.encode with your base URL.
Konstantin Alifanov
@Telpenair
@julienrf
Good day!
Can you please tell me more about overriding request operation?
What i find - that staticPathSegment function somehow make path value (that is baseUrl in fact as i considered).
But how it can be overriden? Or i find wrong way? Can you show some tricks with it? (tricks as it looks like for me).
Julien Richard-Foy
@julienrf
At the place where you apply your xhr.Endpoints interpreter, override the request method like this:
class ClientWithBaseUrl(baseUrl: String) extends MyEndpoints with xhr.future.Endpoints {
  override def request[A, B, C, AB, Out](
      method: Method,
      url: Url[A],
      entity: RequestEntity[B],
      docs: Documentation,
      headers: RequestHeaders[C]
  )(
      implicit tuplerAB: Tupler.Aux[A, B, AB],
      tuplerABC: Tupler.Aux[AB, C, Out]
  ): Request[Out] =
    new Request[Out] {
      def apply(abc: Out) = {
        val (ab, c) = tuplerABC.unapply(abc)
        val (a, b) = tuplerAB.unapply(ab)
        val xhr = makeXhr(method, baseUrl + url, a, headers, c)
        (xhr, Some(entity(b, xhr)))
      }
}
Rustam Sultanov
@RustamSultanov
@julienrf How it work? makeXhr is a private and requre Url[A], but String found. It is fail on compile
Julien Richard-Foy
@julienrf
@RustamSultanov you’re right, sorry you’ll have to inline the content of makeXhr to concatenate the baseUrl to the result of calling url.encode
(but we should really have this baseUrl setting in endpoints)
Konstantin Alifanov
@Telpenair
Thank you for help! It's works.