标签：#Java

pnpm 12 has transitioned to a native Rust implementation, maintaining compatibility with pnpm 11 commands, flags, and formats. This update enhances startup and filesystem performance, particularly when using existing caches. Community feedback highlights the performance gains while noting some trade-offs in larger artifact sizes. By Daniel Curtis

If you're generating test data today, you've probably landed on one of three approaches: click through a UI like Mockaroo, pull in a library like Faker.js and write generation code yourself, or call a hosted API like JsonFabrica. Comparing these test data generation tools side by side, the real differences aren't about which one produces "better" fake data — Faker.js, Mockaroo, and JsonFabrica are all capable of that. The differences are about where the tool lives, how it handles relationships between records, and who's responsible for running it. Three test data generation tools compared, shape by shape Mockaroo is a browser-based UI: you define columns and types through a web form, preview rows, and export a file — or hit its API directly, which is available even on the free tier (paid tiers raise the volume ceiling rather than gate API access itself). Faker.js is a JavaScript library: you import it into your own code and call functions like faker.person.fullName() or faker.internet.email() to build up objects yourself, one field at a time. JsonFabrica is an API-first hosted service: you send a schema (or use a template) to an endpoint and get structured, schema-conformant JSON back, with no UI step and no library to install in your own codebase. That distinction matters more than it sounds. A UI tool is something a person operates by hand. A library is something a developer owns and maintains inside their own project — you write the loops, the relationships, the edge cases. An API-first tool is infrastructure: something your CI pipeline, your seed script, or an AI coding agent can call directly, without a human in the loop or generation logic living in your repo. UI vs. library vs. API, in practice Mockaroo's UI is genuinely fast for a one-off task — sketch a schema, click generate, download a CSV or JSON file. What it isn't built for is wiring generation into an automated pipeline where nobody is clicking anything. Its API can cover that, but at free-tier volume

Sometimes a simple line of JavaScript can do more work than you expect. For example, array.includes() is fine for small arrays, but using it again and again with large datasets can affect performance. Things get even more interesting when it is used inside another loop. I recently wrote about this with simple JavaScript and React examples, including when using Set or Map can be a better choice. 👉 Read the full article: https://nirmitkotadiya.dev/dsa/big-o-javascript-array-includes You don't need to optimize everything. The important part is knowing where a small change in your data structure can make your code much more efficient.

A three-year group chat is a knowledge base nobody can read. Somewhere in it is how long the tax office actually took, which form replaced the old one, which accountant people quietly stopped recommending. Telegram's search finds a word you already know. It cannot answer a question. The fix is boring in outline: get the history out, turn it into documents, hand them to something that reads — NotebookLM, in my case. I built that pipeline for real chats. The parsing has traps, and I list them below, but the design problem is elsewhere: packing, and making the second run idempotent. Two clients, two shapes Export exists in exactly two places. Telegram Desktop has had it since 2018 and offers JSON or HTML. The native Telegram for macOS app — the Mac-only client, not Desktop — added Export Chat History… in 12.10 (24 August 2026) and writes HTML only; the Mac App Store build was still on 12.9, without the menu item, at the end of August. Telegram Web and the phone apps have nothing. So you have to read both formats: JSON — one result.json with the chat's name at the root and a messages array: {id, date, from, text, text_entities} per message. HTML — paginated. messages.html , messages2.html , messages3.html , one page per file, each a few MB. text is not a string In the JSON export, a plain message has text: "hello" . A message with a link, a bold run or a code span has an array of runs : "text" : [ "see " , { "type" : "bold" , "text" : "section 4" }, " first" ] String(msg.text) on that gives "[object Object]" in the middle of your document, and it does it silently. Join the runs instead: // Telegram writes a formatted message as // text: ["plain ", {type: "bold", text: "…"}, …] — String() gives "[object Object]". function contentValueToString ( v : unknown ): string { if ( v === undefined || v === null ) return '' ; if ( Array . isArray ( v )) { return v . map (( x ) => x !== null && typeof x === ' object ' && ' text ' in x && typeof ( x as { text : unknown }). text ===

