0: Друзья, в этом ролике вы увидите запись открытого эфира по теме 5 слоёв кэширования в веб приложениях, который прошёл совсем недавно в нашей школе пайтекс, школа, пайтон, разработки мы готовим сильных инженеров со знанием python, джуниор, джуниор плюс мидл специалистов.

1: И перед началом, конечно же скажу, что все слайды, весь код, все можно забрать по ссылочке в описании в нашем telegram ботье, чтобы у вас не потерялся этот материал, потому что он классный, интересный и ценный, там собрано просто все вместе воедино и конечно приглашаем вас на наше образо.

2: Продукты это курс по бэкенд, разработке, где более 40 часов образовательных материалов можно удобно совмещать с работой и закрывать абсолютно все пробелы, которые накопились в рамках самостоятельного обучения. Вся программа обучения, все отзывы учеников.

3: На сайте ещё чуть позже, в ходе эфира, я расскажу о нашем курсе по backend разработке, а также приглашаю вас на курс по ооп, продвинутое ооп в python, который совсем недавно появился, который прошло уже множество учеников, у нас есть первые отзывы от ребят, кто прошёл и, конечно, приглашаю вас.

4: Наш сайт пайтекс точка скул. Там можно начать курсы бесплатно посмотреть, как мы обучаем, какие темы мы даём, насколько глубоко, как происходит взаимодействие с кураторами наставниками и все в таком духе. Друзья, желаю вам приятного просмотра. Не забывайте подписываться на наши соцсет.

5: На YouTube telegram, чтобы не пропускать подобные эфиры и онлайн вживую задавать свои вопросы друзья, всем привет, как меня слышно, как видно, поставьте плюсик в чат, если все хорошо.

6: Да, всем привет. Всем привет. Давайте тоже перекличку проведём. Кто из какого города смотрит.

7: Кто откуда вообще?

8: Так слышно получше в этот раз, да, друзья, в этот раз микрофон должен быть чуть чуть лучше, что ли?

9: Ростов-на-Дону.

10: Спб. Привет спб. Питер ленинград окей.

11: Ленинград, окей, Архангельск, Новокузнецк, Москва супер, друзья супер.

12: Интересно, есть ли тот, у кого сейчас ночь. А вот Краснодар, а нет, не Краснодар, Красноярск. В общем, о, Воркута, Тюмень. Всем привет, друзья. Давайте пока собираться. Чуть чуть пообщаемся, познакомимся.

13: Так, запись вебинара на YouTube не знаю, записи пока не планируем никуда выкладывать только прямой эфир.

14: Да, друзья, да. Напишите ещё работаете или нет. И какая у вас специальность там, даже если учитесь, там учусь на разработчика, на аналитика, на девопса, на ещё кого-либо.

15: Окей.

16: Так, it аналитик кьюэй кьюэй. Круто.

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

18: Middle backend. Фулстек. Девопс супер.

19: Работаю на заводе, но учусь на разработчика кайф инженер фулстек.

20: Ok, python, кстати, даже не так много python.

21: Москва питон разработчик.

22: Да, друзья, сегодня тоже постараюсь говорить, что спрашивают на собеседованиях, какие вопросы, потому что сегодня разбирать будем довольно много материала. И понятное дело, что часть из него больше идёт для каких-то глубинных знаний, для фундамента, а часть спрашивают на собеседованиях. Я

23: Стараюсь подчёркивать, где, где, что спрашивается, а где, что, просто нужно знать, чтобы реально работать и строить большие классные приложения. Окей, бедет.

24: Python, python окей, так нет звука у кого-то друзья, а вы меня не слышите, че я буду вам говорить?

25: Да, логично.

26: Да, всем, всем привет, друзья. Сейчас пару минут подождём и будем начинать. Сегодня тема очень необычная. Я думаю, редко когда, ну, вообще редко об этой теме вообще говорят про кэширование. Так, более того, в контексте веб приложений. То есть 1

27: Дело про backend и про редис, а другое дело понять а где ещё можно данные кэшировать. И самое удивительное, что именно разработчики за это ответственны там ну иногда девопсы, иногда разработчики, иногда фронте.

28: Но чаще всего бэкендеры. Артём, привет. Как настрой на занятие настрой? Классный настрой. Супер.

29: Так, давайте ещё подождём пару минут, ещё, пока народ соберётся.

30: Ого, кто-то на делфи прогает. Окей. Я кстати тоже на делфи учился в школе, у нас там там пару занятий было все что все что было с делфи.

31: Да, друзья, давайте ещё минуточку и начнём. Поздно ли в 15 лет войти в айти? Ну, это смешной вопрос, конечно, поздно.

32: Да, всем привет, друзья.

33: Хочется больше взаимодействия с чатом. Хорошо, друзья, постараюсь побольше вас спрашивать, что-нибудь, какие-нибудь задачки давать?

34: Так, окей, супер. Давайте ещё секунд 30 и начнём уже. Начнём уже ближе, ближе к делу, ближе к теме.

35: Будут ли примеры кода? Будет несколько примеров кода таких, скажем, базовых, просто чтобы понять, как это выглядит, да, то есть я не хочу абстрактно что-то давать, я покажу примеры, но без того, что мы будем че то кодить, прям большое.

36: Окей, ладно, друзья. 18 0 1. Предлагаю начинать. Кто не подтянулся. В общем, подтянется. Так, презенташка работает. Ну что, друзья, всех приветствую. Сегодня у нас пройдёт открытый урок по теме 5 слоёв кэширования.

37: Веб приложениях, сделаем упор именно на веб приложения и давайте перейдём к плану расскажу, что сегодня будет. Значит мы конечно же обсудим, что такое кэширование, когда его нужно применять, когда его не нужно применять и посмотрим на

38: Разновидности кэша. Это будет внутренний кэш приложения, внешний кэш часть из вас знакомы с этими понятиями и затем мы перейдём к темам, которые вообще редко поднимаются, редко обсуждаются, но тем не менее их важно знать. Это

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

40: Tende. Все это расскажу и покажу. Итак, с чего мы начнём? Начнём с самой базы? Что такое кэширование, чтобы мы все понимали, о чем идёт речь. Значит, базово это способ хранения данных, как мо,

41: Можно ближе к месту их использования. Вот такое определение. То есть важно немножко абстрагироваться для тех, кто привык, что cash это только бэкенд, это только вот где-то вот возле приложения находится. Необязательно сегодня посмотрим, что это не всегда так. И основная цель

42: Это снижение задержек сетевых, ну то есть по времени, чтобы очень быстро шли запросы и снижение нагрузки на сервер. Ну и, как следствие, снижение расходов для компаний это основная цель. И мы сегодня везде посмотрим, каким образом эта цель

43: Достигается разными средствами, разными технологиями.

44: Базово, просто, чтобы все представляли, как этот алгоритм кэширования выглядит. Если говорить про приложение, про бэкенд, у нас когда идёт какой-нибудь 1 запрос от клиента в наше приложение, мы посылаем запрос в базу данных, например, там про какую-нибудь новость.

45: Получаем эти данные и сохраняем в кэш перед тем, как отдать ответ пользователю. И затем на каждый следующий запрос той же новости мы уже будем читать данные из кэша. То есть здесь наглядно видна суть кэширования. Мы

46: Экономим количество запросов к базе данных, мы снимаем нагрузку на неё и в принципе, на всю нашу систему и быстрее отвечаем клиентам. То есть как будто вот вообще вин вин ситуация на самом деле, что все в выигрыше от этого

47: Теперь давайте сегодня рассмотрим немножко абстрагируемся от того, что у нас вот есть только приложение внутри него кэш. Посмотрим, где может быть кэш, какие бывают уровни, как можно с этим кэшом работать, потому что это не просто get set операции в редисе, которым

48: Кто-то может, только с этим знаком. Сегодня посмотрим чуть глубже и перед этим разберём, когда вообще cash нужен, когда он полезен, потому что, очевидно, он полезен не всегда. 1 это когда у нас есть очень много повторяющихся чтений одних и тех же ресурсов.

49: 1 и та же новость, один и тот же твит, 1 и та же картинка в инстаграмме одно и то же видео на YouTube ну это все можно кэшировать, это все можно подвигать ближе к пользователю да, помните определение то есть не обязательно мы где-то в редис, в какой-то технологии кэшируем, мы можем двигать.

50: Ближе к пользователю, ближе к браузеру, ближе к веб серверу. Сегодня посмотрим, как это делается далее. Ну, понятное дело, что если у нас очень дорогие запросы в базу данных, очень сложные, там эскюэль, запросы гораздо лучше закэшировать данные и отдавать уже

51: Готовые. Плюс, если мы говорим про то, что данные могут устаревать, мы используем кэш, например, если мы проектируем какую-нибудь криптобиржу, ну или любую просто финансовую биржу, и у нас котировки меняются раз там, в 10 миллисекунд мы, ну,

52: Может быть будем использовать кэш, который на 5 миллисекунд кэширует, но опять же, будет ли это того стоить где-то не нужен кэш в каких-то проектах он вреден, он наоборот добавляет какую-то дополнительную задержку. Далее очень любопытный момент, на который мы

53: Сегодня посмотрим, как правильно составлять ключи для хранилищ, которые хранят кэш. Нужен понятный ключ, понятный контекст. И важно понимать, как этот кэш, эти данные при случае можно инвалидировать. То есть, ну,

54: Если они устарели, как можно понять, что они устарели? Просто если мы зависим от огромного количества данных и факторов, возможно, легче даже не заносить их в кэш?

55: Дальше. И последнее нагрузка волнами. То есть у нас, ну, грубо говоря, такая сезонность есть в плане запросов у нас то их очень много, то их очень мало. И мы хотим сгладить нагрузку, когда у нас очень много запросов, мы можем одни и те же ответы.

56: Кэшировать и отдавать пользователям. Теперь как бы кэш это не серебряная пуля, она не чинит абсолютно все проблемы на самом деле. То есть если у вас уникальные данные для большинства запросов нет смысла использовать в на

57: Случае, кэш, если у вас данные зависят от конкретного пользователя, например, там его важен, ну, условно, баланс, важны его Роли, важны какие-то данные самого пользователя. И у нас там, условно, 10000000.

58: Пользователей, но вряд ли мы будем кэшировать данные всех этих пользователей. У нас просто не хватит места, и пользователь вряд ли 1 даст большую нагрузку нашему сервису, чтобы кэшировать именно для конкретного пользователя. Далее, как я сказал уже, если нам

