Forem: Akshat Ramanathan

NextJS 15 Gimmicks

Akshat Ramanathan — Thu, 30 Oct 2025 01:54:30 +0000

NextJS: A clash with Cache

A curated list of all NextJS 15 gimmicks

Default Next (App router) behaviours -

Static build all pages unless dynamic apis used like cookies or header or force-dynamic in any subcomponents.
If child component as part of page is dynamic, whole page becomes dynamic. To stream and improve load times, use Suspense boundaries in dynamic parts
API calls in components are cached by default unless no-store header is given as custom config (architecture/framework/infra level hack)
Opt in to "use cache", cacheLife and cacheTag with DynamicIo experimental flag (cacheCompoments in v16) makes API or async calls dynamic and not built statically. Often used with PPR and if caching response required use fetch "store" header or “use cache”
Loading tsx wrappers inside layout. Do not do dynamic stuff in layout as next requires clean static path of components for clear separate boundaries. If layout becomes dynamic whole subtree is forced SSR’d
Streaming only works with app router as RSCs can be streamed down, often used with suspense boundaries.
In suspense previously we had to manually throw promises but in react 19 (next 15+) use() hook removes boilerplate and makes it easy.
Previously, suspense children promises were initialized in parallel and resolve boundary when slowest component/promise resolves so all is batched and shown at once. In React 19 (Next 15) Suspense children no longer concurrent/parallel. They cause waterfall. To avoid, use separate boundaries with loading fallbacks or hoist promise to parent and pass as prop and internal use() hook in children for parallel/concurrent behaviour. Another option, promise.all them in parent after hoisting.
Middleware’s are badly named interceptors and not good for auth and publicly exposed (renamed proxy in v16). Do not use auth logic here. Use for checks and redirects.
Server actions are public endpoints created on build time. Use with daytime and auth to ensure safety.
Client components are SSRd first, then hydrated on client (ensure isomorphic code, fallbacks for DOM APIs, etc.) but server components are only in server as static (RSC payload streamed at runtime)
Streaming RSC payload is converted to vdom nodes on client and hydrated. Hence bundler specific splitting required to split server and client references from isomorphic code with directives like "use client".
Wrapping API calls of server components in suspense also makes it dynamic and not cache the API result. (By default caches unless no-store header). Otherwise caches coz renders static by default. Opt into cache static with “use cache” explicitly mentioned in function or component level. (DynamicIO flag or cacheComponents in v16). If data fetching in layouts, can cache it for example, to improve loading speeds. CacheTag or revalidareTag with expireTag and cacheLife to opt into ISR caching revalidation behaviour explicitly.
If dynamicIO flag is used with async calls, do "use cache" explicitly or wrap with suspense to force dynamic behaviour. We can also use loading tsx. Same functionality as suspense.
Non suspending async components always blocks (dynamic content finishes loading) rendering, then streamed together causing delay

Summary -
Opt into into static max with suspense = PPR
PPR - opt in static part caching with suspense boundary. No forced SSR if small chunk dynamic in page.
Opt into async stuff excluded unless cached during build of ppr/static.
DynamicIO - cache by default (as static SSG behaviour) (cached API response) to opt in cache with “use cache”. No more "force-dynamic" required

Old Next - Pages router

GetServerSideProps work like remix loaders
GetStaticSideProps (like Gatsby) works only during build
Generate static routes on build with generate static paths or some function like that.
No server actions, we used tRPC as a bridge way of calling type safe APIs present in server from client. Under the hood sets up a RPC client and calls functions in server securely

The Resolve

Akshat Ramanathan — Thu, 31 Jul 2025 04:10:14 +0000

This article is a continuation of - First part

Part 3 -The bridge

This is where the server came in. Over the last 2 decades, we have pioneered architectural systems that help keep a separation of cancers, while helping maintain modularity.
Databases although initially created to store data, proved to be an effective tool to process data efficiently. We developed systems for communication with such databases effectively in a consistent, isolated and durable manner. (ACID properties) Giving us atomic transactional capabilities.
Once we realized our data was secure, we moved on to the processes. Our business logic required processing of our data to produce meaningful information for our use cases.Service oriented architecture was born to allow us to club semantically-meaningful operations of data in a concise format providing us with reusable entities. These entities were further managed by the application structure by surrendering control of their creation and asking for them as and when needed. Dependency Injection and Inversion of Control is a core primitive in large scale enterprise-level application management.
This also led to new patterns like MVC pioneered by Ruby on Rails for effective application building. Convention over configuration was sought after for large scale systems to ensure consistency and reliability.
Having such transactional services, which further solidified our atomic resiliency; we finally began our task. Building the bridge.
As other things that change with time, so did this bridge.
What began in the early days simply as templating engines that wrapped data to build our interface (HTML) with data coming from services, was coined as Multi Page Applications (MPAs). The drawbacks for this approach was the need for a full template generation on each request done by user interactivity.

