Comments 24
Ничего не понял, но очень интересно. Собсно куча вопросов, по порядку начну:
```
> goswagger generate server \
--with-context -f ./swagger-api/swagger.yml \
--name example1
```
Флажок разве не депрекейтед? github.com/go-swagger/go-swagger/pull/1806
```
> goswagger generate server \
--with-context -f ./swagger-api/swagger.yml \
--name example1
```
Флажок разве не депрекейтед? github.com/go-swagger/go-swagger/pull/1806
+1
Вот только уже давно есть третья версия спецификации (open API), которую go-swagger, увы, не планирует реализовывать. Видимо, как и последующие.
github.com/go-swagger/go-swagger/issues/1122#issuecomment-353590960
github.com/go-swagger/go-swagger/issues/1122#issuecomment-353590960
+1
это верно, но как сказано в комментарии по вашей ссылке — для большинства задач второй версии хватает.
Варианты перехода на 3ю версию есть, но еще не дошли до конкретного решения.
Варианты перехода на 3ю версию есть, но еще не дошли до конкретного решения.
-1
В целом жить можно, да. Главное сильно не привязываться к таким решениям, чтобы потом не было головной боли с переездами. Как сказали сами разработчики в конце этого топика — их всего пару человек и это их хобби-проект.
0
Ну как бы есть, сырое, но есть. github.com/deepmap/oapi-codegen
0
Продолжу))
>> Уметь конфигурировать приложение: передавать настройки подключения к БД, указывать порт HTTP-соединений и прочее.
Вот и экономия в строке, и порт не нужно указывать в конфиге.
go run ./cmd/… --port 3000
А вообще, что-бы с флагами поработать в го, люди используют что-то из этого viper/cobra или сами пишут. Вот можно почитать github.com/go-swagger/go-swagger/issues/762#issuecomment-269373779
Но я так и не увидел ни разу реализации как красиво это заюзать в проекте.
>> Уметь конфигурировать приложение: передавать настройки подключения к БД, указывать порт HTTP-соединений и прочее.
Вот и экономия в строке, и порт не нужно указывать в конфиге.
go run ./cmd/… --port 3000
А вообще, что-бы с флагами поработать в го, люди используют что-то из этого viper/cobra или сами пишут. Вот можно почитать github.com/go-swagger/go-swagger/issues/762#issuecomment-269373779
Но я так и не увидел ни разу реализации как красиво это заюзать в проекте.
0
А что у вас за goswagger? У меня просто swagger.
0
Верно, по-умолчанию — swagger, но для того, чтобы либа не конфликтовала с текущей версией (если установлена), я в доке по установке указал goswagger: github.com/delivery-club/go-swagger-example
0
А не могли бы объяснить, зачем в вашей апишке шаблоны? Для меня это что-то новое, я конечно поковыряюсь ближе к вечеру, что-бы понять…
upd: А, они используют таки viper сами… век живи, век учись.
upd: А, они используют таки viper сами… век живи, век учись.
0
Зачем в самом сервисе шаблоны? или зачем такой подход в целом?
0
Ну да, и шаблоны и подход. Я просто создаю отдельный пакет, в вашем случае в restapi/configure_example1.go:
И в этом пакете и подключение к базе и возврат middleware.Responder происходит, вот как образец github.com/MarlikAlmighty/library/blob/master/library/library.go
...
myapp.ConfigureAPI(api) // Вот так это выглядит
return setupGlobalMiddleware(api.Serve(setupMiddlewares))
}
И в этом пакете и подключение к базе и возврат middleware.Responder происходит, вот как образец github.com/MarlikAlmighty/library/blob/master/library/library.go
0
зачем сами шаблоны — как я понял, вы используете стандартные шаблоны, нас они не устраивают, поэтому мы используем свои. При этом мы не коммитим основную часть сгенерированного кода (по ряду причин), поэтому шаблоны храним в самом сервисе. Так же это добавляет удобство при редактировании api — у нас автоматически создаются файлы хэндлеров с заглушками, меняются / добавляются модели api — такая рутинная работа делается автоматически.
Что касается в целом подхода — собственно об этом статья:)
Основные причины — поддержка актуальности контрактов api, единый подход подходам в разработке сервисов, автоматизация рутинных задач.
Что касается в целом подхода — собственно об этом статья:)
Основные причины — поддержка актуальности контрактов api, единый подход подходам в разработке сервисов, автоматизация рутинных задач.
0
Мммм, я понял что вы делаете, и это круто. Спасибо, день потрачен с пользой. Пишите ещё, подписался.
+1
Для решения новых задач мы можем переопределить некоторые шаблоны— всё, что у вас там написано далее в этой главе, прямо скажем — ошарашивает. Абсолютно непонятно ни каким образом решение «этих задач» связано с кастомными шаблонами, ни как вы их решили в итоге. Вот этот код, который вы привели после «Опишем шаблон функции и заглушки», он наверное очень простой и его теоретически легко понять. Но выглядит он ужасно, и ни какого желания в нём разбираться нет. Дело в том, что я уже достаточно давно в go-swagger-е, но для решения «этих задач» никогда не пользовался такой сомнительной с моей т.з. фичей, как кастомные шаблоны.
0
Вопрос, а где основная логика приложения, хэндлер который? Если app для подключения к db, то как вы прокидываете этот коннект в хэндлер?
0
grSereger ??? Много вопросов, но так мало ответов))
0
сорри, не получается часто заходить на хабр)
у нас хэндлеры вызывают «процессоры», которые в свою очередь используют «сервисы» для выполнения бизнес-логики (сервисы могут содержать репозиторий).
Сервисы в нашем случае — изолированные блоки какой-либо функциональности.
Инициализируем это все в одном файле, в некоторые сервисах используется di, для упрощения.
Но в этой статье не хотели затрагивать тему со структурой приложения, т.к. эта тема тоже большая, и не хотелось смещать фокус с генерации.
у нас хэндлеры вызывают «процессоры», которые в свою очередь используют «сервисы» для выполнения бизнес-логики (сервисы могут содержать репозиторий).
Сервисы в нашем случае — изолированные блоки какой-либо функциональности.
Инициализируем это все в одном файле, в некоторые сервисах используется di, для упрощения.
Но в этой статье не хотели затрагивать тему со структурой приложения, т.к. эта тема тоже большая, и не хотелось смещать фокус с генерации.
0
Я бы с удовольствием почитал, следующую статью как у вас там всё работает.
У меня возникли вопросы. Дело в том что было-бы неплохо все заглушки размещать в отдельных папках, по tags в swagger-api. То есть как это сделано в ./internal/generated/restapi/operations/ это видимо в шаблонах нужно подправить? Видимо в двух. А сейчас эти заглушки свалены вcе вместе в ./internal/app/.
Потом меня смутило что, в ./internal/app/app.go не отрабатывает метод OnShutdown() то есть отрабатывает штатный сваггеровский а кастомный нет.
Можно подробнее что делает ./internal/app/app.go? Хотя-бы в примерах? И ещё, я так понимаю писать обработку запросов нужно прямо в заглушках?
Спасибо.
У меня возникли вопросы. Дело в том что было-бы неплохо все заглушки размещать в отдельных папках, по tags в swagger-api. То есть как это сделано в ./internal/generated/restapi/operations/ это видимо в шаблонах нужно подправить? Видимо в двух. А сейчас эти заглушки свалены вcе вместе в ./internal/app/.
Потом меня смутило что, в ./internal/app/app.go не отрабатывает метод OnShutdown() то есть отрабатывает штатный сваггеровский а кастомный нет.
Можно подробнее что делает ./internal/app/app.go? Хотя-бы в примерах? И ещё, я так понимаю писать обработку запросов нужно прямо в заглушках?
Спасибо.
0
Или же приходите к нам — сами все увидите)
0
Классная статья, всё по делу!
+1
0
Sign up to leave a comment.
Go-swagger как основа взаимодействия микросервисов