Шагал тут на днях и подумалось - вот было бы окнорм, если бы аишечка определяла перфоманс отдельно взятого человека и его влияние на прибыль компании. Мммм? Звучит же! Столько народа сразу можно увольнять к ебенифени ))) Сразу станет понятно, кто компанию на разных уровнях тянет ко дну.

Правда в таком деле - миллион параметров (от внутренних, до внешних), это примерно как погоду предсказывать, но "по верхам" в целом можно же. Ведь любые действия имеют последствия, условный граф с миллионами ветвей и пересечений с другими такими же графами. Теоретически, возможно. Особенно если срезы делать по тайтлам. Чем выше тайтл, тем больше "эффект" от действий. Но наше дело маленькое в большинстве случаев - апишечки, формочки, архитектурки. Если иметь какой-то референс, основанный на других похожих бизнесах/решений... и это тоже теоретически возможно "оценить". Ну не рокет саенс же. Если можно нанять по человеку на каждый такой "экшон" = "коммит изменений", (где под коммитом принять всё - от строчек кода до имплементаций процессов и бизнес решений) и детерминировать до мелких шагов, где каждый шаг - условное "ребро" графа со своим "весом эффективности", то можно и картинку уже нарисовать. А если можно выяснить, значит и аишечка сможет.

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

В общем, я ещё раз подумал - я против всей этой АИ движухи! Все на улице окажутся, даже эффективные 😂😂😂

Но если кто хочет вложиться в такой стартап - высылайте мне деньги, я попробую на ноде написать. Кто знает, есть готовый NPM пакет? 😂😂😂

Шутки шутками, а я верю, что так и будет ⌨️

Ловите пару неплохих докладов про GraphQL

https://www.youtube.com/watch?v=YgRmgHPTXr4 - доклад 2017-ого, но по прежнему актуален, докладчик очень живой и сама презентация хороша с примерами на Java.

https://www.youtube.com/watch?v=3fHKySh07ow - доклад с HighLoad конфы (этого года), где пацаны рассказывают как переводили Яндекс.Афишу (+кинопоиск) на GraphQL - он уже чуть более сложный (но в рамках), скорее для мидлов/помидоров.

Оба примерно по часу 🍌

У меня сейчас проект на GraphQL. Что я могу сказать - интересная технология, но её нужно правильно готовить. Уже собрано прилично граблей и костылей.

Одни проблемы REST Api она решает :
- больше контроля над схемой
- "клиентам" проще создавать чуть более гибкие запросы при надобности
- уменьшает кол-во передаваемых данных по сети (клиентам-мобилкам зайдёт)

Но как по мне бОльше проблем создаёт :
- Проблема с N+1. Это когда у вас вместо батч запросов, двиг графа бегает в базу за каждой энтитей (тут есть решение, но он тоже компромиссное если у вас serverless - DataLoader)

- Кеширование. GraphQL строится ПОВЕРХ http и у вас все запросы бегут по одному урлу - невозможно использовать стандартные механизмы http кеширования (заголовки, прокси и тд)

- Отслеживание перфоманса запросов. Какие-то тулы уже умеют в парсинг запросов, но скорее всего вам нужно будет писать свои костыли

- Версионирование. Довольно большая проблема с back-compatibility изменениями моделей - эт боль. GraphQL придерживается "эволюционного" подхода с помечанием полей как deprecated, но если связи/изменения обширны - это превращается в ад. Ну и если вы изначально плохо спроектировали АПИ - вам пиздец. Но это и к restApi относится.

- Security. Природа GraphQL подразумевает provisioning = клиент знает и может посмотреть все доступные методы/модели. С одной стороны плюс (тот же сваггер можно пользовать для реста), но выставлять весь апи, простите - ГОЛОЙ ЖОПОЙ во внешку... ну так себе идея. Вот ребята во втором докладе костыли впилили, посмотрите - интересно. Если у вас открытй API, будьте готовы, что злоумышленники изнасилуют вас всеми возможными способами и с большой вероятностью найдут граф, который вызовет отказ в обслуживании, чем ёбнут вам весь сервер. Ну т.е. за этим реально следить нужно.

