вот только его все забывают выпиливать и этот ком растет

Ну релиз инженер выполнил миграции. Текущая версия на проде ломается что ли до апдейта?

он руками выполняет их

Да похер как) я не о том спрашиваю)

:)

о том, он руками выполняет миграции в том порядке, что бы не ломалось... или вообще заворачивает релиз если там альтер жуткий

Нахуй нужен такой релиз менеджер)

о том, он руками выполняет миграции в том порядке, что бы не ломалось... или вообще заворачивает релиз если там альтер жуткий

Он и код приложения знает?

Или ты о поломке базы?

Мы просто о поломке приложения после изменения базы

он может спросить релизера если что

Чет по описанию вы себе на ровной протоптанной тропинке проблем придумали, имхо

А миграции которые ломают базу это полный пиздец

Тем более если они дошли до релиза

мы не о ломании, а о правильном их порядке относительно релиза кода

У нас например часто бывает зарелизили потом ой надо откатить, чета не то

и о потенциально просаживающих производительнось особо

Откатываем

А сайт надо чтобы без даунтайма все это время

Пока раскатывается новая версия на несколько серверов, бывают обновляешь страницу и тебе то старая то новая

Тут полюбому надо так делать нам, чтобы код без миграции работал правильно

код не сломается, если будет лишняя колонка

Да, в случае удаления колонки все верно. Но например такая ситуация: зарелизили, удалили колонку, а через 15 мин поняли что надо откатить релиз

Поэтому я обычно удаляю колонку уже назавтра в другом релизе

А в случае добавления нового поля сложнее: надо 100% сначала накатывать миграцию с новым полем, а потом код, который его юзает

ну да, только у нас не программисты следят за этим, а девопсы

У нас тоже

Интереснее вопрос как сделать тяжелый алтер без даунтайма

и один файл миграции могут исполнить в разном порядке или вообще не исполнить

Не делать альтер :)

Не делать альтер :)

Ну да

В каком мире ты живёшь ?)

У нас бывает на 2-3 минуты альтеры, мы просто по живому делаем и миримся с локами таблицы на 2-3 минуты

Очень редко

Интереснее вопрос как сделать тяжелый алтер без даунтайма

есть такая методика с копированием всего

А если альтер 15-20 минут

есть такая методика с копированием всего

И процедурками?

Ну надо придумывать исходя из ситуации

Тут общего решения наврядли будет

угу, тригера для догона и потом ренейм

В идеале если 24/7 не надо, можно ночью сайт приложить

Как онлайнер делал

В идеале если 24/7 не надо, можно ночью сайт приложить

И делает )

Мы иногда тоже прикладываем в 6 утра когда очень надо

Если на америкосов работать то даже ночами не придётся не спать :)

Удобно

Но наверное есть проекты кому нельзя так

Там придумывают что-то

Есть конечно

Ну вот выше описали кейс

Мне не приходилось

Но мы так по-моему ни разу не делали

Не ну если можно уйти в даун то зачем

Наверное кучу методик можно придумать

Самая простая - не делать альтеры

Можно в коде придумывать разные воркэраунды

Новая таблица там

Конечно если инт на бигинт поменять, наврядли это спасет :)

ну или варчар расширить, да

Я могу представить себе очень хорошо ситуацию когда просто скажешь так не будем делать

Бизнес говорит - хотим 512 вместо 256 поле

А программисты такие уууууу

Там таблица на 10 млрд записееей...

Не, не будем это делать

