I'd built a whole PixiJS-based effects system for Clypra Studio — filters, transitions, video effects, all running as real GLSL shaders. It worked. It looked good in demos. And then I sat down to trace whether the Desktop Editor — the actual product people would use to cut and export video — was using any of it.

It wasn't. Not fully. Not even close, in places I was most confident about.

What followed was months of tracing render paths, naming a bug pattern I kept tripping over, studying how Premiere and Resolve actually solve the problems I was hand-rolling badly, and slowly earning the right to say Clypra's preview is GPU-accelerated end to end. This is the long version of that story — the bugs, the research, the dead ends, and where it's headed next.

Why Canvas 2D stops working the moment you have more than one thing on screen

Canvas 2D is fine for a single overlay. It falls apart the moment you're compositing multiple video layers, each with their own effects, at 1080p or higher, sixty times a second.

Here's the mechanism, concretely. ctx.drawImage(videoElement, ...) requires the CPU to copy the current decoded video frame into the canvas's backing store, every tick, per layer. Any per-pixel effect — a glitch filter, an RGB channel split — usually means getImageData/putImageData, which forces a full GPU-to-CPU pixel readback. That's one of the most expensive individual operations you can perform in a browser, and my early architecture was doing it in a loop, once per effect, per clip, per frame.

PixiJS flips this entirely. VideoSource uploads the decoded frame straight into GPU memory as a texture — many browsers have an accelerated path that never touches the CPU at all. A GLSL fragment shader runs the same per-pixel math in parallel, across potentially thousands of GPU cores, instead of a JavaScript loop touching every pixel sequentially. PixiJS also batches sprites that share a texture into a single draw call, collapsing what would be many separate CPU-side operations into one GPU submission.

None of this is a novel insight. It's why Premiere's Mercury Playback Engine, Resolve's Fusion pipeline, and Final Cut's Metal-based renderer all do GPU compositing natively rather than through a 2D canvas. I was just late to admit my own architecture hadn't caught up to that reality yet.

The bug that actually took the app down

The scariest bug wasn't a rendering bug at all — it was a lifecycle bug that froze the entire browser tab, and finding it taught me more about async ownership than anything else in this project.

I'd fixed one WebGL context-loss issue by making a renderer's destroy() method more aggressive about releasing GPU resources — calling WEBGL_lose_context's loseContext() explicitly, rather than trusting garbage collection to eventually free the context. That fix introduced a worse bug. React Strict Mode, in development, synchronously mounts a component, tears it down, and remounts it — a deliberate stress test for exactly this kind of lifecycle bug. My "more aggressive" destroy call fired during the phantom teardown, calling loseContext() on a canvas element that the second, surviving mount was about to reuse. A canvas only ever hands out one real WebGL context for its entire lifetime — forcing that context to die didn't just clean up the phantom instance, it permanently poisoned the canvas for the real one too.

The console told the story clearly once I knew what to look for: WebGL context lost — attempting recovery, fired twice, right alongside two duplicate "Font system initialized" logs — unambiguous proof that two Application instances had briefly existed against one canvas. Chrome enforces a hard cap on simultaneous WebGL contexts per page. Cross it, and the browser forcibly reclaims the oldest one to free GPU resources. Once that happens, shader compilation starts failing, gl.getProgramInfoLog() returns null, and the render loop hangs trying to recover from a context that is never coming back — because there's nothing left to recover to.

The actual fix wasn't "destroy more carefully." It was recognizing that destruction was happening on the wrong instance entirely. I built a canvas-keyed singleton registry — a WeakMap from canvas element to renderer instance — so a phantom Strict Mode remount recognizes an existing owner and reuses it instead of racing to create a second one. Only a genuine final unmount, confirmed by generation-counting across the synchronous replay, is allowed to actually call destroy(). Once I had that pattern, I found myself wanting to apply the exact same discipline everywhere a GPU resource got created: mount once, update every frame, tear down exactly once, on purpose, never by accident.

What professional editors already knew that I had to learn the hard way

One bug in particular sent me down a genuinely useful research rabbit hole. A user sent a screenshot: a video clip rendering as a tiny box in the middle of the frame instead of filling it, with the selection handles drawn at a completely different size than the actual pixels.

The root cause was two compounding bugs. First, sizing was computed from videoWidth/videoHeight read live, at whatever moment the code happened to run — sometimes before the video's loadedmetadata event had even fired, meaning the dimensions were still zero. Second, an anchor mismatch: PixiJS sprites default to a top-left anchor point, matching old Canvas 2D drawImage semantics, but the transform-handle system needed a center anchor to support rotation-around-center. Somewhere in the migration, the anchor got changed to center without the position math being updated to compensate — so every sprite silently shifted up and left by half its own dimensions.

Before writing a fix, I went and read how Premiere, DaVinci Resolve, and Final Cut Pro actually solve this, because I suspected I was reinventing a wheel badly. I was right. Every one of them treats a clip's size relative to its canvas as an explicit, named, stored property — never something recalculated live from a possibly-unready source during rendering. Final Cut calls it Spatial Conform: Fit, Fill, or None, chosen once and stored, editable later but never implicitly guessed. DaVinci Resolve's node-based compositor makes the rule explicit at the architecture level — in a Merge node, whichever input is connected as the background defines the output resolution, and the foreground gets fit into that space, full stop. Resolve's Transform node is deliberately resolution-independent: it always references a clip's defined source resolution, captured once, never re-read live — which is exactly the discipline my bug was missing.

That research turned into an actual system: a ClipConform record storing mode (fit, fill, or none), sourceWidth/sourceHeight captured exactly once via a loadedmetadata listener, and user-adjustable scale and offset layered on top. One function, resolveConform(), became the single place fit math is allowed to happen — no more ad hoc position calculations scattered across render call sites, each one a fresh opportunity for the same bug to reappear in a new shape.

The hang that taught me to stop trusting my own assumptions about "cheap"

Stacking two video clips on overlapping tracks — a completely ordinary edit — started making the whole preview stutter and occasionally hang outright. I assumed it was a rendering complexity problem. It was actually a caching problem, hiding in code I'd written to fix a caching problem.

The compositor rebuilt every filter and effect from scratch, every single frame, for every clip — new AdjustmentFilter(), new BlurFilter(), fresh GPU shader construction, sixty times a second, with the previous frame's instances never explicitly destroyed. Shader compilation is one of the most expensive synchronous operations WebGL can perform. Doing it once a frame for one clip stayed just under the threshold of "obviously janky." Doing it for two simultaneously active clips doubled that cost in the exact frame budget that was already tight — which is precisely why stacking clips, and only stacking clips, triggered visible stutter.

