HTTP/2 Multiplexing about tink_http HOT 13 CLOSED

Not sure it is practical to make this a part of tink_http. There are many cases of HTTP containers that work purely on a request/response model, e.g. PHP, AWS Lambda, Java Servlets. The focus of tink_http is to provide a consistent API for HTTP, so that applications (and frameworks like tink_web) written on top of it are highly portable.

from tink_http.

Hm. That's definitely something I hadn't really considered. I'll revisit this when it's more relevant but I just feel like tink_web and tink_http are already very close to being able to support this. You can already stream the request while writing the response AFAIK (which I guess is half of half way there)

I'll close this for now as I give it more thought.

from tink_http.

@back2dos hey, I've been looking into this more.

I'm pretty sure this can already be implemented as is with tink_http, would just have to create some special Stream type I guess, sort of like these Go examples

Also, Google closure-library and grpc-web in Haxe will probably need to happen and also subsequently be adapted to tink_http (client-side, though it's already possible both client and server side I'm pretty sure, the client just needs to stream the body.. from what I can tell it buffers it in JsClient); shouldn't be a problem since they're just ReadableStreams/WritableStreams (for example, it has goog.net.streams.XhrNodeReadableStream), which tink_io wraps.

The result of all of that will probably be something like GRPC client (which will be similar to existing JsClient but.. using Google closure externs, whenever I get around to writing those and tinkifying them) and some tink_web macros or something server side (I guess do special stuff if return type/input parameters are aforementioned Stream type)

I plan to try out bidirectional streaming with tink_http/tink_web in a bit.

I'm pretty sure I'll eventually work my way through all these things. When I do, I will show you how I incorporate tink I guess and you guys can decide if it fits in with tink_http

ETA: oh, oversimplifying a little. Obviously probably have to write a hxproto3 (runtime/reflection version) and probably tink_proto3 (macro version; tink_web compat) or something still. But still, I can at least get multiplexing client in via google-closure before that.

ETA: also, probably still do tink_schema to fit generating protobuf, OpenAPI, JSON Schema, etc... Eventually, to produce schemas from Haxe. But this would come with tink_proto3.. I would want it to handle generating tink_web routers from schema's as well as the reverse, all via macros

from tink_http.

Is http2 supported in browser js?

from tink_http.

Is http2 supported in browser js?

Yes via Google closure-library

from tink_http.

Link

(It's where the goog namespace comes from)

from tink_http.

@back2dos also to your point I don't know if it will work for any container other than node and local container; I actually intend to use this surprisingly via local container, in a node container (SaaS stuff), but I also don't see why it can't work (in node and local). It is technically still request-esponse model, just the request and response may be streams.

from tink_http.

Yes via Google closure-library

any examples?

from tink_http.

Yes via Google closure-library

any examples?

Here's the XhrStreamReader should be browser compatible.

Unsupported browsers

EDIT: sorry here is the XhrNodeReadableStream

from tink_http.

https://stackoverflow.com/a/32592978/3212365

I am sad that they don't bother take the chance to rename the awkwardly named API: XML?HttpRequest
But even worse is that they try to squeeze new APIs into the class... (use onprogress to get pushed resources?!)

from tink_http.

https://stackoverflow.com/a/32592978/3212365

I am sad that they don't bother take the chance to rename the awkwardly named API: XML?HttpRequest
But even worse is that they try to squeeze new APIs into the class... (use onprogress to get pushed resources?!)

;) That's the JS way. Backwards compatibility trumps all else. Also why JS is such a weird language today

But that's also why I am falling in love with closure-library.

Seems they abstract away most of the weird stuff (and they even write wrappers for the bleeding edge APIs which is nice).

haxe externs for google-closure would be a great birthday gift for me next year.

But Haxe Tinkerbell wrappers for the Google closure library would complete my existence (until the next shiny new server side tech makes it past Draft stage lol)

from tink_http.

@back2dos @kevinresol circling back on this with additional thoughts:

So http2.connect = http request on node (both establish an HTTP cnx), and then http2.connect returns Http2Stream and you can do stream.request (multiple requests on single stream).

This would mean when creating a client, you should establish a connection to the URL authority (so that the resultant stream lasts the lifetime of the client).

As such, it would make sense for HTTP2 clients to be disposable (you need to close that stream when done)

Not sure what would be the best approach to this, I'd like it to just be a tink.core.Disposable but for HTTP/1 clients it's just a noop (harmless I guess) on dispose.

ETA: This only applies to sys clients, as browsers handle the connection.

from tink_http.

Example gRPC echo service in tink_web (using some ugly extern libs I wrote for fetch and node http2)

EDIT: well, "grpc", browsers don't support binary fetch streaming yet, so it's textual (and also not compressible I don't believe)

from tink_http.