статья скорее о том, как делать не надо. Не удивительно, что при настолько маленькой нагрузке, все начало лагать.
Статья будет полезна тем, кто работает с FastAPI, микросервисами и думает о надежности и масштабируемости своих систем.
что происходит, когда приложение падает? Ждет, пока вы придете и пнете его? Или все-таки развернут какой-нибудь k8s?
Как это деплоится, как обеспечивается бесшовный деплой.
С помощью каких инструментов происходит мониторинг, алертинг?
т.к. вы говорите про "стабильную работу", как обеспечивается отказоустойчивость БД? Как сконфигурирован кластер и что происходит в случае отказа одной из нод?
Технически, для 18-летнего парня на самом деле сделано неплохо, но это далеко не профессиональный уровень, как вы пытаетесь это выдать. Хороший пет проект, для получения большого количества опыта, это круто на самом деле. Но это не уровень для написания статей на хабре, где многие читатели сами работают с нагрузками выше в тысячи раз.
Лично мне, гораздо интереснее было б почитать со стороны маркетинга, как именно вы добились такой пользовательской базы, что получаете 200к запросов в сутки. Вот это реально крутое достижение для 18 летнего парня и именно об этом вам лучше писать.
Когда увидел заголовок статьи, подумал, что тут что-то про алгоритмы машинного обучения в трейдинге, с примерами реализации нейросетей и их тестирования, добавил в закладки, чтобы прочитать потом такую интересную статью. А когда добрались руки и прочитал, тут просто промпт в дип сик...
Ладно б еще хотябы стратегия была интересной, а тут даже сам автор говорит, что она бесполезна.
Бесполезная статья про бесполезный промпт, которая видимо сама написана дипсик-ом
это все ни сколько не замена кук, вот даже не близко. Это все инструменты для определенных узких целей. 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-е. Тем более в центре, там кругом полиция.
ну давайте пойдем дальше тогда. Пусть каждый школяр пишет о том, как он делал домашку по информатике с помощью chatGPT, раз ориентиров не должно быть.
статья скорее о том, как делать не надо. Не удивительно, что при настолько маленькой нагрузке, все начало лагать.
что происходит, когда приложение падает? Ждет, пока вы придете и пнете его? Или все-таки развернут какой-нибудь k8s?
Как это деплоится, как обеспечивается бесшовный деплой.
С помощью каких инструментов происходит мониторинг, алертинг?
т.к. вы говорите про "стабильную работу", как обеспечивается отказоустойчивость БД? Как сконфигурирован кластер и что происходит в случае отказа одной из нод?
Технически, для 18-летнего парня на самом деле сделано неплохо, но это далеко не профессиональный уровень, как вы пытаетесь это выдать. Хороший пет проект, для получения большого количества опыта, это круто на самом деле. Но это не уровень для написания статей на хабре, где многие читатели сами работают с нагрузками выше в тысячи раз.
Лично мне, гораздо интереснее было б почитать со стороны маркетинга, как именно вы добились такой пользовательской базы, что получаете 200к запросов в сутки. Вот это реально крутое достижение для 18 летнего парня и именно об этом вам лучше писать.
Когда увидел заголовок статьи, подумал, что тут что-то про алгоритмы машинного обучения в трейдинге, с примерами реализации нейросетей и их тестирования, добавил в закладки, чтобы прочитать потом такую интересную статью. А когда добрались руки и прочитал, тут просто промпт в дип сик...
Ладно б еще хотябы стратегия была интересной, а тут даже сам автор говорит, что она бесполезна.
Бесполезная статья про бесполезный промпт, которая видимо сама написана дипсик-ом
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 тоже такое себе