Layered on top of that: a media-sync function was firing unconditionally on every single animation frame during playback, regardless of whether the set of active clips had actually changed. There was already a signature computed elsewhere — a hash of exactly which clips were currently active — that existed specifically to answer "did anything actually change." It just wasn't being used to gate this call at all.

The fix for the first problem was a structural key: cache filter instances per clip, keyed on which effects are structurally active, not their live parameter values — rebuild only when an effect is added or removed, update uniforms in place every other frame. The fix for the second was using the hash that already existed instead of computing a new one nobody asked for. Neither fix was clever. Both were things I'd have caught immediately if I'd asked "what does this actually cost, every single frame" before writing the first version, instead of after a user reported the app hanging.

Building toward something bigger than PixiJS

Here's the honest part: PixiJS is the right tool for where Clypra is right now. It's not a compromise — CapCut's own web tooling runs on comparable pipelines, and for an editor competing at that tier, general-purpose WebGL compositing is genuinely sufficient, not a placeholder I should feel uneasy about.

But it has a ceiling, and I want to be upfront about where it sits. Real professional-tier tools — Resolve, Premiere, Avid — don't render through a browser-embedded GPU context at all. They talk directly to the native graphics driver: Metal, DirectX, sometimes Vulkan. That buys them things a browser context structurally can't give you for free: 10-bit and HDR color pipelines, ten-plus simultaneous 4K layers without breaking a sweat, and rock-solid multi-hour session stability that doesn't have "the browser tab decided to reclaim your WebGL context" as a category of failure.

The clearest proof this ceiling is real, and crossable: Figma. It's the best-known case of a creative tool built on browser GPU rendering that actually scales to genuinely professional use — and they didn't reach for an off-the-shelf library to get there. They built a fully custom WebGL renderer, specifically because general-purpose scene-graph engines don't have the domain-specific memory management a massive-scale creative tool needs.

That's the honest long-term plan for Clypra. Not "replace PixiJS because it was wrong" — grow a native Rust compositing layer, most likely via wgpu, that handles production-grade rendering and export once Clypra's ambitions genuinely push past what a general-purpose library can give. And the part I'm most relieved about: none of the GLSL effect work is wasted if that day comes. GLSL translates to WGSL far more cleanly than rebuilding an entire effect library from first principles. The shader logic is portable, even if the rendering backend underneath it eventually isn't permanent.

What I'd actually tell someone starting this migration

Audit before you assume. I thought I knew what my own renderer was doing. I was wrong about several load-bearing pieces of it, including the one — transitions — I'd been actively designing new features against for weeks. The only way I found out was tracing real call paths, not trusting file names, import statements, or my own memory of what I'd built.

Name the pattern the second time you see it, not the eighth. Split-brain became a search query, not just a diagnosis, the moment I had a name for it. I stopped waiting for the next screenshot to hand me the ninth instance and started actively hunting for it with a taxonomy in hand.

Don't build the safety net you don't need yet. I spent real effort designing a dual-pipeline architecture — feature flags, gradual rollout, automatic fallback to Canvas 2D if the WebGL path failed — before remembering Clypra doesn't have real production users yet. That entire apparatus was solving a problem I didn't have. The moment I admitted that, the plan simplified from "careful phased rollout" to "just finish the migration properly, all at once." The more cautious-looking plan isn't always the right one — sometimes it's just the more comfortable one.

A shader recompiled every frame will always cost more than you think it should. Twice, separately, the actual bug was "this is more expensive per-frame than it looks," not "this logic is wrong." I've started asking that question first now, before writing the first version of anything that runs inside a render loop.

If you're mid-migration on something similar — Canvas to WebGL, or any "two systems quietly disagreeing" bug of your own — I'd genuinely like to hear what pattern you found repeating on you. Mine was split-brain. What's yours?

1. The move from "prompts" to "workflows"

The biggest shift this year isn't a smarter model, it's architecture. Teams aren't chaining one-off prompts anymore; they're building orchestrator agents that hand off work to specialized sub-agents, each with its own context window, running in parallel. Zapier reportedly runs 800+ internal agents this way. The pattern is simple: one agent breaks the job down, others execute narrow pieces, and a human signs off at the risky step.

If you're building an agent product, "it can do X autonomously" is the wrong pitch. "It cuts this specific 3-hour task to 20 minutes, with a review step" is the one that actually holds up.

2. MCP is back — for a narrower reason than expected

Early 2026, Model Context Protocol got roasted for its token overhead, some ops were costing 30-80k tokens versus ~200 for a direct CLI call. That criticism was fair. But MCP usage is climbing again through mid-2026, not because the overhead problem went away, but because for irregular, cross-tool integrations (versus tight production pipelines), the standardization is worth the cost. Lesson: CLI still wins for repetitive, high-volume automation. MCP wins when you need an agent to talk to a dozen tools it wasn't purpose-built for.

3. Verifiability decides where agents actually work today

Coding agents in the terminal are thriving because their output is checkable — tests pass or they don't. Browser agents doing multi-step UI flows are still shaky, because there's no clean signal for "did this actually work." If you're deciding where to point an agent in your own stack, ask this first: can I cheaply verify the output? If the answer is no, you need a human in the loop, not more autonomy.

4. Smaller, task-specific models are quietly winning

The "one giant model for everything" era is fading. Domain-tuned, smaller models (IBM Granite, Ai2's Olmo 3, DeepSeek's line, and others) are matching or beating general models on narrow tasks and they're cheaper and easier to fine-tune. If you're an indie builder, this is good news: you don't need frontier-model budgets to ship something genuinely useful in a specific niche.

5. Security and governance stopped being an afterthought

Every agent now needs an identity, scoped permissions, and logs — the same way you'd manage employee access. That's not enterprise fluff; it applies the moment your agent can touch real user data, source code, or payments. Bake in scoped permissions and audit trails from day one, even for a side project.

The builder takeaway

None of this requires a huge team or a funding round. It requires picking one real, bounded, verifiable task, wiring an agent to it with clear guardrails, and measuring whether it actually saved time. That's it. That's the whole playbook right now, everything else is noise dressed up as a demo.

This is exactly the kind of thing we're building around at Stackkith: less chasing every new "AI agent" launch, more understanding what's structurally changing and building something real with it — open source, SaaS, side projects, whatever moves you forward.

If you're building with agents right now, even something small and rough — drop it in the comments. Let's push each other's work into more feeds this week.

#AIAgents #LLM #BuildInPublic #OpenSource #Stackkith

You build something with a few hundred animated elements — particles, nodes in a graph, tiles in a dashboard — and the browser starts to stutter. You optimize. You debounce. You throttle. You add will-change and transform3d and every trick from every performance article you've ever read. It helps a little. Then you add fifty more elements and you're back to stuttering.

