AP
не, это конкретно местный стартап типа, http://testfit.io/
вроде не паблишил никто, может полезно будет
https://t.me/startupoftheday/1346
Size: a a a
2020 May 13
D
2020 May 14
AP
судя по тому что я это вижу уже раз 8-й, скорее всего было)
D
судя по тому что я это вижу уже раз 8-й, скорее всего было)
Про Рыбака 2 новости было ) одна что он канал завел.
МС
Кто-нибудь знает аналог Swager'а или, быть может, знает как его правильно готовить?
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
A
Всем привет ) Есть задача перевести продукт, есть json-файл, который содержит переменные со строками. Кто-то знает нормальный сервис, в который можно этот файл загрузить, отправить переводчикам, чтобы они там перевели и можно было выгрузить результат? Ну и в идеале он бы ещё поддерживал хостинг таких файлов, чтобы можно было прямо к продукту подключить и не гонять файлы туда-сюда.
мы написали тулзу которая онлайн переводчиком все переводит. не гуглом правда, а каким-то другим... доберусь до компа гляну код
A
мы написали тулзу которая онлайн переводчиком все переводит. не гуглом правда, а каким-то другим... доберусь до компа гляну код
вот эту юзаем https://mymemory.translated.net/doc/spec.php
раньше нелегально юзали гугл-транслейт апи, но они его прикрыли
раньше нелегально юзали гугл-транслейт апи, но они его прикрыли
СА
Кто-нибудь знает аналог Swager'а или, быть может, знает как его правильно готовить?
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
Опыт последних нескольких проектов показывает, что генерировать OpenAPI-спеку из кода - не лучшее решение. Удобнее писать её руками, держать в отдельном репо и использовать в сервере и клиентах. Для сервера из неё можно делать автотесты, для клиентов - dummy-сервер.
СА
Кто-нибудь знает аналог Swager'а или, быть может, знает как его правильно готовить?
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
А для сервера и клиентов наоборот использовать кодгенерацию из спеки, как минимум в части моделей данных, но можно и шире, как показывает практика.
PN
Кто-нибудь знает аналог Swager'а или, быть может, знает как его правильно готовить?
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
Сейчас файл описания для него генерируется из кода, а я хочу ещё из браузера его дополнять параллельно.
А кто-нибудь оборачивал Swagger over TCP или Websocket?
МС
Опыт последних нескольких проектов показывает, что генерировать OpenAPI-спеку из кода - не лучшее решение. Удобнее писать её руками, держать в отдельном репо и использовать в сервере и клиентах. Для сервера из неё можно делать автотесты, для клиентов - dummy-сервер.
Так-то оно так. Вот только в проекте, в котором сейчас работаю принято наоборот : код->Swagger->дока. А я не могу сильно повлиять на внутренние процесса. Вот и ищу, как можно доку по API улучшить без доступа к коду.
СА
Так-то оно так. Вот только в проекте, в котором сейчас работаю принято наоборот : код->Swagger->дока. А я не могу сильно повлиять на внутренние процесса. Вот и ищу, как можно доку по API улучшить без доступа к коду.
Очевидно никак. Раз она генерируется из кода - значит и менять надо в коде. Ну или какой-то дополнительный слой из diff/patch городить (не рекомендую)
МС
Ну мало ли, вдруг есть вебморда, которая умеет показывать доку из свагер-файла и отдельного источника комментариев.
PN
Ну мало ли, вдруг есть вебморда, которая умеет показывать доку из свагер-файла и отдельного источника комментариев.
МС
Хорошая штука, но для мой проблемы не подходит, однако. )
MS
Опыт последних нескольких проектов показывает, что генерировать OpenAPI-спеку из кода - не лучшее решение. Удобнее писать её руками, держать в отдельном репо и использовать в сервере и клиентах. Для сервера из неё можно делать автотесты, для клиентов - dummy-сервер.
а зачем?
MS
мне кажется генерить из кода лучше потому что получается один source of truth
МС
Source of Truth - это хорошо. Однако, этим эталоном должен быть - API. ))
МС
По хорошему, нужно сначала описывать API, согласовывать, а потом делать код по нему. Этим могут заниматься даже разные люди.
СА
мне кажется генерить из кода лучше потому что получается один source of truth
В моей схеме тоже есть один source of truth, и это (суб)репо со спекой. А при генерации из кода любой инженер бэкенда что-то меняет в коде - и автоматически, без его на то явного согласия, меняется содержимое source of truth, ставя всю остальную команду перед фактом.