Благодарим, что изучили нашу статью и оставили обратную связь.
Мы считаем, что работа UX/UI-дизайнера не ограничивается только крупными платформами, такими как Telegram или Яндекс. Многим лендингам также требуется продуманный пользовательский опыт. Особенно для образовательных продуктов и презентации стартапов. Грамотная UX/UI-архитектура помогает повышать конверсию и удерживает внимание аудитории.
Многие тренды действительно начинаются как узкопрофильные решения. Но они показывают направление развития индустрии и инструменты, которые, возможно, через пару лет станут стандартами. Поэтому мы и не говорим про универсальные подходы, а рассказываем, какой тренд применим для продуктов в разных категориях.
Что касается AI в дизайне, то в нашем тренд репорте как раз и сделан вывод, что искусственный интеллект пока что не может заменить реального дизайнера. Но те, кто его используют, получают больше конкурентных преимуществ.
Спасибо за ваш комментарий! Действительно, ни Facebook Marketplace, ни eBay позиционируют себя как чисто P2P-платформы — это модели C2C, где присутствует определённый уровень централизованного контроля и защиты. В нашей статье мы рассматриваем P2P как формат, где участники взаимодействуют напрямую, без значительного вмешательства платформы. Это создаёт свои вызовы, особенно в управлении рисками. Вот как мы решаем ключевые проблемы в P2P:
Верификация и репутация. Мы создаём систему проверки участников с помощью технологий (например, машинное обучение для поиска подозрительных действий) и ручной модерации. Это помогает увеличить доверие между пользователями.
Прозрачность сделок. В отличие от C2C, где платформа решает конфликты, в P2P важно, чтобы участники могли сами оценивать надёжность друг друга. Поэтому мы внедряем рейтинги, отзывы и взаимные гарантии.
Управление рисками. Прямые сделки требуют особого подхода. Мы используем технологии для анализа транзакций и проводим обучение пользователей, чтобы они знали о возможных рисках.
Собственная экосистема безопасности. Хотя у крупных C2C-платформ, таких как eBay или FB, есть команды, специализирующиеся на разрешении споров, мы создаём специальные механизмы поддержки, которые адаптированы под особенности P2P — от арбитражных процедур до дополнительных гарантий для наиболее уязвимых участников.
Наш подход гибкий и нацелен на создание максимально безопасной и прозрачной среды для всех участников.
Next.js имеет собственные настройки кэширования, информацию о которых можно найти в официальной документации - https://nextjs.org/docs/pages/api-reference/components/image#caching-behavior А чтобы уменьшить нагрузку на сервер, можно использовать статический рендеринг, который сейчас пропагандирует Vercel в последних версиях. Так же можно делать кэширование в сторе, к примеру redux, либо можно использовать http-кэширование.
писали бы на React.js. Для бэка бы подключили просто orval для автогенерации если дока есть. Если не то без него, более ничего не нужно. А так в целом на любом фреймворке же можно, что на Vue, что на Svelte
Ну точно так же из строя может выйти облачный managed сервис. Или если развернуть кубер руками, взять 3 ноды, то и все 3 могут сгореть, в одном большом пожаре.
По факту, современные сервера очень надежные, и просто так из строя не выходят, возможно в очень редких случаях.
Ключевое же в такой ситуации сохранить именно данные (бд и файлы), но это уже другая большая тема. К тому же куберу обычно базу разворачивают отдельно. Точно так же можно сделать и для компоуза.
Как и написано в статье, кубер поднимался через microk8s. Для дева можно было бы перейти на managed, но это дополнительные деньги. А клиенты многие приходят с требованиями по хостингу/ос . Там нет возможности взять managed решение.
По поводу ресурсов. После перехода с кубера нагрузка упала в 2 раза. Может дело в microk8s, а может в самом кубере.
вы не поверите, для надежной работы любого кластера нужно больше одной ноды
Дело в том, что для 95% клиентов кластер то и не нужен, 4/8 сервер справляется с нагрузкой. И на одной ноде компоуз работает без проблем, с кубером постоянно проблемы были. То крон зависнет намертво, то еще что-то.
ну никто же не заставляет
А потом выясняется, что есть проблемы с безопасностью. Например, по такому пути :10255/pods кубер светил env переменные и другие данные подов. Да и в целом, вносятся изменения, которые облегчают жизнь.
И да, docker compose ни разу не альтернатива kubernetes.
Согласен, но базовая задача управление контейнерами докера, чем оба инструмента и занимаются. Конечно, кубер это комбайн с кучей функций, которых лишен компоуз. Но не всем они нужны. Ну и в целом, чем система проще, тем она надежнее)
Не хотелось после кубернетес погружается в еще один оркестратор, который к тому же гораздо менее популярный. Как следствие меньше информации в интернете. А опыт с чистым compose оказался удачным, проблем практически не возникало в работе, по этому нем и остановились на данный момент.
Но делать законченное продакшн решение это проект и это дорого,
Да, согласен. Но у нас решение получилось чисто под наши задачи, и только для тестового окружения. Работает уже 9 месяцев, без проблем) периодически что-то туда дописываем.
в десяток строчек на bash
Думаю строчек было бы больше. Либо разбивать на множество скриптов. Поднять деплой, очистить, склонировать базу данных, создать базу данных для нового деплоя, крон задачи. Да и крон пришлось бы тогда в системе использовать либо еще что-то изобретать.
А так у нас супер легкий клиент, который почти ничего не делает, и сервер который все умеет, собранный в один бинарник. Внутри него и крон и работа с бд. Не вижу никакого преимущества в скриптах перед этим...
Вообще, за идею я взял кубер как раз. Где есть клиент (kubectl), который по http доставляет конфигурацию на сервер, а он уже с ней работает
а зачем нужно было использовать два бинарника на гоу, если тоже самое вроде как можно сделать внутри gitlab-ci.yml без использования утилиты taskfile.dev
Каким образом?
И второй вопрос с миграциями БД: как решено то, что некоторые миграции могут сломать работающее приложение?
Ну это не проблема инструмента деплоя. А вообще если миграция развернулась на деве, то развернется и на проде. Схема базы одинаковая. Не помню с этим никаких проблем
Хотя если процесс деплоя на дев и на прод сильно различаются (например, используют разные инструменты), то это тоже не хорошо.
Инструменты действительно разные, но в целом суть похожа. На проде первичная настройка идет в ручном режиме. Далее уже рабочее приложение обновляется через ci/cd . Это не занимает на самом деле много времени, при этом дает гибкость.
Да, у нас сейчас и есть wildcard, от letsencrypt. Но кроме выдачи сертефиката, traefik еще и динамический роутинг дает, смотрит на labels контейнеров и направляет на них трафик.
Ну и еще вот в одном проекте стояла задача, когда нужно было выделить разные поддомены, например by.myfeature.test.company.com . wildcard бы отвалился, но traefik самостоятельно выдал обычный letsencrypt сертефикат
О я бы наверное про это отдельно написал, уже не как перевод) Мы мне кажется через многие ситуации уже прошли. Было бы круто, если бы накидали сюда своих историй и болей, а я бы со стороны работодателя раскрыл видение.
Вот вы классный момент заметили, когда «работник вкалывает сверхнормы и не требует за это ничего(а работодатель и не дает)»
Итог в конце, репозиторий работает, нейросети претензии передадим 🫡
И правда - добавили тэг!
В точку!
завидуем 😔
а потом оказывается, что все доносы от Grok попадают в Спам))
Благодарим, что изучили нашу статью и оставили обратную связь.
Мы считаем, что работа UX/UI-дизайнера не ограничивается только крупными платформами, такими как Telegram или Яндекс. Многим лендингам также требуется продуманный пользовательский опыт. Особенно для образовательных продуктов и презентации стартапов. Грамотная UX/UI-архитектура помогает повышать конверсию и удерживает внимание аудитории.
Многие тренды действительно начинаются как узкопрофильные решения. Но они показывают направление развития индустрии и инструменты, которые, возможно, через пару лет станут стандартами. Поэтому мы и не говорим про универсальные подходы, а рассказываем, какой тренд применим для продуктов в разных категориях.
Что касается AI в дизайне, то в нашем тренд репорте как раз и сделан вывод, что искусственный интеллект пока что не может заменить реального дизайнера. Но те, кто его используют, получают больше конкурентных преимуществ.
Спасибо за ваш комментарий! Действительно, ни Facebook Marketplace, ни eBay позиционируют себя как чисто P2P-платформы — это модели C2C, где присутствует определённый уровень централизованного контроля и защиты. В нашей статье мы рассматриваем P2P как формат, где участники взаимодействуют напрямую, без значительного вмешательства платформы. Это создаёт свои вызовы, особенно в управлении рисками. Вот как мы решаем ключевые проблемы в P2P:
Верификация и репутация. Мы создаём систему проверки участников с помощью технологий (например, машинное обучение для поиска подозрительных действий) и ручной модерации. Это помогает увеличить доверие между пользователями.
Прозрачность сделок. В отличие от C2C, где платформа решает конфликты, в P2P важно, чтобы участники могли сами оценивать надёжность друг друга. Поэтому мы внедряем рейтинги, отзывы и взаимные гарантии.
Управление рисками. Прямые сделки требуют особого подхода. Мы используем технологии для анализа транзакций и проводим обучение пользователей, чтобы они знали о возможных рисках.
Собственная экосистема безопасности. Хотя у крупных C2C-платформ, таких как eBay или FB, есть команды, специализирующиеся на разрешении споров, мы создаём специальные механизмы поддержки, которые адаптированы под особенности P2P — от арбитражных процедур до дополнительных гарантий для наиболее уязвимых участников.
Наш подход гибкий и нацелен на создание максимально безопасной и прозрачной среды для всех участников.
Next.js имеет собственные настройки кэширования, информацию о которых можно найти в официальной документации - https://nextjs.org/docs/pages/api-reference/components/image#caching-behavior
А чтобы уменьшить нагрузку на сервер, можно использовать статический рендеринг, который сейчас пропагандирует Vercel в последних версиях. Так же можно делать кэширование в сторе, к примеру redux, либо можно использовать http-кэширование.
писали бы на React.js. Для бэка бы подключили просто orval для автогенерации если дока есть. Если не то без него, более ничего не нужно. А так в целом на любом фреймворке же можно, что на Vue, что на Svelte
Ну точно так же из строя может выйти облачный managed сервис. Или если развернуть кубер руками, взять 3 ноды, то и все 3 могут сгореть, в одном большом пожаре.
По факту, современные сервера очень надежные, и просто так из строя не выходят, возможно в очень редких случаях.
Ключевое же в такой ситуации сохранить именно данные (бд и файлы), но это уже другая большая тема. К тому же куберу обычно базу разворачивают отдельно. Точно так же можно сделать и для компоуза.
Как и написано в статье, кубер поднимался через microk8s. Для дева можно было бы перейти на managed, но это дополнительные деньги. А клиенты многие приходят с требованиями по хостингу/ос . Там нет возможности взять managed решение.
По поводу ресурсов. После перехода с кубера нагрузка упала в 2 раза. Может дело в microk8s, а может в самом кубере.
Дело в том, что для 95% клиентов кластер то и не нужен, 4/8 сервер справляется с нагрузкой. И на одной ноде компоуз работает без проблем, с кубером постоянно проблемы были. То крон зависнет намертво, то еще что-то.
А потом выясняется, что есть проблемы с безопасностью. Например, по такому пути :10255/pods кубер светил env переменные и другие данные подов. Да и в целом, вносятся изменения, которые облегчают жизнь.
Согласен, но базовая задача управление контейнерами докера, чем оба инструмента и занимаются. Конечно, кубер это комбайн с кучей функций, которых лишен компоуз. Но не всем они нужны. Ну и в целом, чем система проще, тем она надежнее)
Не хотелось после кубернетес погружается в еще один оркестратор, который к тому же гораздо менее популярный. Как следствие меньше информации в интернете. А опыт с чистым compose оказался удачным, проблем практически не возникало в работе, по этому нем и остановились на данный момент.
Да, согласен. Но у нас решение получилось чисто под наши задачи, и только для тестового окружения. Работает уже 9 месяцев, без проблем) периодически что-то туда дописываем.
Думаю строчек было бы больше. Либо разбивать на множество скриптов. Поднять деплой, очистить, склонировать базу данных, создать базу данных для нового деплоя, крон задачи. Да и крон пришлось бы тогда в системе использовать либо еще что-то изобретать.
А так у нас супер легкий клиент, который почти ничего не делает, и сервер который все умеет, собранный в один бинарник. Внутри него и крон и работа с бд. Не вижу никакого преимущества в скриптах перед этим...
Вообще, за идею я взял кубер как раз. Где есть клиент (kubectl), который по http доставляет конфигурацию на сервер, а он уже с ней работает
Только с v2, но он же устаревший
Каким образом?
Ну это не проблема инструмента деплоя. А вообще если миграция развернулась на деве, то развернется и на проде. Схема базы одинаковая. Не помню с этим никаких проблем
Инструменты действительно разные, но в целом суть похожа. На проде первичная настройка идет в ручном режиме. Далее уже рабочее приложение обновляется через ci/cd . Это не занимает на самом деле много времени, при этом дает гибкость.
Это не работает без swarm
Да, у нас сейчас и есть wildcard, от letsencrypt. Но кроме выдачи сертефиката, traefik еще и динамический роутинг дает, смотрит на labels контейнеров и направляет на них трафик.
Ну и еще вот в одном проекте стояла задача, когда нужно было выделить разные поддомены, например by.myfeature.test.company.com . wildcard бы отвалился, но traefik самостоятельно выдал обычный letsencrypt сертефикат
Кубер хорошо работает если брать его в облаках, самому же поднимать на голом железе то еще удовольствие, да и стабильность куда ниже.
А вот использовать облака не всегда есть возможность, некоторые клиенты приходят с запросом на определенный хостинг или даже ОС
Вот вы классный момент заметили, когда «работник вкалывает сверхнормы и не требует за это ничего(а работодатель и не дает)»