Over time, the client grew stronger and this lead to an interesting paradigm shift.
Initial web interactivity was limited with JS not being as standardized and powerful. Before such advancements and evolvement there were others that took upon this job to provide powerful interactions. Java applets, Microsoft silverlight, and Adobe Flash were revolutionary. This allowed for complex animations, high interactive experiences at the cost of non web-native technologies. Each had a form of injecting custom non-standard elements inside the DOM which were read and processed in the client end only if they support that technology locally in the form of a plugin. This was a major drawback of such experiences however enterprise level requirements were now being met effectively with the help of such implementations for niche use cases. However due to limited support for mobile platforms and other non standard clients these technologies succumbed to their demise over the last decade.
The good however, was the growth in native web technologies. With HTML5, CSS3 and ES3/5/6 (ECMAScript standard) of JS, it was now possible to implement many complex implementations in JS natively. The runtimes available - SpiderMonkey(Firefox), JavascriptCore(Safari) and V8 (Chrome) were to adhere to the ECMAScript standards and provide native support for all modern features including modern HTML5 and CSS3 compatibility. Complex use cases could now be implemented with JS native web interactions (PEMPA - Progressively Enhanced Multi page Apps - as coined by Kent C Dodds) which built on the MPA pattern with some small amount of template generation/manipulation capabilities in the client. The drawbacks of this approach was the need to manage 2 bundles. One for client and 1 server side that also included a lot of duplication of code on both ends for smilier template generation tasks. Around this time we also gained better Dev tools support and a growing ecosystem due to the creation of NodeJS runtime now being able to run code locally on the server without the need of a browser leading to native development directly with I/O heavy tasks like file systems via asynchronous processing.

This later lead to the modern revolution of SPAs - Single Page Apps.
Over the last decade SPAs and the growing mobile development community led to a need for a client agnostic format for data transmission from the server to the client in the bridge layer. The need previously fulfilled by SOAP was very bloated, not performant and reduced flexibility. This lead to the REST API revolution supported by AJAX where the responsibility of the server was now to handle API requests and provide JSON responses of required data instead of HTML templates. This greatly simplified server development by reducing complex flows (role P-R-G on form submissions) with direct data responses. The templating logic for DOM manipulation, however was moved to the client side which led to better UX at the cost of heavy client computation support requirements. The other main benefit was server data could now be sent client agnostic and used by either web apps or mobile apps; greatly increasing sharability. The other growth was in the authentication mechanism with OAuth and OIDC standards, PKCE implementations were easy to implement and session management became easier server side due to JWTs and other moderns solutions.
The drawbacks however were mainly JS oriented. The applications were no longer progressively enhanced meaning low bandwidth areas were rough for the application and lead to an increase in client heavy paradigms (state management, client-server waterfalls, graphQL, etc) that led to complexity overhead.

Part 4 - The modern era

So back to the drawing board. Client heavy SPAs are super useful for highly interactive real-time applications however they also come with their own set of challenges. Having a client-server network boundary, the “native” experience in web will almost always be affected by latency of network systems. There is a work around tho. Most sites (non applications) are static in nature. Be it marketing, branding, etc. the use case is not of that of an interactive application. This is also why content heavy CMS like WIX or Wordpress exist that makes non developers build such sites using low code tools. A similar alternative would be Jamstack. Tools like eleventy, Hugo or Jekyll and the like allow us to render HTML templates at build time and serve them as static files with minimal API requests for interactivity. The statically built JS takes care of the UX with API communication with the backend server. They are hence an architecture paradigm that integrate well with modern frontend tools and frameworks like React, Vue as well as build tools that power them. This also includes SSG that are a fundamental part of the Jamstack ecosystem. They allow this generation of static HTML+JS bundles ahead of time and gives great result for UX while not requiring us to maintain a server for the HTML generation. A backend is still required however for APIs to be exposed for the data interchange in order to display accurate information in the application. The drawback however remains the same as SPAs as they are built and run as SPAs in many cases by the SSG framework in order to maintain a smooth app-like UX.

