DEV Community: The Beyond Horizon

Tailwind CSS Advanced Patterns and Custom Plugins

The Beyond Horizon — Fri, 03 Jul 2026 06:21:20 +0000

Custom utilities, CVA variants, dark mode, animations, and writing custom Tailwind plugins — beyond utility classes

Beyond Utility Classes
Tailwind CSS has become the default styling solution for modern React and Next.js applications. Most developers learn the basics — utility classes like p-4, text-lg, flex — and stop there. But Tailwind’s real power emerges with advanced patterns that keep your code DRY, your designs consistent, and your bundle sizes minimal.

At The Beyond Horizon, Tailwind CSS is in every project. Here are the patterns and techniques we use daily.

Custom Utilities with tailwind.config
Tailwind’s configuration file is where you extend the framework to match your design system:

Custom Colors
Define your brand colors as CSS custom properties and reference them in tailwind.config. Use semantic names like primary, secondary, accent rather than color values. This way, dark mode and theme switching only require changing CSS variable values.

Custom Spacing and Typography
Extend the spacing scale for your design system. If your design uses an 8px grid, add custom values: 4.5 for 18px, 13 for 52px, etc. For typography, define custom font sizes with matching line heights as tuples: fontSize: { “display”: [“3.5rem”, { lineHeight: “1.1” }] }.

Custom Animations
Define keyframes in tailwind.config and reference them as animation utilities. Create slide-in, fade-up, scale-in, and other animations that match your design language. Use these with the animate- prefix: animate-slide-in, animate-fade-up.

Component Variants with CVA
Class Variance Authority (CVA) is the best way to build component variants with Tailwind. It provides a typed API for defining variant combinations:

Define a button variant using cva() with base styles, then variants for intent (primary, secondary, destructive), size (sm, md, lg), and other dimensions. Each variant maps to specific Tailwind classes. CVA handles combining these variants and resolving conflicts.

Why CVA Over Manual Classes
Type safety: Variant options are typed. Your IDE autocompletes valid variants.

Compound variants: Define styles that apply only when specific variant combinations are active.

Default variants: Set default values so consumers do not need to specify every variant.

Write on Medium
Composability: Merge CVA variants with additional classes using tailwind-merge to resolve conflicts.

Responsive Design Patterns
Mobile-First Breakpoints
Tailwind is mobile-first by default. Unprefixed utilities apply to all screen sizes. sm:, md:, lg: prefixes apply at that breakpoint and above. Always design for mobile first, then add complexity for larger screens.

Container Queries
Tailwind v3.4+ supports container queries with the @container plugin. Unlike media queries that respond to viewport width, container queries respond to the parent container’s width. This is essential for reusable components that appear in different layout contexts.

Responsive Typography
Use Tailwind’s clamp-based fluid typography or define responsive font sizes at breakpoints. For hero headings: text-3xl md:text-5xl lg:text-6xl. For body text, keep it consistent — readability suffers when body text size changes between breakpoints.

Dark Mode
Tailwind supports dark mode with the dark: prefix. Use the class strategy (dark mode toggled by a class on the HTML element) for user-controlled dark mode, or the media strategy (follows OS preference) for automatic switching.

Implementation Pattern
Store the user’s preference in localStorage

Apply the dark class to the HTML element on load, before first render, to prevent flash

Use CSS custom properties for semantic colors: — background, — foreground, — muted — then switch their values between light and dark themes

shadcn/ui uses this pattern and provides an excellent reference implementation

Animation Utilities
Beyond Tailwind’s built-in animations (animate-spin, animate-pulse, animate-bounce), build a library of custom animations:

Entrance animations: animate-in for modals and dropdowns. Combine with transition-all for smooth mounting.

Scroll-triggered animations: Use IntersectionObserver to add classes that trigger Tailwind animations when elements enter the viewport.

Staggered animations: Use animation-delay utilities with CSS custom properties. Each child in a list has an incrementing delay for a cascade effect.

Reduced motion: Always wrap animations in motion-safe: to respect the prefers-reduced-motion user preference.

Writing Custom Plugins
Tailwind plugins extend the framework with custom utilities, components, or variants:

Utility Plugin
Create a plugin using Tailwind’s plugin() function. Add utilities with addUtilities(), providing CSS-in-JS objects. For example, a text-balance utility that applies text-wrap: balance for headline typography.

Component Plugin
Use addComponents() for more complex patterns. A card component plugin might add .card with padding, border-radius, and shadow, plus .card-header and .card-body with appropriate spacing.

Variant Plugin
Use addVariant() to create custom selector-based variants. A hocus variant that matches both :hover and :focus states. A group-sidebar variant that matches when a parent has a specific data attribute.

Tailwind is a design system toolkit, not just a CSS framework. Master these patterns and you will build UIs faster with more consistency. Need a design system built? Let us help.

Building Real-Time Applications with WebSockets and Next.js

The Beyond Horizon — Fri, 03 Jul 2026 06:20:47 +0000

WebSocket fundamentals, Socket.io vs native, scaling strategies, and fallback patterns for real-time apps

Why WebSockets Matter
HTTP is request-response. The client asks, the server answers. For real-time features — live chat, collaborative editing, stock tickers, multiplayer games, live dashboards — this model falls short. Polling (asking the server every N seconds) wastes bandwidth and introduces latency. Server-Sent Events work for one-way streams but not bidirectional communication.

WebSockets establish a persistent, full-duplex connection between client and server. Once opened, both sides can send messages at any time without the overhead of HTTP headers. A single WebSocket frame is as small as 2 bytes.

WebSocket Basics
The WebSocket protocol (RFC 6455) starts with an HTTP upgrade handshake. The client sends an Upgrade: websocket header, the server responds with 101 Switching Protocols, and the connection upgrades from HTTP to WebSocket. From this point, both sides communicate over the same TCP connection.

Key Concepts
Connection lifecycle: open, message, error, close events

Frames: Messages are sent as frames. Text frames carry UTF-8 strings. Binary frames carry arbitrary data.

Ping/Pong: Keep-alive mechanism to detect dead connections. The server sends a ping, the client responds with pong.

Close handshake: Either side can initiate a graceful close with a status code and reason string.