59: Нужна чёткая, прям строгая актуальность прямо здесь и сейчас. Какая условно, сейчас котировка какой-то ценной бумаги или какой сейчас баланс у меня на счёте, там нужна актуальность. Ну и последнее, как я сказал, если у нас есть

60: Какие-то проблемы там с базой данных с cpu у нас не хватает оперативной памяти нет смысла навешивать кэш, лучше починить саму проблему да саму болезнь, чем пытаться как-то её там запить условно таблетками и поставить Кэш на.

61: Что все хорошо. Ну на самом деле, потом когда-нибудь все равно это выстрелит. Теперь давайте посмотрим на 1 слой. 1 уровень это внутренний кэш. Скорее всего, вы использовали когда-либо в своей практике.

62: Внутренний кэш, что такое внутренний кэш? Это когда мы храним все данные прямо внутри нашего приложения. Вот в каком-нибудь объекте, в каком-нибудь словарике, в каком-нибудь массиве. То есть мы не ходим во внешние хранилища. То есть базово это выглядит так, у нас живёт, например,

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

64: Есть минусы. Напишите сейчас в чат, давайте быстренько порассуждаем, посмотрю вообще, как вы понимаете эту тему, что, например, когда имеет смысл, да, использовать внутренний кэш, а когда нет

65: Вот отвечайте вот просто, что придёт 1 в голову, как бы, если вот вы на system design интервью, например, что бы вы ответили, стоит ли использовать внутренний кэш или нет? Так, при перезагрузке кэш пропадёт корректно.

66: Это правильно. То есть, если он хранится просто в памяти приложения, мы его перезагружаем, мы его редеплоим. Кэш теряется кэш равно мани, окей.

67: Tell функции. Так не очень понял ну, тетель, мы можем реализовать в целом больше памяти занимает приложение ну нет, вот если вот взять так чисто этот аргумент, то нет, как бы мы эту же память могли хранить в редисе, а так мы её

68: Храним в нашем приложении там какая разница? 10 мегабайт в редисе, 10 мегабайт в нашем приложении. Тут нужна конкретика, где память утекает.

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

70: Неудобно считывать и контролировать. Вот Алексей написал несколько реплик приложения, свой кэш. То есть когда у нас 1 реплика, то есть всего 1 экземпляр проблем сильных не возникает, но когда у нас много реплик, сейчас посмотрим, проблемы возникают

71: Так, это слишком, слишком большой объём данных, не нужен внутренний кэш. Ну, ну, смотря что такое слишком большой. То есть, опять же, мы в кэше стараемся не хранить там какие-то отчёты на 50 мегабайт. Это строго запрещено, мы храним обычно там, ну, данные грубо.

72: Говоря там до нескольких мегабайт, хотя и то меньше.

73: Окей, ну как-то не так много плюсов и минусов вы написали, но давайте посмотрим, какие плюсы и минусы. Значит, базово самые крутые плюсы. Это минимальная задержка. У нас нет сетевых запросов, мы не ходим в редис или в какое-то другое храни.

74: В мемкэш, например, нам это не нужно. Мы просто создали словарь, условно глобальный объект, да, вот в питоне, допустим, и просто в него сгружаем все данные и оттуда достаём. Ну и это, конечно, просто внедрить. Вам не нужно знать никакую другую технологию. Берете.

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

76: Пайтекс и я приглашаю вас на наш курс по backend разработке наш флагман, который прошло уже огромное количество учеников, многие стали джуниор мидл, кто-то, даже senior специалистами за то время, пока существует программа и мы собрали все то, что нужно знать.

77: Крепкому бэкэнд, разработчику, чтобы успешно работать и решать задачи. Наше обучение помогает закрыть такие пробелы в знаниях, как работа с паттернами проектирования, с логированием обработкой ошибок, тестированием, работой с базой данных, фоновыми задачами. Архитектурой пайтон приложе

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

79: Эти идеи в своих проектах и берём на вооружение. После прохождения программы вы станете абсолютно точно более уверенным в своих знаниях. И именно в прикладном плане вы сможете применять их в своих рабочих проектах. Друзья, курс удобно совмещать с работой. Это короткий

80: Видео по 10:15 минут, которые быстро можно посмотреть и быстро внедрить у себя в проектах, а также огромное количество практических тестовых заданий. Работа с куратором, который вам всегда поможет и подскажет все это есть у нас. Вы можете как приобрести обучение, прямо сейчас и начать заниматься

81: Уже сегодняшнего вечера. Так и начать курс бесплатно. Если хотите посмотреть, какая у нас подача материала и насколько он качественен. И также можете взять бесплатную экскурсию. Мы просто созвонимся и покажем, как все выстроено, где у нас находятся курсы. Работа с куратором персо.

82: Проект бонусные уроки, дополнительные материалы, шпаргалки все это покажем, расскажем, друзья буду рад видеть вас на наших курсах, а мы продолжаем эфир минусы. Смотрите, очень важно понимать минус, как сказали, сброс при рестарте. То есть если мы опять

83: Загружаем приложение, перезагружаем там, не знаю, рестартим докер контейнер или новая версия приложения вышла, нужно её задеплоить. Понятное дело, у нас старая версия упадёт, новая запустится, то есть данные, ну, как бы кэш охладеет, да, все данные из него.

84: Падут. Их нужно будет заново, заново нагревать кэш. Условно рассинхронизация. Тот момент, который никто не сказал, но который у меня на опыте лично выстрелил. На 1 из проектов, над которым я сейчас работаю изначально мы реализовывали

85: Внутренний кэш. И у нас было запущено приложение в 4 разных экземплярах. И смотрите, у всех экземпляров мы никогда не знаем, в какой конкретно экземпляр попадёт запрос от пользователя. И бывало так, что если данные обновляются, они

86: В 1 экземпляре, в 1 воркере уже обновились, а в другом ещё старые, и если пользователь условно обновит страничку, то у него может запрос уйти не в тот же воркер, где кэш произошёл, а в старый, где лежит старый кэш, где ещё?

87: Не истекла старая версия, и он увидит другой, другие данные. Опять обновит, опять другие увидит. В общем, может быть дикий рассинхрон. В этом плане сложная инвалидация. Когда у нас просто все хранится в памяти, мы не можем какой-то сетевой запрос отправить, чтобы вот инвалидировать данные, чтобы их удали.

88: Потому что, опять же, мы не можем так легко достучаться до внутрянки приложения, ну и разрастание памяти, то, что было оговорено в чате. Но тут конкретно, смотрите, какой момент, если у нас 1 экземпляр приложения, ну, допустим, какой-то стартап эмвипи, там, не знаю,

89: Очень простенький проект вы для себя делаете? Здесь из минусов только сброс при рестарте и сложная инвалидация. То есть у вас нет никакого рассинхрона и нет разрастания памяти. А если у вас приложение, например, вы там в БИК техком,

90: Или просто в какой-то компании, где есть разворачивание на нескольких экземплярах, может быть в кубернетисе, может быть там докерсворм, неважно, может, руками. И у вас там 10 экземпляров, и в каждом будет 10, не знаю, там 15 мегабайт кэша, и это 15 мегабайт.

91: В 10 раз умножится, то есть один и тот же кэш будет храниться одинаковый в 10 экземплярах, хотя можно было бы это вынести, например, во внешнее хранилище в редис и вместо 150 мегабайт занимать 15. Но тогда у нас бы, конечно,

92: Была задержка дольше. То есть сразу надо понимать, какие плюсы и минусы есть. То есть это неплохо. Если у вас проект с 1 экземпляром, то есть 1 воркер, 1 процесс, грубо говоря, и нет каких-то планов на рост. Окей.

93: Эта самая база, её можно использовать. На самом деле, это неплохо. То есть можно объединять и внутренний кэш, как мы посмотрим, и внешний кэш. Но внутренний, например, для тех данных, которые, ну, вообще никогда не меняются. Ну вот бывают такие данные, которые какой-нибудь там словарик.

94: Имею ввиду какой-нибудь справочник, вот он там раз в год меняется. Ну пожалуйста, закэшируй её его внутри, там это займёт 3, 4, не знаю, 5 килобайт, может быть памяти, но у вас будет очень быстро он использоваться. Здесь всегда важно чувствовать приложение.

95: То есть это, ну, это надо прочувствовать. Если у вас бизнес контекст такой, что какие-то данные используются супер часто, и они очень редко меняются, можно закэшировать внутри приложения. Теперь давайте про внешний кэш, то есть это

96: Внутренний это, ну больше для каких-то маленьких проектов или для каких-то вот исключительных случаев, которые я озвучил, когда данные очень редко меняются. Есть, конечно, монополист наш внешний кэш. Чаще всего мы используем редис, но давайте

97: Посмотрим вот абстрактно, как это работает самая популярная стратегия кэширования если опять же вы планируете изучать подробнее эту тему, собеседоваться по system design, если вас спросят, что такое кэш сайт, вы сможете воспроизвести эту схему.

98: Да, то есть, ну, по-русски кэширование на стороне. Это значит, что наше приложение, когда поступает запрос, сначала идёт в кэш, да, 2 пункт. Если на шаге 3 нету данных в кэше, мы идём в базу данных.

99: И потом эти данные кладём в кэш и только потом отвечаем клиенту. Это называется кэширование на стороне. Когда наше приложение само ходит в базу данных, само ходит в кэш, сама складирует данные, есть ещё несколько других подходов, но вот этот используется в

100: Подавляющем числе случаев. Давайте посмотрим на примере питона как на питон кода, как это может выглядеть, чтобы у вас было понимание, потому что я понимаю, что может звучать довольно абстрактно. Есть, например, какая-то функция. Давайте взглянем.

101: И, ну, она довольно небольшая, специально такая схематичная, чтобы было, можно было прочувствовать. В 1 очередь, мы создаём какой-то ключ про ключи. Мы посмотрим чуть позже. Ключ, например, там. User id не знаю, 20, чтобы мы могли потом

102: Достать этого юзера id 20 из кэша. Дальше мы идём в кэш, да, вот тот самый запросик смотрим, а есть ли в кэше эти данные, если они есть, мы просто там приводим к джейсону. Ну, потому что редис обычно не, не в очень

103: Удобном формате, он обычно возвращает данные, мы приводим их к удобной нам форме и возвращаем клиенту гуд. Отлично, но если данных в кэше нету, мы идём в базу данных. То есть мы только в этом случае нагружаем базу данных.

104: И условно, если там пользователя нет, возвращаем, что sorry, такого пользователя нет, если же он есть, обязательно сохраняем в кэш и возвращаем, то есть Ровно вся вот эта схема показана на следующем примере кода если что, вся презентация кто?

105: Досмотрит до конца вам придёт на почту и в telegram бота.

