Pull to refresh

Comments 24

Ничего не понял, но очень интересно. Собсно куча вопросов, по порядку начну:

```
> goswagger generate server \
--with-context -f ./swagger-api/swagger.yml \
--name example1
```
Флажок разве не депрекейтед? github.com/go-swagger/go-swagger/pull/1806
Спасибо за замечание, видимо при переезде с 0.21 на 0.24 осталось.
Поправим.
это верно, но как сказано в комментарии по вашей ссылке — для большинства задач второй версии хватает.
Варианты перехода на 3ю версию есть, но еще не дошли до конкретного решения.
В целом жить можно, да. Главное сильно не привязываться к таким решениям, чтобы потом не было головной боли с переездами. Как сказали сами разработчики в конце этого топика — их всего пару человек и это их хобби-проект.
Продолжу))

>> Уметь конфигурировать приложение: передавать настройки подключения к БД, указывать порт HTTP-соединений и прочее.

Вот и экономия в строке, и порт не нужно указывать в конфиге.

go run ./cmd/… --port 3000

А вообще, что-бы с флагами поработать в го, люди используют что-то из этого viper/cobra или сами пишут. Вот можно почитать github.com/go-swagger/go-swagger/issues/762#issuecomment-269373779

Но я так и не увидел ни разу реализации как красиво это заюзать в проекте.
Мы указываем параметры через env — такой подход принят давно и не только для go-сервисов, поэтому и не работаем с передаваемыми аргументами.
Верно, по-умолчанию — swagger, но для того, чтобы либа не конфликтовала с текущей версией (если установлена), я в доке по установке указал goswagger: github.com/delivery-club/go-swagger-example
А не могли бы объяснить, зачем в вашей апишке шаблоны? Для меня это что-то новое, я конечно поковыряюсь ближе к вечеру, что-бы понять…

upd: А, они используют таки viper сами… век живи, век учись.
Зачем в самом сервисе шаблоны? или зачем такой подход в целом?
Ну да, и шаблоны и подход. Я просто создаю отдельный пакет, в вашем случае в restapi/configure_example1.go:

...
myapp.ConfigureAPI(api) // Вот так это выглядит
return setupGlobalMiddleware(api.Serve(setupMiddlewares))
}


И в этом пакете и подключение к базе и возврат middleware.Responder происходит, вот как образец github.com/MarlikAlmighty/library/blob/master/library/library.go
зачем сами шаблоны — как я понял, вы используете стандартные шаблоны, нас они не устраивают, поэтому мы используем свои. При этом мы не коммитим основную часть сгенерированного кода (по ряду причин), поэтому шаблоны храним в самом сервисе. Так же это добавляет удобство при редактировании api — у нас автоматически создаются файлы хэндлеров с заглушками, меняются / добавляются модели api — такая рутинная работа делается автоматически.

Что касается в целом подхода — собственно об этом статья:)
Основные причины — поддержка актуальности контрактов api, единый подход подходам в разработке сервисов, автоматизация рутинных задач.
Мммм, я понял что вы делаете, и это круто. Спасибо, день потрачен с пользой. Пишите ещё, подписался.
Для решения новых задач мы можем переопределить некоторые шаблоны
— всё, что у вас там написано далее в этой главе, прямо скажем — ошарашивает. Абсолютно непонятно ни каким образом решение «этих задач» связано с кастомными шаблонами, ни как вы их решили в итоге. Вот этот код, который вы привели после «Опишем шаблон функции и заглушки», он наверное очень простой и его теоретически легко понять. Но выглядит он ужасно, и ни какого желания в нём разбираться нет. Дело в том, что я уже достаточно давно в go-swagger-е, но для решения «этих задач» никогда не пользовался такой сомнительной с моей т.з. фичей, как кастомные шаблоны.

Вопрос, а где основная логика приложения, хэндлер который? Если app для подключения к db, то как вы прокидываете этот коннект в хэндлер?

сорри, не получается часто заходить на хабр)
у нас хэндлеры вызывают «процессоры», которые в свою очередь используют «сервисы» для выполнения бизнес-логики (сервисы могут содержать репозиторий).
Сервисы в нашем случае — изолированные блоки какой-либо функциональности.
Инициализируем это все в одном файле, в некоторые сервисах используется di, для упрощения.

Но в этой статье не хотели затрагивать тему со структурой приложения, т.к. эта тема тоже большая, и не хотелось смещать фокус с генерации.
Я бы с удовольствием почитал, следующую статью как у вас там всё работает.

У меня возникли вопросы. Дело в том что было-бы неплохо все заглушки размещать в отдельных папках, по tags в swagger-api. То есть как это сделано в ./internal/generated/restapi/operations/ это видимо в шаблонах нужно подправить? Видимо в двух. А сейчас эти заглушки свалены вcе вместе в ./internal/app/.

Потом меня смутило что, в ./internal/app/app.go не отрабатывает метод OnShutdown() то есть отрабатывает штатный сваггеровский а кастомный нет.

Можно подробнее что делает ./internal/app/app.go? Хотя-бы в примерах? И ещё, я так понимаю писать обработку запросов нужно прямо в заглушках?

Спасибо.
Или же приходите к нам — сами все увидите)
Я не программист, чуть-чуть фрилансю, и пытаюсь развиваться. Спасибо.
Sign up to leave a comment.