Meanwhile, somewhere on the internet, a WebGL-based visualization is rendering 50,000 moving objects at a locked 60fps on the same hardware. Not a typo. Fifty thousand.

The gap isn't better code. It's a completely different rendering model, and understanding why reveals something every engineer should know about how browsers actually draw things, whether you ever touch a canvas element or not.

THE DOM WAS NEVER BUILT TO ANIMATE THOUSANDS OF THINGS

Every DOM element you animate forces the browser through a pipeline: style recalculation, layout, paint, and composite. Modern browsers are extremely good at skipping steps when they can, a transform-only animation can often skip layout and paint entirely and go straight to composite. That's why transform and opacity animations are the ones performance guides always recommend.

But the compositor still has to manage every element as an individual object in the render tree. Each one carries its own overhead: its own paint record, its own layer promotion decision, its own bookkeeping in the browser's internal structures. A few hundred of these, animated simultaneously, and the compositor's per-object overhead starts to dominate. It's not that the browser is bad at this. It's that the DOM's object model was built for documents, not for tens of thousands of independently moving visual primitives.

WHAT PIXIJS DOES DIFFERENTLY

PixiJS doesn't render through the DOM at all. It renders through WebGL, the same low-level GPU API that powers 3D games in the browser, and it does one thing extremely well: batching.

Here's the core idea. Instead of asking the GPU to draw 50,000 individual objects one at a time, PixiJS groups objects that share the same texture and rendering state into a single draw call. The GPU receives one instruction — "draw these 50,000 vertices" — instead of 50,000 separate instructions. The overhead that kills DOM performance at scale, the per-object bookkeeping cost, gets amortized across the entire batch instead of paid individually per object.

This is why a PixiJS scene with 50,000 sprites can outperform a DOM layout with 500 elements by orders of magnitude. It's not that WebGL is "faster" in some abstract sense. It's that the entire rendering model is built around minimizing the thing that actually costs time at scale: the number of separate calls made to the GPU.

WHY THIS MATTERS EVEN IF YOU'LL NEVER WRITE WEBGL DIRECTLY

Here's the part that applies to every developer, not just people building games or creative-coding projects.

The batching principle in PixiJS is a specific instance of a pattern that shows up everywhere in engineering: individual operations have fixed overhead, and the way to scale past that overhead is to group operations together and pay the fixed cost once instead of many times.

Database engineers know this as batch inserts instead of row-by-row writes. Network engineers know this as HTTP/2 multiplexing instead of one connection per request. Backend engineers know this as bulk API endpoints instead of N sequential calls. It's the same idea, wearing a different costume, in every layer of the stack.

PixiJS makes this principle visible and tangible because you can watch the frame rate collapse the moment your batching breaks, for example, when you introduce a texture swap mid-batch and force the renderer to flush and start a new draw call. Understanding why that breaks batching teaches you to recognize the same failure pattern in a slow SQL query with N+1 lookups, or an API that makes fifty round trips when it could make one.

WHERE PIXIJS ACTUALLY SHOWS UP

This isn't a niche tool for game jams. PixiJS quietly powers a huge amount of the interactive web you've already used: data visualization dashboards rendering thousands of live data points, generative art installations, interactive maps with dense marker clusters, creative agency sites with particle-based hero sections, and yes, browser games.

Anywhere the interface needs to render more moving visual elements than the DOM can comfortably handle, PixiJS or something built on the same WebGL batching principles is usually underneath it.

The next time your UI starts stuttering past a few hundred animated elements, the fix probably isn't a smarter debounce function. It's recognizing that you've hit the fundamental limit of a rendering model that was never designed for that scale, and that the solution, in some form, is almost always the same one PixiJS is built around: stop asking for things one at a time.

Have you hit this wall in a real project? What did you reach for — PixiJS, raw WebGL, Canvas 2D, or something else entirely?

The worst bugs I've ever encountered aren't the ones that crash the application.

Crashes are honest. They announce themselves. They produce logs, stack traces, incident alerts. They interrupt the user so visibly that the bug report arrives within minutes. You know something is wrong, you know when it started, and the path to the crash site is usually short.

The bugs I'm talking about are different. They don't crash anything. The application keeps running, the UI stays responsive, the user keeps working and somewhere underneath, silently, everything they're doing is being thrown away.

I found two of those bugs in Clypra few days ago. They were sitting next to each other in the same codebase, following the same pattern, operating on the same principle: look fine, do nothing, destroy things quietly.

THE FIRST BUG

I was doing a lifecycle audit, not debugging a specific complaint, just trying to understand exactly what happens in Clypra when a user switches between projects. I had a document open, I was tracing the code path step by step, and about two hours in I hit a section of closeProject() that didn't look right.

There was a function call being made, a call that was supposed to reset the timeline to empty after a project closed. Nothing unusual about the intent. But the way it was written meant the reset happened asynchronously, without waiting for itself to complete before returning.

That sounds academic until you think through what it means in practice.

If a user closes Project A and then immediately opens Project B, the application loads Project B's data into memory correctly. The timeline fills with B's clips, B's tracks, B's entire editing history. Then, a few milliseconds later, after the code has already moved on, the reset from when Project A closed finally runs. And it doesn't know Project B has loaded. It has no way of knowing. It was started in a different context, and by the time it arrived, the world had changed.

So it wipes the timeline clean. Project B opens looking exactly as it should except for one thing: the timeline is empty. Not broken. Not crashed. Empty. The user assumes the load failed and starts recreating their work from scratch.

I sat with that for a while before I fully understood it, because the failure mode is so counterintuitive. The function that caused the damage had already returned successfully before it caused any damage. The harm came later, from a different execution context, triggered by work that started in a project that no longer existed.

The fix, when I found it, was a single word. But understanding why the fix was correct required understanding a principle I've seen in distributed systems literature, you cannot assume the context you started an operation in is still valid when it completes. The operation here was small, local, nothing resembling a distributed system in the traditional sense. But the race condition it created was structurally identical to the ones Kleppmann describes in DDIA when talking about async operations in multi-node environments. The producer and the consumer were running in different temporal contexts with no shared awareness of what had changed between them.

THE SECOND BUG

The second bug was quieter in a different way.

It lived in the auto-save layer. When a user drags a clip on the timeline, auto-save pauses, you don't want to write a half-finished edit to disk. When the drag ends, auto-save resumes and flushes whatever changes accumulated during the drag.

The mechanism that pauses and resumes auto-save is a flag, a single boolean, stored at the module level, shared across the entire application. It gets set to true when a drag starts and back to false when a drag ends. Simple, functional, and completely correct under normal usage.

But the teardown path, the code that runs when a project closes, doesn't know about this flag. It was never told. When I audited the reset function that's supposed to clean up all project state on close, the auto-save middleware wasn't in the list. Nobody had added it.