И бизнес такой Okaaaay =(

И нету проблемы миграции

почему не будете? Вон ребята из соседней фирмы делают это каждую неделю? - а мы не умеем и учиться не хотим - а, ну ок... Прошло две недели...

ERROR: S client not available

Не ну бывает всякое

Просто если отдел разработк связан с бизнесом, у них одинаковые приоритеты в итоге, и получается ты не говоришь конечно не будем это делать, а по факту говоришь ну мы конечно можем если очень надо, но это будет... Это будет... 300! И бизнес такой ой не очень-то уже и хотелось, давайте лучше другую фичу в это время запилите

https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html

Всем привет. Предположим, есть достаточно большой проект, сердцем которого является некое API. Технологии не важны, но для контекста: PHP7 и GraphQL. Далее есть некие клиенты, которые работают с API: CLIENT1 - панель управления (админка) / ReactJS CLIENT2 - клиент для гостей / PHP CLIENT3 - личный кабинет для зарегистрированных / ReactJS CLIENT4 - блог / PHP ... Сейчас аутентификация пользователя на API происходит через JWT-token. Если вкратце, то мы делаем некий запрос с логином и паролем, получаем некий токен и с помощью него делаем уже авторизованные запросы. Далее я столкнулся со следующим вопросом: а как аутентифицировать клиенты? API имеет ряд запросов, которые не покрывает JWT, тоесть данные по этим запросам можно получить без аутентификации. Например пользователь заходит на CLIENT4, CLIENT4 в свою очередь делает запрос на API, получает список статей и показывает их пользователю (пользователь может быть гостем). Тут все верно. Однако остается и такой вариант, когда пользователь может миновать CLIENT4, сделать запрос к API и получить данные на прямую. Вопрос заключается в том, как лучше всего закрыть API от всех прямых запросов и дать доступ только определенным клиентам? ———————————————————————————- Некоторые дополнительные размышления. Хорошим и безопасным вариантом было бы ограничить доступ и сделать API локальным, однако некоторые клиенты могут быть на другом сервере или требовать внешний доступ (например мобильные устройства). Я отказался от использования протокола OAuth2, так-как по сути в проекте нет 3 стороны. Поэтому получается не совсем то, что нужно. Единственный вариант пока приходит в голову, это некий дополнительный токен, который хранит каждый клиент и получает доступ к API подставляя в каждый запрос. Собственно хотелось бы получить советы/рекомендации, возможно ссылки на технологии/протоколы, которые упустил.

у перконы там прикольные тулзы) на любое кол-во голов раскидывает быстро и прозрачно даже по меркам мускуля)

Всем привет. Предположим, есть достаточно большой проект, сердцем которого является некое API. Технологии не важны, но для контекста: PHP7 и GraphQL. Далее есть некие клиенты, которые работают с API: CLIENT1 - панель управления (админка) / ReactJS CLIENT2 - клиент для гостей / PHP CLIENT3 - личный кабинет для зарегистрированных / ReactJS CLIENT4 - блог / PHP ... Сейчас аутентификация пользователя на API происходит через JWT-token. Если вкратце, то мы делаем некий запрос с логином и паролем, получаем некий токен и с помощью него делаем уже авторизованные запросы. Далее я столкнулся со следующим вопросом: а как аутентифицировать клиенты? API имеет ряд запросов, которые не покрывает JWT, тоесть данные по этим запросам можно получить без аутентификации. Например пользователь заходит на CLIENT4, CLIENT4 в свою очередь делает запрос на API, получает список статей и показывает их пользователю (пользователь может быть гостем). Тут все верно. Однако остается и такой вариант, когда пользователь может миновать CLIENT4, сделать запрос к API и получить данные на прямую. Вопрос заключается в том, как лучше всего закрыть API от всех прямых запросов и дать доступ только определенным клиентам? ———————————————————————————- Некоторые дополнительные размышления. Хорошим и безопасным вариантом было бы ограничить доступ и сделать API локальным, однако некоторые клиенты могут быть на другом сервере или требовать внешний доступ (например мобильные устройства). Я отказался от использования протокола OAuth2, так-как по сути в проекте нет 3 стороны. Поэтому получается не совсем то, что нужно. Единственный вариант пока приходит в голову, это некий дополнительный токен, который хранит каждый клиент и получает доступ к API подставляя в каждый запрос. Собственно хотелось бы получить советы/рекомендации, возможно ссылки на технологии/протоколы, которые упустил.

В чём проблема запихнуть название/идентификатор клиента в сам токен?

В чём проблема запихнуть название/идентификатор клиента в сам токен?

в том, что некоторые данные можно/нужно получать без аутентификации пользователя.

@oldenby ^^^

в том, что некоторые данные можно/нужно получать без аутентификации пользователя.

то есть, их можно получить, но ты хочешь, чтобы нельзя было?

в том, что некоторые данные можно/нужно получать без аутентификации пользователя.

Тогда в хедерах отправлять, x-client-id какой-то, в каждом клиенте свой прописать

то есть, их можно получить, но ты хочешь, чтобы нельзя было?

чтобы их можно было получать только через определенные клиенты (мобилы, планшеты, десктоп и тп.)

Тогда в хедерах отправлять, x-client-id какой-то, в каждом клиенте свой прописать

как быть, если токен будет скомпромитирован ?

ну просто в случае с блогом - у тебя априори нет какого-либо токена можно, конечно, извратиться с чем-то вроде csrf токена...

Мне кажется OAuth2 можно было бы юзать, в нем есть понятие сервер креденшелс, можно получить токен как с креденшелами юзера, так и с креденшелами сервера

Соответственно, разные права им раздавать

Я бы наверное сюда смотрел

ну либо я чего-то не понимаю

