Комментарии 8
Посмотрел оригинал, не могу сказать что всё ужасно, но конкретно части 2-4 очень не удачные: в 2 и 3 смущает ну прямо самый очевидный выбор самых популярных, но далеко не лучших роутера и фреймворка. И это не говоря про качество кода выдаваемого генератором из 4. Ощущение будто автор набрал в гугле "rest api golang", и переложил на более культурный язык.
Ну если говорить про выбор роутеров и фреймворков - что угодно на базе fasthttp. Лично я предпочитаю fiber за удобство и комьюнити, но вариантов много. Если же без fasthttp - самым приятным в использовании без преда для производительности (субъективно) ощущается echo, из совместимых с net/http - chi.
А про сваггер - там грустная история потому что есть х реализаций опенапи 3, но они все весьма посредственный код выдают, поэтому (пока) я бы обошёлся либо go-swagger генерирующим сервер из сваггер 2, либо swaggo/swag генерирующим сваггеровский файл из комментариев к коду.
NewTaskServer
— это конструктор для нашего сервера, имеющего типtaskServer
.
Больше похоже на фабрику.
Сервер включает в себя
TaskStore
, что безопасно с точки зрения конкурентного доступа к данным.
Кто-то может объяснить каким образом это делает доступ к хранилищу данных безопасным?
Не
/task/
, а/tasks/
и это важно, так как глупо будет ожидать на запросGET /task
список задач.Не
/due/<yy>/<mm>/<dd>
, а/tasks?due=yy/mm/dd
, REST это все же про ресурсы, а ресурса и сущности due у вас нет.В хендлерах обращаться сразу к store странно, почти всегда будет бизнес логика в прослойке service между хендлером и стором.
В 4 последних проектах использовал роутер от julienschmidt/httprouter - крайне положительно. и интерфейс совместим со стандартным и по скорости приятный.
Разработка REST-серверов на Go. Часть 1: стандартная библиотека