DEV Community: Thanapon Jindapitak

Why gRPC is not natively supported by Browsers

Thanapon Jindapitak — Sun, 17 Dec 2023 20:09:44 +0000

Hi there,

Hope that this blog will give everyone some idea of why gRPC is not natively supported by the Browsers.

Many mentioned "because of Browser limitation".
But they don't explain why.

Even in the https://grpc.io blog says this

It is currently impossible to implement the HTTP/2 gRPC spec3 in the browser, as there is simply no browser API with enough fine-grained control over the requests. For example: there is no way to force the use of HTTP/2, and even if there was, raw HTTP/2 frames are inaccessible in browsers

https://grpc.io/blog/state-of-grpc-web/#the-grpc-web-spec

No one give explanations about why we cannot make Browser expose HTTP/2 frames

...

TL;DR

There are 2 main reasons:

There is no way to force HTTP/2 on browser
=> Because we need a server to support HTTP/2 too! and most of the server now in the internet only support HTTP/1.1
Even we can force HTTP/2 on browser, raw HTTP/2 frames are inaccessible in browsers
=> Browser nowadays supports HTTP/2, but it hides the communication part behind the scene. So it exposes only some small API to HTTP/2.
gRPC uses HTTP/2, but not a trivial HTTP/2, it leverage a header frame to end the gRPC session (called 'Trailer' header frame).
And this 'Trailer' header frame has to be accessible by JS, to determine the end of gRPC session along with grpc-status.
But the Chromium team decided to 'WontFix' due to "the cost of this feature" is not worth it !!

Believe it or not.

I've attached the decision made by Chromium team member here

As I explained previously, the time cost is not a single-cost, but an ongoing resource cost that will be perpetually paid, as every feature will need to consider the interactions with and implications of trailers. Writing the code is, unquestionably, the easy part - reviewing it for correctness, maintaining it for cross-browser interoperability, interacting with the rest of the networking and loading stack are significant and non-trivial costs. As we explained on the issue as well ( https://github.com/whatwg/fetch/issues/34 )
That also discusses security risks. From a product perspective, only supporting it for non-semantic expression is equally not a desirable nor interoperable outcome.
I appreciate your interest, but I think the decision to WontFix is based on a holistic evaluation of the cost of this feature, and leaving it Available for over a year is not a good representation that this has been reviewed, triaged, and actively rejected as something we want to support.

See
bugs.chromium.org/p/chromium/issues/detail?id=691599

Very well, let's try to understand their perspective a bit. We have to get some knowledge about gRPC over HTTP/2.

Here is briefly how gRPC over HTTP/2 works

Let's go

HTTP/2 is an upgraded version of HTTP/1.1

I'll cover only 2 gRPC related parts of HTTP/2

Instead of sending HEADER and DATA in the same packet as HTTP/1.1. HTTP/2 introduces concept of Frames--Header frame and DATA frame. Each frames will be sent on different packet
The connection for HTTP/2 is now support multiplexing, e.g. Client can use the same connection to send data to server, server can send data to client at the same time

There are a lot more in HTTP/2 (I recommend to read more on this blog https://ably.com/topic/http2)

That's HTTP/2

Now, gRPC.

ref: https://www.oreilly.com/library/view/grpc-up-and/9781492058328/ch04.html#simple_rpc_message_flow

For a simple RPC call to remote server (Unary RPC, client sends single request to server and server sends single response to client),
Request message will split into 3 frames:

HEADER frame (to start the gRPC channel)
DATA frame (your function parameters, can be in protobuf format)
another DATA frame (to tell the server that client is done sending)

Let's look into a bit at the actual data

HEADER frame (to start the gRPC channel)

HEADERS (flags = END_HEADERS)
:method = POST
:scheme = http
:path = /Service/method
:authority = example.com
te = trailers
grpc-timeout = 1S
content-type = application/grpc
grpc-encoding = gzip

DATA frame (your function parameters, can be in protobuf format)

DATA
010101010111010110 // hahaha it is encoded, how would I be able to read it, but you get it right?, it's just a bunch of alien bytes

DATA frame (to tell the server that client is done sending)

DATA (flags = END_STREAM)

Ok now the communicate is at a state called half-closed specifies the HTTP/2 spec

That state thingy have nothing to do to this blog at all, I just want to show off my knowledge a bit. Haha sorry let's continue.

Then the server starts to process client request. Call the method, get the response.

To response to client, server sends 3 frames (3 frame just to demonstrate a simple gRPC call) back to client:

HEADER frame (to tell client that server now want to send response to client)
DATA frame (to return what ever server wants to return)
HEADER frame (to close the gRPC channel), please pay attention to this, server uses HEADER frame to end the gRPC session, NOT DATA frame as when Client want to end the request sending frame. AND this last HEADER frame they called it Trailers in HTTP/2

Again, let's see the actual data

HEADER frame (to tell client that server now want to send response to client)

HEADERS (flags = END_HEADERS)
:status = 200
grpc-encoding = gzip
content-type = application/grpc

DATA frame (to return what ever server wants to return)

DATA
1000011011100011010 // again it's encoded

HEADER frame (to close the gRPC channel) aka 'Trailers'

HEADERS (flags = END_STREAM, END_HEADERS)
grpc-status = 0  // 0 means OK for gRPC
grpc-message = xxxxxx

That's all, when client receives this last frame (Trailers) it can read this grpc-status to understand the status of the gRPC call.

And JS want to read this Trailers frame but Trailers frame is not accessible in Browser since browser was implemented, even until now.

The problem is, why don't they implement it, right?

I ask the same question, everyone ask the same question, but the answer to that is "the cost of this feature" is not worth it!!

Now they try to introduce another protocol called 'grpc-web' to not always relies on HTTP/2.

YES I'M NOT MAD AT ALL

If you want to see it yourself, please read it here (don't miss last comment): bugs.chromium.org/p/chromium/issues/detail?id=691599

Bye

Server-Sent Events Explained

Thanapon Jindapitak — Sat, 05 Aug 2023 18:48:15 +0000

Hi there, it's been a while 👨🏼‍🦳

In the era of Internet, people mostly are connected through Web technology, and even though we are talking about gigabit network nowadays, there are still some people who is obsessed about network utilization--make it faster, don't waste any of bytes! and they come up with different ideas to improve the protocol or even try to hack the existing protocol.

I can give you an example, in the history of HTTP protocol, HTTP/1.0 has been introduced in 1996 but then suddenly next year, they introduced HTTP/1.1 this is still okay because HTTP/1.0 is really not usable--there are lot of limitation such Head-of-Line blocking (HOL blocking, see https://engineering.cred.club/head-of-line-hol-blocking-in-http-1-and-http-2-50b24e9e3372).

OK, HTTP/1.1 is now a standard protocol (standardizing a protocol, it's a document published by Internet Engineering Task Force (IETF), you may heard of RFC-XXXX, HTTP/1.1 was standardized in RFC 2068) until year 2015, again, Google introduced another one called SPDY but got renamed to HTTP/2. It improves on many different areas and also bring many features such as keep-alive, server push.

As you can predict. Google (again) are still not satisfied with just HTTP/2, they introduced yet another improved version--named QUIC which then got renamed to HTTP/3 in year 2022!. Earlier version they are using TCP, but now they go deeper in layer 4 (OSI Layer 4, Transport). They changed from TCP to UDP based on the idea that we are ok to lose some packet, how crazy! 🤯

We are all been told that TCP is reliable and UDP is unreliable, but how comes QUIC or HTTP/3 can use UDP?

Here is the reason, the general idea is QUIC uses sequence number (same idea as TCP) to track the segment (Segment is the Protocol data unit, PDU for Transport Layer) ... there is more to that I'll cover more detail in my next blog, but if you want to read more detail, see RFC 9000: https://datatracker.ietf.org/doc/html/rfc9000#section-13

...

Phew ~
Let's take a short break

...

Alright, let's go

...

There is no such perfect thing in the world, this applies to the world of technology as well, I'm 100% sure that there will be more versions of HTTP to come in the future.

But what we are discussing here ...
Just to see, understand and use the non-perfect protocol ?

The answer is Yes! ✅
There are pros/cons on every thing, but what we need is to understand tools/options we have on hands, try to understand why they implement it that way and understand when to use and when not to use. These reasoning is really useful when we have to analyze/estimate our solution in the future.

...

So much talking, sorry, like I said, it's been a while 😁

...

There is another interesting topic that people tries to "utilize" every single bytes possible, it is Server-Sent Events

TL;DR

Server-Sent Events is leveraging HTTP protocol, to keep the connection open until server decides to close it. It is one-direction communication (only server can send messages to client)

A bit of history about SSE (I rephrase the original from Wikipedia: https://en.wikipedia.org/wiki/Server-sent_events)

SSE was introduced in 2006 as part of HTML5 and during HTTP/1.1 day by Ian Hickson.

...

I'll cover 4 parts today

How SSE works
Example
Pros/Cons
Learn

Not wasting time, let's dive into part 1 (I already wasted too much time above 😅)

Here we go ... part 1 how SSE actually works
SSE is using HTTP protocol and HTTP rely on TCP to transfer the data. We have to understand that when it comes to TCP there are so many overhead because they will have to guarantee that the segment will be reliable, but in this blog I'll just mention only some part of TCP for the sake of simplicity.

Every start of a connection using TCP, client has to do 3 way handshake with server to exchange something called sequence number, both side will have it's own sequence number. This number will be used to tell the integrity of the data sent (I'll explain more detail in the next blog)

Here is how TCP's 3 way handshake works

After that we can say that the connection is OPEN.
And now client can send HTTP message to server via this connection.

Alright, now SSE
Because SSE is not our every day HTTP message, so, there should be a way for client to tell server that, "hey server this is a request for SSE, let's keep the connection open until I close it, and you can send me data via this open connection".

Ok here is how, after connection is open, client will send HTTP request GET / with header Accept: text/event-stream

When server receives the request, server understands that it has to upgrade this connection to SSE, that's it!

And when server wants to send data to client, it has to send with



Headers:
Content-Type: text/event-stream
Tranfer-Encoding: chunked

Body:
"data: <text>\n\n"

And I'm not joking here... server has to send data in this format data: <text>\n\n, or else, the protocol will not understands

I'll demonstrate as diagram, to make it more clear

Not only just data: there are more fields, if you are interested, please check this https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#fields

that is it! general idea of how SSE works, and I already covered part 1

...

Next is Part 2 Example

I have a server on NodeJs Express running on port 8080



import app from "express";

const server = app();

server.get("/", (req, res) => res.send("hello"));

server.get("/stream", (req, res) => {
  console.log("SSE Connected ....");

  res.setHeader("Content-Type", "text/event-stream");
  write(res, 0);
});

function write(res, i) {
  setTimeout(() => {
    res.write("data: " + i++ + "\n\n");
    write(res, i);
  }, 1000)
}

server.listen(8080);

console.log("Listening on 8080");

And I have multiple clients connects to it

My client is curl -H Accept:text/event-stream http://localhost:8080/stream

You can see clients connect to server using SSE then our server sends back i++ every 1 second

That's cool isn't it, and I just covered part 2, that was quick 😉

...

Part 3 Pros/Cons

Pros

during message pushing from server, no header ! (you just have to follow patter data: <text>\n\n)
HTTP/2 compatible
Firewall friendly, because it's http! not any fancy new protocol

Cons

Proxy could be hard
Layer 7 Load balancing could be hard
It is hard to scale (less than WebSocket)
Feature is limited, if the requirement changed, we might have to re-implement with WebSocket

...

Part 4 learn

I really like this part, because this part is purely from my deduction and reasoning skill on why Ian comes up with this idea, there will be a lot of discussion on it. And by understanding why it has been invented also try to make sense with it. It is super beneficial.

Because SSE comes after WebSocket, but still, Ian had pushed SSE to become a standard in HTML5 (see https://html.spec.whatwg.org/multipage/server-sent-events.html), so, I think we should compare SSE with WebSocket just to see, in what case we should use SSE over WebSocket. Because both SSE and WebSocket, server can send data to client without the need to client asking every single time.

WebSocket

Is a full-duplex which means, client and server can talk to each other simultaneously
The protocol starts with TCP 3 way handshake, then client sends GET / UPGRADE Http request, if server can support websocket, server will ack back, after that the communication talks in a different protocol, not HTTP anymore and it requires WebSocket headers
Client has to implement reconnection logic by themself, where SSE on the other hand, client is support by EventSource interface (supported 95% of the browsers, see https://developer.mozilla.org/en-US/docs/Web/API/EventSource)
Horizontal scaling is hard, because it is stateful

By knowing that, I think, Ian introduces this SSE because he wants to have an alternative way of server sending data to client (without client asking every single time), and he wants to make it compatible on existing Networking device, for example, router, firewall. And also it is faster! (than WebSocket) because WebSocket has it's own header but SSE does not! (I mean, only the data format data: <text>\n\n we have to follow)

That's it! I cannot think of any other reasons why Ian had invented this SSE. If you can think of other good reason, please let me know.

End of part 4

...

Next chapter let's deep dive into TCP
And WebSocket afterward

Cheers !

....

references

QUIC: https://http3-explained.haxx.se/en/quic-v2
Pitfalls of EventSource on HTTP/1.1: https://textslashplain.com/2019/12/04/the-pitfalls-of-eventsource-over-http-1-1/

What is business domain?

Thanapon Jindapitak — Wed, 30 Jun 2021 13:51:49 +0000

So I've read books about "Domain Driven Design" architecture,
most of the thoughts coming to my mind during reading process are where should I put these fraction of code to? And wonder that everyone is also having this problem.

Then, I concluded that you will put everything related to "Business logic" into "Domain layer"

Next question comes to my mind, "Are these fraction of code business logic ?"

FU.. it's a hard question, I even let my friends look at the code and ask them is it the "Business logic" or not, not to be surprised, their answers diverted and with different reasons at that.

Confused, really confused.

Then I found this "Vertical Slice Architecture" (ref. https://jimmybogard.com/vertical-slice-architecture/) invented by Jimmy Bogard, and went through some of his talks.

Finally, I got the idea that every thing is "Business logic", don't spend a lot of time arguing where should we put the code to, put it in plainly first then the important step is later "Refactor" it.

That's it !!

Better way of storing Per-Request data across middlewares in ASP.NET Core

Thanapon Jindapitak — Thu, 11 Jun 2020 14:39:02 +0000

Hi developers who loves to work from home like me, for those who doesn't enjoy working from home, please skip this post. warning!

As you can guess from title, this post is about "How to not use HttpContext.Items"

To be honest, I'm the one who is still using HttpContext.Items because why not, right?--It's static! easy to write.

But no, collectively, it gives me tremendous amount of issues.

First, it's static! forget about mocking it.
Second, it's static! forget about testing it.
Third, it allows me to modify any variables I want!, brilliant !!, why is that a bad thing? because I can't control them. I can perform any add/delete/modify operations to any objects.

aight, anyways, I will show you how to use HttpContext.Items first, I know it's boring, just bear with me once. coz I don't have many things to make my blog longer. haha.. oops.

aight, let's go
HttpContext.Current.Items is a Key-Value-Pair, key and value both are type object.
You can access anywhere in your middlewares.

to store

HttpContext.Current.Items["myobject"] = new MyObject();

to read

var myObject = (IMyObject)HttpContext.Current.Items["myobject"];

to modify

var myObject = (IMyObject)HttpContext.Current.Items["myobject"];
myObject.Hime = "Hime Hime~";

easy peasy!

now let's have a look into this code one bit

app.Use(next => async context =>
{
    context.Items["DogSays"] = "Henlo hooman";
    await next(context);

    sexyMailer.Post((string)context.Items["DogSays"]);
});

app.Use(next => async context =>
{
    context.Items["DogSays"] = "Kwakkkkk!";
    await next(context);
});

now you can imagine if you work with 1500+ developers, how troublesome to maintain your calm, when you're assigned to find who changes our dog to says "Kwakkkkk!".

enough playing with time.

I found 2 elegant ways

[1.] use IHttpContextAccessor this interface is to read HttpContext through DI, simply you can register it by
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
// this has to be registerd as singleton as per this announcement ref.
or in ASP.NET Core 2.1 or above, you can use extension method services.AddHttpContextAccessor();

now in your class, you can access context via DI
for example,

public class HomeService{
    private readonly IHttpContextAccessor _httpContextAccessor;
    public HomeSerivce(IHttpContextAccessor httpContextAccessor){
        _httpContextAccessor = httpContextAccessor;
    }
    public DoWork(){
        var says = (string)_httpContextAccessor.HttpContext.Items["DogSays"]
        Log.Rock(says);
    }
}

now you can mock your IHttpContextAccessor quite easily! and live a happy life.

[2.] Create a Class to handle the modification of this shared objects, and register it as Scoped (created once per client request (connection) ref.) then you can use it through DI, also it's a class! you can do a typed properties

so do speak, here is the code.

public interface IVaultAccessor<T> {
    void AddToVault(T t);
    T GetFromVault(T t);
}

public class VaultAccessor<MyDog> : IVaultAccessor<MyDog> {
    private MyDog _myDog { get; set; }

    public void AddToVault(MyDog myDog) {
        _myDog = myDog;
    }

    public MyDog GetFromVault() {
        return _myDog;
    }
}

public class MyDog {
    public string WhatDoesTheDogSay { get; set; }
}

// register as Scoped
services.AddScoped<IVaultAccessor<MyDog>>(sp => new VaultAccessor<MyDog>());


// Usage in any random class
public class Tea: ITea {
    private readonly IVaultAccessor<MyDog> _myDogAccessor;
    public Tea(IVaultAccessor<MyDog> myDogAccessor) {
        _myDogAccessor = myDogAccessor;
    }

    public void RandomName() {
        var myDog = _myDogAccessor.GetFromVault();
        Log.Rock($"What a relief you are still my dog, {myDog.WhatDoesTheDogSay}");
    }
}

You can make IVaultAccessor fancy to the extent. And live a happy life.

Whoaaa! that's it for today.
How was it guys, hope you enjoy being chubbier.

See you around.

Monadic null checking in ES6

Thanapon Jindapitak — Thu, 14 Nov 2019 16:38:58 +0000

Hola, readers

I'd like share you guys my journey of moving from C# world to JavaScript.

First and last, it was fun.

Of course, there're some features I really miss,
One of them is the beautiful Monadic null checking in C#.

Some of you might have no idea.
Let me tell, you can do something like

var duck = new Duck();
Console.WriteLine(duck.Name?.ToLowerCase() ?? "again? duck has no name");

When duck.Name is null it won't throw exception, instead it ignores the rest of statement replacing with null.
Then we can simply use ?? operator to check weather it's null or not

Basically, we can say, if duck.Name is null use default value

That's it! brilliant, loved it !.
This feature is amazingly powerful and save up lots of null checking line of code.

But in JavaScript ... THERE IS NO SUCH THING! WHY?

No worry, it's time to use Google to search good things, my friend.

Apparently, there're soooo many questions like this in StackOverflow,
now I know that people are struggling, upsetting, drowning in his/her own null checking code

And there are helpful valid answers:

Use try catch => Nah (dunno why, but, nah)
Use Lodash.get => Nah (hate when I'm forced to use string!)
Use ES6's Proxy => Nah! ... oh! this is new, this is new.

Let's see, what it can do.

The Proxy object is used to define custom behavior for fundamental operations (e.g. property lookup, assignment, enumeration, function invocation, etc).
developer.mozilla

Whoaaa !.. sounds good but I don't understand

After years of researching ES6's Proxy
Finally, I did it!

Here it is. (I'm not gonna explain anything about this code, since I have to do dishes and clean my house, sry, duty calls)

// proxyLib
const proxies = new WeakSet();

const def = (o, d) => {
    return proxies.has(o) ? d : o;
}

const getEmptyProxy = () =>
    new Proxy({}, {
        get: (t, p) => {
            const pr = getEmptyProxy();
            proxies.add(pr);

            return pr;
        }
    });

const getProxyObject = (obj) => {
    return new Proxy(obj, {
        get: (target, propertyName) => {
          const value = target[propertyName];

          if (!value && value !== 0) {
            return getEmptyProxy();
          }

          return value;
        }
    });
}




// main
const obj = {
    a: 1
};

const proxiedObj = getProxyObject(obj);

console.log(def(proxiedObj.a, "hello")); // 1
console.log(def(proxiedObj.b.c.d.e.f.g, "world")); // world

That's it everyone, thanks for reading, hope you guys enjoy.
Feel free to comment, I rather not reply back, since I already have too many haters. Anyways, see you.

Peach...

dang auto correct

Peace