JS refactoring in preparation for client backend schism #6390
Conversation
| * This client is currently not production grade, but convenient for | ||
| * experimentation and exploration. |
There was a problem hiding this comment.
In theory, this could be a very good client (like the jdk-http-client) if someone put in the work to make it robust and expose the configuration options.
There was a problem hiding this comment.
Also FTR, I wouldn't be opposed to keeping this http4s private or just dumping it altogether. It's useful for testing, but dealing with JS APIs is fiddly and I don't want it to become a maintenance burden on the core team especially when the whole point of the schism is to reduce said burden.
I don't expect it to break (the underlying Node.js APIs are stable) but it might require additional work if/when the ClientRouteTestBattery gets more tests.
There was a problem hiding this comment.
Is it useful in a REPL? That's the other place that the Java 8 one comes in handy.
There was a problem hiding this comment.
No, because there is no Scala.js REPL. This is on scala-cli's radar but seems unlikely.
There was a problem hiding this comment.
It's always easier to make something public than take it away. If you have any doubts, I'd make it private.
| @@ -67,7 +67,6 @@ lazy val modules: List[CompositeProject] = List( | |||
| asyncHttpClient, | |||
| jettyClient, | |||
| okHttpClient, | |||
| nodeServerless, | |||
There was a problem hiding this comment.
The node-serverless module provided:
- Converters to/from the Node.js HTTP models. These have now moved to core.
- Helpers for exporting
HttpApps as JS "listener" functions, commonly used in serverless frameworks. These will find a better home in https://github.com/typelevel/feral.
I never published this module in 0.23 because I was skeptical of the API, but it was useful internally to implement the server scaffold on JS.
There was a problem hiding this comment.
The JavaScript ecosystem still bewilders me, but I don't see anything troublesome here. I trust @armanbilge to decide whether to keep that new client public or private.
| * This client is currently not production grade, but convenient for | ||
| * experimentation and exploration. |
There was a problem hiding this comment.
It's always easier to make something public than take it away. If you have any doubts, I'd make it private.
This is a necessary preliminary to publishing a client testkit #5320 which is a necessary preliminary to schisming the client backends.
Changes in this PR:
Move Node.js interop stuff into core module under
org.http4s.nodejspackage.Refactor the JS scaffold server to use that ☝️
Remove the unpublished node-serverless module.
Implement a
NodeJSClientanalog to theJavaNetClient: a dependency-free, non-production-grade client. This also provides us an independent way to test the scaffold server and Node.js interop. Previously these were tested implicitly while actually testing ember-client.js.Correctly implementing the
NodeJSClientwas annoyingly hard because of crappy Node.js APIs. So I'm glad we have ember on JS instead.