106: То есть примерно так это выглядит. Понятное дело, что на в реальных системах здесь нужно добавить обработку ошибок. Здесь нужно добавить логирование, это нужно разнести по разным функциям, но опять же схематично это выглядит примерно так и внимательно из вас.

107: Сразу могут заметить, что здесь есть параметр экс равно 60, да? Ну или экспиренс есят.

108: Очень важная вещь, которую надо понимать, когда мы работаем с кэшированием, мы абсолютно всегда, вот вообще всегда должны задавать какой-то срок жизни этого кэша, то есть нельзя оставлять его. Ну тут можно

109: Сделать типа срок, срок кэша 0 и он будет храниться вечность. Так лучше не делать. У нас из за этого может забиться кэш по памяти и данные, даже если кажется, что они никогда в жизни не изменятся, не изменятся, они могут поменяться, поменять.

110: Поменяется там бизнес требования, поменяется ещё что-то. А вы забудете, что в кэше это было сохранено. Поэтому лучше всегда ставить срок экспирации какой-то адекватный. Ну там иногда это несколько секунд, иногда несколько минут, иногда несколько дней, несколько месяцев, но все равно он должен быть

111: Мы на него чуть позже ещё посмотрим подробнее. То есть примерно так это может выглядеть в вашем коде.

112: Теперь как раз-таки вот та самая эксперация термин называется ttl, или time to live, он есть не только в редисе, но в редисе он очень много где используется, что важно понимать то, что я уже сказал, не надо давать.

113: Кэшу жить вечно это плохая практика. То есть, если данные устарели, они удалятся автоматически. То есть, почему я говорю про редис, сразу поясню, везде упоминаю его либо редис, либо кэш, потому что это, по сути, монополист, по сути,

114: Самое популярное решение для задач кэширования, для задач хранения в оперативной памяти есть, конечно, аналоги типа мемкэш или свои собственные какие-то кастомные там в крупных компаниях. Но редис просто топ 1.

115: Топ 1 инструмент. То есть мы автоматически освобождаем память, не допускаем утечек памяти и нам не нужно руками удалять какие-то устаревшие ключи, лезть в редис, просить там девопса, чтобы он выдал нам продакшн доступ или сам удалил.

116: Там какие-то ключи, это очень долго, это очень неудобно. Лучше заранее заложить в приложение такую логику. И чтобы у вас было понимание, здесь привёл 2 кодика 1. Это взаимодействие с редисом. У редиса есть свой собственны

117: Как бы силай инструмент, чтобы с ним работать, и код на питоне. То есть, например, когда мы, фредис, кладём какой-то ключик и для него значение, да, в данном примере я попытался отразить, например, взаимодействие с YouTube, когда вы смотрите видео,

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

119: Джейсон, например, сохраняем эти данные, чтобы все следующие клиенты, которые заходят на это видео, они из кэша получали данные и ставим здесь экспирацию 60 секунд.

120: То есть так это выглядит на языке грубо говоря, редисон так это выглядит на языке python конечно, внимательные из вас могут сразу заметить, что что если у нас название поменяется и описание, то человек все ещё будет получать, получается данные старые, то есть.

121: В течение 60 секунд все ещё люди будут получать старое название. Старое описание. Действительно, такая проблема есть. И если вы не предусмотрите, как можно инвалидировать кэш, ну будут маленькие или большие проблемы, поэтому

122: Давайте посмотрим, как работает инвалидация, да, или удаление устаревших данных. Есть 2, ну, таких, как бы, способа, которые вы можете встретить либо в своих проектах, либо самостоятельно реализовать. 1, когда вы работаете напрямую с базой данных. Да, вот здесь пример, например, кто, т,

123: Переименовывает своё имя пользователя. Мы сначала отправляем запрос в базу данных, а после этого из кэша удаляем этого пользователя. Почему? Ну, потому что в кэше лежит его старое имя старый никнейм, и это может поломать

124: Какие-то участки системы, да, если будут отправляться старые невалидные данные или пользователь будет видеть старые данные, хотя он вроде сделал обновление, но ему там браузер показывает, что нет, у вас все ещё старое имя. Представьте, как бы шок, и удивление, и непонимание.

125: Как это исправить у пользователя? Ну, конечно, это относится не только к фронтенду. Это относится и к взаимодействию между микросервисами. Если у вас коллега, который с другой командой реализует другой микросервис, он получил устаревшие данные, хотя вроде их обновил, он тоже, конечно, будет.

126: Раздосадован, мягко скажем, и есть 2 вариант, если вы работаете в событийно ориентированной архитектуре, то есть, когда у вас есть брокеры сообщений, например, там kafka rabbitmq нас, и вы получаете какие-то события здесь, я

127: Пытался тоже на языке python кратенько показать, как это работает, например, вы получили из микросервиса биллинга какое-то сообщение, что у пользователя успешный платёж прошёл, да, он купил подписку на ваш сервис.

128: У вас в кэше лежит, лежат какие-то права пользователя. То есть у вас, например, сервис прав. А вот есть сервис биллинга, да, сервис оплат, и он вам сказал, дружище, а пользователь то оплатил платёж. Ну сорри, оплатил заказ. Что мы делаем в данном случае? Мы допустим, тут

129: Активируем какую-то ему подписку, добавляем какие-то права и из кэша удаляем старые данные про права пользователя, про его доступы или что-то такое. То есть, ну суть 1 и та же, неважно, мы работаем в микросервисной архитектуре, в монолитной мы

130: После того, как получили какое-то событие.

131: Мы очищаем кэш, то есть это такой вот как бы ручной способ и очень, очень корректный. То есть так так делать принято.

132: Теперь история, которая вообще редко касается, как бы редко мы сами это реализуем, редко понимаем, как это работает, но опять же для вопросов проектирования надёжных систем, или если вы метите там расти,

133: Дальше, мидл мидл plus. Сеньор, вам важно понимание систем дизайна, то это важно понимать, как можно вытеснять кэш. Как бы какая проблема. Смотрите, вот в кэше закончилось место, да, место закончилось. Как понять, какой элемент можно надо удалить? Ну или можно удалить.

134: У вас там всего зарезервировано, там 100 мегабайт оперативки для редиса. И вот уже лезет 101, кого удалять. Есть много разных способов. Тут их 4, но на самом деле их гораздо больше. Мы рассмот.

135: Смотрим 2 самых популярных, самых используемых, потому что-то, что не используется, я не вижу большого смысла сегодня рассматривать это lr ю и это elf ю да, если базово, то lr ю сейчас детально на них посмотрим, если что, мы удаляем то что давно.

136: Не использовали, то есть там хранится в кэше уже там месяц какие-то данные, но никто их не использовал, то есть как только память забьётся, мы удалим эти старые данные, которые месяц уже не использовались а lf ю это когда мы удаляем то, что редко используют ну есть

137: Ещее фифо лифо random много других разных теоретических и практических способов но опять же я постараюсь в этом уроке больше практики вам дать давайте посмотрим детально на элр ю. Как это работает ну вообще расшифровывается лист и

138: Just и давайте посмотрим на пример вот мы написали наш бэкенд, нашу эйпиай для YouTube, да, вот и нам обращаются пользователи сначала запрос к видео с котиками, потом запрос на видео с собачками, потом на видео с мистером бист.

139: И потом вот я выпустил видео по фастапи какое-то, и у нас в кэше хранятся 4 видео, то есть у нас хранится какой-то ключ и для него значение, например, там название описание, не знаю, количество лайков. Вот какая-то базовая метаинформация.

140: И вот эти 4 значения забили полностью память редиса все. У нас в кэше нету, нету больше возможности вставлять новые данные вообще и делается новый запрос на, например, вот видео с редисом, я, допустим, какое-то выложил кого

141: Из них мы вот из котиков собачек, мистер бист фастапи будем удалять.

142: Если мы говорим про стратегию элр ю, то есть то, что дольше всего не использовалось, а это котики. То есть к котикам обратились, вот, не знаю, там 4 часа назад к собачкам, 3 часа назад к мистеру убийству, час назад к постапе только что. И вот сейчас обновились, обратилис.

143: К редису мы удалим котиков, мы удалим их, поставим туда редис, потому что котиков очень давно не смотрели. То есть, если видео бы условно открыли котиков ещё раз несколько раз, то котики сдвинулись бы в начало, в самый конец.

144: Простите, вот этого списка и собачек бы уже удалили. То есть смысл такой.

145: Я помню, как-то в 1 видео я говорил в последнем, что объясняют иногда на котиках и собачках какие-то темы. Мне это не нравится. Ну в данном случае, я надеюсь, понятно, на котиках и собачках. То есть суть в том, что у нас есть какой-то хронологический порядок вызова этих

146: Ресурсов, да, если говорить в терминах рестапи или этих сущностей, и мы замещаем тот, который больше всего не использовался.

147: Теперь есть ещё 1 стратегия вытеснения она называется элэф ю лист, frequent ли just да, по частотности смотрите, например, к котикам обратились 5 человек видео по собачкам посмотрели 4 человека мистера биста 7 и фастапи odi.

148: Человек, и у нас кэш полностью заполнился. Ну, понятно. Пример абстрактный, там ключей не 4, а 40000, наверное, чтобы заполнить нормально оперативку, но базово. Так, кого мы будем из них удалять? Ну, фастапи, потому что всего

149: 1 раз получили это значение и нам как бы наша цель. Напоминаю ещё раз в кэшировании как можно как можно больше снизить задержку по времени и снизить нагрузку на нашу ба.

150: Данных. Соответственно, мы уберём отсюда фастапи, мы его выкинем из кэша и поставим на его место редис. То есть последнее видео, которое вот хотели получить пользователи, это 2 самые популярные стратегии. Очень важный вопрос, который 100

151: Здесь поднять, нужно ли это реализовывать руками вот эти алгоритмы lr ю элэф ю или какие-то другие нет, если мы говорим про redis, ну или редиссон её какие-то технологии, то чаще всего.

152: Алгоритмы такие уже реализованы. Элэф, ю, элр ю. И вам важно понимать, то есть они настраиваются условно 1 командой в редисе, и за это, скорее всего, ответственен какой-нибудь девопс инженер, если мы говорим про серьёзную разраб, про, ну, большие компа,

153: Большим количеством штата. Важно понимать, какой у вас кэш, чтоб вы понимали, где какие данные могут устареть. И если что, если вы занимаетесь проектированием с нуля какого-то микросервиса, вы лучше всех

154: Понимаете, какая стратегия вытеснения вам нужна? Элю элэф ю или, возможно, какая-то либо более экзотическая, которую вы сами там имплементирует.