Socket.io vs Native WebSockets
Native WebSocket API
The browser’s built-in WebSocket API is simple: new WebSocket(url), then listen for onopen, onmessage, onerror, and onclose events. Send messages with socket.send(data).

Advantages: No dependencies, smallest bundle size, direct control over the protocol.

Disadvantages: No automatic reconnection, no room/namespace support, no fallback for environments that block WebSockets, no built-in message acknowledgment.

Socket.io
Socket.io is a library that wraps WebSockets with additional features:

Automatic reconnection: Reconnects with exponential backoff when the connection drops.

Rooms and namespaces: Organize connections into logical groups. Broadcast to all users in a chat room without managing connection lists manually.

Fallback transports: Falls back to HTTP long-polling when WebSockets are blocked (corporate firewalls, some mobile networks).

Acknowledgments: Callback-based message confirmation. Know when the server received and processed your message.

Binary support: Seamless handling of binary data alongside text.

Become a Medium member
Our recommendation: Use Socket.io for production applications. The reconnection handling and room support alone justify the 40KB bundle addition.

Implementing Real-Time Chat
A basic real-time chat with Next.js and Socket.io requires:

Server Setup
Create a custom server (server.ts) that initializes both the Next.js app and a Socket.io server on the same port. Listen for connection events, then within each connection listen for join-room, leave-room, and send-message events. Broadcast received messages to all other users in the same room using socket.to(room).emit().

Client Setup
In your React client component, initialize the Socket.io client with useEffect. Connect to the server, join a room, and listen for incoming messages. Store messages in state and render them. Send messages through socket.emit(“send-message”, { room, text }).

Message Persistence
For production chat, persist messages to a database. When a user joins a room, fetch recent message history from PostgreSQL. New messages are saved to the database and simultaneously broadcast via Socket.io.

Building Live Dashboards
Real-time dashboards push data updates to connected clients as they happen:

Server-side: A background process monitors data changes (database polling, webhook listeners, or change data capture). When data changes, emit an event to connected dashboard clients.

Client-side: Subscribe to specific metric channels. Update charts and counters in real-time as events arrive.

Throttling: Batch updates into 1-second windows to prevent overwhelming the UI with per-millisecond updates.

Scaling WebSockets
A single Node.js process handles approximately 10,000–50,000 concurrent WebSocket connections depending on message volume and server resources. For larger scale:

Redis adapter: Socket.io’s Redis adapter enables multiple server instances to share connection state. A message emitted on one server is broadcast to clients connected to other servers.

Sticky sessions: WebSocket connections must maintain affinity to a single server instance. Configure your load balancer for sticky sessions based on the connection ID.

Horizontal scaling: Add more server instances behind the load balancer. Each instance handles a portion of connections, coordinated through Redis.

Fallback Strategies
Not all environments support WebSockets reliably:

Corporate proxies: Some proxies terminate WebSocket connections. Socket.io’s HTTP long-polling fallback handles this transparently.

Mobile networks: Cellular network switches can drop WebSocket connections. Implement reconnection with exponential backoff.

Server-Sent Events: For one-directional data (server to client only), SSE is simpler than WebSockets and works through more proxies.

Real-time features transform static applications into living, interactive experiences. Want to build real-time into your product? Get in touch.

Server Components vs Client Components in Next.js 15

The Beyond Horizon — Fri, 03 Jul 2026 06:20:05 +0000

When to use server vs client components, the use client directive, data fetching patterns, and composition strategies in Next.js 15

The Component Model Shift
Next.js 13 introduced the App Router with React Server Components (RSC). Next.js 15 has refined this model into a mature, production-ready architecture. The fundamental shift: components are server components by default. They run on the server, have zero JavaScript bundle cost on the client, and can directly access databases, file systems, and APIs.

This is the biggest change to React development since hooks. Understanding when to use server components versus client components is now the most important architectural decision in Next.js applications.

Server Components: The Default
Every component in the App Router is a server component unless you explicitly add the “use client” directive. Server components:

Run on the server only: Their code never ships to the browser. Import a 200KB charting library in a server component and your client bundle is unaffected.

Can be async: Use async/await directly in the component body to fetch data. No useEffect, no loading states in the component itself — just await your data.

Access backend resources directly: Query your database with Drizzle, read files with fs, call internal APIs — all without exposing endpoints.

Stream to the client: React renders server components to a special format that streams to the browser, enabling progressive page loading with Suspense.

What Server Components Cannot Do
No useState or useReducer — they have no client-side state

No useEffect — they have no lifecycle in the browser

No event handlers (onClick, onChange) — they cannot respond to user interactions

No browser APIs (window, localStorage, IntersectionObserver)

Client Components: Opt-In Interactivity
Add “use client” at the top of a file to make it a client component. Client components:

Run on both server (for SSR) and client: They are server-rendered for the initial HTML, then hydrated on the client for interactivity.

Support all React hooks: useState, useEffect, useRef, custom hooks — everything works.

Handle user interaction: onClick, onSubmit, onChange — any event handler requires a client component.

Write on Medium
Access browser APIs: localStorage, window dimensions, intersection observers, media queries.

The “use client” Directive
The directive marks a boundary. The file it appears in and everything it imports becomes part of the client bundle. This is why you should push “use client” as deep into the component tree as possible — wrap only the interactive leaf components, not entire page layouts.

Data Fetching Patterns
Server Components: Direct Data Access
In server components, fetch data directly. Call your database, call external APIs, read from the file system. The data is fetched at request time (dynamic rendering) or build time (static rendering) depending on your configuration.

Use the cache() function from React to deduplicate data fetches when multiple server components need the same data during a single render.

Client Components: API Routes or Server Actions
Client components cannot access the database directly. They fetch data through:

Server Actions: Functions marked with “use server” that client components can call directly. Next.js handles the RPC communication automatically.

API Routes: Traditional REST endpoints in the app/api directory.

Client-side fetching: SWR or React Query for data that needs to refresh on the client (real-time data, polling).

Performance Implications
The server/client split has dramatic performance implications:

Bundle size: A page with 80% server components and 20% client components ships 80% less JavaScript than the same page built entirely with client components.

Time to Interactive: Less JavaScript means faster hydration. Users can interact with the page sooner.

SEO: Server-rendered HTML is immediately available to search engine crawlers.

Streaming: Server components support Suspense streaming, showing content progressively as it becomes available.

