HTTP та його версії 🌐

HTTP (Hypertext Transfer Protocol) - це протокол, що є основою передачі даних у WEB. В цьому дописі пропоную трохи розібратися в його еволюції.

🌐 HTTP/0.9

Найперша версія HTTP була створена за ініціативи Тіма Бернерс-Лі. Насправді, в неї в той час не було номера, але з часом до неї стали звертатися як до версії 0.9. У HTTP/0.9 не було хедерів, статус кодів, а єдиним можливим форматом файлів для передачі був HTML. Запит складався з однієї строчки, єдиним доступним методом був метод GET. Респонс містив в собі тільки файл, що було запитано.

🌐 HTTP/1.0

1.0 була націлена на усунення лімітацій попередньої версії. Тепер при респонсі ми стали отримувати статус коди, що дозволило браузерам реагувати не них належним чином. З’явилися хедери, що зробило можливим уніфікацію передачі метаданих. Також завдяки появі хедеру ‘content-type’ стало можливим передавати не тільки файли типу HTML.

🌐 HTTP/1.1

Це перша стандартизована версія HTTP протоколу. Крім цього, вона впровадила декілька важливих змін. Ми отримали змогу мати keep-alive connection, pipelining, а також розбиття респонсу на чанки, що знижувало затримку в комунікації. Клієнт і сервер могли домовитися, який вміст обмінювати (мова, кодування, тип). HTTP/1.1 був відносно стабільним протягом 15 років.

🌐 HTTP/2

Основні зміни, впроваджені в рамках цієї версії, були спрямовані на перформанс. Потокол став бінарним, а не текстовим як в HTTP/1.x, що дозволяє впроваджувати вдосконалені методи оптимізації. Завдяки його мультіплексійності, паралельні запити можуть виконуватися через одне з’єднання. Також тепер ми стали стискати заголовки, що усуває дублювання та зменшує обсяг переданих даних.

🌐 HTTP/3

Семантика цієї версії така ж, як у попередніх. Основною відмінністю стало використання QUIC замість TCP, що зменшує затримку HTTP-з'єднань та запобігає блокуванню всіх потоків у разі втрати пакетів.

Пропоную вирішити класичну інтервʼю задачку по тому, як працює контекст в javascript

Ваші відповіді, та (важливо) пояснення чому так працює пишіть в коменти)

Я на свята буду скоріше за все зайнятий, а мені є що сказати - то ж не буду стримуватися.

По-перше. Дякую. Дякую спільноті та особливо тим хто прямо допомагав в цьому складному році - @babich_ss, @fwdays, Skelar, @olenitut та інші. Ви допомогли тоді, коли це було потрібно, а це найбільш цінно. То ж дякую ще раз, вірю що ще зустрінемося за келихом кави, просто трохи пізніше.

По-друге. Ми так і не навчилися спілкуватися. Нажаль я не можу передати вам свій досвід на службі, а ви не можете передати як то шукати роботу два роки і не знаходити. А зараз від цього буквально залежить виживання нашої держави. І заклики "гуртуйтеся", "готуйтеся", "не сріться", не працюють. Особливо коли умовно свої ж підпалюють машину звичайної людини, аби вона вийшла.

Для мене початок війни асоціювався з піснею Меч Арея. Сильна пісня про людей що стали на захист своєї сім'ї та країни. Але, нажаль зараз це більше схоже на Sleeping in The Cold Below, - пісню прощання.

Тому, перед цими святами, я хочу побажати всім нам уміння розумітися один з одним та підтримки. Є такі шляхи які одна людина подолати не може. А от разом з товаришами, з друзями, зі спільнотою - це може стати дійсністю.

На цьому у мене все, всіх обнімаю, побачимося потім,
Ваш зампомиш

П.М. Коли буде трохи вільного часу - запишу вам нове відео на ютуб, вже знаю про що.

SOLID частина 1

