Создание API с помощью Go - Часть 1 Выбор роутера

Этот пост - начало серии, которая поможет вам изучить свой API в Go и принять правильные решения.

Мы тестировали различные языки, библиотеки и методы кодирования для нашего продукта у моего нынешнего работодателя. После всего этого мы пришли к выводу, что в настоящее время вряд ли найдется язык лучше, чем Go, для создания серверных API-интерфейсов. Этот вывод относится к нашей команде; вы всегда должны обдумывать свои решения, думая о своей команде.

Имея это в виду, давайте проясним, что в этой серии статей мы сосредоточимся на хорошем опыте разработки. Тем не менее, мы не хотим добавлять ненужные накладные расходы или избегать повышения производительности, но это не происходит за счет нашей производительности.

Начнем с нашего первого обзора.

Маршрутизация

Первое, что нужно нашему API, - это маршруты, поэтому нам нужно посмотреть на наш маршрутизатор. Для этого у нас есть множество вариантов, включая стандартный маршрутизатор, базовые маршрутизаторы и многофункциональные платформы.

Стандарт

Это нормально, если вам не нужно выполнять маршрутизацию методами запроса или использовать параметры маршрута. Если вам это нужно, вам придется реализовать это вручную. Вы можете написать несколько операторов if внутри обработчика, чтобы проверить метод. Для параметров вам нужно будет использовать регулярное выражение или что-то подобное. Хорошо помнить об этом решении, но это не то, что нам нужно.

Чи (https://github.com/go-chi/chi)

Отличный маршрутизатор с поддержкой промежуточного программного обеспечения, параметров, методов и суб-маршрутизаторов / групп маршрутизации. API совместим со стандартной библиотекой. Сам маршрутизатор довольно скудный, поскольку он ориентирован только на маршрутизацию, ни на что другое.

Джин (https://github.com/gin-gonic/gin)

Gin обертывает запрос и писателя своим контекстом, предоставляя вам полезные функции. Таким образом, вы можете получить доступ к параметрам и отформатировать ответы немного проще. Хотя это считается рамкой, он не кажется раздутым.

Эхо (https://github.com/labstack/echo)

Echo имеет синтаксис, аналогичный Gin. Разница здесь в том, что он заботится о большем количестве частей вашего приложения, ведении журнала и обработке ошибок. Вы можете настроить регистратор для использования вашей библиотеки, но, честно говоря, это не так просто, поскольку вам нужно написать мост, поддерживающий интерфейс регистратора эха. Из-за этого мы отказались от этого фреймворка. Мы предпочитаем использовать то, что ориентировано только на маршрутизацию и менее категорично в отношении остальной части нашего приложения.

Волокно (https://github.com/gofiber/fiber)

У Fiber лучший синтаксис из всех. Он заботится о маршрутизации, предоставляет множество ценных промежуточных программ с четкой документацией и обрабатывает ошибки, аналогично тому, как это делает echo. Разница в том, что этот фреймворк не такой раздутый, как эхо, и не такой самоуверенный. Это оставляет много места для настройки. Существенным недостатком Fiber является то, что он использует библиотеку fasthttp вместо стандартной net / http под капотом. Кроме того, с этим нелегко добиться правильного распространения контекста. Некоторые существующие библиотеки предполагают, что вы используете net / http, а другие работают с распространением контекста, поэтому они несовместимы с Fiber.

Контрольные точки

Экземпляры D3v2 имеют четыре виртуальных процессора и 14 ГБ оперативной памяти. Зеленая полоса представляет количество запросов, которые сервер может обрабатывать в секунду.

Prefork - это метод, который использует встроенные функции ОС для обработки параллелизма вместо встроенного решения go. Подробнее об этом можно прочитать здесь: 🤔 Для чего нужен префорк? · Проблема №180 · gofiber / fiber (github.com)

В Fiber вы можете включить его, просто передав флаг серверу. Однако на других маршрутизаторах / фреймворках вы должны полагаться на внешнюю библиотеку или писать небольшой код для этого. Поскольку Fiber ориентирован на высокую производительность, вы, как правило, обнаружите, что такую ​​оптимизацию выполнить проще, и вы увидите больше информации об этом в их сообществе, чем о других.

Глядя на такой график, вы можете подумать, что Fiber превосходен, превосходит Chi не по дням, а по часам, и вам следует использовать его, потому что он намного быстрее.

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

Если вам не нужно отчаянно беспокоиться о производительности вашего API, а не просто масштабировать контейнер, это вряд ли имеет значение, если честно.

Заключение

В нашем случае мы выбрали маршрутизатор Chi. Мы можем использовать любую библиотеку для сериализации JSON и настраивать все, не прибегая к решениям, принятым фреймворком. Другими хорошими вариантами были Gin framework или Fiber.

Мы ни в коем случае не заявляем, что Чи лучший отсюда, просто лучший для нас. Было бы лучше, если бы вы помнили, что у каждого варианта есть свои основные области и сообщество вокруг них, которое будет вести себя по-разному в зависимости от того, чего они хотят достичь с помощью своего пакета.

Во второй части этой серии статей мы начнем писать наш API и рассмотрим некоторые решения по дизайну кода и структуре папок, мы будем использовать там маршрутизатор Chi, но вы сможете применить его к любому из вариантов, перечисленных здесь.

«Создание API с помощью Go - Часть 2 Написание наших первых конечных точек | Фернандо Х. Бандейра | Май 2021 г. | Середина"

Дополнительные замечания

Мы рассмотрели множество других фреймворков и маршрутизаторов, включая httprouter, используемый фреймворком Gin. Однако, на наш взгляд, это были лучшие.

Другой фреймворк, который нам показался подходящим, - фреймворк Iris. К сожалению, мы закончили тем, что не использовали и не ссылались на него здесь, поскольку, похоже, этот фреймворк был исключен из списка потрясающих проектов. Часть сообщества также сильно презирает автора.