Composing Server and Client Components
The key rule: server components can import and render client components, but client components cannot import server components. However, client components can accept server components as children via the children prop.

This pattern is called the “donut” pattern: a client component wraps around server components passed as children. The client component provides interactivity (like a collapsible panel), while the server components inside provide the data-heavy content.

Common Composition Patterns
Layout with interactive header: The layout is a server component. The header navigation with mobile menu toggle is a client component. The page content is a server component.

Data table with sorting: The data fetching and initial render is a server component. The sort controls and column resizing are client components.

Form with validation: The form layout and labels are server components. The input fields with real-time validation are client components.

Think of server components as the data backbone and client components as the interactive skin. Keep the skin thin and the backbone heavy. That is the architecture Next.js 15 rewards. Want to build with this architecture? Let us talk.

TypeScript Best Practices for Large Codebases

The Beyond Horizon — Thu, 25 Jun 2026 08:51:50 +0000

Strict mode, discriminated unions, branded types, utility types, avoiding any — TypeScript practices that scale to 500K+ line codebases

Why TypeScript at Scale Is Different
TypeScript in a 500-line side project is forgiving. TypeScript in a 500,000-line production codebase with 20 contributors is a different animal entirely. The type system that was supposed to catch bugs can instead become a source of confusion, maintenance burden, and false confidence if not used deliberately.

At The Beyond Horizon, we enforce strict TypeScript practices across all projects from day one. Here is what we have learned about keeping TypeScript productive at scale.

Enable Strict Mode — All of It
In your tsconfig.json, set “strict”: true. This enables:

strictNullChecks: Variables are not implicitly nullable. You must handle null and undefined explicitly.

noImplicitAny: Every variable must have a type — no silent any types from inference failures.

strictFunctionTypes: Function parameter types are checked contravariantly.

strictPropertyInitialization: Class properties must be initialized in the constructor.

If your existing codebase does not compile under strict mode, enable each flag incrementally and fix errors file by file. Do not leave strict mode off because it is “too many errors” — those errors are real bugs waiting to happen.

Discriminated Unions
Discriminated unions are TypeScript’s most powerful pattern for modeling state. Instead of optional fields and boolean flags, use a union of types with a literal discriminant:

Define a type like ApiResponse with a status field set to a literal string. When status is “loading”, no other fields exist. When status is “success”, a data field is present. When status is “error”, an error field is present. TypeScript narrows the type automatically when you check the status field in a switch or if statement.

This eliminates entire classes of bugs: accessing data before it is loaded, forgetting to handle the error case, or having impossible states like both data and error being present simultaneously.

Branded Types
TypeScript’s structural typing means that a UserId (string) and an OrderId (string) are interchangeable. This is a bug waiting to happen — passing a user ID where an order ID is expected compiles without error.

Branded types add a phantom property that makes structurally identical types incompatible. Declare a type UserId = string & { readonly __brand: “UserId” }. Create a factory function that casts a string to UserId after validation. Now TypeScript prevents you from mixing up ID types.

Utility Types
TypeScript’s built-in utility types eliminate boilerplate:

Partial: Makes all properties optional. Use for update operations where you only change some fields.

Required: Makes all properties required. Use for strict object creation.

Write on Medium
Pick: Extracts a subset of properties. Use for API responses that return only specific fields.

Omit: Removes specific properties. Use for creating types without sensitive fields like passwords.

Record: Creates an object type with keys of type K and values of type V. Use for lookup maps.

Extract and Exclude: Filter union types.

ReturnType: Extracts the return type of a function. Use to type variables that store function results without duplicating the type definition.

Avoiding any
The any type disables all type checking. It is a virus — one any in a function signature infects everything it touches.

Use unknown instead of any for values whose type you do not know. unknown requires type narrowing before use, forcing you to validate.

Use never for cases that should be unreachable. If TypeScript does not error on a never assignment, your logic has a gap.

Use generics when the type depends on the caller: function identity(value: T): T is better than function identity(value: any): any.

Banning any in CI
Add an ESLint rule to ban explicit any types: @typescript-eslint/no-explicit-any set to error. Run this in CI to prevent any from entering the codebase through pull requests.

Module Organization
For large codebases, organize types close to where they are used:

Co-locate types with code: Place type definitions in the same file or a neighboring types.ts file within the same feature directory.

Shared types in a types/ directory: Only types used across multiple features belong in a shared directory.

Barrel exports: Use index.ts files to create clean import paths, but be aware that barrel files can increase bundle size if tree-shaking is not effective.

Namespace with modules: Use TypeScript’s module system (import/export) rather than namespaces for code organization.

Declaration Files
When integrating with untyped JavaScript libraries, write declaration files (.d.ts) rather than using any:

Create a types/ directory for third-party type declarations

Use declare module to type modules without published types

Contribute your types back to DefinitelyTyped when possible

TypeScript is only as good as the discipline your team applies to it. Set strict standards early, enforce them in CI, and your codebase will remain maintainable as it grows. Need help scaling your TypeScript codebase? Contact us.

Database Migration Best Practices for Production Systems

The Beyond Horizon — Fri, 19 Jun 2026 03:51:46 +0000

Zero-downtime patterns, rollback strategies, and data backfill techniques — production-safe database migrations with Drizzle and Prisma

Why Database Migrations Are Scary
Database migrations in production are terrifying because they are irreversible in ways that code deployments are not. You can roll back a bad code deployment in seconds with a container image swap. Rolling back a database migration that dropped a column, transformed data types, or restructured tables is dramatically harder — sometimes impossible without data loss.

Yet migrations are inevitable. Business requirements evolve, schemas need to change, and data models that were perfect six months ago need updating. The question is not whether to migrate — it is how to migrate safely.

Zero-Downtime Migration Principles
The golden rule: never make a breaking change in a single deployment. Instead, split every breaking migration into multiple non-breaking steps:

Adding a Column
This is the simplest migration. Add the column with a default value or allow NULL. Deploy code that writes to the new column. Backfill existing rows. Deploy code that reads from the new column. This can be done in a single deployment since adding a nullable column does not break existing queries.

Removing a Column
This requires two deployments:

Deploy 1: Remove all code references to the column. The column still exists in the database but nothing reads from or writes to it.
Deploy 2: Run the migration to drop the column.