Which means there's a scenario where the flag gets left permanently set.

A user starts dragging a clip. Partway through the drag, before they release the mouse, they change their mind about the whole project and navigate back to the home screen. The application closes the project. The drag never ends, so the "drag ended" cleanup never runs. The flag stays set to true.

The user opens a new project. They make changes. They expect auto-save to work, because why wouldn't it? The UI gives no indication that anything is wrong. But every single save attempt goes through that flag, sees that it's set, and defers. The save never runs. It just keeps deferring, waiting for the drag to end that will never end, until the user closes the browser and loses everything they've done in that second project.

There's no error. No log. The application is healthy from its own perspective. The failure is entirely invisible.

CONCLUSION

When I put these two bugs next to each other, the pattern was immediately clear. Both were about state that was set by one thing and expected to be cleared by another, and the clearing path didn't know about the setting path. In one case the gap was temporal: the async operation resolved into a context it didn't belong to. In the other case the gap was structural: the teardown function that was supposed to clean up project state simply didn't have the auto-save flag on its list.

Both bugs were trivially fixable once found. That's usually how it goes with this class of bug. The fix is never the hard part. The hard part is that they're invisible until you go looking specifically for them and most teams never do.

The audit that found these took an afternoon. The bugs had been there for months.

What silent failure is sitting in your codebase right now, waiting for exactly the wrong moment?

But that's not what scalability really means.

Let me break it down simply.

Imagine your app has 10,000 active users today. Everything is running smoothly. Then tomorrow, something happens your app goes viral, a big media outlet mentions it, or a major event drives traffic, and suddenly you've got a million users hitting your app at the same time.

The real question is: does your app survive that?

If it does, your app is scalable. If it crashes or slows to a crawl, it's not. Simple as that.

And here's the part that trips people up, that survival has nothing to do with how clean your code is. It's about Resources. Servers. Databases. Bandwidth. Computing power. The infrastructure sitting behind your application.

When a million users show up at once, every single one of them is triggering computations — reading data, writing data, sending requests, getting responses. Your servers have to handle all of that simultaneously. If you don't have enough machines, enough memory, enough processing power to go around, your app buckles under the pressure.

So scalability basically comes down to one thing:

Do you have enough resources to handle the load when demand suddenly spikes?

That's why companies like Netflix, WhatsApp, and Google invest so heavily in distributed systems and cloud infrastructure. They're not just writing good code — they're buying the ability to scale. They spread the load across thousands of machines so no single machine gets overwhelmed.

The code matters, yes. But when real scale hits, it's the infrastructure that carries the weight.

Next time someone talks about making an app "more scalable," ask them — are they talking about the code, or the resources behind it? Because those are very different conversations.

Simply put, a reliable system is one that keeps doing what it's supposed to do, even when things go wrong. Hardware breaks, users make mistakes, bugs slip through. A reliable system handles all of that without falling apart.

Here's a quick way to think about it. A reliable app should:

• Do what the user actually expects it to do

• Handle mistakes without crashing, users will always do unexpected things

• Perform well enough for the job it's built for

• Keep unauthorized people out

So reliability basically means, as the book Designing Data-Intensive Applications puts it: "continuing to work correctly, even when things go wrong."

Now, the things that can go wrong are called faults. And systems that can handle faults without breaking are called fault-tolerant or resilient.

Here's something interesting though, a fault is not the same as a failure. A fault is when one part of your system misbehaves. A failure is when the whole system stops working for your users. The goal is to stop faults from turning into failures.

And here's the counterintuitive part: one of the best ways to build fault tolerance is to actually trigger faults on purpose — deliberately breaking things in a controlled environment so your system learns to handle them. Netflix actually built a tool called Chaos Monkey that does exactly this — it randomly kills processes in their system to make sure everything still holds up.

The takeaway? Don't just hope nothing goes wrong. Build for when it does.

In this post, we'll explore how these three concepts work together and separately, why separation of concerns matters, and how this pattern fits into the broader React ecosystem.

The Big Picture: Why These Three Pieces Matter

Before diving into each component, it's worth understanding the problem they solve together. Modern React applications need a way to:

• Store authentication data (tokens, user info, session status) in one place

• Make that data accessible throughout the component tree

• Provide methods to modify authentication state (login, logout, refresh)

• Keep components decoupled from authentication implementation details

This is where the three-part pattern shines. The auth provider owns and manages the authentication logic, the auth state represents the data itself, and the auth hook serves as the interface for components to interact with both.

Auth State: Your Single Source of Truth

Auth state is the foundation of the entire system. It's the JavaScript object (or set of variables) that holds your authentication data at any given moment. Think of it as your application's memory for everything authentication-related.

What Lives in Auth State?

Typical auth state includes:

• User information: Name, email, ID, roles, permissions

• Authentication status: Is the user logged in? Are we still checking?

• Tokens: Access tokens, refresh tokens (though sensitive data requires careful handling)

• Loading states: Is authentication being verified? Is a login request in progress?

• Error states: Did login fail? What went wrong?

Why Separate State Matters

By treating auth state as its own distinct concept, you create a clear boundary between "what we know about authentication" and "how we manage it." This separation is foundational to the entire pattern and offers several benefits:

Predictability: Your auth state is a pure data structure. You always know what shape it takes, making debugging and testing straightforward.

Flexibility: Because state is just data, you can persist it, log it, inspect it in DevTools, or even hydrate it from server-side rendering without worrying about implementation details.

Independence: Components can reason about authentication state without knowing where it comes from or how it's managed. A component simply needs to know "is there a user?" or "what's the user's role?" It doesn't need to know about API calls, token refresh logic, or storage mechanisms.

This aligns with React's unidirectional data flow philosophy, where data flows down through props and state updates flow up through callbacks.

Auth Provider: The Management Layer

The auth provider is a React Context Provider component that wraps parts of your application and manages the authentication lifecycle. It's where all the complex logic lives—the stuff components shouldn't have to worry about.

What the Provider Does

The provider handles the heavy lifting:

• Initialization: Checks for existing sessions on app startup (checking localStorage, validating tokens, making verification API calls)

• State management: Owns the auth state and provides methods to update it

• Side effects: Manages token refresh timers, handles unauthorized responses, syncs state with storage

• Business logic: Implements login flows, logout procedures, token rotation, session management

The Power of Centralization

By centralizing authentication logic in a provider, you gain several architectural advantages:

Single Responsibility: The provider has one job—manage authentication. It doesn't render UI, doesn't handle routing, doesn't manage business data. This focused responsibility makes the code easier to understand, test, and maintain.

Controlled Access: The provider acts as a gatekeeper. All authentication changes flow through it, giving you a single place to add logging, analytics, error handling, or validation.

Implementation Hiding: Components don't know whether you're using JWT, session cookies, OAuth, or some custom authentication scheme. This encapsulation means you can switch authentication strategies without touching every component in your app.

This pattern follows the Provider pattern that's central to React's Context API, allowing you to inject dependencies and share values across your component tree without prop drilling.

How Providers Fit in State Management

In the React ecosystem, providers are the standard way to implement global state. Whether you're using Context API, Redux (which uses a Provider), Zustand, Jotai, or any other state management solution, the provider pattern is fundamental.

For authentication specifically, many developers start with Context API for its simplicity and zero dependencies. As applications grow, some migrate to more sophisticated solutions:

• Redux: Offers time-travel debugging, middleware for side effects, and established patterns for complex state logic. Redux Toolkit has simplified Redux considerably, making it viable even for smaller apps.

• Zustand: A minimalist state management library that offers a simpler API than Redux while still providing centralized state. It's particularly popular for feature-specific state like authentication.

• React Query / TanStack Query: While primarily for server state, many developers use it for authentication state because auth data often comes from servers and benefits from caching, background updates, and automatic refetching.

The beauty of the provider pattern is that regardless of which state management solution you choose, the architecture remains similar—components consume state through hooks, providers manage state and logic.

Auth Hook: The Consumer Interface

The auth hook is the bridge between your components and your authentication system. It's a custom hook (usually something like useAuth or useAuthentication) that components call to access auth state and functionality.

What the Hook Provides

A well-designed auth hook typically returns:

• Current state: The user object, loading status, error states

• Action methods: Functions like login, logout, signup, updateProfile

• Derived state: Convenience booleans like isAuthenticated, isLoading, helper methods like hasPermission

The Beauty of Abstraction

The hook is an abstraction layer, and abstractions are where good architecture shines:

Component Simplicity: Components remain blissfully unaware of how authentication works. They just call useAuth() and get what they need. This keeps component code clean and focused on UI concerns.

Testability: You can mock the hook in tests without mocking entire providers or context values. Testing a component that uses useAuth becomes straightforward—just provide a mock hook that returns test data.

Refactorability: Want to change how authentication works internally? As long as the hook's interface stays stable, components don't need to change. This is the Open/Closed Principle in action.

Hooks in the React Ecosystem

Custom hooks are one of React's most powerful features, introduced in React 16.8. They allow you to extract component logic into reusable functions, and they've become the standard way to share stateful logic across components.

The auth hook pattern mirrors other popular hooks in the ecosystem:

• React Router's useNavigate and useLocation: Abstract routing functionality

• React Query's useQuery and useMutation: Abstract server state management

• Redux's useSelector and useDispatch: Abstract store access

All these hooks follow the same principle: provide a simple, consistent interface that hides complexity and keeps components focused on rendering UI.

Separation of Concerns: The Core Benefit

The real power of this three-part pattern emerges when you see how cleanly it separates concerns:

Layer 1: Data (Auth State)

Pure data structure with no logic. It's serializable, inspectable, and predictable.

Layer 2: Logic (Auth Provider)

Manages state transitions, handles side effects, implements business rules. Components never talk to this layer directly.

Layer 3: Interface (Auth Hook)

Provides a clean API for components. This layer shields components from provider implementation details.

This separation creates several benefits:

Maintainability: Each layer has a clear purpose. When something breaks or needs to change, you know exactly where to look.

Scalability: As your app grows, you can enhance each layer independently. Need better error handling? Update the provider. Need more convenience methods? Extend the hook. Need to track more data? Expand the state structure.

Testability: Each layer can be tested in isolation. State is just data, so test it with simple assertions. Provider logic can be tested by calling its methods and checking state changes. Components using the hook can be tested with mocked hook values.

Team Collaboration: Different developers can work on different layers without stepping on each other's toes. Frontend developers can focus on components and the hook interface while backend/middleware developers work on the provider's API integration logic.

Evolution and Migration

The three-part pattern is also migration-friendly. Many applications start simple and grow over time:

Stage 1: Simple Context API with basic state—perfect for small apps or prototypes.

Stage 2: Add middleware or side effect management as authentication logic grows—perhaps introducing Redux middleware or React Query mutations.

Stage 3: Implement advanced features like token refresh, automatic re-authentication, or multi-factor authentication—all while maintaining the same hook interface for components.

Because the layers are separated, you can evolve each independently without rewriting your entire application.

Conclusion

The auth hook, auth state, and auth provider pattern represents more than just a way to manage authentication—it's a demonstration of good architecture principles applied to React development. By separating data, logic, and interface into distinct layers, you create an authentication system that's maintainable, testable, scalable, and aligned with React's philosophy.

This pattern leverages React's strengths (Context, Hooks, composition) while respecting fundamental software engineering principles (separation of concerns, single responsibility, abstraction). The result is authentication code that's easier to write, easier to test, and easier to change as your application evolves.

Whether you're building a small side project or an enterprise application, taking time to structure your authentication with these three pieces will pay dividends as your codebase grows.

Further Reading

• React Context Documentation

• Rules of Hooks

• Thinking in React

• State Management in React

• React Query Authentication Guide

• Redux Authentication Example

KIRO: Structure for Production-Ready Code

What KIRO Is Good At

KIRO, introduced by AWS, distinguishes itself through its emphasis on spec-driven development. The platform excels at transforming natural language requirements into structured specifications before generating code. KIRO turns prompts into detailed requirements using EARS notation (Easy Approach to Requirements Syntax), then creates architecture plans, system designs, and implementation roadmaps.

The platform's hook system automates repetitive tasks that developers often forget. These event-driven automations execute when files are saved or created, handling tasks like updating test files when React components change, refreshing documentation when API endpoints are modified, or scanning for security issues before commits.

KIRO operates in two modes: Autopilot mode for autonomous code generation, and Supervised mode where developers review and approve each change before implementation. This dual approach allows teams to balance speed with control based on the criticality of different components.

Problems KIRO Solves

The platform addresses the gap between rapid prototyping and production-ready systems. While many AI coding tools excel at "vibe coding" and quick prototypes, KIRO focuses on maintaining the structure, documentation, and consistency required for production environments.

KIRO tackles several persistent challenges in software development: ensuring design alignment across teams, resolving conflicting requirements upfront, eliminating technical debt through proper planning, bringing rigor to code reviews, and preserving institutional knowledge through comprehensive specifications.

The platform helps teams avoid the common pitfall where prototypes built with AI assistance lack the documentation, tests, and architectural clarity needed for long-term maintenance.

Main Focus and Direction

KIRO's primary direction centers on bringing engineering discipline to AI-assisted development. The platform treats specifications as first-class artifacts that guide both human developers and AI agents toward consistent, well-documented implementations.