155: Вот так, перед тем, как переходить к структуре ключа, давайте чуть чуть поотвечаю на ваши вопросы. Может быть что-то у вас появилось из вопросов, и пойдём дальше, посмотрим на структуру ключа.

156: Так, не трогайте котиков, да, друзья, так получилось, что котов первых поставил, поэтому их удалили.

157: Так, да, фифо лифо тоже используются, но они как бы менее применимы на реальных проектах. Как посчитать оптимальный размер кэша? Можно посмотреть на данные за последние, грубо говоря.

158: В метриках там, в логах за последний месяц посмотреть, какие ручки, какие эндпоинты вызывались, каким данным было обращение попробовать воспроизвести там заштурмовали, например, death death стенд такими же запросами посмотреть, сколько памяти это займёт.

159: Потом перенести это все на про, то есть понять какие там на проде реальные реальный трафик и примерно прикинуть но опять же, кэшируем мы далеко не все. То есть если у вас кэш занимает там 10 гигабайт оперативки, скорее всего, что-то лишнее.

160: Было закэшировано.

161: На каком слое работает кэш на слое вью на бэкенде? Нет, он работает больше на слое работы с данными.

162: Так как понять, что давно не смотрели, это все отслеживает именно редис. То есть как он поймёт, какой из этих ключей давно не, не открывался, у него хранится своя внутри структура данных. И он понимает, что из как бы у него

163: То есть список обращений, он понимает, что нужно из этого выкинуть.

164: Где нужно делать логику кэша в репозиториях в целом можно в репозиториях, учитывая, что репозиторий у нас является обёрткой над хранилищами данных, можно на уровне выше, можно некоторую абстракцию сделать.

165: Над репозиториями.

166: Так, окей, окей, друзья, тут че то пошло, какое-то обсуждение. Давайте пойдём дальше, посмотрим на, на структуру ключа, чтоб вы понимали, мы всегда храним ключ и для него значение. Ну, значения это какие-то данные из базы данных. А вот как строить ключ?

167: Важно понимать. Я здесь специально сделал такую радугу, раскрасил и показал пример ключа, который можно использовать, ну, в довольно серьёзных проектах. То есть в маленьких проектах. Ну, вряд ли стоит городить такую серьёзную иерархию в

168: В больших проектах это того стоит. Давайте кратенько объясню вообще, зачем это нужно. Че за ключ? Да, ключ это просто строка, да, вот как здесь на примере показано, и она должна быть достаточно уникальной, чтобы

169: Другие сервисы, другие разработчики случайно не перетёрли условно ваши данные. Скорее всего, есть какое-то соглашение внутри компании, как мы называем, какие ключи и ключ должен содержать в себе следующее. Он должен содержать 1.

170: Окружение. Мы работаем сейчас там с разработческим стендом или с production стендом. Понятное дело, что иногда бывает, что редис разный для разработческого стенда, для продуктового стенда, для там stage стенда, для ещё какого-то стенда. Но если редис

171: С единой лучше указать далее лучше указать название приложения, чтобы можно было легче дебажить. В принципе, если что-то произойдёт неладное с кэшом дальше, если мы говорим про микросервисную архитектуру лучше всегда.

172: Описать, какой сервис работает с этими ключами, да, например, сервис биллинга или сервис новостей, сервис каких-то интеграций, ещё что-либо. Ну и дальше уже вы сами придумываете, какие у вас есть сущности в вашем приложении, в вашей бизнес логике.

173: Например, есть пользователи, у них есть какие-то доступы, и нам нужен пользователь, с доступом у которого айди 42, и мы эти данные закэшировали.

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

175: Отделять друг от друга, чтобы случайно разные проекты, разные сервисы не перетёрли друг друга. И я не сказал про 1 интересную вещь. Это версия, что такое version. Представьте следующее. Представьте, что вы

176: Писали какой-то бэкэнд, он работает там, например, данные по новостям, ну вот допустим какой-то новостной сайт есть, и мы отдаём новости, и у новостей есть какие-то поля, ну там тайтл дейта, автор и что-то

177: Ещё. И вдруг к нам приходит бизнес и говорит нам, что у нас будет там ещё какое-то дополнительное поле в этой новости. Ну не знаю, там url картинки, допустим, или что-то подобное, и мы

178: Переписываем наш бэкенд, нашу апишку, она теперь из базы данных тянет ещё и там url картинки, и мы её кладём в кэш, и версии как раз-таки нужны на тот случай, когда у нас меняется как-то формат представления данных, чтобы нам руками

179: Не перетирать все старые ключи, которые там были с версией 2, например. А у нас новая версия, версия 3 появилась. Мы просто меняем номер версии, все новые запросы на эту конкретную новость.

180: Будут оканчиваться версией 3, а ключи, которые старые, оканчивались на в 2, они потихоньку просто сами удалятся. Помните, я говорил ттл тайм ту лив, да, время жизни ключа всегда нужно устанавливать, потому что никогда не знаешь, когда какие-то данные станут старым.

181: И больше не понадобится. Поэтому версионирование очень помогает уже в таких, ну, более продвинутых случаях использования кэша, когда вы очень сильно на него опираетесь и очень активно используете, чтобы инвалидировать какие-то данные, чтобы не лезть в редис руками. Там ничег.

182: Не удалять. Гораздо лучше использовать такой механизм. Теперь любопытный кейс. Да, немножко, немножко отдохнём, расслабимся и посмотрим на умное использование кэша. Я увидел, услышал.

183: Про этот, как бы про эту фичу где-то в 1 из видео я, к сожалению, не смог его найти, но смотрите в чем суть, когда вы логинитесь в какой-то google сервис, да, например, google почту вы вводите сначала емейл, или там логин или телефон.

184: Нажимаете некст и как бы в чем, в чем была суть пока вы вводите пароль, пока вы там подтверждаете, что это реально, вы на бэкенде уже подгружен в кэш конкрет.

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

186: Проверять, делать много проверок, чтобы уже в кэше были данные, уже быстренько можно к ним обратиться. И вы вот как пользователь просто испытываете невероятное, не знаю, потрясение, удивление, что вас мгновенно логинит. Вы типа, не нужно ждать там.

187: Секунду 2, как на других сервисах, сервисах. Оттуда же вы попадаете на сайт, на свою страничку, на свою почту.

188: То есть это как будто неочевидное решение, что обычно мы кэшируем данные, к которым уже обращались, а тут мы ещё не знаем, что к данным. Точнее, мы предчувствуем, что с этим логином сейчас пользователь войдёт, ну, как бы

189: Обычно сами пользователи заходят, да, они хакеры, поэтому подгружаем данные их в кэш, и когда человек вводит пароль, тут же попадает на свою страницу. То есть мы как будто предвосхитили, что, что сейчас будет, добавили данные в кэш и человек

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

191: Да, друзья, важно, что понимать. Кэш вообще сам по себе. Ну, как бы тяжело его применять, если не владеть бэкэнд разработкой, не понимать, как строится приложение там. Не, ну,

192: Не понимать, как работают базы данных, фоновые задачи и в принципе, строится архитектура приложений. Я сейчас буквально минутку расскажу, что у нас есть курс по бэкенд разработке. Я его автор, и это полное пособие по сути, гайд по тому, как писать

193: Надёжные, крепкие приложения, где мы рассматриваем, конечно же, и кэширование, и фоновые задачи, и самые основные темы бэкэнд разработки, это тестирование приложений, это построение архитектуры с использованием паттернов, с использованием слоёв, да, то есть не просто в 1 файл,

194: В 1 Папке, как иногда по началу, кодишь цель, чтобы вы к концу обучения, да, это записанные по сути видеоуроки смогли писать надёжные классные сервисы, микросервисы, монолитные приложения, в которых есть все необходимы.

195: Компоненты. Ну и конечно, для всех участников будет бонус, но я скажу о нём чуть позже, чуть позже, в конце урока. Давайте теперь поговорим про следующий уровень. То, что я сам узнал лично, только

196: Где-то в начале этого, то ли в начале этого года, то ли, в общем, год назад, где-то. И меня это очень поразило и очень удивило. И я удивился, что никто мне никогда об этом не говорил. Это http кэширование, то есть кэширование на уровне http протокола, то есть мы с вами

197: Ну, с ним постоянно каждый день работаем, но.

198: Есть кое-что в нём интересное. Смотрите, есть такой заголовок, который называется кэш ctrl и

199: Вообще, напишите, кто из вас когда-либо видел, что такое кэш контрол.

200: Да, друзья, скажите, слышите ли вы меня, насколько сейчас вообще хорошая связь, че то, какие-то проблемки?

201: Так, друзья.

202: Да, попробуйте обновить страничку, может это поможет.

203: Алло. Алло, друзья?

204: Так, у меня вообще показывает, что все хорошо. Да, давайте я буду говорить, чтобы было понятно, слышно или нет. Показывает, что все хорошо, но почему-то пишет, что кэш кэш забился, что лагает.

205: Так, слышу. Хорошо, без задержек. Окей.

206: Не помогло.

207: Так, норм, слышно? Окей, все так, да, давайте если сейчас посмотрим, что все хорошо возобновится, то посмотрим дальше. Да, попробуйте поставить низкое качество, чуть чуть пониже.

208: Да, ребят, сейчас технические проблемы, сейчас, я надеюсь, все быстренько решим.

209: Так, так, так, так, вроде пошло. Кэш не реализовали. Среднее качество. Ставьте среднее качество, ставьте так, друзья, да, попробуйте обновить страничку. Надеюсь, все хорошо пойдёт. Честно, не очень хочется вообще прерываться, потому что ещё много интересного.

210: Материалы.

211: Так, давайте, друзья, среднее качество сейчас через 30 секунд продолжим.

212: Да, забыли закэшировать, забыли закэшировать. Да ладно, друзья, давайте, надеюсь, надеюсь, все хорошо. Пойдёт, восстановится. Либо наплыв людей большой, либо что так, да.

213: Давайте, давайте про кэширование сейчас повторю, чтоб все было все понятно, все слышно.

214: Значит, у нас есть такая интересная тема, которая мало где освещается. Я честно узнал сам о ней только там, где-то в этом году или в начале этого года применил сразу же, как только увидел у себя в приложении, и очень

215: Порадовался этому. Сейчас поделюсь с вами, как все это работает.

216: Давайте посмотрим на следующий скриншот, который я сделал, собственно, на своём сайте, на там, где я работаю сейчас в солвите, есть некоторый заголовок в http, который называется кэш ctrl, и у него есть какое-то значение, ну, в данном

