refactor(webhook): change the way to get webhook handler

[shevernitskiy]

PR aiming to close #695 and #696

I'm not good at typing, so I'm requesting help. There are couple "as" in a commit :)

I created a factory of factories to dynamically generate object with creators of callback handlers. I do not know how to document every object property in this case. If it is not necessary, we can just describe the main object.

Regarding the "return" type, I decided to rename it to "ignore" because it does not make any calls and leads to a safe logic branch. The user can pass an empty callback as an argument, and it will work pretty much the same, but with an unnecessary extra call.

So, if we want to slim down and simplify the API, we need to remove "ignore." If we want to gain a nano performance benefit, we should keep it.

[KnorpelSenf]

What does this change?

[shevernitskiy]

I just copy hono part from main branch to fix broken test

[shevernitskiy]

I realized, that in my implementation we have runtime iteration, so i decided to measure perf.

const bot = new Bot("fake-token", { me: {} as unknown as UserFromGetMe });
Deno.bench(function callback() {
    const handler = webhookCallback(bot, "stdHttp", "ignore", 10000, "qweqwe");
});

Deno.bench(function adapters() {
    const handler = webhookAdapters.stdHttp(bot);
});

benchmark   time/iter (avg)        iter/s      (min … max)           p75      p99     p995    
----------- ----------------------------- --------------------- --------------------------    
callback            30.1 ns    33,220,000 ( 24.6 ns … 197.3 ns)  28.2 ns  64.5 ns  89.0 ns
adapters            36.4 ns    27,470,000 ( 30.7 ns … 263.8 ns)  33.9 ns  94.1 ns  99.3 ns

[winstxnhdw]

Why not just unroll the loop? It doesn’t seem to require a runtime.

[shevernitskiy]

Why not just unroll the loop? It doesn’t seem to require a runtime.

You mean make static object with all adapters manually? Sure I can do if it your request to change. My initial intention was more generic solution.

[winstxnhdw]

Someone who has to add support for a new adapter will have to create the new object anyways. A little more wouldn’t hurt. Also, CPU time is precious on a lambda.

[shevernitskiy]

Someone who has to add support for a new adapter will have to create the new object anyways. A little more wouldn’t hurt. Also, CPU time is precious on a lambda.

Got it, will commit in couple hours

[shevernitskiy]

Ok, now we have ability to make an example for each adapter. I leave as todo for now.

[winstxnhdw]

Since we are changing the API entirely, could we have a proper onTimeout argument? Currently, we are checking if it is a function or object. We can do away with that if we just have another argument for its own type.

[shevernitskiy]

Since we are changing the API entirely, could we have a proper onTimeout argument? Currently, we are checking if it is a function or object. We can do away with that if we just have another argument for its own type.

I though about that. It will be simple for use and user just have options object as an argument.
Then we can drop overloading thing.

[shevernitskiy]

it looks not so complicated now:)

[KnorpelSenf]

Rubber-stamp LGTM. We can fix things later if we discover oddities. Long live the liberty of breaking changes!

[winstxnhdw]

Rubber-stamp LGTM. We can fix things later if we discover oddities. Long live the liberty of breaking changes!

Can we still make breaking changes?

[KnorpelSenf]

We can make breaking changes until v2 is released. This will only happen when we no longer want to make breaking changes.

[winstxnhdw]

Nice! I am still not too happy with this API yet. I'll think of something.

[KnorpelSenf]

Looking forward to that!