Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clients should remain Scala.js compatible #21

Closed
juanpedromoreno opened this issue Jul 3, 2017 · 7 comments
Closed

Clients should remain Scala.js compatible #21

juanpedromoreno opened this issue Jul 3, 2017 · 7 comments

Comments

@juanpedromoreno
Copy link
Member

We should split the rpc core in order to make the client part compatible with Scala.js.

@juanpedromoreno
Copy link
Member Author

Interesting findings by @calvellido :)

frees-io/freestyle-opscenter-webclient#17

@L-Lavigne
Copy link
Contributor

@juanpedromoreno could you clarify how this issue relates to #73? Thanks!

@juanpedromoreno
Copy link
Member Author

As we will be deriving HTTP services with its auto-derived clients, those will be Scala.js compatible, so likely this issue could be closed once we get the HTTP features.

@L-Lavigne L-Lavigne added http and removed help wanted Extra attention is needed labels May 24, 2018
@SemanticBeeng
Copy link

SemanticBeeng commented Apr 9, 2019

@juanpedromoreno, @raulraja is it correct to understand this task is about

  1. generating client code that compiles to scalajs
  2. not necessarily generating full client stubs for both avro and protobuf
  3. clearly not about providing the actual runtime for execution of the stubs (for example ScalaPB has the only scalajs GRPC runtime I know)

Please advise in these respects and also what it is necessary to bridge the gap to become able to actually call mu services from web clients compiled with scalajs over https, using either / both avro and protobuf.

Trying to confirm that mu only focuses on providing the "server side" (runtime, generated stubs, etc) and not trying to also provide the clients.

@rafaparadela
Copy link
Member

rafaparadela commented Apr 22, 2019

@SemanticBeeng Thanks for bringing all these questions up.
Under the context of all the issues labeled as http we are implementing the auto derivation of HTTP server and HTTP client for a given schema/protocol.
What this issue proposes is, due to the http4s clients are compatible with scalajs, the derivation of the this part should be in a diferent sbt module, and thus, those projects that are acting as Mu clients only need to add mu-http-client as a dependency, whose artifact must be compatible to scalajs.

Side note: We are not using ScalaPB to convert the idl into the http clients.

I hope this answers your questions.

@SemanticBeeng
Copy link

http4s clients are compatible with scalajs

Thank you for following up.
So #593 is "done" in this sense, then?

@juanpedromoreno
Copy link
Member Author

Dup of #593

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants