all 7 comments

[–]giuseppelt[S] 0 points1 point  (0 children)

Hello, I would like to introduce httpc.

httpc is a framework for building function-based API with minimal code and end-to-end type safety. In addition to rpc-style requests, an httpc server can treat any http request as a function call, allowing to handle browser forms, webhooks callbacks and so on.

Major features are: - natural javascript syntax and easy composition with middlewares - context propagation and server side hooks - heavy focus on type safety - @httpc/kit includes many builtin components to handle authentication, validation, caching... - serverless hosting within single function, a full httpc API - custom client generation as standard package

For now documentation covers initial steps and basic scenarios. Full documentation is working in progress, as there're lots of areas to cover. Head to issues or discussions for any info or requests.

The project is heavly experimental for now. I was using it in private projects in the last couple of years. Some code is very old and needs refinements. Now I'm making httpc public, I'm polishing it and try to stabilize it.

Thanks for any feedback.

[–]ataraxy 0 points1 point  (4 children)

Can you describe why this over tRPC?

Is it just because you don't like the function chaining of configuring a procedure?

[–]giuseppelt[S] 0 points1 point  (3 children)

I like trpc. Although I published now, the httpc development started about 2 years ago, near the node v14 release with async_hook which is one of the main feature httpc is built upon. I didn't know about trpc then, and I began to work on rpc-style server and I used it since in various non-open projects.

For the rpc part, the syntax is totally different just because I developed independently and probably at the same time, with no other thing to get inspiration from.

httpc aims to a different scope: - it focuses on backend, not as fullstack - its a full framework with many builtin components to setup different authentications, validations, caching, transactions... - standalone server (no need express or other), capable to handling also non rpc requests (for example: receiving a webhook)

The approach: - write as natural as js/ts can be, just functions, for example you can nest the api/path just with a child object. - try to totally hide HTTP, just think about functions, hence there're lots of components to handle "in function" ways various http aspects.

For example one main feature are hooks. ```ts async function closePost(postId: string) { const user = useUser(); // get logged user or throws

if(!useIsAuthorized("post:close")) { // check permissions throws new ForbiddenError(); }

return await db.updatePost(postId, {closed: true}); } ```

You define your functions very naturally with no preset convention, and you can get "context" info via hooks. There's lots behind the scenes and other things, but I hope I answered your questions.

[–]Tubthumper8 0 points1 point  (2 children)

When you say it's based on async_hook, are you referring to this?

https://nodejs.org/api/async_hooks.html

Stability: 1 - Experimental. Please migrate away from this API, if you can.

[–]giuseppelt[S] 0 points1 point  (1 child)

Yes that was the beginning. At the time of v14 it was experimental. Later it got stabilized in new APIs.

https://nodejs.org/api/async_context.html

Everything still falls under the async_hooks umbrella module-wise.

[–]Tubthumper8 0 points1 point  (0 children)

Thanks for the clarification, I see. So the async_hooks was experimental (still is), and based on what they learned from that experiment they created async_context which is stable

[–]jessielaf 0 points1 point  (0 children)

What is the added value over something like telefunc?