If you drop the column first, any running server instance that references it will throw errors during the deployment window.

Renaming a Column
Never rename directly. Instead:

Add the new column
Deploy code that writes to both old and new columns
Backfill the new column from the old column
Deploy code that reads from the new column
Deploy code that stops writing to the old column
Drop the old column

Subscribe to the Medium newsletter
Yes, this is six steps for a rename. That is the cost of zero downtime.

Versioned Migrations with Modern ORMs
Drizzle ORM
Drizzle Kit generates SQL migration files from your schema changes. Run drizzle-kit generate to create a numbered migration file. Run drizzle-kit migrate to apply pending migrations. Each migration is tracked in a drizzle migrations table.

Drizzle’s approach is SQL-first — you can inspect and modify the generated SQL before applying it. This is valuable for production systems where you need to review exactly what will run.

Prisma
Prisma Migrate generates migrations from changes to your schema.prisma file. Run npx prisma migrate dev to create and apply migrations in development. Run npx prisma migrate deploy in production to apply pending migrations without generating new ones.

Prisma tracks migrations in a _prisma_migrations table and prevents drift between your schema file and the database.

Rollback Strategies
Every migration should have a corresponding rollback plan:

Additive migrations (adding columns, tables, indexes): Rollback by dropping the added objects. Low risk.

Destructive migrations (dropping columns, changing types): Take a logical backup before the migration. Document the exact rollback SQL.

Data transformations: Store the original data in a temporary column or table until you confirm the migration succeeded. Drop the backup after a verification period.

Automated Rollback Scripts
For every migration file, create a corresponding down migration. Drizzle and Prisma both support this pattern. In CI/CD, test that applying and then rolling back a migration leaves the database in its original state.

Data Backfill Patterns
Large table backfills can lock rows and degrade performance. Use batched updates:

Process 1,000–10,000 rows per batch

Add a short delay between batches to reduce database load

Use a cursor-based approach (WHERE id > last_processed_id) rather than OFFSET for consistent performance

Log progress so you can resume if the backfill is interrupted

Testing Migrations
Test against a production-like dataset: Migrations that work on 100 rows may timeout on 10 million rows.

Measure lock duration: Use pg_stat_activity to monitor locks during migration testing.

Run in a staging environment first: Always. No exceptions.

Test the rollback: If you have never tested your rollback, you do not have a rollback.

Database migrations do not have to be scary. They just have to be planned. Want help with a complex migration? Reach out.

Redis Caching Strategies for Web Applications

The Beyond Horizon — Wed, 17 Jun 2026 11:27:42 +0000

Cache-aside, write-through, and write-behind patterns with Redis — session storage, rate limiting, pub/sub, and TTL strategies for production web apps

Why Caching Changes Everything
Database queries are expensive. A typical PostgreSQL query takes 5–50ms. A Redis cache lookup takes 0.1–0.5ms. For endpoints called thousands of times per minute, caching transforms your application from sluggish to instant.

Redis is an in-memory data store that supports strings, hashes, lists, sets, sorted sets, and streams. It is not just a cache — it is a Swiss Army knife for high-performance data patterns. At The Beyond Horizon, we use Redis in nearly every production deployment.

Cache-Aside Pattern
The cache-aside pattern (also called lazy loading) is the most common caching strategy. The application checks Redis first. If the data exists (cache hit), return it. If not (cache miss), query the database, store the result in Redis with a TTL, and return it.

Implementation
Your data fetching function first calls redis.get(key). If the result exists, parse and return it. Otherwise, query the database, store the result with redis.set(key, JSON.stringify(data), “EX”, ttlSeconds), and return the data.

When to Use
Read-heavy workloads where the same data is requested frequently

Data that does not change often (user profiles, product listings, configuration)

When stale data is acceptable for a short window

Write-Through Pattern
In the write-through pattern, every write to the database simultaneously updates the cache. This ensures the cache is always consistent with the database — no stale data window.

When creating or updating a record, you write to the database first, then immediately set the value in Redis. This eliminates cache misses for recently written data at the cost of slightly slower writes.

Data that is read immediately after writing (social media posts, order status)

When cache consistency is more important than write latency

Applications with predictable access patterns

Write-Behind Pattern
The write-behind (write-back) pattern writes to Redis first and asynchronously persists to the database later. This provides the fastest write performance but introduces the risk of data loss if Redis fails before the database write completes.

When to Use
High-throughput write workloads (analytics events, activity logging)

Write on Medium
When write latency is critical and eventual consistency is acceptable

Batch processing where individual writes can be grouped

Storing user sessions in Redis is one of the most impactful quick wins for web applications. Unlike file-based or database-backed sessions, Redis sessions are fast, shared across multiple server instances, and automatically expire.

Use a session library like connect-redis with Express or iron-session with Next.js. Store the session ID in an httpOnly secure cookie and the session data in Redis with a TTL matching your desired session duration.

Redis is ideal for rate limiting API endpoints. The sliding window pattern uses a sorted set where each request adds an entry with the current timestamp as the score. Count entries within the last N seconds to determine if the limit is exceeded.

For simpler token bucket rate limiting, use Redis INCR with EXPIRE. Increment a counter keyed by the user’s IP or API key. If the counter exceeds the limit, reject the request. The EXPIRE ensures the counter resets after the window.

Redis Pub/Sub enables real-time messaging between services. A chat message published to a channel is instantly delivered to all subscribers. This powers features like:

Live notifications across multiple server instances

Real-time dashboard updates

Cache invalidation broadcasts (one server invalidates, all servers clear the stale entry)

TTL Strategies
Setting the right TTL (time-to-live) is an art:

Static content: (site configuration, feature flags): 1–24 hours

User profiles: 5–15 minutes

API responses: 30 seconds to 5 minutes

Search results: 1–5 minutes

Session data: Match your session timeout (typically 24 hours to 7 days)

When in doubt, start with shorter TTLs and increase based on observed cache hit rates and data freshness requirements.

Redis with Next.js
In Next.js applications, Redis integrates at multiple layers. Use it in API routes for response caching and rate limiting. Use it in server components with unstable_cache for data layer caching. Use it with Next.js middleware for session validation and geographic routing.

Our preferred Redis hosting is Upstash for serverless workloads (pay per request, global replication) and Redis Cloud for dedicated instances with higher throughput requirements.

