As a Tech Lead building my own platform, I live by an old craftsman proverb: "Measure twice, cut once." We spend weeks architecting client systems...
For further actions, you may consider blocking this person and/or reporting abuse
I'm more backend orientated, so I had to find out what Next ISR was. As I understand it refreshes only the changed pages/parts. What happens if a page is added or removed and is in the main menu? Does it update all the pages?
It feels like it needs at least two events, one for the page and one for the menu change.
Looking at your site I don't get why you need to decouple the backend from the frontend, most pages are static. So by using all those extra patterns and abstractions you are making it more difficult than it needs to be.
Hey! Great questions — you're hitting on the exact nuances that make ISR tricky in practice. Let me clarify a few things:
On menu updates and ISR: You're absolutely right that it needs coordination. ISR revalidates pages, not components, so if your main menu data changes, you must explicitly revalidate every page that renders that menu. That's what the
dependenciesarray in myPostUpdatedevent handles — when I update a category, the handshake triggers revalidation for the category page, all post pages within it, and the homepage (which contains the main nav). Without this, you'd serve stale navigation links, which is a silent UX killer.You're spot-on about needing at least two events in theory, but I collapse them into one atomic operation: the content change event carries the full invalidation graph. This avoids race conditions where the menu revalidates before the new page exists.
Why decouple a "mostly static" portfolio? Fair challenge. Yabasha.dev is a showcase, but it's also a production testbed for patterns I use in client systems with 10k+ dynamic pages, multi-tenant APIs, and separate backend teams. The decoupling lets me:
If I hard-coupled them, I'd be showing devs how to build a demo, not a system. The Cache Handshake looks verbose until you're debugging why a webhook failed at 3 AM during a deployment — then that "extra abstraction" becomes the difference between sleep and a mobile alert.
You're right that a simple site doesn't need this. But my goal is showing production-grade resilience: idempotency, retry logic, circuit breakers, observability. Clients don't pay me for code that works on sunny days; they pay for systems that fail gracefully when things go sideways.
Happy to dive deeper into any of these points — especially the ISR mechanics if you're exploring it for your own backend work!
I can understand that.
I don't agree with sentiment that only a backend-frontend separated websites scales or can be multi-tenant.
Separated sites are harder to maintain because it involves more coordination, as your post shows.
The argument of separate frontend and backend teams is a false argument because Next is a full stack framework. So backend knowledge is needed.
In my opinion there should never be separated teams based on the technical layers of a product. The only thing that causes is division, and that is the worst thing for a product.
You're absolutely right that separation adds coordination overhead, and for many projects, a monolithic Next.js app is simpler and better. My approach targets scenarios where backend and frontend must scale independently — multiple API consumers (mobile apps, partners), or when teams genuinely need autonomy.
You're correct that Next.js is full-stack, but "full-stack" doesn't mean "one-size-fits-all." The moment you have non-Next.js consumers or business logic that transcends UI concerns, a dedicated API layer becomes necessary.
The real enemy isn't decoupling — it's accidental complexity. I built this system to showcase intentional architecture for complex scenarios, not to advocate separation for every project. For a simple portfolio? You're spot on: keep it simple.
Thanks for the pushback — it's exactly the kind of healthy skepticism that keeps us from over-engineering!
You don't need Laravel and Next. Just have a static generation functionality for your Laravel/Next application.
To deploy the static site you can use git. Any update -> create commit -> push to repository -> let static hosting(s) listen to the repository. Then there are surgical updates, because how git works.
Just use specific API endpoints when the data for the different tenants is too different from the main API
Why would a frontend/backend team need autonomy working on a same application?
Sure there can be teams that develop a frontend/backend product that can be used by other teams. But then that product has a whole different lifecycle than a website.
I agree with the first part.
If you create an API with Next it is just json like any other backend framework. With that logic none of the frameworks can be used for a website and an API. Most API's I created don't follow the website output, so I should have used multiple frameworks?
You agreed that decoupling has overhead, so it is creating complexity.
Decoupling can be a valid solution, but it is more niche than how people use it now.
Another example is SPA. It is a valid solution, but it is not the right fit for all websites.
After all of that I do understand you want to showcase you can create more complex solutions with a solid foundation.
You're right—static generation covers most cases, and my portfolio uses ISR. The Laravel layer isn't for rendering; it's the AI agent's brain handling LLM benchmarking and metadata generation. That logic stays out of Next.js.
When mobile apps need different auth flows and data shapes, those "specific endpoints" become spaghetti.
BFF patternexists for a reason.You're correct—small teams don't need separate pipelines. But 15+ AI builds/day while keeping frontend stable? Decoupling becomes sanity, not overhead.
Not showcasing complexity; containing it. For a standard blog? Overkill. For autonomous content agents? Necessary.