Should I use fasthttp to create a json API library?

Question

go

Hello, I recently finished writing a library for working with the JSON API of one toy. First, I wrote a client that makes requests using net/http. There was a standard http.Client in my client structure field. I received a request using NewRequestWithContext, set it up and calmly unloaded it into the structure after reading the body with the utility. Today I refactored the code, replacing the standard encoding/json with json-iterator. Instead of the net/http package, I connected fasthttp. The code has become smaller, it began to look more elegant. I tried it in practice - it accelerated. Here's what worries me:

1. I cut out the context, and it is directly intended to work with the API (according to one article with the corresponding name)
   
2. Many advise limiting yourself to the standard package if a highload is not planned. Some say that if you write a lib, then make it productive.
   

1. Should I bother so much about the context? Is it really so necessary in my situation?
2. Whom to listen to? I have a request limiter installed, which the user of the library can configure himself depending on changes in the number of requests in a certain period of time from the API, and therefore, that the number of requests per second will not increase, I will increase the speed of the request (one) .

To be honest, I like that the code has changed and that the library is faster, but I still want to do the right thing.

Answer 1

I like fasthttp, but, unfortunately, I have to admit that the project has stagnated. The author of the project has lost interest in it and is already sawing another project . So, fasthttp still has a lot of shortcomings, if earlier it was possible to turn a blind eye to them, now they are gone. What made me return some of the projects to net/http:

1. There is no support for HTTP2 ( https://github.com/valyala/fasthttp/issues/786 ) and due to the complexity of implementation xs when it appears.
   
2. No stream reading request body ( https://github.com/valyala/fasthttp/issues/622 ). Do not upload files. (here fasthttp has an attack vector on it - through bold posts)
   
3. There is no connection pool. If you have keep alive, then you will have to bathe with them to restart the servers, without waiting for everyone to close the connections.
   

In fact, it would be nice to use fasthttp on the highload, but the base will still slow down the most :)

Answer 2

It is not clear where the context is "cut out". If your solution works fine without context - why not?
About the second point - if there is no direct need for maximum performance, then the choice of a framework or library for the web does not matter. Enough standard http - good. If you want more convenient and readable code - you can use something else.