Пропоную поговорити про принципи солід. Цей концепт був вперше представлений у 2000 році Робертом Мартіном, і він все ще не втрачає своєї актуальності. Тут ми не будемо сперечатися, чи потрібен він нам чи ні, бо SOLID дійсно може бути оверкілом для нескладних проектів. Тим не менш, маючи в голові ці принципи, легше писати гарний код. У цій серії дописів розберемо окремо кожен принцип і подивимося на нескладні приклади його застосування.

Перший принцип - SRP (single responsibility principle). За цим принципом, в класа (функціїї, модуля і тп) повинна бути тільки одна зона відповідальності і одна причина для змін.

Розглянемо приклад:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  getUserInfo() {
    return `Name: ${this.name}, Email: ${this.email}`;
  }
}
class NotificationService {
  static sendEmail(email, message) {
    console.log(`Sending email to ${email} with message: "${message}"`);
  }
}

const user = new User('Alice', 'alice@example.com');
console.log(user.getUserInfo());
NotificationService.sendEmail(user.email, 'Welcome to our platform!');

В коді можемо подивитися невеликий приклад SRP в дії. Ми маємо бізнес задачу - реєструвати юзера і відправлять йому імейли. Початково під час розробки є бажання інкапсулювати цю фічу просто в один клас (функцію). Тобто юзер би і дані юзера записував і імейли відправляв. Але це порушує SRP. По перше, в User більше однієї зони відповідальності (і юзер і імейли). По-друге, в нього більше однієї причини для зміні - щось змінилося в логіці реєстрування юзера або змінилися реквайременти для емейлів. Розділяючи це на два класи, ми дотримуємося SRP. Можна ще створити RegistrationService який би керував процесом реєстрації за допомогою цих двох класів.

Антипатерном принципу Single Responsibility є God Object. Це коли один клас (об’єкт) знає про всю логіку великої фічі/додатку.

Логічний оператор && в #react

Часто* бачу використання логічного && в React для виведення на екран якогось контенту з умовою. Наприклад десь так:

logged && <Greetings/>

І, зазвичай все йде добре, а поки в нашу умову не потрапляє 0. І тоді замість "нічого" ми побачимо 0

Що робити? Або використовувати тернарний оператор разом з null

logged ? <Greetings/> : null

Або, просто перетворити logged на true/false за допомогою !!

!!logged && <Greetings/>

Так і код буде коротшим, і проблем не буде.

П.М. Так, я повернувся з відрядження)
П.П.М. * Ну зараз не часто, але раніше було, це правда 😃

Анонс прямого ефіру 🤩

Мені дали відпустку, так що якщо нічого не станеться то:

Коли: 28.01.24, о вівторок, о 19:00 (через 10 днів)
Де: Ютуб, не забудьте підписатися
Про що: Пет проекти, як доводити їх до кінця і чи потрібно це взагалі.

Буду вдячний за поширення і всіх чекаю.

П.М. Я ж казав що буде нове відео :)

Подкасти повертаються! Уже цього четверга відбудеться запис випуску на тему "Хто такі, курвамать, ті синьйори, як їх відрізнити від нормальних людей і чи варто ломиться в синьйори усім поголовно".

А допоможе мені розібратися в цій темі неперевершений Нікіта Галкін, найбільший експерт з NodeJS, якого я знаю, справжній системний архітектор (не то шо я), Google Developer Expert і просто неймовірної душі людина.

Обовʼязково поговоримо про те, кому нафіг впали грейди в компаніях, які навички треба, аби вважатись гідним високого звання старшого розробника, як з личинки джуна перетворитися на прекрасного синйьора і чи дійсно потрібно усім прагнути до цієї карʼєрної сходинки.

ВАЖЛИВО
1. Запис буде. Але згодом. Змонтований.
2. Під час етеру будемо збирати донати на ЗСУ та розіграємо подарунки
3. Виключно під час етеру ви матимете нагоду поставити своє запитання гостю
4. Ще раз: запис буде викладено згодом, відредагований.
5. Приходьте на етер, буде цікаво ;)