217: Случае Макс эйч 300 что значит на 300 секунд? Закэшируй мне значение, которое отправил сервер, то есть вы как backend разработчики, можете вообще не использовать redis и кэшировать значение внутри браузера.

218: И давайте.

219: Давайте посмотрим базово сейчас, что это такое, какие здесь параметры есть, и затем посмотрим, как другие слои приложения используют этот http кэш, потому что он используется, ну чуть чуть сложнее, чем может показаться.

220: Значит, у нас есть основные директивы, это max age, да, то есть это типа ttl, который у нас был в редисе, это public, чтобы показать данные публичные, типа какой-то, не знаю, новость или погода, то есть котиров.

221: То, что реально всем людям мы можем отдать без авторизации и есть приватные данные, например, там ваш баланс или, ну, ваше имя пользователя, ваш логин, ваше имя, то есть все, что отправляет сервер, но это нельзя.

222: Ну, это не рекомендуется кэшировать да, private, и у нас есть поле по типу no store, это сообщает, что вообще не надо ни в коем случае эти данные кэшировать ни при каких условиях есть интересная.

223: Директива ноу кэш, если захотите, в конце о ней чуть подробнее поговорим. Это когда клиент, даже если видит, что у него у него есть данные, он все равно ходит в сервер. Спрашивает, дружище, а данные случайно не обновились, если обновились, просто вот отда

224: Мне их, а если нет, то я использую кэшированные, сейчас тоже покажу как это работает и мы сегодня посмотрим на cdn, можно ставить срок ттл для cdn систем, если кто не знает что такое cdn, сейчас тоже поговорим посмотрим, но

225: Http, как вы знаете, работает не только в браузере, он работает между сервисами, между микросервисами. Он работает на уровне веб серверов на уровне cdn. И сейчас посмотрим как это работает. Сперва посмотрим на реверс.

226: Proxy cache вот кто знает, что такое реверс прокси чем это отличается просто от от прокси обычного, ну или от forward proxy?

227: Что такое reverse proxy cache? Извините, что такое реверс прокси реверс прокси.

228: Nginx, nginx ну это как бы пример, да, nginx может использоваться как реверс прокси, а что такое реверс прокси?

229: На прокси хранится, а не на бэке, так не очень понял.

230: Энжинкс ну да, nginx а как бы в чем, в чем суть реверс прокси и чем он отличается от обычного прокси?

231: То есть является ли nginx просто обычным прокси, например?

232: Не показывает, от какого сервера пришёл ответ. Нет, это уже

233: Ну, частично можно, наверное. Но скорее, скорее, нет. Сервер, который пересылает запросы, не совсем данные идут через приложение балансировщик, да, в общем, любопытно. Направляет запрос на разные узлы. Окей. Значит, смотрите, какая разница.

234: Есть просто прокси или он называется forward, proxy, да, типа такой прямой и есть реверс прокси, то есть обратный прокси, и разница здесь очень, очень простая, значит, если мы говорим про обычный прокси, это то, что стоит ближе к клиенту.

235: Это то, чем пользуется клиент. Например, вы можете себе поставить на на компьютер прокси и через него слать все запросы. Реверс, прокси стоит всегда ближе к серверу. Это всегда то, как бы, что там

236: Разработчики девопсы у себя ставят. То есть, по сути, это тот же самый прокси, как когда мы ставим у себя на компьютере, просто он живёт ближе к приложению, ближе к серверу и им заведуют разработчики, чтобы чтобы упростить

237: Себе жизнь, чтобы обезопасить себе жизнь. И 1 из примеров. Это, конечно, nginx, который мы ставим, мы тоже на курсе рассматриваем, как работает nginx, и мы через него проксируем все запросы, то есть прогоняем весь трафик через него, и пользователи просто

238: Не видят, куда там запрос улетел, они просто видят, что он улетел в nginx и nginx ему ответил. И давайте посмотрим на то, какое место занимает веб сервер. Ну да, вот в данном случае nginx, например, является реверс прокси у нас

239: Есть наше приложение, оно общается с кэшем, оно общается с базой данных, но оно не напрямую отвечает клиенту, например, с браузера перед ним всегда стоит, ну, в надёжных, как бы хороших больших системах. Веб сервер чаще

240: Всего, конечно, это энджинекс. Если мы говорим про кубер, у нас может использоваться энвой, у нас может использоваться ха прокси, но как бы, самое популярное, конечно, решение это nginx, ну или энджинекс. Сегодня мы чуть позже посмотрим, что, конечно, ещё может стоять сиди.

241: После этого, да, и только потом уже там браузер, уже клиенты. Ну, здесь я описал браузер, мы сегодня смотрим на веб приложение, но здесь может быть, конечно, и любой другой клиент, да, другой микросервис, например.

242: Давайте посмотрим на пример конфига, как можно в этом самом nginx настроить, чтобы он тоже кэшировал запросы, чтобы они даже не долетали до вашего, до вашей апишки, которую вы написали, чтобы вообще даже регис не нагружался. Представляете, как?

243: Это делается, когда вы конфигурируете энджинс. Да, это вот пример, как бы вырезка из конфигурации энджинкса. Если вы пропишите прокси кэш,

244: И будете использовать, и напишите собственно, директиву proxy cache па, чтобы сконфигурировать как-то кэш, то есть он будет храниться вот рядышком с энджинксом, тоже в оперативной памяти, и nginx даже не будет ходить на ваш сервер и не

245: Будет делать запросы в редис, то есть он будет сам из своей оперативки брать, и это будет ещё быстрее, да, то есть не нужно будет заходить в приложение, у вас там не будет работать никакой там мидл вер не будет отправляться запрос в редис. В общем, все будет быстрее. Это

246: Ещё 1 из способов кэширования, который вот есть в этой большой большой огромной цепочке кэшов, на которую посмотрим в самом конце.

247: Что любопытно, я не встречал у себя на практике, чтобы кэшировались данные в энджинксе, ну или в энджинекс, когда вообще может потребоваться кэшировать данные в nginx?

248: Ну, можете попробовать ответить.

249: Но суть следующая. Как я говорил, в случае с с редисом, в случае с кэшированием нам не нужно как бы кэшировать данные, если у нас есть какие-то проблемы на уровне ниже, если у нас тяжёлые скьюль, запросы какие-то сложные, неэффективные.

250: Если у нас есть проблема n + 1, например, известная, если у нас есть в принципе, какие-то проблемы, которые можно починить, то не нужно навешивать кэширование на уровне веб сервера. Но если у вас есть какой-то, например,

251: Как какой-то endpoint конкретный для конкретной для конкретных данных, например ну давайте представим себе YouTube и какой-то там мистер бист, у которого 400 или там 500000000 подписчиков, выпустил видео.

252: И там нагрузка идёт колоссальнейшая на запросы и там возможно уже есть смысл снизить на 5 10:15 миллисекунд время запроса закэшировал данные на стороне веб сервера.

253: Но для базовых приложений, скорее всего, там, с которыми вы работаете, там, где нагрузка, ну даже там 100000 rps, там может 10000 rps, там вряд ли такое нужно. То есть, если мы говорим про бигтех, где вот какой-нибудь там озон, где 5 миллионо.

254: Rps ну, понятное дело, что там не на не на конкретную апишку, не на конкретный микросервис, там на всю систему такой арпис, но если мы говорим про огромные цифры, это как бы микрооптимизация уже может дать какой-то ощутимый

255: Прирост, то есть вот так можно это делать на стороне веб сервера. Понятное дело, что не только в энджинксе это можно делать, как я сказал, не только энджинекс или nginx является веб сервером, но важно понимать, что вот этот http

256: Протокол он пронизывает как бы всех акторов, которые стоят на пути запроса, то есть мы и на бэкэнде, когда там пишем на python, php, голэнг, джава. Работаем с http, можем какие-то заголовки ставить? Они прокидываются дальше и в веб сервер.

257: В nginx они идут дальше и в cdn систему, и дальше в браузер и давайте посмотрим на cdn, если кто не знает, что такое cdn базово допустим, у нас есть какой-то сервер здесь, там, в Москве он называет

258: Origin. То есть как бы как бы самый главный, самый главный сервер. И у нас есть пользователи, например, там, из Владивостока, с какого-нибудь Красноярска, Краснодара, и там с якутии, и у них

259: Очень медленно грузятся наши данные. Прям, ну вот капец, медленно мы можем их кэшировать.

260: Я думаю вы встречались с cdn я думаю вы встречались с тем, что сайты очень легко, очень быстро работают да, неважно в каком там регионе России вы находитесь, у них есть большая сидиэн сеть из серверов.

261: Которые стоят там по России условно, там в 20 локациях. И чем ближе вы к какому-то из них туда и летит запросик. Но очень важно оговориться. Чаще всего на cdn системах кэшируется статический контент. То есть это

262: Картинки это джаваскрипт, это css, это html, это какая-нибудь там музыка может видеофайлы, если мы говорим в контексте api да, в контексте того, что мы разработали какой-то api и хотим.

263: Кэшировать данные в него мы тоже можем закэшировать данные через cdn для этого, а че то забыл я вставить, для этого у нас используется специальная директива с mars max age, то есть мы не просто пишем.

264: В заголовках ответа кэш ctrl там max age мы пишем c max age as отвечает за short, то есть типа делимый ну, важно понимать, что мы никогда не должны кэшировать какие-то приватные данные пользователя, да, потому что они на них нет большой нагрузки, и мы.

265: Хотим, чтобы они были на сиденье, то есть мы кэшируем на сиденье только публичные данные, которые запрашивают сотни пользователей.

266: Это следующий слой, да, это cdn. То есть на нём тоже можно кэшировать. Кстати, так и у нас дальше, да, у нас дальше пример с браузерным кэшем. И посмотрим на сайт apple перед этим давайте немножко.

267: Отвечаю на вопросы все ли понятно в теме реверс прокси nginx cdn?

268: То есть опять же сегодня вот чем дальше мы сейчас идём, чем чем глубже погружаемся, тем это более, наверное, продвинутые темы, которые обычно встречаются уже либо на собеседованиях уровня senior middle.

269: Plus либо уже на уровне работы тимлидом, сеньором архитектором.

270: И опять же, если у вас есть какая-то, например, эндпоинт поинт, который запрашивают, ну просто колоссальное количество раз, и там данные не то чтобы часто меняются, да, это, например, какой-нибудь справочник, какие-нибудь данные, которые актуальны вообще.

271: Для всех пользователей вообще для всех не будет лишним их тоже закэшировать.

