Стоит ли использовать fasthttp для создания библиотеки по работе с json API?
==============================================================================

 Здравствуйте, недавно закончил писать библиотеку по работе с JSON API одной игрушки. Сначала я написал клиент, осуществляющий запросы посредствам net/http. В поле структуры моего клиента был стандартный http.Client. Я получал запрос с помощью NewRequestWithContext, настраивал его и спокойно после прочтения тела иоутилом выгружал в структуру. Сегодня отрефакторил код, заменив стандартный encoding/json на json-iterator. Вместо пакета net/http подключил fasthttp. Кода стало меньше, он стал выглядеть изящнее. Попробовал на деле - ускорился. Вот, что меня волнует:  

1. Я вырезал context, а он напрямую предназначен для работы с API(по словам одной статьи с соответствующим названием)
2. Многие советуют ограничиться стандартным пакетом, если не намечается хайлоад. Некоторые заявляют, что если уж пишешь либу, то делай ее производительной.

  

1. Стоит ли так заморачиваться по поводу контекста?Действительно ли он так необходим в моей ситуации?   

2. Кого слушать? У меня установлен лимитировщик запросов, который пользователь библиотеки сам может настраивать в зависимости от изменений в количествах запросов в определенный промежуток времени от API, а следовательно, что у меня не будет увеличиваться количество запросов в секунду, у меня будет увеличиваться скорость выполнения запроса(одного).  

  

Если честно, то мне нравится, что код преобразовался и что библиотека стала быстрее, но все же хочу поступить правильно. 

 Мне нравится fasthttp, но, к сожалению, приходится константировать что проект впал в стагнацию. Автор проекта потерял к нему интерес и пилит уже [другой проект](https://github.com/VictoriaMetrics/VictoriaMetrics). Так-то у fasthttp есть всё еще куча недостатоков, если раньше на них можно было закрыть глаза то сейчас уже нет. То что заставило меня вернуть часть проектов на net/http:  

1. Нет поддержки HTTP2 (<https://github.com/valyala/fasthttp/issues/786>) и из-за сложности реализации хз когда появится.
2. Нет потокового чтения тела запроса (<https://github.com/valyala/fasthttp/issues/622>). Загрузку файлов не реализовать. (тут у fasthttp есть вектор атаки на него - через жирные посты)
3. Нет пулла коннектов. Если у вас будут keep alive то придётся с ними париться что бы перезагрузить сервера, не ожидая пока все позакрывают коннекты.

  

 По существу, хорошо бы использовать на хайлоаде fasthttp, но всё-равно больше всего будет тормозить база :) 

 Непонятно, откуда "вырезан" контекст. Если ваше решение нормально работает без контекста - почему нет?   

Про второй пункт - если нет прямой необходимости в максимальной производительности, то выбор фреймворка или библиотеки для web значения не имеет. Хватает стандартного http - хорошо. Хочется более удобного и легкочитаемого кода - можно использовать что-то ещё.