- Опытность команды. Нужно понимание ВСЕМИ в командах/стримах как это работает и вообще идеологию GraphQL, иначе у вас там ТАКАЯ КАША будет, что все профиты от технологии быстро нивелируются.

Но фейсбук живёт с этим как-то, как и нетфликсы всякие, но где мы все и где эти все фаанги.

В общем, шансов стрельнуть себе в ногу с GraphQL реально много, но инструмент, безусловно, интересный. Если у вас есть опыт работы с ним - пишите в комментах, интересно почитать.

Всем хороших выходных! ⌨️

Давайте поговорим про JWT 😕

Нахера вам эти access_token и refresh_token и как это всё работает?

Залетел мне тут от друга вопрос - зачем нужен refresh_token в JWT? И что вообще такое это ваше ДЖЭВЭТЭ, блэт???

О JWT чуть ниже, а ответ на первый вопрос казалось бы лежит на поверхности - "Ну эээээ, чтобы забрать новый access_token". Ответ верный, да только ясности не добавляет зачем хромому костыль, ведь можно просто ... скажем хранить access_token с каким-то там expiration и проверять каждый раз. Да?

Нет.

Я пятнадцать лет гребу, а пришлось три часа убить чтобы раскопать этот вопрос. Стыд и срам, конечно, но что поделать. Реально очень смешно, что какую статью не начни читать - там 100500 мнений зачем КОНЦЕПТУАЛЬНО нужен refresh_token. Разбираемся 😊

И так, JWT (Читается кстати не ДЖИВИТИ и не ДЖЕЙ ДАБЛВИ ТИ, а ДЖОТ!) - Json Web Tokens стандарт бла бла бла. В википедии сходите почитайте!

Если короче - это такой хитрый джсончик, который состоит из хедера, body и подписи. И нужен для того чтобы гонять его с сервера в браузер и обратно. Для аутентификации запроса пользователя.


Как это работает. На пальцах.

Смотрите, вот логинится пользователь на сайте. Вводит логин и пароль. Мы бежим в базу, проверяем что да, такой пользователь и правда валяется, а ... что дальше? Ведь чтобы получить доступ к личному кабинету и API личного кабинета на сайте ... нужны эти логин и пароль. Мы же не можем просто сделать редирект и дальше не проверять запросы, ведь нам важно понять в КАЖДОМ запросе - а этот ли пользователь его шлёт? Или другой? А какой конкретно?

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

Поэтому2. Мы на сервере генерируем JWT токен, засовываем в него айди пользователя и ... подписываем получившийся JSON'чик секретным ключом, предварительно сгенерировав его и положив в какой-нибудь конфиг на сервере. В итоге, наш JWT состоит из Header'а с деталями алгоритма, из "тела" с айдишкой пользователя и каким-то хэшем на конце (подпись). Вот тут можно поиграться и посмотреть на структуру : https://jwt.io/

Важно понимать, что сам токен может быть прочитан КЕМ УГОДНО, т.к. все эти данные - открытые, не шифрованные (именно поэтому в JWT никогда нельзя засовывать sensitive data без предварительной шифровки). Но я же могу подменить тот самый ID и тем самым подменить пользователя - скажете вы. Но нет. Не можете. Для этого вы поменяете Body, а вот ХЭШ, который находится в конце - не сможете, т.к. не знаете секретного ключа сервера. В отличии от самого сервера, который может получить такой токен и проверить, что Body подписан правильно (применив свой секретный ключ и сравнив с "хвостом" токена).

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

На сцену выходят access и refresh токены!
Смысл их в том, что при помощи них мы сможем понять - а не пора ли нам снова закинуть пользователя на логин страничку?А так же не позволить злоумышленнику выдать себя за нас. Но зачем оба?

(Вообще, я тут конечно немного помиксал Oauth и JWT, т.к. первый как раз и использует токены, а второй самодостаточный, однако вместе они друг друга дополняют... не забивайте голову).

⬇️Продолжение чуть ниже⬇️

⬆️Начало выше⬆️