23 січня, канал "Сергій Бабіч та Дивовижний світ веброзробки", 19:00

.

Питання зі світу #React і, якщо дуже не пощастить, співбесіди:

Коли ви не можете використати <></>, а змушені використовувати <Fragment>?

Коротка відповідь:
Тоді, коли нам потрібно використати властивість key, яка не існує в <></>

Довга відповідь:
У React компоненті, може бути лише один нащадок нащадок першого рівня. Але, іноді, нам потрібно їх декілька, і раніше нам доводилося створювати зайвий елемент, просто для групування. Це призводить до засмічення коду та появи зайвих елементів в DOM.

Для того щоб із цим боротися з'явився компонент <Fragment>, який потім спростили до конструкцію <></>. Але ця конструкція не може мати атрибутів, в тому числі key який потрібен під час генерації списків. І ось тут то і може стати в нагоді старий <Fragment:

[].map((user, i) => <Fragment key={i}>{user}</Fragment>);

І тут постає ще одне питання - чому ж не винести це в окремий компонент, на якому ми зможемо використати свій key? Як ви думаєте?

Про пет проекти - їх потрібність, як обирати тему і як довести все до кінця - поговоримо вже завтра, 28.01 о 19:00 в прямому ефірі на ютубі

Приходьте, буде цікаво. І завжди вдячний за поширення 😉

П.М. Буду вдячний якщо пошерите в LinkedIn

Невтомлююся радіти людям поруч зі мною. Провів чудовий день разом з @FwDays, які вчергове не відмовили допомогти нам зі збором. Хлопці, дівчата, вся ваша команда крута та неймовірна! Та й і програма була цікава, особливо сподобалася остання доповідь.

П.М. Сподіваюся наш маленький інтерактив нікого не розлякав) Якщо так то на наступну конфу ще щось придумаємо)
П.П.М. Респект Serhii Nemchynskyi за доповідь Українською, дуже круто!
П.П.М. Живий, здоровий, часу на ТГ майже немає :( Але прорвемося!

Повернемося до #React. В #reactrouter є цікава можливість - винесення завантаження даних на рівень роута

Це може спростити ваш код оскільки тепер за обробку помилок а також за обробку стану завантаження буде відповідати код роутера.

Якщо виникне помика - буде показаний errorElement
Поки код буде вантажитися - буде показаний hydrateFallbackElement

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

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

Можливо систему зі складними правилами інвалідації кешу на ньому не побудуєш, але для простих застосунків можливість цікава і зручна. Ну і так, трохи холіварна))

Так панство, тут Genesis Front-End School відкриває безкоштовні курси з побудови фронт-енд застосунків.

З плюсів - в теорії можуть після навчання можуть взяти на роботу
З мінусів - відбір, який треба буде пройти: HTML, CSS, JavaScript/TypeScript, React. Але думається мені ви впораєтеся (або дехто взагалі ментором туди піти може 😅).

Дедлайн 13 квітня, старт 19 травня.

Як на мене звучить як варіант (правда умов контракту я не знаю, якщо там треба буде продати душу, то будь-те обережні, душі річ цінна навіть в поточному перебаханому сьогоденні)

Тут деталі, якщо хтось влаштується буде супер.

П.М. Вибачайте що контенту мало, тексту мало, всього мало. Телеграму під рукою немаю, бачу його вряди годи (лінкедин і то частіше). Та й трохи втомлююся якщо чесно. Останнім часом все дуже нервово і не просто. Напевне війна...

Тримайтеся. Дотянемо, переживемо і ще посидимо на березі річки....
Всіх обняв, ваш ЗамПоМиш

Початкові налаштування нового #react проекту

Видаліть все зайве - зайвий код, зображення, іконки, тощо.

