Друзі, а у вас бувало таке, що все чудово працює на локалці, а в продакшені сторінка раптом починає «думати» значно довше? 😅

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

Продовжуємо нашу серію про типові проблеми продакшену 👇

Попередні пости серії:
📍 Rails без магії: 7 помилок, які роблять навіть мідли
📍 Background jobs: чому “просто Sidekiq” — не завжди просто
📍 Transactions у Rails: чому “і так працює” — небезпечна ілюзія
📍 DB constraints: чому Rails validation — це не гарантія
📍 Fat model / Fat controller: коли клас росте швидше за проєкт

#codica_advice

N+1: коли все працює… поки не з’являються реальні дані

Якщо сторінка відкривається за 50 ms на локалці, але падає в продакшені — дуже часто це N+1.

Rails робить асоціації зручними.
І саме ця зручність іноді дорого коштує.

Ми всі через це проходили 🙂

Класичний приклад

users = User.all
users.each do |user|
  puts user.posts.count
end

Здається невинно.
Але під капотом:
1 запит за всіма users
N запитів за posts для кожного user

Якщо користувачів 200 — це вже 201 SQL-запит.

Чому це небезпечно
🔹 Проблема не помітна на маленьких даних
🔹 Логи виглядають “нормально”
🔹 Ламається тільки під навантаженням
🔹 Важко відловити без моніторингу

N+1 — це не баг. Це “тиха деградація”.

Як це виправити?

1️⃣ includes

users = User.includes(:posts)

Rails зробить 2 запити замість N+1.

2️⃣ preload vs eager_load
includes — універсальний варіант
preload — окремі запити
eager_load — JOIN

Іноді JOIN краще, іноді — ні. Треба дивитись у SQL.

3️⃣ counter_cache
Якщо ви лише рахуєте:

add_column :users, :posts_count, :integer, default: 0

І:

belongs_to :user, counter_cache: true

І більше ніяких .count у циклі.

4️⃣ Дивитись у EXPLAIN
Якщо не дивишся в SQL — ти не контролюєш продуктивність.

Маленьке правило
Якщо в коді є .each + асоціація — перевір, скільки запитів реально виконується.

💬 Хто ловив N+1 уже після релізу? І через що помітили — Sentry, NewRelic чи “клієнт написав”? 😄

TikTok | Instagram | Telegram

Коли робочий тиждень позаду, у Mr. Cody прокидається внутрішній кутюр’є ✨

Наш маскот приміряв традиційні костюми різних країн. Ну який же він у нас гарнюня 🫶 (Окрім одного персонажа з унітазами, але то окрема клінічна історія 🫠)

Який образ Містера Cody залетів вам у саме серце?

Став реакції:
❤️ — за розкішний український аутфіт!
🔥 — за стильні європейські костюми!
🗿 — за «стиль болота» в окремому бліндажі!

TikTok | Instagram | Telegram

Друзі, всім ясного та допитливого вихідного 🔬

#codica_weekend

Зібрали для вас підбірку про науку. Ідеально, щоб залипнути з користю 🧠

➡️ 25 за 25: найбільші наукові відкриття ХХІ сторіччя і що далі до 2050?
Геном, CRISPR, AlphaFold, чорні діри і термоядерка — концентрат науки, після якого трохи інакше дивишся на світ і майбутнє.
⏱ Тривалість — 34 хв

➡️ Людина, яка відкрила антиматерію [VERITASIUM]
Історія відкриття, яке звучить як sci-fi, але стало реальною наукою — дуже захоплює і пояснює складне простими словами.
⏱ Тривалість — 34 хв

➡️ Чому часові пояси такі дивні?
Після цього відео ви нарешті зрозумієте, чому світ живе в такому хаосі часу і чому все могло бути значно простіше 😄
⏱ Тривалість — 27 хв

Нехай ці вихідні будуть з новими відкриттями, гарним настроєм і хоча б однією відповіддю на питання “як це працює?” ☕

TikTok | Instagram | Telegram

Раночку, друзі!!

Ну так і є, а що? 😄
Гарного усім дня!

#codica_humor

TikTok | Instagram | Telegram

🎯 Як відповідати на технічні запитання на співбесіді?

#codica_interviews

❌ Обмежуватися визначенням з документації.
✅ Пояснювати архітектурні нюанси.

📌 Explain what is a session mechanism. How does it work in Rails?
📍 Очікувана відповідь:

HTTP є stateless-протоколом, тому сесія — це спосіб зберегти стан між запитами.

За замовчуванням у Rails використовується ActionDispatch::Session::CookieStore.

Весь стан сесії серіалізується у JSON (починаючи з Rails 7), шифрується алгоритмом AES-256-GCM (через ActiveSupport::MessageEncryptor) і зберігається прямо у браузері користувача.

🔒 Завдяки шифруванню клієнт не може прочитати вміст, а завдяки криптографічному підпису — не може його підробити.

💡 Профі додасть про обмеження та альтернативи:

У CookieStore є ліміт 4KB і відсутній швидкий механізм відкликання сесії з боку сервера (якщо куку вкрали, вона валідна, поки не спливе expires). Тому для критичних систем краще конфігурувати :cache_store (на базі Redis або Solid Cache) — тоді в cookie зберігається лише випадковий session_id, а самі дані лежать на сервері.

🛡 Захист від Session Fixation при автентифікації

def create
  user = User.find_by(email: params[:email])

  if user&.authenticate(params[:password])
    # Повністю оновлюємо сесію перед записом нових даних
    reset_session
    session[:user_id] = user.id
    redirect_to root_path
  else
    render :new
  end
end

📌 Describe CSRF, XSS, session hijacking, and session fixation.
📍 Очікувана відповідь:

🔹 CSRF (Cross-Site Request Forgery) — атака, що змушує браузер авторизованого користувача виконати небажаний запит (POST/PUT/DELETE) на ваш додаток.

🛡 Захист: Rails (у non-API додатках) порівнює токен у параметрах/заголовках із токеном у сесії за допомогою protect_from_forgery. Також допомагає прапорець SameSite=Lax або Strict для cookies.

🔹 XSS (Cross-Site Scripting) — впровадження шкідливого JS-коду в сторінку.

🛡 Захист: Rails автоматично ескейпить вивід у шаблонах (через клас ActiveSupport::SafeBuffer). Метод html_safe та хелпер raw слід використовувати обережно. Глобально додаток захищає налаштування Content Security Policy (CSP) заголовків.

🔹 Session Hijacking — викрадення чужого session cookie (через MITM або XSS).

🛡 Захист: Робота виключно через HTTPS (config.force_ssl = true), а також обов'язкові прапорці HttpOnly (забороняє JS читати куку) та Secure для сесійних файлів cookie.

🔹 Session Fixation — ситуація, коли зловмисник нав'язує жертві свій session_id до моменту логіну, а після авторизації користувача отримує доступ до його сесії.

🛡 Захист: Обов’язковий виклик reset_session одразу після успішного входу (популярні геми на кшталт Devise чи Rodauth роблять це автоматично під капотом).

✅ Коротко:
На співбесіді важливо показати концепцію Defense in Depth (багаторівневий захист): ми не просто сподіваємося на магію фреймворку, а чітко розуміємо конфігурацію кук, HTTP-заголовки безпеки ( HSTS , CSP) та логіку роботи middleware (ActionDispatch).

TikTok | Instagram | Telegram