access_token - это такой токен, который мы можем проверить, что он был подписан секретным ключом сервера (см. Асимметричное шифрование, я делал пост о том как оно работает). Вообще.. это ровно то, что делает JWT токен сам по себе, так что наш JWT и будет сам по себе являться уже Access_token'ом. Но просто знайте, что в мире Oauth вы можете и сами "скрафтить" всё то же самое, просто JWT это стандарт. Обычно, "живучесть" этого токена небольшая. Именно это свойство позволяет гарантировать, что даже если злоумышленник украдёт его - "доступа к апи" у него останется на n минут, если он вообще сможет вовремя им воспользоваться. +у него не будет ни пароля ни логина. Идеально! Вне мира JWT, это вполне может быть "Bearer {access_token}", что часто и бывает.

refresh_token - а этот токен нужен для того чтобы когда истёк access_token, мы сбегали на сервер и взяли новую пару "access+refresh". Срок протухания этого токена уже может быть и день и десять и месяц - зависит от бизнеса.

В чём соль-то?
Трюк тут в том, что получив при логине эту пару токенов вы

а) Сохраняете refresh_token на сервере и привязываете к пользователю.
б) Зашиваете refresh_token в ПАМЯТЬ (если у вас SPA приложение), или в Local Storage (он не передаётся на сервер с каждым запросом) или как вариант - ставите куку с ограничением, что слаться она может только по урлу запроса новой пары токенов. Суть в том, что этот токен НЕ БЕГАЕТ в разные API, он ждёт своего часа, а именно - когда протухнет access_token.
в) Все запросы из браузера теперь бегают с access_token (в нашем случае с JWT). В JWT "зашиваем" expiration_date. Как только мы понимаем, что JWT "протух", сразу же кидаем 403 (Forbidden) и клиент бежит за новой парой токенов. А этот уже становится невалидным.
г) Как только клиент (браузер) получает 403, он сразу же копается у себя в памяти/куке, достаёт сохранённый refresh_token, бежит на какой-нибудь /authenticate_token, где сервер валидирует JWT токен, достаёт оттуд юзера, смотрит в базу (или кэш), сопоставляет с присланным refresh_token (а так же проверяем не стух ли refresh) и если всё совпадает - прекрасно! Выдаём клиенту обновлённый. Если рефреш стух или мы отозвали все токены из базы (просто удалив), то кидаем клиенту допустим ошибку 401 (Not Authorized) и клиент уже понимает - всё, тут уже без странички логина не обойтись.

Фух. Объяснил на пальцах, так объяснил. Ну... как есть, ребят 🙃

В общем, JWT нужен для "подписи" данных, чтобы быть уверенным, что браузер не подменил инфу, которую мы "вшиваем" в json и гоняем между сервером и клиентом, а токены - для того чтобы злой дядя не воспользовался этим JWT и не представился вами. Всё просто 😊

Спасибо за внимание и лайк не забудь 😁

⭐️ [экшон рекваред]

Пашка Дуров запилил сторисы для каналов. Зачем - вопрос хороший, конечно, но пусть на него другие отвечают. Мне интересно другое. Чтобы включить у себя такую возможность - канал нужно "забустить". А делать это могут только подписчики с прем аккаунтами. Я вам тут по пальцам своей руки пересчитал, всего 28/310 с премом (ну.. если считать тех, у кого в никнейме в конце эмоджи есть).

Забавно, что чуть больше года назад я считал и среди вас было всего 1.9% с премом, а сейчас аж 9! (хороший рост у канала кстати, всего минус 7 человек за год 😁. Считаю это успехом. Спасибо ❤️!)

Так вот это. Давайте вы мне буст (я просто ачивки люблю, так-то и даром не нужно), а я вам смешную сторис из своего опыта вспомню.

Вам нужно обновить телегу до последней версии и жмякнуть "Boost" под этим постом. Ну или перейти по этой ссылке : https://news.1rj.ru/str/ITrower?boost

Upd : первого уровня достигли ❤️ сторис запилен 🤡
Upd2 : и второго!
Upd3: до 4-ого бустанули. Аще вы люди-коты, конечно. Пасямбр!

Диди Мадлоба, Генацвале! 🥰

Норм люлей аллегровскому джуну достанется в понедельник.

Но сами виноваты, не нужно заставлять гребцов по выходным работать 🤡

Чё там с санкциями в РФ относительно IT? Каков импакт?