Передивіться вже встановлені залежності коду і перенесіть в секцію dev ті залежності, що призначені для розробки (eslint, prettier, jest). Це буде корисно коли/якщо ви будете налаштовувати npm audit --omit=dev`

Налаштуйте форматування за допомогою prettier

та одразу застосуйте його з прапором --write. Досить сперечатися про крапки з комами.

Встановіть і налаштуйте лінтер - eslint під себе, або за правилами команди. Наприклад для не використаних змінних я ставлю warning замість error, не так сіпається око.

Встановіть та налаштуйте систему хуків для git - husky. Так ви зможете виконувати будь-які додаткові дії перед/після коміту/пушу. Наприклад ви зможете налаштувати husky автоматично запускати форматування staged коду. Тепер код у всіх і завжди буде виглядати одноманітно і без зусиль.

Напишіть readme - Два речення про що проект, як встановити залежності (навіть якщо це тривіальний npm install бо може бути і yarn install), як запустити dev збірку, та які правила ви налаштували (а в ідеалі ще й чому)

Все, можна плисти далі.

Але якщо хочеться більшого то... це буде в наступному пості :)

П.М. Амеліансе, я пам'ятаю що ти не фанат прітієра, та поки краще не зустрічав)

Продовжуємо серію про налаштування #frontend проекту і тепер потурбуємося про #websecurity.

1. Перевірте, що файл .env.local або його аналог не доданй під git. Так ваші паролі або токени не потраплять в мережу, а ви не отримаєте додаткові рахунки. Всі ключі/токени/паролі які ви використовуються мають зберігатися окремо або в key vault, або хоча б на білд машині яка готує реліз.

2. Налаштуйте перевірку ваших залежностей за допомогою команди npm audit. Ця команда покаже вам пакети, що містять вразливості та допоможе оновити їх щоб це виправити. Для того щоб було менше false positive спрацювань:
- - Перенесіть в dev секцію вашого package.json файлу всі залежності що стосуються розробки - prettier, eslint, jest, і т.д.
- - Використовуйте npm audit з прапорцем --production або --omit=dev.
- - Передайте привіт create-react-app :)

Гарною ідеєю буде інтегрувати цю перевірку в merge фазу пулл реквесту. Або раніше якщо не хочеться все перероблювати :)

3. Безпека runtime. Через особливість налаштування, частіше цим займається команда інфраструктури або бекенду, але частково це можемо налаштувати і ми. Особливо якщо у нас щось накшталт #nextjs

Мова йде про основні безпекові заголовки - Content-Security-Policy (CSP), X-Content-Type-Options, Feature-Policy. А якщо ви ще й піклуєтеся про приватність ваших користувачів то й Referrer-Policy. В разі правильного застосування, за заголовки можуть запобігти або суттєво зменшити шкоду користувачам вашої веб сторінки.

Детальніше про ці заголовки та як їх налаштовувати я розповім в наступному пості, бо лонгріди ж ніхто не читає)

Ваш ЗамПоМиш.

П.М. Ви тут як? Бо останнім часом такий цирк на дроті що голова обертом.

Всім привіт!

Кажуть що збори загинаються, люди перестали підтримувати #ЗСУ. А у мене завтра #деньнародження, мені потрібна ваша допомога щоб повернути в стрій наше авто. От і давайте перевіремо. В 22 році з цим не було ніяких проблем, кожен допомагав чим міг. Подивимось що буде зараз :) Отже, на мій день народження, замість купляти собі стім дек, оголошую збір на ремонт зеленого буцефала - нові передні амортизатори (9000) та нову резину (16000). Бо аморти убиті в хлам , а резина лиса як більярдна куля та дірява як друшляк. Буду дуже вдячний за вашу допомогу. Звіт буде під цим постом.

П.М. Стрім обіцяти не можу, але постараюся організувати це найближчим часом.

👉Монобанка тут

Ваш ЗамПомиш,
#ЗСУ #ДеньНародження

Збір закрито, в чому я й не дуже сумнівався. Дякую всім за підтримку та свідому позицію.

А тепер серйозно.

Перемовини гальмуються не просто так. За підтримки трампа, русня вибила можливість заморозки фронту по лінії зіткнення (так, трамп зараз грає на боці русні, йому це просто вигідно). русня накопичила сил та літню кампанію через це зараз зупинятися їй просто немає сенсу. Тому, як мінімум літньо-осінню кампанію ми побачимо. Розвідка Америки взагалі прогнозує повторний наступ на Київ. І від того як нам вдасться відбитися - будуть залежати умови завершення війни.

Тому, будь-ласка, підтримуйте армію. Бо саме я з вами і є армія. Немає цивільних та військових. Є лише ті хто готовий захищати свою країну. І тут ми з вами маємо бути єдині.

Всіх обіймаю, поїхав купляти собі нові штани)

П.М. А це я - в багажнику бусіка. Не так там то і погано з кавою)

Отже про заголовки #websecurity для #frontend

Заголовків багато, різних, та нас цікавлять наступні:

1. Content-Security-Policy. Уявіть простий сценарій. На вашій сторінці знайшли XSS взраливість (треба про це розповідати?) і вбудували туди свій код. А він бах - і не працює. Чому? Тому що за допомогою CSP ви можете заборонити виконувати вбудований код. Тоді зловмисник може спробувати підвантажити код зі стороннього ресурсу. А це теж не працює, тому що ви обмежили завантаження JavaScript своїм доменом. Так само ви можете задати правила для будь-якого ресурсу - хоч JavaScript, хоч зображення, хоч CSS.

Що цікаво, що для налаштування цього заголовку вам не потрібно турбувати бекенд. Ви можете вказати його за допомогою тегу meta з властивістю http-equiv="Content-Security-Policy"

Правда є з ними і проблеми - складність налаштування (раджу використовувати CSP builder) та конфлікти з Google Analytics домен якої залежить від регіону. Відповідно вам доведеться додавати всі піддомени гугла у white list. Таке собі.

Детальніше почитати можна тут

2. Другий заголовок який нас цікавить - X-Content-Type-Options

Цей заголовок забороняє браузеру тип змісту ресурсів що завантажуються. Це протидії наступній цікавій атаці. Уявіть собі що ви налаштували CSP і заборонили виконувати JS. Зловмисник це побачив і замість файлу з content-type text/javascript відправляє той самий JS але не вказуючи тип. Деякі браузери (не всі), можуть спробувати подивитися в зміст файлу, і спробувати самостійно визначити його тип. Якщо тип буде визначено як JS цей файл буде виконано в обхід CSP.

Заголовок X-Content-Type-Options забороняє браузеру "вгадувати"

Нажаль, для цього заголовку, немає http-equiv, тому віддавати його має саме бекенд

Детальніше можна почитати тут

3. Третій заголовок - Feature Policy або його менш підтрумувана версія - Permission Policy. Тут все просто - цей заголовок вмикає/вимикає певні фічі WebAPI. Наприклад, якщо вашій веб сторінці не потрібна камера, ви можете повідомити браузеру що її вмикати взагалі заборонено. Якщо хтось таки зможе вбудувати XSS у вашу сторінку, камеру увімкнути він все одно не зможе. Так само можна вимкнути геолокацію, оплати, тощо. Це може захистити ваших користувачів раптом щось піде дуже не так.

Налаштовується лише через бекенд, детальніше можна подивитися тут

Заголовків ще є, наприклад X-Frame-Options, Referrer-Policy. Раджу їх також подивитися.

А у мене поки все, дякую всім хто дочитав.

От бачите, не подбали трохи за безпеку і вже в сибіру палає.
Хай там навіть 20 літаків пошкоджено, але це просто найсильніша операція ССО у світі за якою можна знімати фільми будь-якого рівня.

Вітаю всіх причетних, та й нас звісно)

А ви будьте уважні, наступні тривоги не ігноруйте.
Побачимося, почуємося :)

Ваш зампомиш.

Харків, співчуваю. росії байдуже кого вбивати. Власне їй навіть на своїх глибоко байдуже.

А з КАБами зараз можна боротися лише вибиваючи їх літаки. Робота ведеться але це займе час.

Харків, тримайся(