Caching is not an optimization — it is an architecture decision. Want to build a high-performance application? Talk to us.

Originally published at https://www.thebeyondhorizon.com on August 19, 2025

Web Performance Optimization: The Complete Guide for 2025

The Beyond Horizon — Wed, 17 Jun 2026 11:26:12 +0000

From image optimization and code splitting to caching strategies and performance budgets — make your website fast on Indian 4G networks

The Real Cost of Slow Websites
Amazon found that every 100ms of latency cost them 1% in sales. Google found that 53% of mobile users abandon sites that take longer than 3 seconds to load. For Indian businesses on 4G networks, where average page load times hover around 5–8 seconds, the performance gap is a massive opportunity.

Web performance is not a technical nicety — it is a business metric. Every second of load time directly impacts conversion rate, bounce rate, and search rankings.

Measuring Performance Correctly
Before optimizing, establish baselines using the right tools:

Google PageSpeed Insights: Combines lab data (Lighthouse) with field data (Chrome UX Report). Field data reflects real user experience.

WebPageTest: Advanced waterfall analysis showing exactly what loads when. Test from Indian locations (Mumbai, Chennai) for accurate results.

Chrome DevTools Performance Panel: Record a trace to see main thread activity, long tasks, and rendering bottlenecks.

Vercel Analytics: Real-time Web Vitals from actual users, segmented by route and device.

The Performance Budget
Set concrete limits before you start:

Total page weight: Under 500KB for initial load (compressed)

JavaScript bundle: Under 200KB (compressed). Every KB of JavaScript costs more than a KB of HTML because it must be parsed, compiled, and executed.

LCP: Under 2.5 seconds on 4G

Time to Interactive: Under 3.5 seconds

Number of requests: Under 30 for initial page load

Track these in CI. If a PR increases the JavaScript bundle beyond the budget, the build fails. This prevents gradual performance degradation.

Image Optimization
Images typically account for 50–70% of page weight. Optimize aggressively:

Format: WebP for photographs (25–35% smaller than JPEG). AVIF for even better compression where supported. SVG for icons and illustrations.

Sizing: Serve images at the exact dimensions needed. A 2000px image displayed in a 400px container wastes 80% of its bytes.

Write on Medium
Lazy loading: Images below the fold should use loading=”lazy”. Above-fold images should use fetchpriority=”high” and never lazy load.

Next.js Image component: Handles format conversion, resizing, lazy loading, and placeholder blur automatically. Use it for every image.

JavaScript Optimization
Code Splitting
Ship only the JavaScript needed for the current page. Next.js does this automatically by page, but heavy components within a page should be dynamically imported.

A chart library (Recharts, Chart.js) used only on the dashboard page should not be in the initial bundle. Use next/dynamic with ssr: false to load it only when needed.

Tree Shaking
Import only what you use. Instead of importing the entire lodash library for a single debounce function, import only lodash/debounce. The difference can be 70KB vs 1KB.

Third-Party Scripts
Analytics, chat widgets, social embeds, and ad scripts are the biggest performance killers. Audit every third-party script:

Does this script need to load on every page?

Can it load after user interaction instead of on page load?

Is there a lighter alternative?

Google Tag Manager should load with the afterInteractive strategy in Next.js Script component. Chat widgets should load only when the user clicks a “Chat” button.

Font Optimization
Use next/font: It automatically hosts fonts locally, eliminating external requests to Google Fonts. Fonts are subset to include only characters you actually use.

Font display: swap: Text renders immediately with a fallback font, then swaps when the custom font loads. No invisible text.

Limit font weights: Every additional weight (400, 500, 600, 700) adds 20–40KB. Use only the weights your design system requires.

Caching Strategy
Static assets: Cache for 1 year with immutable flag. Next.js uses content-hash filenames, so new deployments create new URLs automatically.

HTML pages: Cache for short durations (60–300 seconds) with stale-while-revalidate. Users get cached content instantly while fresh content is fetched in the background.

API responses: Cache based on data freshness requirements. Product listings can cache for 5 minutes. User-specific data should not cache.

Performance optimization is not a one-time project — it is an ongoing practice. Build performance monitoring into your development workflow and treat regressions as bugs.

Want us to audit and optimize your site’s performance? Start here.

Originally published at https://www.thebeyondhorizon.com on June 25, 2025.

Serverless Architecture with AWS, Google Cloud, and Next.js

The Beyond Horizon — Wed, 17 Jun 2026 11:20:38 +0000

When to go serverless, how Lambda and Cloud Run compare, and how Next.js fits the serverless model — a practical 2025 guide

What is Serverless Architecture?
Serverless does not mean no servers — it means you do not manage them. You write functions. The cloud provider handles provisioning, scaling, patching, and monitoring the underlying infrastructure. You pay only for the compute time your code actually uses.

For web applications, serverless eliminates the most tedious parts of infrastructure management while automatically scaling from zero to millions of requests.

Serverless on AWS vs Google Cloud
AWS Lambda
The original serverless compute service, launched in 2014. Lambda supports Node.js, Python, Java, Go, and custom runtimes. Key characteristics:

Cold starts: 100–500ms for Node.js. Reduced with Provisioned Concurrency (keeps instances warm) or SnapStart (for Java).

Execution limit: 15 minutes maximum. Fine for API handlers, problematic for long-running data processing.

Integration: Deep integration with API Gateway, S3, DynamoDB, SQS, and EventBridge. Event-driven architectures are Lambda’s sweet spot.

Pricing: $0.20 per million requests + $0.0000166667 per GB-second of compute. The first million requests per month are free.

Google Cloud Functions / Cloud Run
Google offers two serverless compute options:

Cloud Functions: Similar to Lambda — event-driven functions triggered by HTTP requests, Pub/Sub messages, or Cloud Storage events. Best for simple, single-purpose functions.

Cloud Run: Runs any containerized application serverlessly. This is more flexible than Lambda — you deploy a Docker container, and Cloud Run scales it from zero to thousands of instances automatically. Next.js applications run perfectly on Cloud Run with the standalone output mode.

