Разработка REST-серверов на Go. Часть 1: стандартная библиотека

[manyakRus]

Всё правильно, только не надо было писать много кода чтобы сказать: не делайте как тут написано :( а делайте как написано в части 2 которой ещё нет :)

[gohrytt]

Посмотрел оригинал, не могу сказать что всё ужасно, но конкретно части 2-4 очень не удачные: в 2 и 3 смущает ну прямо самый очевидный выбор самых популярных, но далеко не лучших роутера и фреймворка. И это не говоря про качество кода выдаваемого генератором из 4. Ощущение будто автор набрал в гугле "rest api golang", и переложил на более культурный язык.

[Stas911]

На чем бы вы писали и почему?

[gohrytt]

Ну если говорить про выбор роутеров и фреймворков - что угодно на базе fasthttp. Лично я предпочитаю fiber за удобство и комьюнити, но вариантов много. Если же без fasthttp - самым приятным в использовании без преда для производительности (субъективно) ощущается echo, из совместимых с net/http - chi.

А про сваггер - там грустная история потому что есть х реализаций опенапи 3, но они все весьма посредственный код выдают, поэтому (пока) я бы обошёлся либо go-swagger генерирующим сервер из сваггер 2, либо swaggo/swag генерирующим сваггеровский файл из комментариев к коду.

[rayz_razko]

NewTaskServer — это конструктор для нашего сервера, имеющего тип taskServer.

Больше похоже на фабрику.

Сервер включает в себя TaskStore, что безопасно с точки зрения конкурентного доступа к данным.

Кто-то может объяснить каким образом это делает доступ к хранилищу данных безопасным?

[dikkini]

1. Не /task/, а /tasks/ и это важно, так как глупо будет ожидать на запрос GET /task список задач.

2. Не /due/<yy>/<mm>/<dd>, а /tasks?due=yy/mm/dd, REST это все же про ресурсы, а ресурса и сущности due у вас нет.

3. В хендлерах обращаться сразу к store странно, почти всегда будет бизнес логика в прослойке service между хендлером и стором.

4. В 4 последних проектах использовал роутер от julienschmidt/httprouter - крайне положительно. и интерфейс совместим со стандартным и по скорости приятный.