DEV Community: Viktor Taraskevych

Git merge vs git rebase, explained through relationships 💔➡️❤️

Viktor Taraskevych — Mon, 05 Oct 2026 07:18:00 +0000

You and your partner are dating. Each of you has a life before this: your exes, your habits, your questionable mug collection. Those are your branches.

Then you decide to move in together. There are two ways to do it.

🪢 git merge: the honest marriage

You combine your lives and the whole past stays where it was. Her ex is in the history. Your "I'm going to be a DJ" phase is in the history. On top of it all sits one big commit, "Wedding 🎉", tying everything together.

✅ Totally honest. Everyone can see where you both came from.
❌ At family dinners, relatives scroll through your git log and start asking questions.

🔁 git rebase: "there was no one before you"

You take your life and replay it as if it started after you met. One clean, beautiful line. No branches. No DJ phase.

✅ The history looks perfect.
❌ It's not quite you anymore: new commits, different hashes.

⚠️ The golden rule of rebase

Never rebase history that other people have already seen.

Your mum remembers your ex. Your friends remember the DJ phase. Run git push --force on your biography, and the next birthday party will hit a conflict that can't be resolved automatically.

TL;DR:

Local branch, nobody's seen it → rebase, make it pretty
Shared history, everyone knows → merge, and learn to live with it

So, is your team Team Merge or Team Rebase? 👇

git #frontend #developerhumor #softwareengineering

What's the difference between Dependency Inversion and Liskov Substitution — or how to stay a good parent?

Viktor Taraskevych — Mon, 28 Sep 2026 10:21:49 +0000

Both principles are about replacing one caregiver with another. The difference is who breaks things.

DIP — the family's responsibility
Imagine a child who can only fall asleep if Mom sings that specific song.
Mom leaves for a trip — and nobody can replace her. Not Dad, not Grandma, not a nanny.
The problem isn't the others. The problem is that the family built everything around one specific person.
DIP says: depend on the role ("someone who puts the child to sleep"), not on the person. Then who shows up is just a detail.

👉 Violating DIP = you can't replace anyone.

LSP — the caregiver's responsibility
Now the family did everything right: any caregiver is welcome.
A nanny arrives and says: "I don't feed kids" — or "I only work with kids over five."
The family couldn't have prevented this. The nanny accepted the role but didn't keep its promises.
LSP says: if you take the role, you keep the contract. Your style can differ, your obligations can't.

👉 Violating LSP = you replaced someone, and it broke.

In short:
DIP — can we swap at all? (the family's design)
LSP — is the swap safe? (the caregiver's behavior)

SOLID #SoftwareEngineering #CleanCode #OOP #ProgrammingHumor

OAuth "by the book" doesn't mean secure

Viktor Taraskevych — Sun, 20 Sep 2026 17:51:37 +0000

Went through an article on an OAuth/OIDC attack - sharing the takeaways.

The problem

Common belief: follow "best practices" - BFF, HttpOnly cookies, PKCE - and your app is protected against authorization theft. In practice, it's not.

How the attack works

If an attacker can run JS on your app's page (via XSS, a compromised dependency, or a malicious extension):

The user has an active IdP session (SSO) - authorization happens silently.

The attacker secretly (hidden iframe/window) launches their own OAuth flow in the victim's browser.

The browser auto-completes it and receives an authorization code.

The attacker intercepts that code from the location before the app processes it.

From their own environment, they exchange the code for a session - gaining access as the user.

They don't need the victim's existing tokens, just a parallel flow of their own.

Why usual defenses don't help

HttpOnly cookies: code is stolen from the auth flow itself, not a cookie.
BFF: just moves tokens to the server; the API is still reachable via the session the attacker gets.
PKCE: the attacker can start their own cycle with their own parameters and plug the stolen code in.

RFC 9700 and FAPI 2.0 both acknowledge that for redirect-based flows, no complete protection exists once the authorization response leaks.

What actually works

Form Post Response Mode: the authorization server sends the code via a hidden HTML form (POST) directly to the backend, bypassing the browser/JS entirely. Nothing left to intercept.

Other measures (defense in depth, not silver bullets):

baseline XSS protection
blocking iframe embedding (CSP: frame-ancestors, frame-src)
requiring explicit user interaction
binding the code to IP/device fingerprint
separate subdomain for redirect URI

Why it matters

Not a new attack, but rarely discussed - standards' threat models often exclude such a "powerful" attacker to keep requirements manageable. XSS isn't rare in practice, so the attack stays applicable.

Takeaway: buzzwords like confidential client, BFF, PKCE, HttpOnly create a sense of security but don't replace understanding what each one actually protects against. Threat-model your own app before trusting a checklist.

OAuth #WebSecurity #Frontend #AppSec

Next.js 16.3 update

Viktor Taraskevych — Sat, 12 Sep 2026 17:49:13 +0000

Next.js 16.3 is the biggest framework update since 16.0, and most of the improvements ship with zero code changes.
What every project gets:
Up to 90% less memory in dev - Turbopack now uses disk caching and memory eviction by default. Real case: a 50-route app dropped from ~4.6GB to ~840MB RAM
Up to 5.5x faster repeat builds, thanks to the same disk cache now working with next build too
Up to 22% more requests under load - SSR moved from Web Streams to native Node.js streams
TypeScript 7-10x faster type checking
Edge runtime is now officially deprecated
Separately - Instant Navigations, opt-in features rethinking navigation in server-driven apps:
→ Partial Prefetching - instead of an aggressive full-page prefetch on every link, one reusable "shell" per route, cached for the session → Instant Insights - a devtool that automatically catches navigations that weren't instant and hands you a fix prompt → Better ISR - pages without a build-time prerender now show an instant shell to the first visitor instead of a blocking load → Navigation Inspector - visual debugging of loading states in dev → Playwright helper instant() - catches regressions when a navigation stops being instant after a refactor
This will become the default in the next major version - worth a look now.
https://lnkd.in/dXMz9jYH

nextjs #frontend #webdev #reactjs