272: Как сдаётся, эйчтипи кэш через заголовки. Да, да, давайте ещё раз покажу, чтобы это было понятно. То есть вы как бэкенд разработчик, вот сюда, вниз. Посмотрите на эту штучку перед тем, как вы отправляете пользователю ответ. Ну, по рестапи, например, да, по

273: Граф кюэль, неважно, по tp протоколу вы ручками дописываете ещё конкретный заголовок, который называется кэш контрол да, извините, я забыл пример прикрепить, в общем дописываете заголовок и для него.

274: Значение и значение. Сейчас посмотрим на примере, какие значения бывают. Прописывайте, например, что время экспирации через 60 секунд, да, то есть следующие 60 секунд они будут закэшированы, что это публичные данные, например, и

275: Обязательно их всех прописывать, можно просто прописать max age и все, и больше, и больше не трогать.

276: Сколько тратят на Сидин в больших компаниях на самом деле немного. Если относительно всех трат больше всего, конечно, стоят серваки какие-нибудь, менедж, базы данных, управляемые там реплики, там у баз данных куча реплик какой-нибудь, редис кластерный. Это все стоит больших

277: Денег там, железо, всякие железяки.

278: Так, в чем отличие энджинс от обычного сервера, как сказать, обычный сервер, как сказать энджинс это вот программа типа soft. Его можно запустить в докер контейнере, например, на вашем сервере.

279: Сервер это что-то обычно физическое, это какой-то объём жёсткого диска, это какой-то объём оперативной памяти, это какие-то транзисторы то есть вот какая-то типа какой-то компьютер а веб сервер да он так называется

280: Но это софт, это не что-то не, не материальное.

281: Http кэш не равен браузер кэшу, да, http кэш у нас, как я сказал, он проходит. В общем, http запрос у нас он вообще очень, очень много этапов проходит, он проходит и через cdn систему, если она есть, ну, в больших компаниях точно есть и через веб сервер.

282: И дальше уже попадает в приложение. Обычно маршрут такой. И вот cdn веб сервер, они тоже могут использовать эти заголовки, этот кэш контрол, они могут его распознавать, смотреть на какой срок закэшировать, так что запрос не дойдёт.

283: С веб сервера на приложение или с сидиэна на веб сервер, да, то есть у нас есть разные слои кэширования о чем, собственно весь урок, как cdn понимает к какому серверу я ближе, ну, по ip адресу, я думаю.

284: Как происходит инвалидация кэша в cdn хороший вопрос вообще, чтобы сидиэн кэшировал ещё и запрос ответы от апи, то есть не только статику, то есть картинки джиэс сиэсэс это отдельно конфигурируется как инвалидирует.

285: Кэш сидиэн, хороший вопрос, кстати, а, да, я знаю, как он валидируется, но мы сегодня об этом не будем говорить. Это ещё 1 заголовок в http под названием, и etag её тег. Ну, короче,

286: Сегодня я решил не жестить, как в прошлый раз, чтобы вебинар не длился 2 часа, чтобы он был более коротким и самую ценную инфу вы с собой забрали.

287: На какой уровень рассчитан этот стрим на самом деле, на очень разные, как от Новичков, кто хочет понять только, что такое кэширование, так и для там уже джуниор мидл, ребят, кто просто хочет узнать, как это работает не только на уровне приложения или кто редко щупал кэш.

288: Такое тоже бывает. Http кэш работает только сиден или без него? Конечно, без него тоже он работает. Я вам покажу. Сейчас давайте посмотрим на пример.

289: Например, например, на примере сайта apple давайте зайдём на сайт apple, сейчас все покажу и будет гораздо понятнее я зашёл на сайт apple, нажимаю посмотреть код вкладка сеть, чуть чуть приближу.

290: И давайте я обновлю страничку, обновлю. Так, давайте так сделаем немножко. У нас есть 5 запросов, 5 запросов можно, ну, на самом деле их гораздо больше. Я вот именно взял запросы к апи.

291: Давайте посмотрим, что нам отвечает апи, ну, нам не так важно, че за данные, да, но какие-то данные вот здесь какие-то джейсончик пришёл, что нам отвечают в response хедерах, в заголовках здесь есть кэш ctrl и время экспира.

292: То есть 217 секунд, начиная от вот времени получения ответа, эти данные будут храниться в кэше браузера.

293: То есть они будут прямо в самом браузере сейчас покажу, как это работает ну, тут такой простенький кэш ctrl следующий запрос тут кэш ctrl, например, 113 секунд окей, следующий кэш ctrl уже посложнее тут уже есть набор вот этих директив.

294: Есть прайвет, хотя удивительно да, я вроде не залогинен, но это приватные почему-то данные, и здесь указано, что их не нужно кэшировать вообще no store, то есть не надо их вообще никогда в жизни кэшировать.

295: И браузеры, сидиэн, веб сервера увидят этот заго, как бы это значение поймут. Окей, я ни в коем случае не буду вот эти данные, вот этот ответ кэшировать ни в коем случае. То есть это призыв не только браузеру, это призыв всем клиентам, через которых проходит запрос.

296: Server сидиэн браузер ну и ещё какие-то данные теперь давайте что я сделаю я обновлю страницу и посмотрим че произойдёт обновляю смотрите ну почему-то сделал 4 запроса а не 5 но вот эти все данные они в кэше.

297: Смотрите, время 1 миллисекунда, 2 миллисекунды, 2, 3 миллисекунды, хотя до этого было че то там 50 или 40 миллисекунд, или даже больше. То есть все эти данные, смотрите, взяты с cash. Угадайте, где они хранятся, они хранятся на вашем компьютере.

298: Ну я как бы вот я сижу в google хроме, если удалить google хром с компьютера, данные тоже удалятся, в чем прикол, то есть браузер умный, браузер умный вообще, и они видят вот этот заголовок, видят количество.

299: Секунд и кэшируют у себя, ну на самом деле, на вашем жёстком диске, потому что они у вас на компьютере живут все эти данные. И вы когда ещё раз вот обновите страничку, давайте обновлю Бац. Видите, вот эти 1, 2, 3.

300: Запроса все ещё лежат в кэше. А вот этот запросик, который, видимо, уже успел эксперировать, я, он опять пошёл на backend. То есть смотрите в чем прикол. То есть вот сейчас обновлю страничку вот эти 4 запроса, ваш бэк их даже не увидел, ваш

301: Веб серверах не увидел. Сидиэн их не увидел. Ну, редис база вообще, там уже отдыхают, чилят, потому что эти данные хранятся в браузере, потому что здесь вся сила кэширования на стороне браузера. То есть вы как backend разработчик, да, только пред

302: Представьте, вы вроде бы кент разработчик, какую-то апишку написали, просто в ней добавили ещё кэш ctrl и какое-то количество секунд да, вы сами задаёте, опять же, вот это все вы сами задаёте 60 секунд там год. Сейчас посмотрим, где на сайте нутеллы.

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

304: Сильно снизить нагрузку на свой сервер. Кто-то кто то говорит, что мой комп захламляют яблочники. Друзья, зайдите на абсолютно любой сайт, давайте зайдём на какой-нибудь хабар, который всем всем известен. Честно.

305: Я даже не заходил, не готовился. Посмотрим, есть ли что-то тут из кэширования. Давайте обновим страничку.

306: Тут, правда, я авторизован, тут, видите, уже уже что-то в кэше лежит, уже что-то хабр положил уже давным давно.

307: И какие-то вот распределение зарплат, например.

308: Окей, тут нет кэш контрола тут нет. Кэш контрола. Нет, нет.

309: А вот вот здесь, например, есть кэш ctrl короче да, с хабром наверное, не очень Удачный пример, но если зайти, например, на YouTube, на твиттер, на сайты, которые посещают очень большое количество людей и там данные ну поглощают тысячами 1000000.

310: Запросов, там кэширование крайне полезно, оно крайне быстро настраивается на бэкенде вами, да, разработчиками. И потом вы смотрите на метрики и у вас как бы сглаживается нагрузка. То есть у вас

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

312: То есть важно, как понимать данные, специализированные для пользователя, их не нужно кэшировать. То есть конкретные там личный прогресс, личные какие-то.

313: Не знаю, награды, что-то вот от пользователя не нужно кэшировать. Так, тут че то-нибудь, че у нас кэшируется? Я уже подзабыл диск кэш.

314: Да ну ладно, надо бэкэнд посмотреть.

315: А нет, что что-то мы кэшируем. В общем, да, технические неполадки. В общем, суть в чем и что важно понимать, даже если мир как бы браузеров фронтенда, кажется вам очень отдалённым, что вы на него

316: Вы никак не влияете, вы никак, ну никак не можете исправить ситуацию. На самом деле очень важно, как я и вот на прошлом уроке говорил во вторник и сейчас чуть дальше как бы смотреть за горизонт, за бэкенд.

317: Что там происходит, на что я могу повлиять? И, честно говоря, вот даже такая была история на, на когда я middle plus устроился разработчиком у меня к моей апишке, я написал микросервис, там уведомлений захожу потестить на

318: Сайт на фронтенд. И вижу, что в моей апишке делается условно. Н + 1 запросов. То есть там условно первые 10 уведомлений отправился запрос, когда пользователь хочет проскроллить, посмотреть вторые 20 делается и на первые 10, и на вторые 10, потом ещё скролит.

319: Потом на первые 10, на вторые 10, на третьи 10. И если бы человек скролил дальше, дальше, дальше, вот такая лавина запросов бы пришла на, на бэкенд. И важно всегда понимать, как бы, как будут пользоваться вашей апишкой, корректно ли ей пользуются. То есть всегда смотреть метрики, всегда смотрет.

320: Логи, какие запросы к вам приходят и понимать, что если есть какие-то данные, которые вы можете закэшировать на стороне редиса, на стороне веб сервера, на стороне браузера, да, то есть браузер, опять же, повторю, он не идёт.

321: Фишку, вот этот запрос, где написано апи, он не уходит в апи, все данные хранятся в браузере. То есть вот эти все данные, они хранятся где-то в браузере. Мы можем почистить кэш, конечно, если мы там зайдём в настройки браузера.

322: Почистим кэш, он удалится. Вот как раз-таки, когда вы чистите кэш, и там иногда бывает, там, не знаю, 200, 300 мегабайт. Важно понимать, что все сайты, ну, в той или иной степени, ну, не захламляют, но, в общем, забирают пространство жёсткого диска, просто, чтоб вы имели ввиду, и что

323: Вы использовали это как преимущество, но опять же не нужно кэшировать в браузере, там мегабайтами данные. За это вам пользователи спасибо не скажут. Так.

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