Cold starts: Cloud Run (100–300ms for Node.js containers). Minimum instances can eliminate cold starts entirely.
Execution limit: Cloud Run supports up to 60 minutes (configurable). Cloud Functions support up to 9 minutes.
Pricing: Cloud Run charges per 100ms of CPU time and per GiB-second of memory. The free tier includes 2 million requests per month.
When Serverless Makes Sense
API backends: REST or GraphQL APIs that handle HTTP requests. Each request is independent, stateless, and short-lived — perfect for serverless.

Write on Medium
Webhook handlers: Payment notifications from Razorpay, order events from Shopify, form submissions from your website. Webhooks arrive unpredictably — serverless scales to handle spikes without paying for idle capacity.

Scheduled tasks: Daily report generation, weekly email digests, hourly data synchronization. Use CloudWatch Events (AWS) or Cloud Scheduler (GCP) to trigger functions on a cron schedule.

Image and file processing: Thumbnail generation when a user uploads an image, PDF generation for invoices, CSV processing for data imports. Trigger a function from an S3 or Cloud Storage event.

When Serverless Does Not Make Sense
WebSocket connections: Serverless functions are request-response. Persistent connections need a dedicated server (or managed WebSocket service like AWS API Gateway WebSocket or Ably).

Long-running processes: Video encoding, ML model training, or batch data processing that takes more than 15 minutes. Use dedicated compute (EC2, Compute Engine) or batch services.

High-throughput, steady workloads: If your API handles 10,000 requests per second consistently (not in spikes), a dedicated container cluster is cheaper than serverless. Serverless pricing favors variable workloads.

Serverless with Next.js
Next.js is inherently serverless-friendly:

API routes: become individual serverless functions on Vercel

Server-side rendering: runs in serverless functions that scale automatically

Static pages: are served from CDN edge nodes — no compute required

Incremental Static Regeneration: revalidates pages in background serverless functions

On Vercel, this is zero-configuration. On AWS, you can deploy Next.js using SST (Serverless Stack) or AWS Amplify. On Google Cloud, Cloud Run is the simplest path.

Cost Optimization Tips
API routes: become individual serverless functions on Vercel

Server-side rendering: runs in serverless functions that scale automatically

Static pages: are served from CDN edge nodes — no compute required

Incremental Static Regeneration: revalidates pages in background serverless functions

Serverless is the right choice for most web application backends. Want to architect your serverless infrastructure? Talk to us.

Originally published at https://www.thebeyondhorizon.com on July 8, 2025.

Web Accessibility in React: A Practical WCAG 2.1 Guide

The Beyond Horizon — Wed, 17 Jun 2026 11:18:34 +0000

Accessibility is quality engineering, not charity — semantic HTML, keyboard navigation, ARIA, and testing for WCAG-compliant React apps

Why Accessibility Is a Business Requirement
Web accessibility is not charity work — it is engineering quality. An accessible website works better for everyone: keyboard users, screen reader users, users with slow connections, users on old devices, and users in bright sunlight who cannot see low-contrast text.

In India, an estimated 26.8 million people have visual impairments. Globally, 15% of the population lives with some form of disability. If your website is inaccessible, you are excluding a significant portion of potential customers.

Beyond ethics and market reach, accessibility impacts SEO. Google’s crawlers are essentially blind users — they rely on semantic HTML, alt text, and document structure to understand your content. An accessible website is inherently more SEO-friendly.

The WCAG 2.1 Framework
The Web Content Accessibility Guidelines (WCAG) organize requirements under four principles, known as POUR:

Perceivable
Users must be able to perceive the content through at least one sense.

Alt text for images: Every informational image needs descriptive alt text. Decorative images get alt=”” (empty alt attribute, not missing alt attribute).

Color contrast: Text must have a contrast ratio of at least 4.5:1 against its background (3:1 for large text). Use the WebAIM Contrast Checker to verify.

Captions for video: Pre-recorded video content needs synchronized captions. Live video needs captions where feasible.

Do not rely on color alone: “Click the red button” is meaningless to colorblind users. Use color plus text, icons, or patterns.

Operable
Users must be able to operate the interface.

Keyboard navigation: Every interactive element must be reachable and operable with keyboard alone. Tab to navigate, Enter to activate, Escape to close.

Focus indicators: The currently focused element must have a visible outline. Never remove the default focus ring without adding a custom one.

Skip navigation link: A hidden link that becomes visible on focus, allowing keyboard users to skip the header and navigation to reach main content directly.

No keyboard traps: Users must be able to Tab into and out of every component. Modal dialogs must trap focus while open and return focus when closed.

Understandable
Users must be able to understand the content and interface.

Language attribute: Set lang=”en” (or appropriate language) on the HTML element. Screen readers use this to select the correct pronunciation engine.

Error identification: Form validation errors must identify which field has the error and describe how to fix it. “Invalid input” is not helpful. “Email address must include @” is.

Consistent navigation: Navigation should appear in the same location and order across all pages.

Robust
Content must work with current and future technologies.

Write on Medium
Valid HTML: Proper heading hierarchy (h1 → h2 → h3, never skipping levels). Correct use of semantic elements (nav, main, footer, article, section).

ARIA when needed: Use ARIA attributes only when native HTML elements cannot express the semantics. A button element is better than a div with role=”button”.

Implementing Accessibility in React
Use Semantic HTML
The biggest accessibility win costs zero effort. Use the right HTML elements:

button for clickable actions (not div with onClick)
a for navigation links
nav for navigation sections
main for primary content
form with proper label associations
ul/ol for lists
Component Libraries That Care
Radix UI and Headless UI provide unstyled, fully accessible components for complex patterns like dropdown menus, dialogs, tabs, and popovers. They handle ARIA attributes, keyboard navigation, and focus management correctly. We use Radix UI as the foundation for all our component systems.

Testing Accessibility
axe DevTools: Browser extension that scans the current page for WCAG violations. Run it on every page during development.

Lighthouse accessibility score: Automated audit included in Chrome DevTools. Aim for 90+ (100 is achievable for most sites).

Screen reader testing: Test with NVDA (Windows, free) or VoiceOver (macOS, built-in). Automated tools catch 30–40% of accessibility issues — the rest requires manual testing.

Keyboard testing: Unplug your mouse and navigate your site. If you get stuck or cannot access a feature, keyboard users cannot either.

Quick Wins for Existing Sites