Built on Code OSS (the open-source foundation of VS Code), KIRO supports Model Context Protocol for connecting specialized tools, steering rules to guide AI behavior across projects, and standard features like agentic chat with file and URL context providers. The platform maintains compatibility with VS Code settings and Open VSX extensions.

Antigravity: Agent-First Architecture

What Antigravity Is Good At

Google's Antigravity takes a fundamentally different approach by treating autonomous agents as the primary interface rather than code editing. The platform launches with an Agent Manager interface that functions as mission control for orchestrating multiple AI agents working simultaneously across different workspaces.

Antigravity's unique capability lies in multi-agent orchestration. Developers can spawn multiple agent instances working in parallel—one researching APIs while another builds frontend components, all managed from a centralized dashboard. Each agent operates autonomously across three surfaces: the editor for code generation, the terminal for running commands, and an integrated Chrome browser for testing applications.

The platform's browser automation sets it apart from competitors. Agents can automatically launch applications, interact with them in the browser, capture screenshots, and verify functionality without leaving the IDE. This browser-in-the-loop capability enables agents to test their own work and provide real-time feedback.

Problems Antigravity Solves

Antigravity addresses the limitations of linear, synchronous development workflows where developers must constantly switch contexts. Traditional AI coding assistants operate like chatbots—you ask for something, wait for a response, review it, then ask for the next thing. This sequential pattern doesn't match how modern development teams actually work.

The platform enables asynchronous workflows where developers define high-level objectives and let agents execute them independently while maintaining other tasks. Multiple work streams can progress simultaneously without requiring constant human intervention.

Antigravity's artifact system solves the trust problem in autonomous coding. Rather than forcing developers to review raw tool calls, agents generate transparent artifacts—task lists, implementation plans, code diffs, screenshots, and browser recordings. Developers can leave feedback directly on these artifacts, similar to commenting on documents, and agents incorporate this feedback without stopping execution.

Main Focus and Direction

Antigravity's vision centers on evolving the IDE for an agent-first era. The platform presupposes that AI is not just a tool but an autonomous actor capable of planning, executing, validating, and iterating on complex engineering tasks with minimal human intervention.

Powered by Google's Gemini 3 models (with support for Anthropic's Claude Sonnet 4.5 and OpenAI's GPT-OSS), the platform treats learning as a core primitive. Agents retrieve from and contribute to a knowledge base, improving continuously from past tasks and understanding of the codebase.

The platform is currently available free during public preview, with generous rate limits on Gemini 3 Pro usage. Built as a fork of Visual Studio Code, it maintains compatibility with VS Code settings and extensions while adding agent-centric capabilities.

Cursor: Intelligent Assistance Across the Spectrum

What Cursor Is Good At

Cursor has gained significant adoption by offering what its creators describe as an "autonomy slider"—allowing developers to choose how much independence to give the AI based on the task at hand. The platform excels across multiple interaction levels, from subtle code completion to full autonomous agent mode.

The platform's tab completion feature uses a custom autocomplete model that predicts developer actions beyond simple line completion. It suggests multi-line edits and can anticipate entire code blocks based on context. The Cmd+K functionality enables targeted edits through natural language, allowing developers to describe changes they want across files.

Cursor's chat interface understands the entire codebase, allowing developers to ask questions and receive context-aware answers. The platform can reference code, images, web information, and documentation within conversations. It includes features like automatic commit message generation and bug finding that compares changes to the main branch to identify potential issues.

Problems Cursor Solves

Cursor addresses the cognitive load of modern software development by integrating AI assistance directly into the familiar VS Code environment. Rather than requiring developers to switch between their IDE, documentation, Stack Overflow, and ChatGPT, Cursor brings all these capabilities into a single interface.

The platform reduces context switching by keeping developers in their workflow while providing intelligent assistance. Developers can continue writing code naturally while receiving suggestions, ask questions without leaving their editor, and make targeted edits through conversational commands.

Cursor's approach makes AI assistance accessible to developers at all skill levels. Beginners can describe what they want in plain English and see working code generated as examples to learn from. Experienced developers can use it to accelerate routine tasks while maintaining full control over critical components.

Main Focus and Direction

Cursor's primary focus centers on making AI coding assistance feel natural and integrated rather than disruptive. The platform builds on the familiar VS Code foundation that millions of developers already use, adding AI capabilities that enhance rather than replace traditional coding workflows.

The platform supports model optionality, allowing developers to choose between frontier models from OpenAI, Anthropic (Claude Sonnet 4.5, Claude Opus 4.5), Google (Gemini 3 Pro), and xAI (Grok). This flexibility lets teams select models based on their specific needs and preferences.

Cursor emphasizes productivity without requiring developers to fundamentally change how they work. It provides tools for both quick tasks and complex multi-file operations, with features designed to reduce tedious work while keeping developers in control of architectural decisions.

Comparing Approaches

These three platforms represent different philosophies about AI-assisted development:

KIRO focuses on structure and production readiness, emphasizing that AI-generated code needs proper specifications, documentation, and automated quality checks to be maintainable long-term. It targets teams who need to move from prototypes to production systems with proper engineering discipline.

Antigravity pursues an agent-first future where developers orchestrate autonomous agents working in parallel rather than directly writing code. It targets workflows requiring significant coordination across multiple tasks and benefits teams who can delegate entire features to AI while maintaining oversight through artifacts and feedback.

Cursor takes a more gradual approach, enhancing traditional coding workflows with AI assistance at varying levels of autonomy. It targets developers who want AI help without completely changing their existing practices, making it accessible to broader audiences from beginners to experienced professionals.

Practical Considerations

Each platform makes different trade-offs in terms of learning curve, workflow changes, and target use cases:

KIRO requires adopting spec-driven development practices and may feel more structured than some developers prefer. However, this structure pays dividends for teams building production systems requiring comprehensive documentation and testing.

Antigravity demands the most significant workflow shift, moving from direct code editing to agent orchestration. This works well for complex projects with multiple parallel work streams but may feel excessive for simpler tasks or developers who prefer hands-on coding.

Cursor offers the gentlest learning curve since it builds on VS Code's familiar interface and allows developers to use as much or as little AI assistance as they want. However, this flexibility means teams must develop their own practices around when and how to leverage AI capabilities.

Looking Forward

These platforms illustrate how AI is reshaping software development tools in different ways. KIRO brings engineering discipline to AI coding, Antigravity explores autonomous agent workflows, and Cursor makes AI assistance accessible within traditional development patterns.

The choice between them depends on team priorities: production readiness and documentation (KIRO), parallel autonomous workflows (Antigravity), or flexible AI assistance within familiar tools (Cursor). As these platforms evolve and others emerge, developers will have increasingly sophisticated options for incorporating AI into their workflows in ways that match their specific needs and working styles.

