Ми всі любимо ReactJs за його продуктивність рендеринга, модульність і свободу, яку він дає вибрати ваш стек. Але є одна річ, яка робить це виділенням. Відображення на стороні сервера . До реагування більшість фреймворків javascript зосереджувалися на створенні єдиних прикладних програм і зробили дуже велику роботу. Але зараз це 2016, ера гібридних додатків! Програми, які можуть працювати за межами середовища веб-переглядача . React розпочав тенденцію, підтримуючи рендеринг на стороні сервера, що дає нам змогу створювати скрізні програми для JavaScript.
Трохи фону
Зараз я працюю Практичне здоров'я місце, де лікарі та фахівці з охорони здоров'я пишуть статті про здоров'я та діляться своїми знаннями. Якщо ні, то будь-яка платформа для блогів повинна бути найкращою в одній: SEO . Будь-який блог з хорошим SEO приречений, щоб отримати більше читачів, ніж хто-небудь ще. І більше читачів означає більше SEO!
Щоб отримати кращий SEO, вам доведеться робити багато речей правильно. Але тут ми будемо говорити лише про найважливіші два, найбільш фундаментальні для хорошого SEO:
- Створення вашого сайту для сканування ботів .
- Зробіть його БАШНІМ . Любіть Millennium Falcon швидко!
Входить Реакція!
Коли React вийшов, одним з його пунктів продажу було те, що він підтримував рендеринг на стороні сервера (SSR). Для того, щоб ваша програма підтримувала SSR, все, що вам потрібно, це сервер вузлів і API . Сучасна архітектура виглядає приблизно так:
Зверніть увагу! Сервер вузлів виступає як посередник між користувачем і сервером API. Таким чином, потік проходить так:
- Користувач потрапляє на URL, запит надходить на сервер вузлів .
- Сервер Node робить запит на API сервера і приймає дані з сервера API .
- Виштовхує дані до APP , що створює кінцевий HTML для користувача.
- Повертає користувачеві рядок HTML .
Тепер вся установка виконана! Сервер приймає запити, API дає відповідь і, нарешті, користувач / боти отримують повністю відтворену HTML-сторінку. Але це може виявитися кошмаром користувача .
Питання!
- Що робити, якщо сервер API повільний ! Як 500ms час відгуку.
Однією з проблем з рендерингами на стороні сервера є те, що час відгуку значною мірою залежить від часу відповіді API сервера. Це означає, що незалежно від того, наскільки ефективним і швидким ви зробили додаток, користувач побачить білий екран для принаймні 500 мс, якщо ваш сервер має час відгуку 0 мс. Що практично неможливо (на даний момент).
Тож давайте подивимося на розбивку:
- Час відгуку 500 мс від API
- 150 мс для рендерингу на стороні сервера (так, це займе дуже багато)
- 10 мс для сервера вузлів
- Затримка мережі 150 мс
Таким чином, користувач отримає відповідь після майже 810 мес ! Тепер, звичайно, це лише середні цифри, але в реальному світі це може бути набагато гірше. Оскільки ми не маємо великого контролю над затримкою мережі, ми це збережемо. Таким чином, час відповіді сервера наразі становить 660 мс .
Щоб покращити ситуацію, ми спочатку побачимо найбільшу рибу: час відповіді API.
Входить Redis!
Redis є одним з найпотужніших магазинів даних, який є надзвичайно швидким та ефективним. Ви можете зберігати все там як ключові пари значень. Інтеграція redis для зберігання середовища вузла дуже проста. Якщо ми зберігаємо результат API у redis , ми можемо зберегти нашу мережеву поїздку на сервер API.
Тому тепер, коли користувач робить запит, сервер вузлів запитує Redis, якщо він вже має відповідь. Якщо він є, він буде безпосередньо передавати його до програми для рендеринга і, нарешті, повертає рядок HTML. Якщо у нього немає відповіді, ми підемо вперед і зателефонуємо API, а тепер збережемо цей результат у redis, перш ніж передати його до програми.
Нова розбивка буде:
- 150 мс для рендеринга на стороні сервера
- 5 мс для сервера redis (ПРИМІТКА. Час рендеринга може бути меншим або дуже високим, залежно від розміру програми.)
- 10 мс для сервера вузлів
За допомогою простого кешування наших відповідей API, ми знизилися з 660 мс до 160 мс .
Стисніть More!
Хоча 160 мс хороший, ми можемо отримати більше лише невеликим трюком.
Замість того, щоб зберігати відповідь API у redis, чому б не зберегти всю HTML-версію?
і це був результат!
Середній час відгуку впало до 20 мс !
Заборона кешу
Якщо не обробляти належним чином, кешування стає біль в дупі. Люди починають постійно повідомляти, що старі дані / помилки стають поширеними. Таким чином, з великим кешем, нам також потрібна хороша стратегія зняття кешу. Зазвичай у нас є два випадки, коли потрібно очистити кеш:
- Коли автор оновлює статтю. (Коли відбувається оновлення даних)
Коли автор щось оновлює, він хоче побачити негайно відображені зміни! Для цього ми створили невеликий param cache = false. Всякий раз, коли url потрапляє з цією URL-адресою, сервер вузлів робить і виклик API замість отримання даних з кешу redis. І, отже, кеш оновлюється новими даними.
Всякий раз, коли ви розгортаєте, генерується новий хеш-блок для js і css-файлів. Це означає, що якщо ви зберігаєте весь HTML-рядок у кеші, він стане недійсним з розгортанням. Отже, коли ви розгортаєте, redis db потрібно повністю промити.
Висновки
Вузол швидкий. Так само реагує! Але іноді нам потрібно додати нового гравця для досягнення цієї неможливої мети, не жертвуючи жодними точками досвіду користувача. Redis є дивним. Використовуйте всі ці з розумом.
Замість того, щоб зберігати відповідь API у redis, чому б не зберегти всю HTML-версію?