We finally reached a point where we would like to have the positives of both MPAs and SPAs while mitigating their drawbacks. This basically meant having a progressively enhanced multi page app rendered by the server (at build time/ run time) while also maintaining a smooth SPA like UX in the client. With the advent of client side frameworks and libraries this was now possible with the concept of Hydration. Hydration allowed for HTML template to be generated on the server which was later rejuvenated and linked up (hooking up event listeners required by the framework) on the client after receiving it. This unlocked a new paradigm of rendering strategies that allowed new patterns of data flow. We were now able to mitigate network waterfalls caused by fetch on render pattern (a component renders first then requests for data while showing loading spinners) by changing it to a render-as-you-fetch using loaders pattern. This allowed a page request to fetch data on the server which got passed to the client for initial render and later hydrated on the client end avoiding any waterfalls. We could also stream down pending data (async data fetching) as part of the initial render with loading spinners and handle it on the client. The loaded data can stream down later and handled by the client once ready. This concept was the initial Server Side rendering paradigm. The main requirement for this was the use of NodeJS or a similar runtime (Bun, Deno, etc.) on the server end to handle async data fetching as well as frontend frameworks based rendering on the server. The advent of SPA-influenced isomorphic apps had a few drawbacks due to the isomorphic nature of code. We now had to write code with separation of network boundary in mind as loaders and actions only ran server side and there was a need of clientLoaders/actions for additional client intervention/processing (akin to Remix/ NextSJ pages router way of things). This also closed multi environment builds that had bundlers had to understand and code split to cleanly separate the server and client bundles. Hybrid rendering strategies were also possible on per route basis where static content could be regenerated (SSG) where as other pages were dynamic (SSR).

Part 5 - The Utopia

Due to increase in complexity and cognitive load of application development there was a need simplify this process. Although SSR solves 99.99% of problems it does so with an added layer of paradigms and patterns. Astro (a content heavy framework that began as SSG) lead to the new approach of Interactive islands. Rather than having a server render the entire app and client hydrate it again the idea was to maximize statically generated content with small islands of interactivity. This shift lead to a rendering agnostic architecture that allowed astronomers to combine multiple frontend solutions like React, Vue, Svelte, etc. at the same time on the same page while maintaining a slim client bundle. The minimalistic static heavy approach gave the benefits of SPA in the interactive areas while preserving SSG driven MPA feel.
This pattern mitigated to the industry in many ways. React, a widely used lib-framework started working their ideologies on this approach. What once began as a class based component driven pattern, moved to a functional + hooks based approach that closely aligned with the declarative nature of web while maintaining effective escape hatches for imperative logic using side effect management. This now evolved to a static generated paradigm which was hydrated in the client side using a custom representation called the RSC payload. The Server components model closely align with astro islands architecture that allows for weaving client and server components using this RSC representation that is hydrated by the client. Powered by react suspense, this also enables differing of server heavy tasks by displaying loading skeletons and stream in the required responses that get slotted in later. Similar to the suspense paradigm, astro recently implemented the server islands architecture this year.
I believe with more advancements in compiler based approaches, a lot of the heavy lifting done by the bundlers and dev tools like vite can be taken over and provide a smoother DX for us. Frameworks like Svelte and SvelteKit recently with async capabilities allows us to further blur the network boundary and advance the way we build full stack applications.

So that’s been my rant. If you reached till here you’re awesome! Thank you for taking the time to read my mind barf. I hope you look forward to more content like this. From Vue and React renderings to Suspense inner workings to dev tools deep dive. Im also into Java Spring and PHP Laravel backend stuff a bit. I hope to catch you in the next one!

The One where it all began

Akshat Ramanathan — Thu, 31 Jul 2025 04:07:02 +0000

Preface

After long procrastination, here I am. Content consumption is hard, especially in the era of AI, LLMs and MCPs. I feel I am consuming more content than ever before. So here I am writing my first blog post. Im gonna try building this as reference notes that helps me keep track of my knowledge base and not explode my brain with information overload. To do this, I need to start at the very beginning…

Part 1 - Let there be light

I like building solutions. As a computer science engineer, one chooses their comfort in the level of abstraction they wish to work in. Over the last few years in my undergraduate and post graduate degrees, I have discovered domains from networking, cybersecurity, data science/engineering to low level embedded programming, compiler design and the like. I have come to realize that as a software developer my level of the wheelhouse is as a software developer. As a jack of all trades, master of none, I wish to focus my time on a particular domain first and then branch out to the rest as the opportunity presents itself. So lets’ begin at the outermost layer.

What is an application?
Wikipedia defines an application as a computer program that is intended for the end-user. As simple as that. This implicitly defines a few things for us.

Having an end user interaction requires an interface
Having UI requires systems to be designed in a way that can deal with dynamic interactions
Dynamic interactions are actions done by users at runtime which inherently is not guaranteed to happen in any order

In order to deal with such problems we came up with the request-response model. In distributed systems lingo, this grew to be known as the master slave paradigm. Although, in modern times it’s often referred to as client-server architecture.
The client is an entity that contains this user interface and propagates communication to a server entity. This server entity has 1 job, and that is to fulfill the clients needs. This may be data or hypermedia in any form.
Over the years we have come to defile multiple entities as part of the “client” umbrella. From desktop or mobiles apps, LLM chat interfaces to web browsers. I, being a web developer, am mainly focused on this last one. The browser.

Part 2 - The journey through time