325: Так, давайте, друзья, пару вопросов и перейдём к последней, к последнему слою, который тоже хочется показать.

326: Так, кэш ctrl данные лягут в локал сторедж нет, они не лежат в локал сторедж они лежат в тех структурах которые вы не можете посмотреть нормально, а или нет извините ну да не, нет, вроде вроде бы мы не можем посмотреть нормально этот кэш кэш для.

327: Где настраивать девопс да накст джесс норм тема, да, у нас на нём написан, солвит норм. Тема next тоже норм. Тема.

328: Окей, окей, друзья, и давайте перейдём тогда к последнему, к последнему. Кэш, ну давайте ещё раз покажу, значит, кэш в браузере.

329: Это тот кэш, за который ответственен бэкенд разработчик. То есть фронтендер вообще ничего не сможет с этим сделать. Вообще ничего. То есть именно вы за это ответственны, ответственны. И есть 2 самых важных, которые нужно понимать значения. 1, это max age, это тот же ttl, что в

330: Чтобы у вас автоматически данные из кэша удалились, то есть браузер, или cdn, или веб сервер их удалит у себя из кэша через это время, и указание на private или public эти значения считывают, уже браузер считывает.

331: Ну, короче, все клиенты их считывают и понимают это данные, которые содержат какую-то приватную информацию или нет. И в зависимости от этого более надёжно или менее надёжно их кэшируют. И последнее, опять же, что, наверное, мно,

332: Многим известно, но я покажу интересную реализацию, как мы можем разгрузить немножко бэкенд. То есть, если вы там, как, например, созваниваетесь с фронтендером, обсуждаете какую-то новую фичу там и с продакт менеджером и решай с тимлидом, куда нам поместить вот это вот этот

333: Кэш, вот сейчас увидим, что часть кэша можно хранить на фронтенде.

334: Смотрите, значит на фронтенде есть local сторож, вы многие о нём слышали, сейчас покажу, как он выглядит на реальном примере, опять же, если в консоли разработчика зайти и зайти во вкладку эппликейшен или приложение здесь локал сторож, вы увидите много.

335: Много разных данных. И сейчас покажу на реальном примере, как можно использовать local store, чтобы решать реальные проблемы пользователей и не нагружать backend. То есть вы, то есть у меня было несколько таких случаев, когда вот опять же я работал на middle plus позиции, это

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

337: Это будет удобнее, потому что так, так и так. Смотрите, какой есть прикол. Например, вы зашли, захотели решить вот там насовывать какую-то задачу, не знаю, какую-нибудь вот задачу из яндекса начали писать какой-то код, какой-то прям код.

338: Очень, очень, очень сложный. Писали его 2 часа. Ну, грубо, там, не знаю, час. Ну, короче, очень много сил вложили, и потом взяли и случайно закрыли вкладку.

339: Ну, собственно, решаете открыть её заново. И видите, что весь ваш код сохранился, да, то есть, как бы он закэшировался, то есть он здесь же, и он не удалился, как это работает, как мы могли бы

340: Что делать? Мы могли бы на каждое нажатие символа отправлять запрос на backend, когда здесь что то что-то делается, каждый раз оповещать бэкэнд, кэшировать там, но это супер неудобно, потому что это огромная нагрузка на бэкенд. Ну можно было бы веб сокеты поднять, по веб сокету гонять, да, н.

341: Опять же, это очень неудобно. Есть замечательный локал сторож на фронтенде. То есть опять же, это те проблемы, которые вот когда вот есть какая-то фича, которую вам нужно разработать, и вы её обсуждаете с командой, вы можете сказать, что ребят, давайте вот это на фронте кэшировать.

342: В локальном хранилище, чтобы снизить нагрузку на бэкенд и сделать это максимально удобно, потому что не всегда данные нужно хранить на бэкенде, кэшировать, да, какие-то данные лучше хранить на фронтенде. И здесь, например, у нас

343: У нас есть специальный объектик для кэша, и мы просто, ой, и мы просто храним те чуть побольше сделаю тот код, который вы ввели, чтобы если вы вернулись к задаче, вернулись там через, через день, через 2 или

344: Через 5 секунд, случайно закрыв его, потратив до этого там несколько часов, вы легко, ну, как бы фронтендер легко отсюда его восстанавливает и вам пересылает. То есть даже если вкладка закрылась, если браузер закрылся, ноутбук разрядился, у вас все равно типа остаётся.

345: Этот код и не нужно нагружать другие уровни приложения. Приложение база кэш веб сервер сидиэн. Не нужно их как бы без особого смысла тревожить но опять же, да, опять же нужно иметь ввиду, что здес

346: Мы не кэшируем мегабайты. Здесь, в принципе есть ограничение какое-то количество килобайт, я не очень помню, но типа в local стороже нельзя закэшировать там мегабайты данных, то есть опять же всегда нужно с умом подходить к решению задач и

347: Да, это был такой пример. И давайте посмотрим ещё раз на общую схему, да, на финальную схему, как у нас выглядят вот эти слои приложения? У нас есть frontend. Да, вот там local сторож, на который мы с вами не особо влияем. Ну как бы, как там фронтендер?

348: Сделает. Ну, мы можем с ним че то обсудить, договориться, но мы не особо сильно на него влияем. Но дальше есть зона ответственности, бэкенд разработчика. Ну, то есть большинство из тех, кто смотрит, и мы можем кэшировать наши данные в приложении, да, используя редис или вообще во внутр.

349: Кэше, который мы в самом начале рассмотрели прям вот в каком-то словарике в питоне или в какой-то мапе в хэшмапе и очень быстро их отдавать мы можем кэшировать их на уровне веб сервера, используя специальные ситипи заголовки cache control на уровне

350: Cdn сервисов, если вы в большой компании, в распределённой системе, где как бы из разных точек там России или мира к вам обращаются, конечно, он у вас есть, тоже можно кэшировать данные и на стороне браузера, то есть вроде как не

351: Не очевидно, но мы можем. Мы отвечаем за то, как данные хранятся в кэше браузера.

352: Ok, пишут 5 10 мегабайт локал сторедж ну кстати, я не видел таких ограничений, но примерно примерно звучит, звучит так.

353: И, друзья, на этом основная часть закончилась. Сейчас я уделю буквально 5 минут, чтобы рассказать про курс по бэкенд разработке. И сразу хотел показать на той же схеме, что вот это вот эти части, веб сервер, приложение ре,

354: База данных как бы такой кор, да, фундамент приложений, он разбирается весь на этом курсе. Более того, мы с нуля пишем весь как бы весь стек, используем веб сервер, энджинекс, кэширование, редис.

355: База данных postgresql приложение на python на фреймворке фаст айпиай на 1 из последних версий всех технологий и используется face эйпиай, эскью, алхимия, пайдентик в общем, все те библиотеки, которые испол.

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

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

358: Используется в принципе в комьюнити разработчиков, а не что-то вот вы там написали из головы или откуда-то скопипастили что из интересного вы можете бесплатно попробовать курс, у него первые 3 3 урока доступны

359: Бесплатно с шпаргалками, с кодом, с проектами. Поэтому можно перейти к нему бесплатно и кратенько пробегусь по модулям, которые у нас есть 1. Это про асинхронность пайтон просто чтобы освежить знания, да, как у нас все работает.

360: Асинкао газер таск групп, который появился в 1 из последних версий в python, который многие на удивление не знают, это освоение фреймворка да, фреймворк это, ну это, по сути, база, без которой тяжело уехать дальше, поэтому.

361: Посвящаем 1 модуль изучения фаст эйпиай это сейчас топ 1 фреймворк по спросу на рынке труда в России и в снг.

362: Далее мы большое внимание уделяем базе данных. База данных, как бы сегодня, конечно, мы о ней мало говорили, но я думаю, вы знаете, что работа с скюэль, работа с базой данных с орм это 1 из фундаментальных навыков, и мы его

363: Закрепляем не просто, не просто так, а с использованием паттернов. Да, это репозиторий, это дата маппер, это дто. Мы изучаем, как работают. Ну, реально пишем джойны мэни, ту мэни связи.

364: Релейшн шипы как можно как бы не писать эскьюэль, а оперировать пайтон объектами python, структурами и получать довольно сложные данные, которые нужны, например, для генерирования отчётов или.

365: Каких-то структур, данных для удобных для клиентов, для фронтенда. Мы также смотрим на авторизацию и аутентификацию. Да, без этого особо никакой серьёзный продукт не сделаешь без дживет токенов, без хэширования паролей, рефреш, токенов. Как это все работает.

366: Мы делаем на реальном проекте, внедряем в тот же проект, который мы пишем. Далее, как я сказал, продвинутая работа с базой данных у нас тоже присутствует. То есть подзапросы сэте это то, что когда вот пишешь простые крудик, простые приложения, простые микросервисы. Такое бывает, к Сожа.

367: Ну, как бы, не, к сожалению, просто такая реальность. Тяжело пощупать что-то более сложное, какие-то вот сложные запросы с фильтрами, с группировками, с индексированием. И, ну, прям кайфануть от процесса, просто, просто писать селект, просто делать get, запросы, ну, как бы.

368: Сильно от этого не развиваешься. 1 из уникальных форматов, который есть на этом курсе, который я лично как бы придумал и реализовал. Это обзор реальных проектов, больших продакшн проектов на там 100000 строк кода. Ну понятно, мы не все эти 100000

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

370: Для обработки ошибок, для работы с репозиторием, для работы с базой данных, с революционной, с нереволюционной базой данных для интеграции с api с. Смотрим как интегрируется там чат gpt в какой-то сервис в общем, смотрим просто на актуальные.

371: Концепции для работы. Также мы рассматриваем, конечно, редис, о котором сегодня мы очень много говорили, и работа с фоновыми задачами через брокера селари. Отдельный блок посвящён тестированию, если кто

372: Натыкался на собеседовании, на вопросах про pytest что такое scope фикстура? Или ещё не спотыкался, но, в общем, ожидает то на этом модуле вы точно закроете это очень, довольно большой на самом деле модуль очень много сил вложил, и вы просто закроете все вопро.

373: По тестированию приложений по тестированию пайтон приложений и ближе к концу мы доводим все до production ready, чем отличаются учебные проекты от близких к продакшену. Это наличие форматировщиком, наличие стати.

374: Изаторов сильная архитектура, когда у нас многослойная архитектура, да, а не не что-то на коленке придуманное, а какие-то реально проверенные годами там, книгами и многими разработчиками подходы и паттерны.