Add alt text to all images (30 minutes for most sites)
Fix color contrast ratios (use a CSS find-and-replace for low-contrast grays)
Add a skip navigation link (5 minutes)
Ensure all form inputs have associated labels (15 minutes)
Set the lang attribute on the HTML element (1 minute)
Test and fix keyboard navigation for interactive components (1–2 hours)

These six changes address the majority of accessibility issues on most websites.

Accessibility is not a feature — it is quality engineering. Want us to audit your site? Contact us.

Originally published at https://www.thebeyondhorizon.com on July 22, 2025.

MongoDB vs PostgreSQL: Choosing the Right Database for Your Project

The Beyond Horizon — Wed, 17 Jun 2026 11:16:31 +0000

A practical comparison — when MongoDB or PostgreSQL is the right choice based on data model, scaling, and use case

The Great Database Debate
Choosing between MongoDB and PostgreSQL is one of the most consequential early decisions in any project. Both are excellent databases — but they excel at fundamentally different things. Picking the wrong one creates friction that compounds over the entire life of your application.

At The Beyond Horizon, we have shipped production systems on both. Here is our honest, experience-based comparison.

Data Model: Documents vs Relations
MongoDB stores data as JSON-like documents (BSON). Each document can have a different structure. A users collection might have documents where some have an address field and others do not. This schema flexibility is powerful during early development when your data model is evolving rapidly.

PostgreSQL stores data in tables with fixed columns and strict types. Every row in a table has the same structure. Relationships between tables are expressed through foreign keys and enforced by the database itself. This rigidity is a feature — it prevents bad data from entering your system.

When Documents Win
Rapidly changing schemas: Startups iterating on their data model weekly benefit from not running ALTER TABLE migrations constantly.

Deeply nested data: Product catalogs where each product category has entirely different attributes (electronics vs clothing vs food) map naturally to documents.

Content management: Blog posts, articles, and CMS content with varying metadata fields fit documents well.

Event logging and analytics: High-volume write workloads where each event has a different shape.

When Relations Win
Financial data: Transactions, balances, and ledgers demand ACID compliance and referential integrity. MongoDB added transactions in 4.0, but PostgreSQL was built for this.

Complex queries: JOINs across multiple tables, window functions, CTEs, and aggregate queries are PostgreSQL’s strength. MongoDB’s aggregation pipeline is powerful but more verbose.

Become a Medium member
Reporting: SQL is the universal language of data analysis. Every BI tool speaks SQL natively.

Multi-table relationships: Many-to-many relationships with join tables are natural in SQL but require embedding or referencing patterns in MongoDB that can become unwieldy.

ACID Compliance
PostgreSQL is fully ACID compliant by default. Every transaction is atomic, consistent, isolated, and durable. You do not need to configure anything — it just works.

MongoDB added multi-document ACID transactions in version 4.0, but they come with performance overhead. Single-document operations in MongoDB are atomic, but cross-document consistency requires explicit transaction handling. In practice, MongoDB applications are often designed to avoid multi-document transactions entirely by embedding related data in a single document.

Horizontal Scaling
MongoDB was designed for horizontal scaling from day one. Sharding distributes data across multiple servers based on a shard key. For applications that need to handle millions of writes per second — IoT data ingestion, real-time analytics, social media feeds — MongoDB’s sharding is battle-tested.

PostgreSQL scales vertically exceptionally well. A single PostgreSQL instance on modern hardware handles millions of rows and thousands of concurrent connections without breaking a sweat. For horizontal read scaling, PostgreSQL supports streaming replication with read replicas. For write scaling, tools like Citus (now part of Azure) enable distributed PostgreSQL.

JSON Handling
PostgreSQL’s JSONB column type stores and indexes JSON data natively. You get the flexibility of document storage within a relational database. GIN indexes on JSONB columns provide fast queries into nested JSON structures.

This is a game-changer. Many teams choose MongoDB for its JSON flexibility, but PostgreSQL gives you JSON storage plus relational integrity plus SQL querying — all in one database.

Real-World Use Cases
Choose MongoDB when: You are building a content platform with varying document structures, an IoT system ingesting millions of events per second, a product catalog with heterogeneous attributes, or a prototype where the data model will change significantly.

Choose PostgreSQL when: You are building a SaaS application with complex business logic, a fintech product where data integrity is non-negotiable, an e-commerce platform with inventory and order management, or any application where reporting and analytics are important.

Our Default
At The Beyond Horizon, PostgreSQL is our default database. Paired with Drizzle ORM and hosted on Supabase or Neon, it handles 90% of our use cases. We reach for MongoDB when a project genuinely needs schema flexibility at scale — but that is less common than many developers assume.

Need help choosing the right database for your project? Let us help.

Originally published at https://www.thebeyondhorizon.com on August 5, 2025.

PostgreSQL for Web Developers: Schema Design, Performance, and Best Practices

The Beyond Horizon — Thu, 11 Jun 2026 11:42:11 +0000

Why PostgreSQL is the default database for modern web apps — schema design, indexing strategies, and query optimization

PostgreSQL Is Not Just a Database
PostgreSQL is the most advanced open-source relational database in the world. It handles JSON documents like MongoDB, full-text search like Elasticsearch, geospatial queries like PostGIS, and time-series data like TimescaleDB — all in one system. For web applications, this versatility means fewer moving parts and simpler architecture.

At The Beyond Horizon, PostgreSQL is our default database choice. After using it across 100+ production projects, here is why and how we use it.

Why PostgreSQL Over MySQL or MongoDB
vs MySQL: PostgreSQL handles complex queries better — window functions, CTEs (Common Table Expressions), recursive queries, and JSON operations are first-class citizens. MySQL has improved significantly, but PostgreSQL’s query planner is consistently superior for analytical queries alongside transactional workloads.

vs MongoDB: For applications with relational data (users have orders, orders have items, items belong to categories), PostgreSQL’s relational model with JOINs is fundamentally more efficient than MongoDB’s document embedding or referencing. And with JSONB columns, PostgreSQL stores flexible schema data just as well as MongoDB when you actually need it.

Schema Design Principles
Normalize First, Denormalize When You Measure
Start with a normalized schema. Every piece of data lives in one place. When you identify actual performance bottlenecks through query analysis, selectively denormalize.