TL;DR It's been a while since I've done a collection (maybe month ago), but today let's look at 12 new and not-so-new projects that can really help you in development. They touch on different areas of development, but we will mainly talk about web development. If there's a project worth adding to the next collection, feel free to write about it in the comments, and maybe it will be included. 1. 🤖 OpenWork - The open source Claude Cowork alternative. And we will continue, of course, with AI projects. This tool will allow you to work in one convenient interface with many popular LLMs. OpenWork is the desktop app that lets you use 50+ LLMs. 💎 Check out the OpenWork repository ☆ 2. 💻 T3 Code - The open-source control plane for coding agents. If you know a YouTuber like Theo, then you should know this project. It's an OpenCode alternative that lets you work with AI in an easy-to-use chat interface. It enables control of the agents on your machine with a best-in-class mobile app (iOS, Android), web app and Electron-based desktop app. 💎 Check out the T3 Code repository ☆ 3. ⚙️ Summarize - Point at any URL or file. Get the gist. The first project is a small tool for extracting short info of content. Summarize was created by one of the creators of the well-known OpenClaw. Fast summaries from URLs, files, and media. 💎 Check out the Summarize repository ☆ 4. 👾 Godot - Free and open source 2D and 3D game engine A truly legendary engine like Unity or Unreal Engine for games. If you are a game developer, you should know this project. From pet projects for the university to multi-million dollar games - it gives it all. Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unified interface. It provides a comprehensive set of common tools, so that users can focus on making games without having to reinvent the wheel. 💎 Check out the Godot repository ☆ 5. 💎 React Bits - An open source collection of animated, interactive & fully customizable Rea

If you work with Java/JDBC long enough, you eventually run into this situation: You have code like this: String sql = "SELECT * FROM users WHERE id = ? AND status = ?" ; PreparedStatement pst = con . prepareStatement ( sql ); pst . setLong ( 1 , userId ); pst . setString ( 2 , status ); And then, from a log or debugger, you know something like: userId = 42 status = ACTIVE But what you actually need is the SQL you can paste into your database client: SELECT * FROM users WHERE id = 42 AND status = 'ACTIVE' ; Doing this once is trivial. Doing it repeatedly while debugging production issues is annoying. It gets worse when: the SQL is split across several Java strings; values come from map.get("KEY"); there are dates or timestamps; strings contain apostrophes; some parameters are unresolved; the method contains several PreparedStatements. I kept doing this manually, so I built a small tool called Bind2SQL. What it does Bind2SQL takes Java/JDBC code and reconstructs the executable SQL. For example: String sql = "SELECT * FROM person " + "WHERE person_id = ? " + "AND type_id = ? " + "AND created_at >= ?" ; PreparedStatement pst = con . prepareStatement ( sql ); pst . setLong ( 1 , values . get ( "PERSON_ID" )); pst . setInt ( 2 , values . get ( "TYPE_ID" )); pst . setDate ( 3 , Date . valueOf ( "2026-09-02" )); With runtime values: {PERSON_ID=12648350, TYPE_ID=29} It produces something like: SELECT * FROM person WHERE person_id = 12648350 AND type_id = 29 AND created_at >= DATE '2026-09-02' ; The important part is that unresolved parameters are not silently guessed. If Bind2SQL cannot resolve something, it leaves it clearly marked so you can review it manually. Why I made it browser-only I often use this kind of tool with real application code and runtime values. That may include: internal SQL; identifiers; production log values; table names; application-specific data. So I didn't want a server in the middle. Bind2SQL runs entirely in the browser. There is: no backend; no