The network was a magical invention. More so the process of communicating over the network allowed infinite possibilities in the world of web technology. Over the years we have had big entities that have enabled and standardized many paradigms giving us structure and obedient formats that can be used to build software in this domain in the form of specs. From the W3C to the WHATWG have all worked immensely hard to push the web forward in a unified way. The advancements in each level of the OSI models has taken place for us developers to work on the last layer to provide a meaningful experience to our users. From IP to SSL to HTTP to HTML. Each layer, produces a crucial part of hypermedia processing that allows us to inherently work with data and provide meaningful application of our interface - hence the name “Apps”.

Over the past few decades, we have made certain discoveries. We have come up with patterns that are repeated in many technologies from time to time. As developers, building meaningful user interfaces is a complex task. We approach our problem from multiple angles, engineering a solution to best fulfill our task, users needs and the technical constraints presented to us. Through this journey we have realized it is a good design to implement our application structure in the form of a hierarchy in a declarative manner. This gave us the implementation of markup languages that help define HTML, XML, and the like. From Java Swing(AWT based) to JavaFX, XAML and MAUI from the Microsoft world, to the web DOM. Many domains across the many fields have narrowed down on this approach to maintain a structural hierarchy of the interface as a static entity to be defined with which the user can interact upon.
This idea of the interface arranged as a hierarchy of nodes is achieved with markup as it allows us to define the entities in a tree-like way providing clear relationships. This potentially unlocks the core essence of the computer science by providing Modularity as well. However in order to improve on this model and not deal with a chaotic hierarchy, we have had further enhancements providing us with semantic meaning to these entities.

However there is a cost. Hierarchy does not necessarily always define the design. UI Design and experience (UX) almost always drives a direct impact on the interactivity of the software. Having an hierarchy solves the problem of composition of interface in terms of engineering design by declaratively building it; however it does not solve the look-and-feel of the software. That is the reason UX as a branch of such is very psychological in nature providing solutions to scenarios that depend on user interaction and the philosophy behind it. To solve this problem we have realized a way to express our design opinions and link it to the markup entities providing a direct relation between them. This lead to the development of CSS. A DSL for the browser that not only helps apply styles to the interface but also cascades based on its hierarchy further binding the two together. This composition pattern of CSS linking to HTML provides a system that allows us to declaratively build the interface and style them as required. In modern times CSS supports complex styling requirements for UX design like animations, view transitions and mathematical computations.

The last clutch is that of interactivity. The web and hypermedia in general, although began as static newspapers and magazines has now progressed to advanced complex applications. In order to support such complex interactions we need an imperative way of enabling our markup to support dynamic events. This lead to languages like JS (that although was scrapped together in 10 days) that has driven the web forward in building complex interactive experiences. Across other domains, like AWT/XAML etc the core logic of such interactions are imperatively programmed to allow us to handle them in a controlled way. Now enabled with an interactive interface we can finally do things with our experience (apart from just reading beautified content). But where would that be?

And so it begins

Akshat Ramanathan — Thu, 05 Jun 2025 20:13:12 +0000

Content consumption is hard. With the amount of AI generated crap out there along with the dynamic and ever evolving landscape of the web; even when I try watching videos on youtube leisurely it becomes a binging session with hard disciplined study following each video. After about a year of such binge sessions and learning new technologies and stacks I realised my YouTube watch later and favourites playlists contents have become textbooks in themselves.

So here I am, a fullstack web dev trying to annotate my thoughts as I go along surfing the web on my learning journey. From Java to PHP and from react to htmx I’ll try to cover all kinds of content to learn and discover more and more about this strange world of web and leave no stone unturned. After 2 failed attempts at microblogging, this is gonna be a new take but with a twist.

Concept - each post contains a video
Followed by the contents covered in the video and my thoughts on it. Highlighting the important parts (almost like TLDR). The goal is to make it like a diary entry of notes which I can refer back to when I think about something from any of the old videos or if I want to, a refresher to any of them.

I’m still working on the order of videos to cover. So stay tuned. The goal is to make 2 posts a week covering 2 elaborate videos. Feel free to follow me to get updates on upcoming posts and let’s begin the Dev Bytes!

Collision Detection

Akshat Ramanathan — Sat, 21 Sep 2024 13:35:23 +0000

This is a submission for the Web Game Challenge: One Byte Explainer

Explainer

Collision detection:
It is the process of determining when two or more objects intersect or come into contact. It ensures interactions like collisions, overlaps, or proximity events are handled, affecting gameplay like physics, damage, or movement blocking.

Additional Context

Every game engine has one or other form of physics engine responsible for managing such interactions. Games are highly interactive pieces of software. In order for such interactivity to be present, event driven principles like pub-sub or the observer pattern are often used to target and keep such physics related phenomenons in check!

This is an individual submission!

Thank you!