Use Appropriate Data Types
UUID for primary keys: Use gen_random_uuid(). UUIDs prevent enumeration attacks and work across distributed systems.

TIMESTAMPTZ over TIMESTAMP: Always store timestamps with timezone information. “2025–03–15 10:00:00” is ambiguous. “2025–03–15 10:00:00+05:30” is not.

TEXT over VARCHAR(n): In PostgreSQL, TEXT and VARCHAR perform identically. The length constraint in VARCHAR rarely prevents bugs but frequently causes production issues when a user enters a longer-than-expected name.

JSONB for flexible data: User preferences, feature flags, or metadata that varies between records. JSONB is indexed and queryable — not just a text blob.

Indexing Strategy
Indexes make reads faster and writes slower. Be strategic:

B-tree indexes: Default. Use for equality and range queries (WHERE status = ‘active’, WHERE created_at > ‘2025–01–01’).

GIN indexes: Use for JSONB columns and full-text search. A GIN index on a JSONB column lets you query nested keys efficiently.

Partial indexes: Index only rows that match a condition. An index WHERE deleted_at IS NULL is smaller and faster than indexing all rows.

Download the Medium app
Composite indexes: For queries that filter on multiple columns. Order matters — put the most selective column first.

Query Performance
EXPLAIN ANALYZE Everything
Never deploy a query without running EXPLAIN ANALYZE in development. It shows the actual execution plan — which indexes are used, how many rows are scanned, and where time is spent.

Common findings:

Sequential scan on large table: Missing index. Add one.

Nested loop with high row count: Consider a different join strategy or add an index on the join column.

Sort operation on disk: Not enough work_mem. Increase it or add an index that eliminates the sort.

Connection Pooling
PostgreSQL creates a new process for each connection. At 100+ concurrent connections, this becomes a bottleneck. Use PgBouncer or Supabase’s built-in pooler to multiplex connections.

For serverless environments (Vercel, Cloudflare Workers), connection pooling is mandatory. Each serverless function invocation could otherwise create a new database connection — quickly exhausting your connection limit.

Backup and Recovery
Automated daily backups: Every managed PostgreSQL provider (Supabase, Neon, RDS) includes automated backups. Verify they are enabled and test restoration quarterly.

Point-in-time recovery (PITR): For critical applications, enable WAL archiving. This lets you restore to any second in time — not just the last backup.

Logical backups: pg_dump for portable, human-readable backups that can be restored to different PostgreSQL versions.

Our Stack
For most projects, we use:

Supabase or Neon: Managed PostgreSQL with connection pooling, automatic backups, and a generous free tier

Drizzle ORM: Type-safe queries in TypeScript with zero runtime overhead — SQL queries are generated at build time

pgAdmin or Drizzle Studio: Visual database management for development and debugging

PostgreSQL scales to millions of rows without breaking a sweat. It is free, battle-tested, and backed by 30+ years of development. Unless you have a specific reason to choose something else, PostgreSQL is the right default.

Need help designing your database architecture? Reach out.

Local SEO for Indian Businesses: The Complete 2025 Guide

The Beyond Horizon — Wed, 10 Jun 2026 16:23:21 +0000

Dominate ‘near me’ searches with Google Business Profile optimization, NAP consistency, review strategies, and local content that ranks

The Local SEO Opportunity in India
“Near me” searches in India have grown 150% year-over-year. When someone searches “best dentist near me” or “AC repair in Jaipur,” they are ready to buy — right now. Local SEO puts your business in front of these high-intent searchers.

Unlike national SEO where you compete with massive websites, local SEO levels the playing field. A well-optimized local business can outrank national chains in their service area. Here is how.

Google Business Profile: The Foundation
Your Google Business Profile (GBP) is the single most important factor in local search rankings. It controls what appears in Google Maps, the local pack (the map with 3 listings that appears above organic results), and Google’s knowledge panel.

Optimization Checklist
Business name: Exact legal name. Do not stuff keywords — Google penalizes this.
Categories: Choose the most specific primary category. “Orthodontist” beats “Dentist” if that is what you are. Add relevant secondary categories.

Address: Exact match with your website and all citations. Even small differences (“Rd” vs “Road”) can cause ranking issues.

Phone number: Use a local number, not a toll-free number. Local numbers signal local presence.

Hours: Keep accurate. Google shows “closed” warnings that devastate click-through rates.

Photos: Businesses with 100+ photos get 520% more calls than average. Upload exterior, interior, team, and product photos weekly.

Posts: Google Business Posts appear in your listing. Post weekly updates, offers, or events to signal activity.

NAP Consistency
NAP stands for Name, Address, Phone number. These must be identical across every platform where your business is listed:

Your website

Google Business Profile

Justdial

IndiaMART

Sulekha

Facebook

Industry directories

Download the Medium app
Inconsistent NAP information confuses search engines about which data is correct. The result: lower rankings across all platforms.

Review Strategy
Reviews are a direct local ranking factor. Quantity, quality, velocity, and diversity all matter.

Ask systematically: After every completed job, send a direct link to your Google review page. Make it effortless.

Respond to every review: Both positive and negative. Google explicitly states that responding to reviews improves local ranking.

Never buy reviews: Google’s algorithms detect fake reviews and penalize businesses. The risk is not worth it.

Diversify platforms: Reviews on Justdial, Facebook, and industry platforms reinforce your reputation signals.

Local Content Strategy
Create pages targeting “[service] in [city]” queries:

“Web development company in Ajmer”

“Mobile app developer in Jaipur”

“Best UI/UX designer in Rajasthan”

Each page should include:

Unique, detailed content about your service in that location

Local testimonials from clients in that area

Embedded Google Map showing your location

LocalBusiness schema markup with geo-coordinates

Internal links to your service and portfolio pages

Technical Local SEO
LocalBusiness schema: JSON-LD markup with business name, address, phone, hours, geo-coordinates, and service area.

Geo-targeted meta tags: Include city and region in title tags and meta descriptions for location pages.

Mobile optimization: 76% of local searches happen on mobile. Your site must be fast and mobile-friendly.

Google Maps embed: Embedding a Google Map with your business marker on your contact page sends a strong local signal.

Local SEO is the highest-ROI marketing channel for service businesses. The competition is lower, the intent is higher, and the results compound over time.

Want to dominate local search in your area? Get started.