375: Собственно, мы порядка там 5 или 6 паттернов разбираем, всего в курсе. Ближе к концу смотрим на сиайсиди, на энджинекс, о котором сегодня была речь, как это все настраивается, как это все работает через docker без докера и в конце прям вот нужно.

376: Выполнить задание без него там нельзя дальше пройти, нужно развернуть на реальный сервер свой проект и, значит, ну, как бы показать его, сеньор, разработчику. То есть у нас есть кураторы это senior и middle plus. Разработчики, которые проверяют ваши задание, как вы справились, все ли правильно сделали.

377: Если ошибки в коде, вы также проводите код ревью, если вот кто там, не было опыта работы в команде или не было опыта поревьюить кого-то здесь вы ревьюите код и вас, сеньор разработчик проверяет, насколько вы хорошо код.

378: То есть, насколько хорошо вы воспринимаете чужой код, ну и базово, если по процессу обучения, то это короткие видеоуроки, которые я записал примерно на 15 минут, там 10, 15 минут. Каждый всего, там около 30 часов, кажется, материала. То есть довольно много. Вы можете выбрать тему, которая вам

379: Нужно закрепить и закрепляете это огромное количество практики и Тестов. То есть вы закрепляете как как теорию, так и практику. Ну, самое большое количество времени уходит, конечно, на практические задачки, над ними прям нужно поломать голову, подумать, как все это решить.

380: Ну, как я сказал, да, у нас есть кураторы, у нас есть чат, в котором вам всегда ответят, помогут. Вы напишите полноценный учебный проект, с ним подробнее можно будет ознакомиться на сайте, и вы пишите финальный проект. Вот.

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

382: Проект или полноценный стартап, да, примерно там за 2, 3 недели с использованием redis, с использованием энджинекс фоновых задач архитектуры, тех подходов, которые вы изучили, чтобы вы реально их поняли. То есть, ну, 1 дело смотришь видео вроде все понятно, да, вот как сегод.

383: Сегодня, потом пытаешься применить на практике и ничего не выходит почему? Ну, потому что не было практики руки не запомнили, как бы код не печатался, а здесь вы вместе с senior разработчиком обсуждаете архитектуру, схему базы данных.

384: Какие, какой стек использовать, какие библиотеки использовать, как в микросервисах поднять лучше кафку, лучше rabbit, mq. В общем, полностью обсуждаете все те вопросы, которые вас мучают, которые вам не дают покоя, да, там чем отличается, например, кафка от rabbit, вы вот

385: Как бы некому задать. А тут Бац, 2 консультации можно взять, ну, как бы они входят в курс у разработчика и все это узнать. Ну и да, финальный проект автор курса. Это я, Артём Шумейко, сеньора.

386: Разработчик и по тарифам у нас сейчас действует 3 тарифа и новогодняя акция. И есть специальное предложение для тех, кто участвует лично сегодня на вебинаре. Сразу скажу, что у нас есть кнопка под текущим видео.

387: Чтобы можно было записаться на консультацию. То есть я понимаю, что довольно много материала. Вы можете абсолютно бесплатно просто пройти такую, типа, экскурсию, посмотреть, как это все выглядит изнутри. Мы вам покажем, расскажем, ответим на вопросы, скажем, нужно ли вам это, или там ещё не дотягиваете, или наоборот,

388: Нужно закрепить какие-то пробелы. Курс можно купить по 3 разным тарифам. Самый популярный это курс плюс проект, где есть дополнительный проект сеньор разработчиком, где есть помощь в чате, где есть там расширенный доступ к курсу и можно взять

389: Рассрочку или по полной оплате и для тех, кто сегодня присутствует, есть специальный бонус, а даже 4 бонуса это повышенная скидка по промокоду на экране. Да, если хотите, то запишите обязательно его себе в подарок идёт.

390: Интенсив по поиску работы. То есть если у вас есть какие-то сложности или непонимания, как составить резюме, откликаться на вакансии, общаться с рекрутёром, поднимать себе зарплату, поднимать оффер, проходить технические собеседования, собеседования с рекрутёром, как

391: Откликаться на зарубежные вакансии. Если у вас есть такая цель, все это рассмотрено, вы получаете полностью в подарок. Это лично интенсив, который лично вёл я в небольшой группе. Также 3 месяца доступа к тренажёру собеседований солвит, который я разрабатываю с командой.

392: И 3 дополнительных месяца обучения на любом тарифе, чтобы вы могли точно все успеть, точно получить всю обратную связь и написать полноценный проект. Да, ещё раз, друзья, скажу, что можно записаться на консультацию по кнопочке под этим видео.

393: Она прям снизу должна была появиться.

394: И также очень прошу вас оставить отзыв, обратную связь. Тоже кнопочка внизу появилась, чтобы я понял, что улучшить, что поправить, потому что это вот 2 такой опыт за жизнь было бы интересно.

395: И давайте да, бонусные материалы, собственно вся презентация придёт вам на почту и в telegram бота, поэтому ожидайте, если не придёт, то пишите нам, пришлём и давайте отвечу на ваши вопросы. Поболтаем немножко несколько.

396: Минут.

397: Так, промокод на подарки действует без покупки курса нет. То есть все подарки идут вместе с только вместе с курсом. Все 5 слоёв можно применять в приложении. Да, конечно, можно применять все 5 слоёв. То есть я показал такое.

398: Скорее такую продакшн, интерпрайз биг, тех слэш систему, в которой есть все эти слои. Чем меньше компания, чем меньше проект, тем меньше слоёв, как бы вы, в принципе можете задействовать. Но что точно вы можете задействовать, если

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

400: Данные в браузере это 100%. Мы можем использовать внутренний кэш для каких-то очень час очень часто используемых данных, но редко изменяющихся, да, какие-то справочники, какие-то вот конфиги и внешний кэш это редис.

401: Да, как я в начале говорил, кэширование на стороне кэш сайт, самый популярный подход. Когда мы сначала идём в базу, там сначала идём в кэш, если там нету, кладём в базу и записываем в кэш. Да, поэтому, друзья, вот я вот сейчас сам говорю, уже так давно был этот

402: Сайт, поэтому как презентацию пришлём, обязательно посмотрите, ещё раз, освежите все эти данные, пока они не испарились.

403: В конце курса уровень условно миддл ну, если с полного нуля, то уровень скорее условно, на 1 уровень выше вы прыгнете, то есть, если вы сейчас джуниор плюс, вы прыгнете до middle middle, плюс, если вы мидл, вы прыгнете до middle.

404: Плюс senior то есть нет такого, что-то есть каждый для себя что-то, что-то своё, что-то новое усвоит, то есть у нас много училось и джунов, и мидлов, и даже сеньоров, у нас даже видеоотзыв от сеньора есть на сайт.

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

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

407: Ошибки, но у нас есть ошибки нашего приложения, нашего домена. У нас есть ошибки фреймворка, они должны быть на своих слоях, в своих функциях, их нельзя мешать. И как бы все, я все объясняю, почему так, почему не иначе, на реальных примерах. Какой фреймворк исполь.

408: Для бэкенда солвит, конечно, в фастапи. Друзья, конечно, в фастапи какие интересные вопросы про кэширование могут задать на собесе?

409: Ну, часть из тех, что я задавал сегодня.

410: Если мы говорим про обычный технический, технический собес, там будут какие-то примитивные вопросы. Если мы говорим про систем дизайн интервью, то там знание уже кэша, сайт знание разных подходов, стратегий, инвалидации данных это то, что выделит вас крайне, очень сильно.

411: На в сравнении с другими кандидатами помощь при поиске работы есть на курсе она есть вот в этом интенсиве как раз-таки там там просто просто инструкция как вот там я очень сильно мотивирую людей, типа иди делай это, иди делай это.

412: Иди сделай это, даю конкретные шаги, чтобы нельзя было отлынивать. И, ну как бы прям такой live помощи, что я созваниваюсь, мы составляем резюме. Такого нет, но этого интенсива должно быть достаточно, чтобы найти

413: Работу, как отношусь к расту. Отлично. Классный язык сейчас набирает потихонечку обороты.

414: Нужен ли этот курс медлу? Лучше запишитесь на консультацию, тут нужно понимать, какие вот есть у вас пробелы, ну и как бы опять же, middle медлу рознь в 1 компании это мидл, в другой компании это джун или senior, даже так тяжело сказать, честно говоря, то есть я

415: Потихоньку отказываюсь от концепции грейд, от концепции грейда. В принципе, потому что есть мидлы, которые там не знают, как работать со 3 хранилищем, с брокером. Никогда не работали, чуть чуть знают там, может, про фоновые какие-то задачи.

416: Плохо с асинхронкой. Ну, в общем, у всех разный бэкграунд.

417: Так, друзья, давайте ещё несколько.

418: Вопросов.

419: Артём, эфир про жвт сессии был отличный. Да, друзья, спасибо. Как подготовить проект production опять же зависит от проекта и и как бы какой будет трафик, какая будет нагрузка, что за проект, какие там критические точки боттлнеки?

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

421: Вопрос, можно ли, допустим, сейчас приобрести, а начать проходить через 2, 3 месяца, да, так можно так делается, так делается. Ну, как бы мы видим. То есть, если вы реально там 2, 3 месяца не проходите, мы даже можем продлить потом на эти 2, 3 месяца. Ну, не всегда, но

422: Ну, как бы, 1, 1 раз мы так точно можем сделать. Спасибо большое за стрим. Да, друзья, пожалуйста. Да, вообще, как вам стрим. Да, оставьте, пожалуйста, отзыв. Очень, очень приятно было почитать отзывы к прошлому эфиру. Я все их прочитал, тоже оставьте отзыв к этому, чтобы было понятно, что

423: Улучшить. Я уже понял, что нужно улучшить техническую часть. Да, там, чтобы Лагов не было. Но я рад, что мы до конца дожили вместе с вами. Пользовался ли вью постгресса 1000 раз, и вьюшки материализованные вьюшки, мы их используем постоянно в солвит.

424: Я сюда хотел вставить сегодня, кстати друзья материализованные вью в postgres как ещё 1 как бы, ну не кэш, а вот как бы такая пре пре пре создание данных, чтобы они уже были в удобном формате, но решил, что слишком много сюда будет.

425: Что мы и так уже полтора часа здесь сидим. Спасибо за эфир. Спасибо. Спасибо, друзья. Да, спасибо. Очень приятно читать ваши комментарии. Ладно, давайте тогда будем на этом потихоньку заканчивать. И, да, ещё раз напомню, что можно оставить отзыв по кноп.

426: Внизу и записаться на консультацию тоже по кнопочке внизу на курс. Все, друзья, огромное всем спасибо за просмотр. Скоро отправим.