The Problem They're Solving

Imagine you're using an AI assistant to book a restaurant reservation. Right now, you'd have this tedious back-and-forth:

• You: "Book a table for tomorrow at 7pm"

• AI: "How many people?"

• You: "Two people"

• AI: "Any dietary restrictions?"

• You: "One vegetarian"

This text-only interaction is clunky and slow. Now imagine if the AI could just show you a booking form with date picker, time slots, and input fields—all pre-filled based on what you said. That's what these new protocols enable.

What is A2A (Agent2Agent Protocol)?

A2A allows AI agents to communicate with each other, securely exchange information, and coordinate actions across various enterprise platforms or applications. Think of it as a universal language that lets AI agents from different companies work together seamlessly.

Key Features:

• Open Standard: Donated to the Linux Foundation with support from over 150 organizations including Atlassian, Box, Salesforce, SAP, and ServiceNow

• Enterprise-Ready: Built-in security with authentication and authorization

• Long-Running Tasks: Supports everything from quick tasks to deep research that may take days

• Multi-Modal: Handles text, audio, and video streaming

Real-World Example: Your company's AI assistant could talk to Salesforce's AI agent to pull customer data, then communicate with SAP's AI to check inventory, and finally coordinate with your internal booking system—all without you manually connecting each piece.

What is A2UI (Agent to User Interface)?

A2UI provides a standard format for agents to generate rich user interfaces that render natively on the client side. Instead of just sending text responses, AI agents can now create interactive, visual interfaces on the fly.

Key Features:

• Security First: Uses declarative JSON format, not executable code—preventing malicious code injection

• LLM-Friendly: Designed for AI models to generate easily and update incrementally

• Framework-Agnostic: Works with React, Flutter, Angular, and other platforms

• Native Look: Inherits your app's styling and branding automatically

Real-World Example: You upload a photo of your backyard and ask an AI landscaping assistant for help. Instead of describing what forms you need to fill out, the agent uses Gemini to understand the photo and creates a custom form specifically for your landscaping needs—with all the right fields based on what it sees.

How A2UI and A2A Work Together

These protocols are designed to complement each other:

1. A2A handles agent-to-agent communication behind the scenes

2. A2UI handles how agents present information to you, the user

3. Together, they create a multi-agent ecosystem where different AI agents can collaborate and show you beautiful, interactive interfaces

You can send A2UI directly to a client front end via A2A, creating a seamless experience from backend collaboration to frontend presentation.

Why This Matters for Developers and Businesses

For Developers:

• Build once, deploy anywhere (web, mobile, desktop)

• No more choosing between security and rich UI

• Easy integration with existing tech stacks

• Open-source and community-driven

For Businesses:

• Agents from different vendors can now work together

• Better user experiences with visual, interactive interfaces

• Enterprise-grade security and authentication

• Standardized approach to managing AI agents across platforms

Getting Started

Both protocols are open-source and available now:

• A2UI: Visit a2ui.org for documentation and examples

• A2A: Currently at version 0.3, with SDKs available for Python and other languages

• Integration: Frameworks like CopilotKit, Flutter's GenUI SDK, and AG-UI already support A2UI

The Bigger Picture

We're entering what Google calls "the era of the multi-agent mesh"—a future where AI agents from Google, Microsoft, SAP, Salesforce, and countless other companies can work together seamlessly. These protocols are the foundation for that future.

Rather than having isolated AI tools that can't communicate, we're moving toward an interconnected ecosystem where agents collaborate to solve complex problems, and users interact with them through beautiful, intuitive interfaces.

Want to learn more? Check out the official documentation and start experimenting with these protocols in your projects. The AI revolution isn't just about smarter models—it's about smarter collaboration and better user experiences.

Follow AIEraDev for more insights on AI development and emerging technologies.

The Fear Factor

Developers are genuinely getting scared to keep using React. Not because it's bad at what it does, but because keeping up feels like a full-time job. Every few months, there's a new paradigm shift: Hooks replaced classes, Server Components are replacing client-side rendering, and the goal posts keep moving. The fear isn't about learning new things—developers love that—it's about investing time in patterns that might be deprecated next year.

When your production apps rely on a library that's constantly reinventing itself, that's not innovation, that's instability.

Over-Engineering Everything

React has become over-engineered. What started as a simple library for building UIs has morphed into an entire ecosystem of concepts that require deep understanding: Suspense boundaries, Server Components, streaming SSR, selective hydration, and async transitions.

Do we really need all this complexity for most applications? A typical CRUD app or dashboard doesn't need the bleeding edge of rendering optimization. Yet React's direction seems to optimize for the 1% of applications at the scale of Facebook, leaving the 99% to deal with unnecessary complexity.

Developers Want Separation

Here's the uncomfortable truth: most developers still prefer the clean separation between frontend and backend. The traditional model where your backend serves an API and your frontend consumes it isn't outdated—it's proven, simple, and flexible.

React Server Components (RSC) blur this line in ways that make many developers uncomfortable. Mixing server and client code in the same component tree feels like we're going backwards to the PHP days, except with more complexity. The mental overhead of tracking what runs where, managing the boundary between server and client, and dealing with serialization constraints—it's exhausting.

Developers chose React precisely because it let them focus on the frontend while backend teams handled their domain. Now React wants to be full-stack, and not everyone is on board.

The Framework Lock-In

React used to be just a library. Now, to use its latest features properly, you practically need Next.js or another meta-framework. That's framework lock-in disguised as progress. What happened to the "just a view library" philosophy?

The Community Split

The React community is splitting into two camps: those building the next Twitter or Netflix, and those building regular business applications. The former group embraces every new feature. The latter group just wants stability, simplicity, and patterns that won't be obsolete in 18 months.

React's core team seems to be optimizing for the former while the majority falls into the latter.

What Developers Actually Want

Most developers want:

• Stability over constant paradigm shifts

• Simple mental models over theoretical purity

• Clear separation of concerns

• The ability to use React without a PhD in concurrent rendering

• Backwards compatibility that actually works

Moving Forward

React isn't going anywhere—it's too entrenched. But the growing concerns are valid. Maybe it's time for the React team to slow down, stabilize what exists, and remember that not every app needs to be optimized like Facebook.

Or maybe it's time for developers to seriously evaluate alternatives like Vue, Svelte, or Solid that prioritize developer experience over architectural experiments.

The library that won by being simple is losing developers by being complex. That's the irony React needs to address.

What's your take? Are you feeling the React fatigue, or are you excited about its direction? Let me know in the comments.

And here's the kicker: you can host up to 10 full-stack projects for just $5/month if you're strategic about it. Let me show you how.

The Problem with Traditional Cloud Platforms

