это все ни сколько не замена кук, вот даже не близко. Это все инструменты для определенных узких целей. 1. Google Privacy Sandbox заранее собранные кем-то (гуглом) непонятно как когорты юзеров, которые довольно абстрактны и на них какие-то серьезные алгоритмы таргетинга не выстроить. Про ретаргетинг можно вообще забыть. Кроме того, работает только на хроме, что отрезает половину трафика. 2. Yandex Advanced Matching - это вообще не технология по обходу третьих кук, а сервис яндекса, как часть его рекламной сети по созданию сегментов, используя номера телефонов или email. Зачем его сюда приплели, непонятно, ведь вне яндекса им не воспользуешься. Годится только для ретаргетинга, про охват новой аудитории можно забыть. 3. Unified ID 2.0 - тоже только для ретаргетинга, без охвата новой аудитории, да еще и работает через RTB (SSP/DSP), где 90+ процентов трафика - фрод.
вообщем в статье никаких нормальных альтернатив предложено не было. Вскользь, одной строкой, упоминался stable ID от "платформы", который действительно наиболее близкий вариант замены третьих кук. Но автор почему-то про него решил в детали не вдаваться. Хоть и к ним тоже есть масса вопросов, но они вне рамкок этого комментария.
Как итог своего комментария - в статье приведены инструменты, которые решают свои узкие задачи, но они ни в коей мере не являются "альтернативой кук". При этом реальные альтернативы не предложены.
учить всегда это только на старте карьеры, первые 2 года, потом попроще. Я вот по выходным трачу пару часов на чтение технической литературы по тому направлению, которое сейчас изучаю. У меня план изучения на 2 года вперед продуман. Встал с утра, умылся, попил кофе, пару часов что-то почитал и потом весь день делай что хочешь. Вечера после работы тоже свободны, при этом потихоньку в чем-то постоянно прокачиваюсь.
аутентификации, потоковой передачи данных в любую сторону, управление потоками, отмену и time-out запросов
Часть преимуществ, которые действительно значительны, уместил в половину предложения. Вся остальная статья про "преимущества" которые никакой роли не играют.
В отличие от REST, gRPC - решение, которое не зависит от платформы и языка
REST тоже не зависит от платформы и языка
в gRPC наименования полей, ожидаемых запросов и возвращаемых ответов определяется и описывается в одном месте - в файле .proto
На практике разницы практически никакой, посмотреть в документации, какую структуру создать перед кодированием в JSON или посмотреть в proto файл, какую структуру создать перед отправкой по gRPC.
Так же совершенно не раскрыл тему, где он применяется, в каких кейсах. Раз уж так, дополню из личного опыта.
gRPC отлично себя показывает в бэкенде при взаимодействии микросервисов друг с другом под высокой нагрузкой.
Тот самый protobuf, автор так и не сказал, в чем его преимущество, а оно вот в чем: перед отправкой данные запаковываются в бинарный вид и сжимаются. Эта операция легче, чем кодирование/декодирование JSON. Тут мы получаем во-первых уменьшение утилизации CPU, т.к. отсутствует кодирование/декодирование JSON, во-вторых отказываемся от передачи (пусть и сжатых в gzip) избыточных данных (всякие кавычки, двоеточия, названия параметров и т.д.), что уменьшает объем передаваемых данных, что в свою очередь уменьшает задержку и снова нагрузку на CPU.
Возможность потоковой передачи от сервера к клиенту, от клиента к серверу или в обе стороны одновременно.
Общий таймаут на всю цепочку сервисов. Например, у нас есть сервис А который принимает внешний HTTP запрос и отправляет его дальше в обработку в сервис B. "B" в свою очередь в С и т.д. Получается подобная цепочка: A->B->C->D->E, Сервис E генерирует окончательный результат и он возвращается по цепочке обратно в A. Допустим, сервис A должен вернуть ответ клиенту максимум за 1 секунду. Получается, если, например, сервис C затупил, на нем уже истекла эта секунда, сервис А прекращает ждать ответ по таймауту и возвращает клиенту ошибку, все остальные все-равно продолжают работать, сервис С, а затем D и E не знают ничего о том, что сервис А ответ уже не ждет и их работа бесполезна. В gRPC можно установить общий таймаут на всю цепочку сервисов. Если сервис А прекращает ожидание ответа, об этом узнает и сервис C и прекращает обработку запроса и не отправляет его дальше по цепочке в D и C
У gRPC клиентов из коробки доступна балансировка запросов по Round Robin. При настройке коннекта передаем несколько хостов или хост DNS, который возвращает несколько ip. В результате, клиент начинает их чередовать, поочередно отправляет запросы на разные сервера. Это позволяет не писать самостоятельно подобную балансировку на каждом клиенте (сервисе) и не ставить балансировщики перед каждым сервисом.
gRPC так же имеет в своем арсенале трассировку запросов, по ней подробно ничего не могу сказать, не использовал, т.к. привык уже работать с Jaeger, но такая возможность есть.
всю жизнь живу в Нижнем Новгороде на Автозаводском районе, могу прогуляться в том числе и ночью без какой-либо опаски, даже не задумывался никогда об этом и ни разу ничего плохого со мной не случалось. Страшно было разве что в 90-е. Тем более в центре, там кругом полиция.
stableID, который формируется каким-нибудь алгоритмом на основе косвенных данных и данных от провайдеров.
это все ни сколько не замена кук, вот даже не близко. Это все инструменты для определенных узких целей.
1. Google Privacy Sandbox заранее собранные кем-то (гуглом) непонятно как когорты юзеров, которые довольно абстрактны и на них какие-то серьезные алгоритмы таргетинга не выстроить. Про ретаргетинг можно вообще забыть. Кроме того, работает только на хроме, что отрезает половину трафика.
2. Yandex Advanced Matching - это вообще не технология по обходу третьих кук, а сервис яндекса, как часть его рекламной сети по созданию сегментов, используя номера телефонов или email. Зачем его сюда приплели, непонятно, ведь вне яндекса им не воспользуешься. Годится только для ретаргетинга, про охват новой аудитории можно забыть.
3. Unified ID 2.0 - тоже только для ретаргетинга, без охвата новой аудитории, да еще и работает через RTB (SSP/DSP), где 90+ процентов трафика - фрод.
вообщем в статье никаких нормальных альтернатив предложено не было. Вскользь, одной строкой, упоминался stable ID от "платформы", который действительно наиболее близкий вариант замены третьих кук. Но автор почему-то про него решил в детали не вдаваться. Хоть и к ним тоже есть масса вопросов, но они вне рамкок этого комментария.
Как итог своего комментария - в статье приведены инструменты, которые решают свои узкие задачи, но они ни в коей мере не являются "альтернативой кук". При этом реальные альтернативы не предложены.
то, что вы написали в статье это тоже основы основ
учить всегда это только на старте карьеры, первые 2 года, потом попроще. Я вот по выходным трачу пару часов на чтение технической литературы по тому направлению, которое сейчас изучаю. У меня план изучения на 2 года вперед продуман. Встал с утра, умылся, попил кофе, пару часов что-то почитал и потом весь день делай что хочешь. Вечера после работы тоже свободны, при этом потихоньку в чем-то постоянно прокачиваюсь.
1-2 года опыта, это скорее джун, а не мидл
так CTO и должен построить нормальные процессы, а не бежать, если до него никто их не выстроил
Автор совершенно не раскрыл тему gRPC.
Часть преимуществ, которые действительно значительны, уместил в половину предложения. Вся остальная статья про "преимущества" которые никакой роли не играют.
REST тоже не зависит от платформы и языка
На практике разницы практически никакой, посмотреть в документации, какую структуру создать перед кодированием в JSON или посмотреть в proto файл, какую структуру создать перед отправкой по gRPC.
Так же совершенно не раскрыл тему, где он применяется, в каких кейсах.
Раз уж так, дополню из личного опыта.
gRPC отлично себя показывает в бэкенде при взаимодействии микросервисов друг с другом под высокой нагрузкой.
Тот самый protobuf, автор так и не сказал, в чем его преимущество, а оно вот в чем: перед отправкой данные запаковываются в бинарный вид и сжимаются. Эта операция легче, чем кодирование/декодирование JSON. Тут мы получаем во-первых уменьшение утилизации CPU, т.к. отсутствует кодирование/декодирование JSON, во-вторых отказываемся от передачи (пусть и сжатых в gzip) избыточных данных (всякие кавычки, двоеточия, названия параметров и т.д.), что уменьшает объем передаваемых данных, что в свою очередь уменьшает задержку и снова нагрузку на CPU.
Возможность потоковой передачи от сервера к клиенту, от клиента к серверу или в обе стороны одновременно.
Общий таймаут на всю цепочку сервисов. Например, у нас есть сервис А который принимает внешний HTTP запрос и отправляет его дальше в обработку в сервис B. "B" в свою очередь в С и т.д. Получается подобная цепочка: A->B->C->D->E, Сервис E генерирует окончательный результат и он возвращается по цепочке обратно в A. Допустим, сервис A должен вернуть ответ клиенту максимум за 1 секунду. Получается, если, например, сервис C затупил, на нем уже истекла эта секунда, сервис А прекращает ждать ответ по таймауту и возвращает клиенту ошибку, все остальные все-равно продолжают работать, сервис С, а затем D и E не знают ничего о том, что сервис А ответ уже не ждет и их работа бесполезна.
В gRPC можно установить общий таймаут на всю цепочку сервисов. Если сервис А прекращает ожидание ответа, об этом узнает и сервис C и прекращает обработку запроса и не отправляет его дальше по цепочке в D и C
У gRPC клиентов из коробки доступна балансировка запросов по Round Robin. При настройке коннекта передаем несколько хостов или хост DNS, который возвращает несколько ip. В результате, клиент начинает их чередовать, поочередно отправляет запросы на разные сервера. Это позволяет не писать самостоятельно подобную балансировку на каждом клиенте (сервисе) и не ставить балансировщики перед каждым сервисом.
gRPC так же имеет в своем арсенале трассировку запросов, по ней подробно ничего не могу сказать, не использовал, т.к. привык уже работать с Jaeger, но такая возможность есть.
всю жизнь живу в Нижнем Новгороде на Автозаводском районе, могу прогуляться в том числе и ночью без какой-либо опаски, даже не задумывался никогда об этом и ни разу ничего плохого со мной не случалось. Страшно было разве что в 90-е. Тем более в центре, там кругом полиция.
Покупать новостройку на краю города и жить как на стройке лет 5 тоже такое себе