The bug that doesn't show up in tests — and what to do about it There is a class of bug in event-driven systems that is almost invisible in development and devastating in production: publishing a message to Kafka for data that never actually reached the database. It doesn't crash. It doesn't throw. The Kafka message goes out, the consumer picks it up, and it tries to process a batch that doesn't exist. Depending on your retry and error handling strategy, this can cascade silently for a long time before anyone notices. The fix is simple. The reason most people don't apply it is that the problem isn't obvious until you've seen it. The Problem: Publishing Inside the Transaction The intuitive approach is to publish to Kafka as part of the same transactional method: @Transactional public void process ( SettlementWindow window , LocalDate today , Participant participant ) { // ... FileBatch savedBatch = batchPort . save ( batch ); orderPort . updateStatusBatch ( orders ); // Publishes BEFORE the transaction commits publisherPort . publish ( savedBatch ); } This looks safe. The transaction is still open, the data is there, everything is consistent — until the transaction rolls back. If anything fails after publish() — another database update, a constraint violation, an unexpected exception — Spring rolls back the transaction. The database returns to its previous state. But Kafka already received the message. There is no rollback for Kafka. The consumer now holds a reference to a FileBatch that does not exist in the database. This is a phantom message . The Fix: afterCommit() Spring's TransactionSynchronizationManager provides a hook that fires after the transaction has successfully committed: @Transactional ( propagation = Propagation . REQUIRES_NEW ) public void process ( SettlementWindow window , LocalDate today , Participant participant ) { // ... FileBatch savedBatch = batchPort . save ( batch ); orderPort . updateStatusBatch ( orders ); // Kafka fires only after the d

JavaScript Functions and Hoisting Functions are one of the most important concepts in JavaScript. A function is a reusable block of code that performs a specific task. JavaScript provides different ways to create functions, such as: Function Declaration Function Expression Arrow Function IIFE These functions can behave differently when hoisting is involved. What is Hoisting in JavaScript? Hoisting is the behavior where JavaScript processes declarations before executing the code. For example: console . log ( name ); var name = " Abishek " ; Output: undefined This happens because the var declaration is processed before execution. We can think of it like this: var name ; console . log ( name ); name = " Abishek " ; Notice that only the declaration is processed early. The value "Abishek" is assigned later. Hoisting does not physically move the code to the top. The same concept also applies to functions, but the behavior depends on how the function is created. What is a Function? A function is a reusable block of code that performs a specific task . Example: function greet () { console . log ( " Hello " ); } greet (); Output: Hello Here: function greet() → function declaration greet() → function call We can call the function whenever we need it. 1. Function Declaration A function declaration is the normal way of creating a function. greet (); function greet () { console . log ( " Hello " ); } Output: Hello Why does this work? Because function declarations are fully hoisted . JavaScript makes the function available before executing the code. Hoisting Rule Function declarations can normally be called before their declaration. Example: greet (); function greet () { console . log ( " Hello " ); } ✅ Works. 2. Function Expression A function expression is a function stored inside a variable. const greet = function () { console . log ( " Hello " ); }; greet (); Here: const greet is a variable, and the variable stores a function. Now look at this: greet (); const greet = function

Developer Relations has traditionally been built around one primary audience: Developers. We write docs for them. We build tutorials for them. We create SDK examples, maintain GitHub repositories, run communities, and answer implementation questions. But AI coding assistants are changing the developer journey. The developer may now ask an AI agent to research a library, understand an API, write an integration, or debug an error. That means your documentation can become an input to an AI agent before it ever reaches a developer. The new developer journey Previously: Developer → Search → Docs → Code Now: Developer ↓ AI Assistant ↓ Docs / GitHub / API Reference ↓ AI interprets information ↓ Code ↓ Developer reviews The developer is still the user. But the AI can become the first consumer of your developer experience. That's why documentation quality matters differently now. Write documentation that removes guessing Consider this: Use our SDK for authentication. It sounds simple, but it leaves a lot unanswered. A developer or AI agent still needs to figure out: Which package? How do I install it? Where does the API key go? Can I use it in the browser? What happens when authentication fails? What's the response format? A better example provides actual implementation context: const client = new Client({ apiKey: process.env.API_KEY }); const user = await client.users.get("123"); console.log(user); Then explain what the code does, what the inputs mean, and what can go wrong. This helps both audiences. Examples are part of the API An API reference without good examples can force developers to guess. AI agents have the same problem. If the API is: client.users.create(options) showing a complete request is more useful: const user = await client.users.create({ name: "Alex", email: " alex@example.com " }); Then document: Required fields Optional fields Response shape Validation errors Authentication requirements The more important the API, the less you want people guessing. Don'

Preventing Cache Penetration in Spring Boot Using Redis and Bloom Filters Cache penetration occurs when high-frequency requests query non-existent keys, bypassing the Redis cache completely and hitting the relational database directly. Here is how we set up a Bloom Filter guard layer in front of Redis and PostgreSQL. 1. The Bloom Filter Guard Concept A Bloom Filter is a space-efficient probabilistic data structure that tests whether an element is definitely NOT in a set or MIGHT be in a set. @Component public class CachePenetrationGuard { private final BloomFilter < String > accountFilter ; public CachePenetrationGuard () { // Expected insertions: 500,000, False positive probability: 0.01 (1%) this . accountFilter = BloomFilter . create ( Funnels . stringFunnel ( StandardCharsets . UTF_8 ), 500000 , 0.01 ); } public void registerKey ( String accountId ) { accountFilter . put ( accountId ); } public boolean mightContain ( String accountId ) { return accountFilter . mightContain ( accountId ); } } 2. Service Layer Verification Before querying Redis or PostgreSQL, verify with the Bloom Filter: @Service public class AccountService { private final CachePenetrationGuard guard ; private final RedisTemplate < String , AccountDto > redisTemplate ; private final AccountRepository repository ; public AccountDto getAccount ( String accountId ) { // Step 1: Bloom filter pre-check if (! guard . mightContain ( accountId )) { return null ; // Instant rejection, saves DB from unnecessary lookups } // Step 2: Redis lookup AccountDto cached = redisTemplate . opsForValue (). get ( "acc:" + accountId ); if ( cached != null ) return cached ; // Step 3: DB fetch and cache populate AccountDto dbResult = repository . findByAccountId ( accountId ); if ( dbResult != null ) { redisTemplate . opsForValue (). set ( "acc:" + accountId , dbResult , Duration . ofMinutes ( 30 )); } return dbResult ; } } 3. Summary Combining Bloom Filters with TTL jitter in Redis shields backend databases from cache

Imagine a website where users can post comments. Someone submits this as their comment: <script> alert ( " Hello " ); </script> If the application takes that input and places it directly into the HTML it serves to other users, the browser doesn't see a comment. It sees a script tag. The vulnerability isn't that JavaScript exists on the page. JavaScript belongs on web pages. The problem is that untrusted user input ended up in a context where the browser interpreted it as executable content rather than inert text. The Core Problem A browser rendering a webpage doesn't distinguish between HTML the developer wrote and HTML that arrived through a comment field. It parses what it's given. If user input gets embedded into the page without being handled carefully, the browser processes it the same way it processes everything else. User Input ↓ Web Application ↓ HTML / DOM ↓ Browser ↓ Input interpreted as executable content Untrusted data should remain data. XSS occurs when the application allows that data to cross into a context where the browser interprets it as code or executable markup. The boundary between "string containing angle brackets" and "HTML the browser will parse" is where the vulnerability lives. Three Forms of XSS XSS shows up in a few different ways depending on where the injection happens and how the input travels. Stored XSS is when untrusted input gets saved to a database and later served to other users. The comment example above is stored XSS. An attacker submits input once, and every user who views that page subsequently receives it. The application acts as an unwitting distribution mechanism. Reflected XSS involves input that isn't stored but gets reflected back in an immediate server response. Search pages are a common example: if a query is echoed into the page as "You searched for: [query]" and the query isn't handled carefully, an attacker can craft a URL whose query parameter contains a payload. When another user visits that URL, the server refl

On July 11, 2026, I started building a project inspired by link-in-bio platforms. The idea was pretty straightforward: Create a profile → customize it → add your links → share it. So I built Rizzzler. And right now, it has 11 users. Yep. 11 😂 Not exactly the kind of number you'd put on a startup pitch deck. But those 11 users actually made me think about the project in a completely different way. The problem I noticed 🤔 I started looking at how people were using Rizzzler. And I noticed something: People would create their profile... Then disappear. Some wouldn't come back for a week. Some wouldn't even check the app for weeks. And eventually I realized something obvious. Why would they? Rizzzler was primarily a profile website. Once you've created your profile and shared your link, what reason do you have to open it again? You don't. That got me thinking: What else can we actually do with a profile? I didn't want Rizzzler to become something people set up once and completely forget about. I wanted the profile to actually do something. And that's where I got a pretty crazy idea. What if Rizzzler became more than a profile? I've used services that let you log into other applications using their account. For example: Sign in with GitHub. That got me thinking: What if Rizzzler could do something similar? Instead of Rizzzler only being a place where you create a profile... What if developers could use Rizzzler as an identity provider? And suddenly I had a new idea: Sign in with Rizzzler That was probably the craziest idea I've had for this project so far. And I decided to build it. I built my own OAuth 2.0 system 🔐 I started building the OAuth 2.0 mechanism, the developer-side integration, and the documentation. I also created a developer docs page so developers can understand how to integrate Sign in with Rizzzler into their applications. I've tested the mechanism locally, but there's an important distinction: It hasn't been properly tested by a real third-party applica

The problem: every "free" image converter wants your files If you've ever needed to quickly convert a batch of photos to WebP or shrink a folder of PNGs before shipping them to production, you've probably run into the same annoyance I did: most " free online converters " require you to upload your files to a remote server first. That's fine for a random screenshot. It's not fine when the images are: Unreleased product shots under NDA Client assets you're not supposed to redistribute Personal photos you'd rather not hand to a third-party server you know nothing about So I started looking at what the browser can actually do on its own — and it turns out, more than most people assume. What the browser can already do Modern browsers ship with everything needed to decode, resize, re-encode, and compress images entirely client-side: + toBlob() / toDataURL() for re-encoding to JPG, PNG, or WebP The File API for drag-and-drop and batch uploads Web Workers to keep the UI thread responsive during batch conversion JSZip (or similar) to bundle multiple converted files into a single downloadable ZIP None of this requires a backend. No image ever has to leave the user's machine. Why this matters beyond privacy Besides the obvious privacy win, doing conversion in-browser has some nice side effects: No server costs that scale with usage. A traditional image-conversion API has to provision compute for every request. A client-side tool scales for free — the user's own CPU does the work. No upload/download round trip. For large batches, skipping the network entirely is often faster than uploading to a server and waiting for a processed file back. Works offline once loaded. A PWA-style client-side converter keeps working even with a flaky connection. The trade-offs It's not free lunch: Very large batches (hundreds of high-res images) can strain the main thread if you're not careful with Web Workers. WebP/AVIF encoder quality and speed vary by browser engine, so you can't guarantee byte

async/await without the pitfalls Async/await is the bread and butter of modern JavaScript. It makes asynchronous code look synchronous, which is great for readability. But it comes with its own set of footguns that can bite you in production. Here's how to avoid them. Pitfall 1: Forgetting await in a loop You might write something like this, expecting each request to finish before the next starts: async function fetchAll ( urls ) { const results = []; for ( const url of urls ) { const res = await fetch ( url ); // this is fine, but see below results . push ( await res . json ()); } return results ; } That's actually correct. The issue arises when you forget await inside a .map() or .forEach() : // Wrong: map returns an array of promises, not data const data = urls . map ( async ( url ) => { const res = await fetch ( url ); return res . json (); }); // data is now an array of promises, not the JSON data async functions always return a promise. So if you use map with an async callback, you get an array of promises. To fix it, use Promise.all : const data = await Promise . all ( urls . map ( async ( url ) => { const res = await fetch ( url ); return res . json (); })); But beware: Promise.all fails fast. If one request fails, the whole thing rejects. If you need to handle failures individually, use Promise.allSettled instead. Pitfall 2: Swallowing errors silently A common mistake is to catch an error and do nothing, which makes debugging a nightmare: try { const data = await fetchData (); // process data } catch ( error ) { // do nothing? bad! } Always at least log the error. Even better, handle it gracefully or rethrow it: try { const data = await fetchData (); } catch ( error ) { console . error ( ' Failed to fetch data: ' , error ); throw error ; // rethrow if you want the caller to handle it } If you're using async/await , unhandled promise rejections can crash your app in Node.js. Always have a catch or a global handler. Pitfall 3: Sequential execution when you ne

A few weeks ago I built a free online Merge PDF tool that runs 100% in the browser. Today I'm sharing its sibling: a Split PDF tool using the same library — pdf-lib — with zero file uploads, zero watermark, and zero server code. You can try it live here: https://yourutilityhub.com/pdf/split-pdf Why split PDFs in the browser? Most online PDF tools upload your file to a server — which means your document is never truly private. Splitting pages locally means: No uploads — nothing leaves your device No watermark or signup Free — no per-page charges Works offline, fast, for files of any size (limited by your browser's memory) The plan We'll load the PDF, pick a page range (or specific pages), copy those pages into a fresh PDFDocument , and save the result — all with pdf-lib . Let's walk through the full working component . 1. Install and import npm install pdf-lib import { PDFDocument } from " pdf-lib " ; 2. Load the uploaded file const arrayBuffer = await file . arrayBuffer (); const pdf = await PDFDocument . load ( arrayBuffer ); const totalPages = pdf . getPageCount (); PDFDocument.load() accepts an ArrayBuffer . We read it straight from the File object — no server involved. 3. Split by page range (e.g. 1-5 or 3- ) const parts = pageRange . split ( " - " ); const startRaw = parseInt ( parts [ 0 ]. trim (), 10 ); const endRaw = parts [ 1 ]. trim () === "" ? totalPages : parseInt ( parts [ 1 ]. trim (), 10 ); // validate 1..totalPages const startPage = Math . min ( startRaw , endRaw ) - 1 ; // 0-based const endPage = Math . max ( startRaw , endRaw ) - 1 ; const newPdf = await PDFDocument . create (); const pageIndices = []; for ( let i = startPage ; i <= endPage ; i ++ ) { pageIndices . push ( i ); } const copiedPages = await newPdf . copyPages ( pdf , pageIndices ); copiedPages . forEach ( page => newPdf . addPage ( page )); The trick: copyPages() wants 0-based indices , but users type 1-based page numbers, so we subtract 1. "3-" with an empty end means "to the last pa

Open a page and it can start guessing which browser extensions you run before you click a thing. Not "extensions in general" - which ones . Your password manager, your ad blocker, the wallet, the internal tool your employer ships, the accessibility extension you depend on. The page never asks and you never see it happen. This is not a bug in Chrome. It is the sum of a few features working exactly as designed, and the people best placed to close it are extension authors who mostly do not know they left it open. I maintain an extension and a library that talks to it, so I have spent real time on the detectable side of this. Here is how a page does it, what the answer is worth to whoever is asking, and what actually stops it. Technique one: ask the extension directly Some extensions accept messages from web pages on purpose - our own does, so a customer's "report a bug" button can tell whether the extension is there. The API is chrome.runtime.sendMessage : chrome . runtime . sendMessage ( EXTENSION_ID , { type : ' ping ' }, ( reply ) => { if ( reply ) { // it is installed, and it answered } }); For a page to be allowed to send that message, the extension has to list the page's origin in its manifest, under externally_connectable . Authors who want their extension to work with any site reach for the wildcard: "externally_connectable" : { "matches" : [ "<all_urls>" ] } And that one line is the door. <all_urls> does not mean "my customers' sites". It means every site on the internet may now open a channel to this extension - which means every site may ping it and learn whether you have it. The convenience the author wanted for their own pages, they handed to everybody's. This technique is narrow, because it only finds extensions that chose to talk to pages. The next one is not narrow. Technique two: knock on the extension's own files Extensions ship assets - icons, injected stylesheets, images. Any asset marked web-accessible is reachable at a fixed URL built from the ext

GitHub热门项目 | [CVPR'25 Oral] MoGe: Unlocking Accurate Monocular Geometry Estimation for Open-Domain Images with Optimal Training Supervision | Stars: 2,863 | 29 stars today | 语言: JavaScript

The Challenge: Realtime in the Age of Server Components The paradigm shift toward React Server Components (RSC) and the Next.js App Router has fundamentally changed how we architect web applications. We are now defaulting to server-side rendering, which is fantastic for performance, SEO, and initial load times. However, a common friction point arises when we need to inject high-frequency, bidirectional realtime data into these server-rendered pages. Too often, developers fall into the trap of importing heavy socket libraries directly into their server components or wrapping their entire application in massive context providers, effectively bloating the client bundle and negating the performance gains of the App Router. The Solution: The "Client Island" Pattern Instead of fighting the architecture, we can embrace "Client Islands"—a pattern where we isolate the stateful, client-side logic into a tiny, focused leaf component. By keeping the WebSocket management strictly client-side, we ensure that our server-rendered pages remain lightweight, fast, and cacheable. Implementing the WebSocket Island The goal is to keep the WebSocket connection lifecycle outside of the rendering flow. We utilize useEffect to manage the connection, ensuring it only runs on the client, and we tap into data fetching libraries like TanStack Query or SWR to surgically update the UI. ' use client ' ; import { useEffect } from ' react ' ; import { useQueryClient } from ' @tanstack/react-query ' ; export function RealtimeSync ({ token }) { const queryClient = useQueryClient (); useEffect (() => { const ws = new WebSocket ( `wss://realtime.example.com?token= ${ token } ` ); ws . onmessage = ( event ) => { const data = JSON . parse ( event . data ); queryClient . setQueryData ([ ' items ' ], data ); }; return () => ws . close (); }, [ token , queryClient ]); return null ; // This component renders nothing, just manages the side effect } Persistence via RootLayout To prevent the connection from dropp

Scaling Kafka Consumers in Spring Boot: How We Cut Lag and Saved Latency When scaling high-throughput event-driven microservices in fintech, default Spring Kafka consumer configurations often run into throughput limits under peak loads. Here is the exact production setup we engineered to resolve consumer lag and reduce API processing latency by 35%. 1. Concurrency Tuning Over Single-Threaded Listeners By default, @KafkaListener operates with concurrency = 1. When a partition receives high message volume, processing gets backlogged. @Configuration @EnableKafka public class KafkaConsumerConfig { @Bean public ConcurrentKafkaListenerContainerFactory < String , PaymentEvent > kafkaListenerContainerFactory ( ConsumerFactory < String , PaymentEvent > consumerFactory ) { ConcurrentKafkaListenerContainerFactory < String , PaymentEvent > factory = new ConcurrentKafkaListenerContainerFactory <>(); factory . setConsumerFactory ( consumerFactory ); factory . setConcurrency ( 6 ); // Matches number of partition splits factory . getContainerProperties (). setAckMode ( ContainerProperties . AckMode . MANUAL_IMMEDIATE ); return factory ; } } 2. Explicit Batch Processing and Idempotency Instead of committing offset per message, processing batches with manual acknowledgments ensures atomic handling: @Service public class PaymentEventConsumer { @KafkaListener ( topics = "payment.settlement.v1" , containerFactory = "kafkaListenerContainerFactory" ) public void consume ( ConsumerRecord < String , PaymentEvent > record , Acknowledgment ack ) { try { processPayment ( record . value ()); ack . acknowledge (); } catch ( Exception ex ) { log . error ( "Failed processing record key: {}" , record . key (), ex ); // Route to Dead Letter Queue (DLQ) handleDeadLetter ( record ); ack . acknowledge (); } } } 3. Key Takeaway Scaling Kafka consumer pipelines requires matching topic partition count with container concurrency, tuning database connection pools and implementing dead letter queues for fail

Domain-Driven Design for Microservices: Building Scalable Systems with Clear Domain Boundaries Introduction Domain-Driven Design (DDD) isn't just another architecture pattern—it's a philosophy that aligns technical decisions with business reality. When building microservices at scale, DDD becomes essential. Without it, you end up with services that don't respect business domains, unclear responsibilities, and integration nightmares. Why DDD Matters for Microservices Microservices force you to make decisions about boundaries. The question isn't whether you'll decompose your system—it's whether you'll do it thoughtfully using DDD principles, or accidentally create distributed monoliths. DDD answers three critical questions: Where should a service boundary exist? (Bounded Contexts) How do we communicate across services without coupling? (Domain Events, Anti-Corruption Layers) How do distributed teams understand the same problem? (Ubiquitous Language) Core Concept 1: Bounded Contexts A Bounded Context is a boundary within which a domain model is applicable. Each microservice should typically map to one or more Bounded Contexts. Java Example: E-commerce System // Ordering Context - Bounded Context 1 public class Order { private String orderId ; private List < OrderLineItem > lineItems ; private OrderStatus status ; // PENDING, CONFIRMED, SHIPPED, DELIVERED private LocalDateTime createdAt ; public void confirmOrder () { if ( this . status != OrderStatus . PENDING ) { throw new InvalidOrderStatusException ( "Cannot confirm non-pending order" ); } this . status = OrderStatus . CONFIRMED ; } } // Inventory Context - Bounded Context 2 public class InventoryItem { private String skuId ; private Integer availableQuantity ; private Integer reservedQuantity ; public void reserveStock ( Integer quantity ) { if ( availableQuantity < quantity ) { throw new InsufficientStockException ( "Not enough stock to reserve" ); } this . reservedQuantity += quantity ; this . availableQuantity -