Интересный доклад опубликовали на канале Highload++, о том как крупные игрроки в РФ пытаются справляться с недостатком персонала, железа для серверов и датацентров после начала войны. (спойлер - так себе. дважды ха)

[55 мин] https://www.youtube.com/watch?v=eRv_psKxbI0

В двух словах, кто не хочет смотреть :

Железо :
- многое стало x2-4 дороже
- что-то заменяют неочевидными вещами из других отраслей (ЖД, Авто), допиливают напильниками или же им обещают, что вот-вот допилят
- всё что сделано импортозамещением сейчас бустится на глазах, туда льют много денег
- обходят санкции через Казахстан и другие *станы. +шёлковый путь (параллельный/серый импорт)
- есть ипортозамещение серверов, но у них одна общая проблема - компонентная база. Если память еще могут какую-то сделать (нет), то чипами владеют Интел, Амд и Армы (Англия) - все они не хотят работать с РФ. С памятью чуть проще - Hynix и Samsung - Азия условно, и Micron (Америка). Памяти делают очень много для мира + основные идут из Азии, она попроще к санкциям относится условно. Поэтому РФ в целом "хватает", узкого места тут нет. Похожая ситуация с SSD.

Софт :
- самая тяжёлая ситуация - с ПО. Microsoft - официально уже не купить офф лицензию (а если и есть, то лицензируют не на РФ). Oracle ушёл. Sap ушёл. VmWare уходит. Всё это нужно замещать - эти вопросы еще не решены, предстоит решать в ближайшие год-два.

По персоналу :
- много аутсорса уехало и увезли с собой многих лучших спецов. Осталось куча джунов. Мидлы и сеньоры уехали. "Возрастные сеньоры" в целом остались.
- конкуренция выросла на внутреннем рынке.

В целом - ландшафт этого всего что описано выше - меняется раз в неделю.

Импакты : цену увеличились в среднем х2 (затраты), операционные выросли на 20%, относительный кадровый голод хороших специалистов.

Интересная ситуация с б/у оборудованием : многие начали активнее использовать, но и до этого была практика. Главная проблема в том, что б/у = старое, а старое = более прожорливое/медленное/тяжёлое = проблемы с современными датацентрами, которые заточены не под это уже.

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

Ах да, и главный вывод - нехуй войны начинать 😤

Вводная в текущие реалии WEB3 и TON (Telegram Open Network) 😎

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

Честно говоря, после просмотра я даже немного "поджёгся" идеей пройти бесплатный курс гостя и немножко пощупать TON и может быть даже написать какой-то супер-простой смарт-контракт! Выглядит это всё очень интересно и амбиционзно. Но после того как закончу другой свой мини-хобби проект 😁 (забавно, что он тоже с телегой связан, потом может расскажу если доведу до прода)

В общем, строго рекомендую. Длится видео чуть больше трёх часов - лично я его за два раза прекрасно "проглотил" прогуливаясь по городу. В комментариях к этом посту оставлю mp3 выпуска (так же можно скачать у бороды, но у него там какой-то формат не эмпэтришный, ап2ю в общем).

Ссылка на ютубчик

🎹 Сколько процентов занимает AWS в мировом облачном хостинге? А Ажур? А на третьем месте кто?

Коротенькая интересная статистика из предыдущего радиота [6 минут]

В комментариях mp3 версия

💻 Немного про оптимизации в Telegram API

В последнем Радиоте (ну да, задолбал я уже вас им, что поделать. терпите) ребята за тему ботов в телеге начали перетирать и зашла речь про эмоджи, которые клиент тг видит (ну и вы соответственно). И через официальный API для ботов нельзя вытащить из поста/сообщения кол-во и вид эмоджей.

Но ведь клиент как-то их получает, а протокол условно открытый. Т.е. Telegram Client API имеет доступ к этой информации, но с хитринкой. Оказалось, что разработчики соптимизировали этот момент и клиент вытаскивает эмоджи к сообщениям только тогда, когда вы на них смотрите!

Однако в рамках приходящих Updates на клиент вы их не словите, т.е. работает это путём не notify'я клиента, а путём дополнительных запросов к серверу тг. Погуглив - так и есть. Про лимиты ни слова, но что-то мне подсказывает, что так можно и бан получить, если часто запрашивать.

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

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