Before we dive into Railway, let's talk about the elephant in the room. Traditional cloud platforms like AWS, GCP, or Azure are powerful, but they're overkill for hobby projects. They come with:

• Complex pricing models that make you feel like you need a PhD in cloud economics

• Overwhelming dashboards with thousands of services

• The constant fear of accidentally leaving a resource running and getting a surprise $500 bill

• Configuration hell that turns a simple deployment into a multi-day ordeal

Meanwhile, simpler platforms like Heroku became increasingly expensive, and the free tiers started disappearing left and right.

Enter Railway: Developer Experience Meets Affordability

Railway is a modern cloud platform that's built specifically with developers in mind. Think of it as the perfect middle ground: simpler than AWS but more powerful than traditional PaaS solutions.

Here's what makes Railway special:

1. Deploy in Seconds, Not Hours

   Railway connects directly to your GitHub repository. Push your code, and Railway automatically detects your framework, builds your project, and deploys it. No Docker knowledge required (though you can use Docker if you want).

    # It's literally this simple
    railway init
    railway up
   

2. Database Provisioning is a Breeze

   Need a PostgreSQL database? Click a button. Want to add Redis for caching? Another click. Railway provisions fully managed databases in seconds, and they're automatically connected to your application with environment variables.

3. Built-in DevOps Tools

   Railway gives you everything you need out of the box:

   • Automatic HTTPS certificates

   • Environment variable management

   • Deployment logs and metrics

   • Easy rollback to previous deployments

   • Custom domains with zero configuration

The Magic $5/Month Strategy

Now, let's talk about the game-changer: how to host 10 full-stack projects for just $5/month.

Understanding Railway's Pricing

Railway's Hobby plan costs $5/month and gives you:

• $5 worth of usage credits

• Pay only for what you use (compute, memory, bandwidth)

• No hidden fees or surprise charges

The Backend-Only Approach

Here's the secret: deploy only your backends on Railway and host your frontends elsewhere (for free).

Modern full-stack development naturally separates concerns:

• Backend: APIs, databases, business logic, authentication

• Frontend: React, Vue, Next.js, static sites

Your backend needs to be always running and requires compute resources. But your frontend? It's just static files that can be served from a CDN.

The Math Behind 10 Projects

By deploying only your backend infrastructure on Railway, you dramatically reduce resource usage:

1. Small API services (Node.js, Express, FastAPI) use minimal resources when idle

2. Railway's usage-based pricing means you only pay when your services are actually working

3. Shared databases can serve multiple small projects

A typical small hobby project backend might use:

• 0.5GB RAM

• Minimal CPU (only when handling requests)

• A shared PostgreSQL database

With smart resource management, $5 can easily cover 8-10 small to medium hobby projects.

Real-World Setup Examples

Example 1: The Side Project Portfolio

Railway (Backend Infrastructure):
├── Project 1: Todo API (Node.js + PostgreSQL)
├── Project 2: Blog API (Python FastAPI + PostgreSQL)
├── Project 3: Image Upload Service (Node.js + Redis)
├── Project 4: Auth Service (Node.js + PostgreSQL)
└── Shared PostgreSQL Database (multiple schemas)

Vercel/Netlify (Frontend - Free):
├── Todo App (React)
├── Blog Frontend (Next.js)
├── Image Gallery (Vue.js)
└── Portfolio Site (Static)

Example 2: The Microservices Enthusiast

Railway:
├── User Service API
├── Payment Service API
├── Notification Service API
├── PostgreSQL Database
└── Redis Cache

Frontend Host (Free):
├── Admin Dashboard
├── Customer App
└── Marketing Site

Best Practices for Maximizing Your $5

1. Consolidate Databases

   Instead of spinning up a separate database for each project, use one PostgreSQL instance with different schemas:

    CREATE SCHEMA todo_app;
    CREATE SCHEMA blog_api;
    CREATE SCHEMA image_service;
   

2. Use Serverless-Friendly Patterns

   Design your APIs to sleep when not in use. Railway's cold start times are minimal, so embrace stateless services that can scale to zero.

3. Optimize Your Docker Images

   If you're using Docker, use multi-stage builds and Alpine Linux to keep images small:

    FROM node:18-alpine AS builder
    WORKDIR /app
    COPY package*.json ./
    RUN npm ci
    COPY . .
    RUN npm run build
   
    FROM node:18-alpine
    WORKDIR /app
    COPY --from=builder /app/dist ./dist
    COPY package*.json ./
    RUN npm ci --production
    CMD ["node", "dist/index.js"]
   

4. Monitor Your Usage

   Railway provides excellent usage metrics. Check your dashboard regularly to ensure you're staying within budget.

5. Host Frontends on Free Tiers

   Perfect free hosting options for your frontends:

   • Vercel: Best for Next.js and React apps

   • Netlify: Great for static sites and JAMstack apps

   • Cloudflare Pages: Unlimited bandwidth, great performance

   • GitHub Pages: Perfect for documentation and simple sites

When Railway Shines

Railway is perfect for:

• Side projects and portfolios: Keep costs low while maintaining professional infrastructure

• Hackathon projects: Deploy quickly without infrastructure headaches

• Learning and experimentation: Try new technologies without commitment

• Small SaaS MVPs: Validate your idea before scaling up

• API-first applications: Backend services that power multiple frontends

Potential Limitations

To be fair, Railway might not be ideal for:

• High-traffic production apps: Once you exceed the hobby plan limits, costs can scale up

• Large monolithic applications: Better suited for microservices and smaller apps

• Projects requiring specific AWS services: Railway focuses on the core infrastructure

• Ultra-low latency requirements: While fast, it's not as globally distributed as major CDNs

Getting Started

Ready to try Railway? Here's your quickstart:

1. Sign up at railway.com (use GitHub OAuth)

2. Create a new project from a template or connect your repo

3. Add a database if needed (PostgreSQL, MySQL, MongoDB, Redis)

4. Deploy your backend and grab the public URL

5. Configure your frontend to use the Railway API URL

6. Deploy your frontend on Vercel/Netlify (for free)

Conclusion

Railway has genuinely transformed how I approach hobby projects. The combination of excellent developer experience, transparent pricing, and powerful features makes it the sweet spot for full-stack developers.

By strategically deploying only your backend infrastructure on Railway and leveraging free frontend hosting, you can maintain a portfolio of 10 active projects for just $5/month. That's less than the price of a fancy coffee, and you get professional-grade infrastructure for all your side projects.

Stop worrying about hosting costs and infrastructure complexity. Focus on building amazing things. Railway will handle the rest.

Have you tried Railway? What's your go-to platform for hosting hobby projects? Drop your thoughts in the comments below!

Disclaimer: I'm not affiliated with Railway—just a genuinely happy user who wants to share this gem with fellow developers.