Всем привет. Предположим, есть достаточно большой проект, сердцем которого является некое API. Технологии не важны, но для контекста: PHP7 и GraphQL. Далее есть некие клиенты, которые работают с API: CLIENT1 - панель управления (админка) / ReactJS CLIENT2 - клиент для гостей / PHP CLIENT3 - личный кабинет для зарегистрированных / ReactJS CLIENT4 - блог / PHP ... Сейчас аутентификация пользователя на API происходит через JWT-token. Если вкратце, то мы делаем некий запрос с логином и паролем, получаем некий токен и с помощью него делаем уже авторизованные запросы. Далее я столкнулся со следующим вопросом: а как аутентифицировать клиенты? API имеет ряд запросов, которые не покрывает JWT, тоесть данные по этим запросам можно получить без аутентификации. Например пользователь заходит на CLIENT4, CLIENT4 в свою очередь делает запрос на API, получает список статей и показывает их пользователю (пользователь может быть гостем). Тут все верно. Однако остается и такой вариант, когда пользователь может миновать CLIENT4, сделать запрос к API и получить данные на прямую. Вопрос заключается в том, как лучше всего закрыть API от всех прямых запросов и дать доступ только определенным клиентам? ———————————————————————————- Некоторые дополнительные размышления. Хорошим и безопасным вариантом было бы ограничить доступ и сделать API локальным, однако некоторые клиенты могут быть на другом сервере или требовать внешний доступ (например мобильные устройства). Я отказался от использования протокола OAuth2, так-как по сути в проекте нет 3 стороны. Поэтому получается не совсем то, что нужно. Единственный вариант пока приходит в голову, это некий дополнительный токен, который хранит каждый клиент и получает доступ к API подставляя в каждый запрос. Собственно хотелось бы получить советы/рекомендации, возможно ссылки на технологии/протоколы, которые упустил.

Может зарегать клиентов у себя в базе, дать им private public ключи, и далее проводить аутентификацию с помощью них? по публичному токену аутентифициурешь клиента, по приватному проверяешь подлинность подписи.

Все спасибо, что-то в голове сфорировалось =)

фичефлаги далеко не всегда возможны и замусоривают код

приведи пример когда не всегда возможны

и да - не замусоривают код) елси грамотно делать)

У нас фичефлаги в проекте работают через тот же механизм, что и разделение по разным прайс планам фич, поэтому получается очень аккуратно в итоге, сначала фича делается, потом добавляется некоторым клиентам, потом какому-то прайс плану

В целом по нашему проекту я бы не сказал, чтобы мы очень страдали от этого

@oldenby ^^^

Я все пропустил )

Всем привет. Предположим, есть достаточно большой проект, сердцем которого является некое API. Технологии не важны, но для контекста: PHP7 и GraphQL. Далее есть некие клиенты, которые работают с API: CLIENT1 - панель управления (админка) / ReactJS CLIENT2 - клиент для гостей / PHP CLIENT3 - личный кабинет для зарегистрированных / ReactJS CLIENT4 - блог / PHP ... Сейчас аутентификация пользователя на API происходит через JWT-token. Если вкратце, то мы делаем некий запрос с логином и паролем, получаем некий токен и с помощью него делаем уже авторизованные запросы. Далее я столкнулся со следующим вопросом: а как аутентифицировать клиенты? API имеет ряд запросов, которые не покрывает JWT, тоесть данные по этим запросам можно получить без аутентификации. Например пользователь заходит на CLIENT4, CLIENT4 в свою очередь делает запрос на API, получает список статей и показывает их пользователю (пользователь может быть гостем). Тут все верно. Однако остается и такой вариант, когда пользователь может миновать CLIENT4, сделать запрос к API и получить данные на прямую. Вопрос заключается в том, как лучше всего закрыть API от всех прямых запросов и дать доступ только определенным клиентам? ———————————————————————————- Некоторые дополнительные размышления. Хорошим и безопасным вариантом было бы ограничить доступ и сделать API локальным, однако некоторые клиенты могут быть на другом сервере или требовать внешний доступ (например мобильные устройства). Я отказался от использования протокола OAuth2, так-как по сути в проекте нет 3 стороны. Поэтому получается не совсем то, что нужно. Единственный вариант пока приходит в голову, это некий дополнительный токен, который хранит каждый клиент и получает доступ к API подставляя в каждый запрос. Собственно хотелось бы получить советы/рекомендации, возможно ссылки на технологии/протоколы, которые упустил.

Вот тут

приведи пример когда не всегда возможны

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

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

Плохо представляю как фичатоглы ведут к конфликтам...

ну и когда у тебя то что ты описал - что-то идет не так. Тоглы обычно юзаются только на UI

где все красиво можно разделить на компоненты

а если у тебя большая команда и много людей тыкаются в одинаковых местах - опять же проблемы разделения задач между людьми и планирования

(или разделения проекта на модули)

ну т.е. если нет UI - нет фичефлагов?