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

Question

[Mikkkch]

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

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

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

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

Answer 1

[Ivan Shalganov]

Мне нравится fasthttp, но, к сожалению, приходится константировать что проект впал в стагнацию. Автор проекта потерял к нему интерес и пилит уже другой проект. Так-то у 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, но всё-равно больше всего будет тормозить база :)

Comments

[Mikkkch]

Спасибо за ответ! Но я полагаю, что Вы не совсем поняли в какой области я задействую эту либу. Я не пишу сервера, я обращаюсь к API , которая возвращает json и выгружаю тело в структуру. Простейшие действия, но структуры большие, чтобы как можно лучше ускорить свою либу я задействовал фхттп и jsoniter вместо стандартных решений. Если с такой точки зрения смотреть, то как Вы считаете?

[Ivan Shalganov]

Mikkkch, а Вы используете HTTP2? Почему спрашивают, скоро уже будет HTTP3 (типо HTTP2 по UDP) который даст хорошую производительность таким приложениям как, например, онлайн игры. В net/http уже идёт работа по HTTP3. Сейчас, да, fasthttp то что вам надо, но если смотреть дальше, то тут не всё так однозначно.

Если коротко: в вашем случае (если не используете HTTP2) то сразу брал бы fasthttp, но код писал так что бы было можно легко метнуться к net/http в случае чего.

[Mikkkch]

Ivan Shalganov, спасибо. В любом случае меня, да я думаю и многих остальных преследует синдром, при котором ты возвращаешься к своему коду и с удивленным лицом задаешь сам себе вопрос насчет того какой кретин это все накалякал)

Answer 2

[Дмитрий Шицков]

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