Комментарии 13
По поводу Postman:
Если пользуетесь продуктами JetBrains, можно использовать их встроенный http-клиент. Где-нибудь в проекте создаёте папочку, кидаете туда файл с окружениями http-client.env.json:
{
"my-env": {
"auth": "bearer xxxxxxxxxxxx"
}
}
Добавляете его в .gitignore, чтобы свои токены не светить.
Создаёте файл с запросами
GET http://localhost/api/v1/version
Authorization: {{ auth }}
Accept: application/json
###
POST http://localhost/api/v1/endpoint
Authorization: {{ auth }}
Accept: application/json
Content-Type: application/json
{
"key": "value"
}
###
Открываете этот файлик в IDE, слева от каждого запроса появляется кнопочка run (зелёный треугольник).
Вверху в выпадашке Run with: выбираете свой env (в моём случае my-env), жмёте run и смотрите ответ.
Коллекции запросов можно прямо в репе и хранить, если нужно их шэрить
JetBrains, конечно тоже России рукой махнули, но у многих остались fallback-лицензии
Действительно, всегда удивляло: зачем вообще люди используют postman вместо удобного клиента от JetBrains. А автоматизированные тесты проще в той же Java-е написать
Так же поддерживаются e2e тесты, gRPC, есть консольная версия и docker image.
# Check response status is 200
GET https://httpbin.org/status/404
> {%
client.test("Request #3 is 200", function() {
client.assert(response.status === 200, "Response status is not 200");
});
%}
Мы у себя к сожалению пока пользуется postman, из-за того что они значительно опередили jetbrains и мигрировать будет больно.
JetBrains, конечно тоже России рукой махнули, но у многих остались fallback-лицензии
Поддержка вполне работает и оплачивать картами иностранных банков по прежнему можно.
Есть миграция в один клик же! https://plugins.jetbrains.com/plugin/22438-import-from-postman-collections
Спасибо за подробное описание. У нас есть сервисы где команды решили пойти по этому пути и успешно пользуются этим DSL.
Этот подход предполагает хранение "коллекций запросов" в репозитории приложения. Postman же предлагает решение с централизованным хранилищем, которое в довесок включает в себя пространства команд и другие плюшки (например, генерация коллекций по сваггеру).
У нас львиная доля работы с Postman - это межсервисные флоу, потому когда-то его и выбрали. Чтобы достичь того же с решением JetBrains, нужно создать единый репозиторий и поддерживать его. Теперь, конечно, это касается и Postman.
Но есть еще один важный момент - чтобы перейти на решение JetBrains, нужно переписать все коллекции. Зачем, если следующий шаг будет тот же?
Ну так ровненько, спасибо, что поделились информацией.
Вместо Postman есть, к примеру, Insomnia
Нам интересно двигаться в сторону BFF — Backend For Frontend: мы видим, что этот подход становится все более популярным
Звучит слегка иронично: Ламода старается следить за модой в архитектуре web технологий.
Но не следует слепо идти за модой, даже если в каждом утюге об этом свистят. BFF - это прошлое, как треуголки. Да - было красиво, да - было полезно, но ТОГДА, с тем интернетом, с теми браузерами и теми стеками. Сейчас у вас есть WASM, сокеты и возможность исследование новые способы рендеринга в браузере (не через JS - вспоминаем картинку как он работает). Не надо смотреть назад - смотрите вперед и не бойтесь экспериментировать с чем то новым (у вас же наверняка куча программистов C++). Это будет гораздо интереснее читать. И возможно вы станете новым законодателем моды :)
По BFF. Вам не хватает контрактов? Вы запутались в этом зоопарке? Так сходите к фронтам, у них этого гораздо больше! и ниче, справляются. Вам на бэке это тяжело поддерживать? Поэтому я топлю чтобы в простых проектах B4F фронтеры сами его себе писали на (хоты бы даже) ноде. Это получается и просто и работает (часто даже с общшим кодом фронта и бэка). Вариантов куча.
BFF - это еще и перекладывание части головной боли с фронта опять же на бэк. Но зачем? Ваш фронт не справляется? Значит что-то не так на фронте (или в людях или пора менять архитектуру). ИМХО бэк должен заниматься только и только данными, и ничего не знать о фронте и его зоопарке девайсов, компонент и т. п.
Еще использование BFF говотрит о том что явный перекос в силах команд в сторону бэка. Но опять же это не значит что надо отдавать им флаг и пусть рулят. Эт сигнал что надо усиливать фронт-команду
++ в Ламоде не используются особливо
Еще использование BFF говотрит о том что явный перекос в силах команд в сторону бэка.
Здесь вы попали прямо в точку. В латехе действительно большой перекос в сторону бэкенда. Причина проста - это работа с тремя платформами(web, android, ios) которые должны работать синхронно и максимально идентично. Поэтому концентрация бизнес логики на бэкенде решает вопрос дублирования этой логики на клиентах и вопрос поддержки, проблема физического обновления приложений на смартфонах все еще актуальна: многие пользователи не спешат обновляться на более свежие версии.
Но не следует слепо идти за модой
Скорее не погоня за модой, а исторически сложившаяся ситуация. Когда, то у каждой платформы был свой бэкенд. Потом появился единый api для мобилок. Но как оказалось, в нем не было учтено весь функционал web-платформ. Поэтому приходиться поддерживать bff для агрегации данных с разных сервисов.
Поэтому я топлю чтобы в простых проектах B4F фронтеры сами его себе писали на (хоты бы даже) ноде.
Так оно и получилось, что bff по большей части ушло в ответственность фронтов. Пока там go, но в планах есть переход на nodejs. Если конечно, раньше не получится переход полностью на единый api, в эту сторону сейчас идет активное движение
Коллекции Postman нынче одним кликом конвертируются в файлы http клиента IDEA/PyCharm/Goland, а лого отлично хранятся в VCS
Техрадар Lamoda Tech-2023: наша рефлексия о разработке и технологиях за три года