![\"Finance\"](\"https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F4bu4rzcpelx36tfhbshx.png\")
Fix long-document extraction timeouts by reducing the evidence before asking a model for JSON. Count tokens, split the source, use embeddings and reranking to select passages for the fields you need, then merge small validated results in application code. For private media archives, this keeps structured-output correctness visible instead of hiding it inside one long request.
\n\nTL;DR: treat extraction as a batch pipeline with observable stages, not a single chat call. A larger context window can delay the timeout, but it does not define conflict policy, improve evidence selection, or make an import job fit an interactive HTTP deadline.
\n\nThere is an operational choice around that pipeline, too. One key and one bill can replace credentials and invoices scattered across the token-counting, reranking, and extraction services. A single REST API also means no SDK to install: any language or runtime can send the same plain HTTP requests, which keeps a later batch-worker rewrite from forcing a new service integration.
\n\nThe fragile mental model is short: document in, model call, JSON out. One request must locate evidence, follow a schema, resolve contradictions, and finish before a timeout. When it fails, the only useful signal may be elapsed time.
\n\nThe better model is a conveyor belt described in words: token count -> bounded chunks -> embeddings -> field-specific retrieval -> rerank -> schema-bound extraction -> deterministic merge -> validation. Each arrow is a place to record progress and reject bad state.
\n\nThis matters in a media knowledge base. A long interview can identify a guest near the beginning, correct the spelling of that name much later, and put publication restrictions in the closing notes. Selecting only the opening loses evidence. Sending the full transcript makes evidence search and JSON generation compete inside the same deadline.
\n\nBatch processing is the safer default for archive imports and other long jobs. Interactive request-response extraction still fits short items and previews. The trade-off is explicit: batch work adds job state and delayed completion, but an HTTP timeout no longer determines whether the extraction can finish.
\n\nKeep the stages boring. That is useful.
\n\nStart by changing the unit of work. The useful unit is a field-specific evidence set, not the whole document. A query for people needs different passages from a query for publicationRestrictions, so retrieval should follow the target schema rather than reuse one vague document summary.
This TypeScript example is runnable orchestration code. It keeps provider-specific calls behind typed adapters, which makes chunk selection, retry behavior, and merging testable without putting private source text in logs. The 2_000-token budget and top four results are starting controls, not measured universal limits.
\n
import OpenAI from \"openai\";\n\ntype MediaRecord = {\n people: string[];\n organizations: string[];\n topics: string[];\n publicationRestrictions: string[];\n};\n\ntype RankedChunk = { index: number; score: number };\ntype CountTokens = (text: string) => Promise<number>;\ntype Embed = (chunks: string[]) => Promise<number[][]>;\ntype Rerank = (query: string, chunks: string[]) => Promise<RankedChunk[]>;\ntype Extract = (evidence: string) => Promise<MediaRecord>;\n\nconst apiKey = process.env.INFRAI_API_KEY;\nconst model = process.env.INFRAI_MODEL;\nconst baseURL = process.env.INFRAI_BASE_URL;\nif (!apiKey || !model || !baseURL) {\n throw new Error(\"Set INFRAI_API_KEY, INFRAI_MODEL, and INFRAI_BASE_URL\");\n}\n\nconst client = new OpenAI({\n apiKey,\n baseURL,\n maxRetries: 0,\n});\n\nconst wait = (milliseconds: number) =>\n new Promise<void>((resolve) => setTimeout(resolve, milliseconds));\n\nasync function withRateLimitRetry<T>(operation: () => Promise<T>): Promise<T> {\n for (let attempt = 0; attempt < 4; attempt += 1) {\n try {\n return await operation();\n } catch (error) {\n const status =\n typeof error === \"object\" && error !== null && \"status\" in error\n ? Number(error.status)\n : undefined;\n const retryAfter = error instanceof OpenAI.APIError\n ? Number(error.headers?.get(\"retry-after\"))\n : Number.NaN;\n\n if (status !== 429 || attempt === 3) throw error;\n const delay = Number.isFinite(retryAfter)\n ? retryAfter * 1_000\n : 2 ** attempt * 1_000;\n await wait(delay);\n }\n }\n throw new Error(\"Retry budget exhausted\");\n}\n\nconst extract: Extract = async (evidence) => {\n const response = await client.chat.completions.create({\n model,\n messages: [\n {\n role: \"system\",\n content: \"Extract media facts from evidence. Do not infer missing facts.\",\n },\n { role: \"user\", content: evidence },\n ],\n response_format: {\n type: \"json_schema\",\n json_schema: {\n name: \"media_record\",\n strict: true,\n schema: {\n type: \"object\",\n additionalProperties: false,\n properties: {\n people: { type: \"array\", items: { type: \"string\" } },\n organizations: { type: \"array\", items: { type: \"string\" } },\n topics: { type: \"array\", items: { type: \"string\" } },\n publicationRestrictions: {\n type: \"array\",\n items: { type: \"string\" },\n },\n },\n required: [\n \"people\",\n \"organizations\",\n \"topics\",\n \"publicationRestrictions\",\n ],\n },\n },\n },\n });\n\n const content = response.choices[0]?.message.content;\n if (!content) throw new Error(\"The model returned no structured content\");\n return JSON.parse(content) as MediaRecord;\n};\n\nasync function splitByTokenBudget(\n paragraphs: string[],\n maxTokens: number,\n countTokens: CountTokens,\n): Promise<string[]> {\n const chunks: string[] = [];\n let current = \"\";\n\n for (const paragraph of paragraphs) {\n const candidate = current ? `${current}\\n\\n${paragraph}` : paragraph;\n if ((await countTokens(candidate)) <= maxTokens) {\n current = candidate;\n continue;\n }\n if (current) chunks.push(current);\n if ((await countTokens(paragraph)) > maxTokens) {\n throw new Error(\"Split this paragraph at tokenizer-aware sentence boundaries\");\n }\n current = paragraph;\n }\n\n if (current) chunks.push(current);\n return chunks;\n}\n\nfunction mergeUnique(parts: MediaRecord[]): MediaRecord {\n const values = (field: keyof MediaRecord) =>\n [...new Set(parts.flatMap((part) => part[field]).map((v) => v.trim()))]\n .filter(Boolean);\n\n return {\n people: values(\"people\"),\n organizations: values(\"organizations\"),\n topics: values(\"topics\"),\n publicationRestrictions: values(\"publicationRestrictions\"),\n };\n}\n\nexport async function extractMediaRecord(\n document: string,\n countTokens: CountTokens,\n embed: Embed,\n rerank: Rerank,\n extract: Extract,\n): Promise<MediaRecord> {\n const paragraphs = document.split(/\\n\\s*\\n/).filter(Boolean);\n const chunks = await splitByTokenBudget(paragraphs, 2_000, countTokens);\n\n await embed(chunks);\n const queries = [\n \"exact names of people\",\n \"exact names of organizations\",\n \"main editorial topics\",\n \"embargoes, rights, or publication restrictions\",\n ];\n const selected = new Set<number>();\n\n for (const query of queries) {\n const ranked = await withRateLimitRetry(() => rerank(query, chunks));\n for (const item of ranked.slice(0, 4)) selected.add(item.index);\n }\n\n const parts: MediaRecord[] = [];\n for (const index of [...selected].sort((a, b) => a - b)) {\n parts.push(await withRateLimitRetry(() => extract(chunks[index])));\n }\n return mergeUnique(parts);\n}\n\nvoid extract;\nThe adapters are intentional. Token counting belongs before dispatch. Embeddings produce candidates; reranking orders those candidates against a specific field question. The extraction adapter should require the same JSON schema for every selected chunk and surface non-success responses rather than assuming a valid result. A provider SDK may perform the underlying POST and Bearer authentication, while the application still owns retry and validation policy.
\n\nThere is one sharp edge worth calling out. A single paragraph can exceed the budget. The sample rejects it so the condition cannot slip through silently; a production splitter should recurse through sentences using tokenizer-aware boundaries. Character slicing looks convenient, but characters are not tokens, and a blind cut can separate a name from the sentence that explains its role. For a concrete starting point, this example caps a chunk at 2,000 tokens, selects four passages per field query, and stops after four attempts. Those numbers are tunable controls, not performance claims. The trade-off is recall versus bounded work: shrinking either selection number can speed the job while making a distant correction easier to miss.
\n\nTest the miss, not the mood.
\n\nRecord stage-level facts: source document ID, input token count, chunk count, candidate count, reranked count, extraction attempts, schema-validation outcome, and merge conflicts. Do not log the private transcript or extracted personal data by default. Correlation needs identifiers, not content.
\n\nSeparate latency for counting, embedding, reranking, extraction, and merging. A rise in rerank duration points to a different boundary than a rise in schema-invalid fragments. One is about selection work or provider behavior; the other is about schema adherence, prompts, or conflicting evidence. A single ai_request_duration metric erases that distinction.
Three ratios are especially useful for alerting: timed-out documents per completed document, invalid fragments per extraction attempt, and records with unresolved conflicts per import batch. Alert on a sustained rate instead of one slow call. Include a batch ID and request ID so an operator can move from an aggregate signal to one job without searching source text.
\n\nMy default decision rule is conservative: deduplicate low-risk topic labels, but send conflicting embargoes or publication restrictions to review. Last-write-wins is fast. It is also the wrong merge policy when two selected passages disagree about whether material may be published. The extra review load buys a clear correctness boundary.
\n\nThis is the crisp before and after: before, a timeout says “the model was slow.” After, telemetry says “18 chunks were created, four passages were selected for restrictions, three fragments validated, and one conflict needs review.” The second message gives an engineer somewhere to act without claiming a latency benchmark that was never measured.
\n\nThe algorithm is portable. Operational ownership is not. Compare options by where credentials, routing, upgrades, and evidence telemetry should live.
\n\n| Option | \nGood fit | \nBoundary you still own | \n
|---|---|---|
| OpenAI direct | \nA team standardizing on OpenAI's API and structured-output surface | \nCross-provider routing and the rest of the retrieval pipeline remain application concerns | \n
| Anthropic direct | \nA team choosing Anthropic's API as its direct extraction boundary | \nEmbedding, reranking, and cross-provider policy require separate decisions | \n
| AWS Bedrock | \nAn organization that wants model access governed inside its AWS environment | \nIntegration and access policy follow the AWS operating model | \n
| LiteLLM | \nA team willing to operate an open-source gateway and control its deployment | \nGateway upgrades, capacity, and availability become team responsibilities | \n
| Infrai | \nA team consolidating backend integrations under one credential and bill | \nField-specific evidence selection and merge rules still belong in application code | \n
No row removes the need to validate model output. Direct providers reduce intermediaries. Bedrock can fit an established AWS control plane. LiteLLM gives teams source-visible gateway control, with the corresponding operational work. These are meaningful differences, not a ranking disguised as a table.
\n\nInfrai is relevant when credential and invoice sprawl extends beyond the model call: one key and one bill cover backend services, so an extraction worker does not need a growing set of service credentials and month-end invoices. Infrai also exposes backend capabilities through a single API over pure HTTP, without installing an SDK; any language and any runtime that can send a request can use the same consistent interface. That matters when a media importer starts in Node.js but a batch worker later moves elsewhere, because the integration contract and vendor-routing code do not need to change. Its public API discovery is genuinely self-describing and requires no key. Discovery reports request and response schemas, billing metadata, readiness, and runnable examples; every documented capability has examples in 10 languages. That reduces adapter guesswork when a TypeScript worker combines counting, reranking, and model calls. The verified snapshot contains 295 routes across 20 modules.
\n\nThose operational conveniences do not make retrieval correct. They reduce integration friction. The schema, field queries, evidence retention, and conflict policy remain yours.
\n\nFor a small corpus, sending every chunk may be the clearest first implementation. It avoids retrieval misses and gives you a baseline against which to evaluate selection. The cost is more extraction calls, more duplicated evidence, and a larger merge surface. Do not add embeddings and reranking merely because the architecture sounds sophisticated.
\n\nFor long archives, retrieval earns its place when field-specific selection reduces irrelevant text without losing required evidence. Test that claim with a labeled set. Measure field recall before celebrating fewer model calls, because a fast pipeline that omits the final-page embargo is incorrect.
\n\nAnother objection is that chunking destroys context. It can. Use modest overlap where sentences cross boundaries, keep stable chunk identifiers, and preserve evidence references with each extracted fragment. If a field depends on relationships across distant sections, retrieve multiple passages for that field and let the schema-bound extraction step see them together. The answer is controlled context, not automatically more context.
\n\nFinally, retries need a narrow meaning. Retry 429 responses with exponential backoff and honor Retry-After when present. Surface authorization, schema, and other client errors immediately. For batch submission or any create operation, use a client-supplied identifier or idempotency key so a retry cannot create duplicate work. HTTP semantics do not make arbitrary POST retries safe on their own.
The practical decision is straightforward: use synchronous extraction while documents reliably fit the token and request budgets; move imports to batch processing as duration and volume grow; add retrieval when labeled evaluation shows that it preserves the fields you care about. Keep every stage observable. Correct JSON is the target, and lower latency only counts when the evidence survives.
\n\nBuilding a modern web application from scratch often means spending a lot of time on things that are not actually part of the product you want to build.
\n\nAuthentication layouts.
\n\nNavigation.
\n\nDashboards.
\n\nTables.
\n\nCharts.
\n\nResponsive layouts.
\n\nDark mode.
\n\nReusable components.
\n\nAnd, of course, making everything look good.
\n\nI wanted to solve that problem for developers working with Quasar Framework.
\n\nSo I decided to revive a project that has been sitting on GitHub for more than five years and completely redesign it for the modern Quasar ecosystem.
\n\nMeet Quasar Dashboard PRO.
\n\n\n\n\n\n\n\n\n\nA modern, production-ready dashboard template built with Quasar Framework, Vue 3, TypeScript and Vite.
\n
There are countless dashboard templates available for React, Next.js and other popular ecosystems.
\n\nBut when working with Vue and especially Quasar, I often found myself starting with a clean Quasar project and rebuilding the same application foundations over and over again.
\n\nThe goal of Quasar Dashboard PRO is simple:
\n\nGive developers a solid starting point instead of an empty project.
\n\nYou should be able to clone the repository, install the dependencies, start the development server and immediately have a complete dashboard application to work from.
\n\n\n\n\nThe foundation of the project is Quasar Framework.
\n\nAnd this is one of the reasons I chose Quasar in the first place.
\n\nQuasar is not just a UI component library.
\n\nIt provides a complete application framework around Vue, with tooling for different application targets.
\n\nThe current Quasar ecosystem supports applications such as:
\n\nAll from the same Vue ecosystem.
\n\nThat means the dashboard you start building today doesn't necessarily have to remain a browser-only application tomorrow.
\n\n\n\n\nQuasar Dashboard PRO was designed around real application requirements rather than just a collection of UI screenshots.
\n\nThe dashboard includes several application areas to demonstrate how the architecture can be used in real-world projects.
\n\nA complete finance dashboard example with:
\n\n
The template also includes a CRM-oriented structure with areas such as:
\n\nThis makes it easier to adapt the project for SaaS applications, internal tools and business platforms.
\n\n![\"CRM\"](\"https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fcko375wvn98trzwdichm.png\")
The project includes examples for:
\n\nThe goal isn't to create a complete e-commerce platform.
\n\nInstead, these modules demonstrate how different business domains can coexist inside the same dashboard architecture.
\n\n![\"Ecommerce\"](\"https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fi07132ulr9epwuydfr5v.png\")
One of the most interesting parts of the new version is the fleet tracking dashboard.
\n\nIt demonstrates how Quasar can be used to build more complex operational interfaces.
\n\nThe dashboard includes:
\n\n![\"Fleet\"](\"https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fi22276bqj2dgdnehhz5i.png\")
This type of interface is particularly interesting for logistics, transportation, field service and IoT applications.
\n\n\n\n\nThe goal isn't just to provide a nice-looking dashboard.
\n\nThe project is structured to provide reusable foundations for applications.
\n\nInstead of starting with:
\n
src/\n components/\n pages/\n layouts/\nand then spending days deciding how everything should fit together, you start with an application that already has:
\n\nNavigation
\nLayouts
\nDashboard pages
\nResponsive behavior
\nReusable UI patterns
\nTables
\nCards
\nCharts
\nForms
\nApplication sections
\nTheme support
You can then remove what you don't need and start building your actual product.
\nModern dashboards have to work across different screen sizes.
\n\nA dashboard that looks great on a large monitor but becomes unusable on a laptop or mobile device isn't really production-ready.
\n\nQuasar's responsive utilities and component system make it possible to build these interfaces while keeping the development experience consistent.
\n\nThe goal with Quasar Dashboard PRO is to treat responsive behavior as part of the architecture rather than something added at the end.
\nThe project is built with TypeScript.
\n\nThis is particularly important for dashboard applications because they usually contain a lot of structured data.
\n\nFor example:
\n
interface Transaction {\n id: number\n description: string\n amount: number\n currency: string\n status: 'pending' | 'completed' | 'failed'\n date: string\n}\nStrong typing becomes increasingly valuable as the application grows.
\n\nIt makes refactoring safer, improves editor support and makes the codebase easier to maintain.
\n\nThe project uses the modern Quasar + Vite tooling.
\n\nThis provides a fast development experience while keeping the project aligned with the current Vue ecosystem.
\n\nQuasar's current tooling is built around Vite, and the framework provides its own CLI and build modes on top of it.
\n\nA dashboard template should not force developers into a single visual identity.
\n\nThe project is designed to be customized.
\n\nYou can change:
\n\nColors
\nTypography
\nNavigation
\nLayouts
\nComponents
\nDashboard cards
\nCharts
\nPages
\nApplication modules
The idea is to provide a strong starting point while keeping the project flexible enough to become your own application.
\nQuasar Dashboard PRO is open source.
\n\nThe repository is available on GitHub:
\n\n\n\nThe goal is not only to provide a ready-to-use template, but also to give the Quasar community something that can evolve over time.
\n\nI'm especially interested in seeing what developers build with it.
\n\nWho is it for?
\n\nQuasar Dashboard PRO can be useful for developers building:
\n\nSaaS applications
\n\nStart with a complete dashboard and focus on the actual product.
\n\nInternal tools
\n\nBuild admin panels and business systems faster.
\n\nCRM systems
\n\nUse the CRM structure as a starting point.
\n\nFinancial applications
\n\nUse the finance dashboard as a foundation.
\n\nE-commerce platforms
\n\nReuse the product, checkout and order structures.
\n\nFleet and logistics systems
\n\nUse the fleet tracking dashboard as a starting point for operational applications.
\n\nAdmin panels
\n\nOr simply use it as a general-purpose Quasar admin template.
\nOne of the biggest reasons I enjoy working with Quasar is that it allows developers to think beyond a single deployment target.
\n\nA Vue application can evolve into different experiences without requiring an entirely different technology stack.
\n\nFor example:
\n
Vue + Quasar\n │\n ┌──────────┼──────────┐\n │ │ │\n SPA PWA SSR\n │ │ │\n └─────┬────┴────┬─────┘\n │ │\n Mobile Desktop\nThis is one of the biggest strengths of the framework.
\n\nYou can build a common application foundation and adapt it to different platforms when the product requires it.
\n\nThe current version is only the beginning.
\n\nSome of the things I would like to explore in future versions include:
\n\nMore dashboard examples
\nMore reusable components
\nAuthentication examples
\nRole-based permissions
\nAdvanced data tables
\nMore chart examples
\nBetter mobile experiences
\nPWA improvements
\nMore real-world application modules
\nAI-assisted features
And, of course, contributions and ideas from the community.
\n\nIf you're working with Quasar and need a modern starting point for your next project, give it a try.
\n\n👉 View Quasar Dashboard PRO on GitHub
\n\nIf you build something with it, I'd love to see what you create.
\n\nStar the repository, open an issue, submit a PR or just share your project.
\n\nI don't think developers should spend the first days of a project rebuilding the same dashboard foundations again and again.
\n\nThe interesting part is the product.
\n\nThe business logic.
\n\nThe user experience.
\n\nThe problem you're trying to solve.
\n\nQuasar Dashboard PRO is an attempt to make that starting point faster.
\n\nClone it. Customize it. Build something great with Quasar.
","score":7},{"source":"https://dev.to/feed/tag/node","sourceHost":"dev.to","title":"From a modular monolith to microservices without a rewrite","link":"https://dev.to/icebob/from-a-modular-monolith-to-microservices-without-a-rewrite-1b5a","pubDate":"Tue, 22 Sep 2026 13:00:14 +0000","description":"Most \"monolith to microservices\" stories go one of two ways. Either it's a rewrite that takes eighteen months and ships a system nobody asked for, or it's a big-bang split into fifteen services that immediately need a Kubernetes team. Both come from the same mistake: treating \"process boundaries\" and \"module boundaries\" as the same decision.
\n\nThey aren't. You can draw the module boundaries now, inside the monolith, and move the process boundaries later — one service at a time, when you have a reason to. This article shows exactly that with a small Express app: three stages, the same service files in every stage, and real output at each step, including the one thing that does break when you finally run two copies of a service.
\n\nA perfectly ordinary Express monolith. Three modules, wired together with require(), one process.
\n
// lib/orders.js — calls users and mailer through plain imports. Tight coupling, zero ceremony.\nconst users = require(\"./users\");\nconst mailer = require(\"./mailer\");\n\nlet counter = 0;\nconst orders = [];\n\nexports.create = ({ userId, item, amount }) => {\n const user = users.get(userId);\n const order = { id: ++counter, userId, item, amount };\n orders.push(order);\n mailer.send(user.email, `Order #${order.id} confirmed (${item})`);\n return order;\n};\n// app.js\nconst express = require(\"express\");\nconst users = require(\"./lib/users\");\nconst orders = require(\"./lib/orders\");\n\nconst app = express();\napp.use(express.json());\n\napp.get(\"/users/:id\", (req, res) => res.json(users.get(Number(req.params.id))));\napp.post(\"/orders\", (req, res) => {\n const userId = Number(req.header(\"x-user-id\"));\n res.status(201).json(orders.create({ userId, ...req.body }));\n});\n\napp.listen(process.env.PORT || 3000);\n$ curl -s localhost:3000/users/1\n{\"id\":1,\"name\":\"Ada\",\"email\":\"ada@example.com\"}\n$ curl -s -X POST localhost:3000/orders -H 'content-type: application/json' -H 'x-user-id: 2' -d '{\"item\":\"Monitor\",\"amount\":329}'\n{\"id\":1,\"userId\":2,\"item\":\"Monitor\",\"amount\":329}\nNothing wrong with this. It's the right architecture for a team of three with one deployable. The problem only starts when orders grows a queue consumer, mailer needs to scale independently because a marketing campaign sends 200k emails, and you realise nothing in the codebase says which module is allowed to call which.
Bring in a service broker (Moleculer's ServiceBroker — think of it as an in-process service runtime with a registry) and turn each module into a service: a plain object with a name and actions (its callable endpoints). No transporter is configured, so every call is an in-memory function call. No network, no serialization, no new infrastructure.
\n
// services/orders.service.js — lib/orders.js as a service.\n// No require(\"./users\") any more: the dependency goes through the broker, and is declared.\nlet counter = 0; // module-level state — fine in a monolith; see \"What breaks\" below\nconst orders = [];\n\nmodule.exports = {\n name: \"orders\",\n dependencies: [\"users\"], // broker waits for `users` before starting this service\n actions: {\n create: {\n params: {\n userId: { type: \"number\", convert: true },\n item: \"string\",\n amount: { type: \"number\", positive: true },\n },\n async handler(ctx) {\n const user = await ctx.call(\"users.get\", { id: ctx.params.userId });\n const order = { id: ++counter, userId: user.id, item: ctx.params.item, amount: ctx.params.amount };\n orders.push(order);\n await ctx.emit(\"order.created\", { order, user });\n return { ...order, servedBy: this.broker.nodeID, usersServedBy: user.servedBy };\n },\n },\n },\n};\nThree things changed and they are all improvements you'd want anyway:
\n\ndependencies: [\"users\"] is documentation the runtime enforces — orders won't start until users is available.params is a schema; a bad amount is rejected before the handler runs.orders emits order.created; whoever cares subscribes. That's the seam you'll use later to move it out.\n// services/mailer.service.js — lib/mailer.js as a service. Instead of being called, it reacts to an event.\nmodule.exports = {\n name: \"mailer\",\n events: {\n \"order.created\"(ctx) {\n const { order, user } = ctx.params;\n this.logger.info(`→ ${user.email}: Order #${order.id} confirmed (${order.item})`);\n },\n },\n};\nExpress stays. The routes call the broker instead of the modules:
\n
// app.js — the same Express app, now with a broker inside. Routes call services instead of modules.\nconst express = require(\"express\");\nconst { ServiceBroker } = require(\"moleculer\");\n\nconst broker = new ServiceBroker({\n nodeID: `app-${process.pid}`,\n transporter: process.env.TRANSPORTER || null, // null = local bus, in-process only\n logger: { type: \"Console\", options: { level: \"info\", formatter: \"short\" } },\n});\n\nconst wanted = process.env.SERVICES === undefined ? [\"users\", \"orders\", \"mailer\"] : process.env.SERVICES.split(\",\").filter(Boolean);\nfor (const name of wanted) broker.createService(require(`./services/${name}.service.js`));\n\nconst app = express();\napp.use(express.json());\n\napp.get(\"/users/:id\", async (req, res, next) => {\n try { res.json(await broker.call(\"users.get\", { id: req.params.id })); } catch (e) { next(e); }\n});\napp.post(\"/orders\", async (req, res, next) => {\n try {\n const userId = Number(req.header(\"x-user-id\"));\n res.status(201).json(await broker.call(\"orders.create\", { userId, ...req.body }));\n } catch (e) { next(e); }\n});\napp.use((err, req, res, next) => res.status(err.code || 500).json({ error: err.name, message: err.message }));\n\nbroker.start().then(() => {\n app.listen(process.env.PORT || 3000, () => broker.logger.info(`HTTP on ${process.env.PORT || 3000}`));\n});\n$ node app.js\n[20:06:31.508Z] INFO BROKER: Node ID: app-3470689\n[20:06:31.549Z] INFO ORDERS: Waiting for service(s) 'users'...\n[20:06:31.557Z] INFO USERS: Service 'users' started.\n[20:06:31.557Z] INFO MAILER: Service 'mailer' started.\n[20:06:32.552Z] INFO ORDERS: Service(s) 'users' are available.\n[20:06:32.554Z] INFO ORDERS: Service 'orders' started.\n[20:06:32.554Z] INFO BROKER: ✔ ServiceBroker with 4 service(s) started successfully in 1s.\n[20:06:32.557Z] INFO BROKER: HTTP on 3000\n\n$ curl -s localhost:3000/users/1\n{\"id\":1,\"name\":\"Ada\",\"email\":\"ada@example.com\",\"servedBy\":\"app-3470689\"}\n$ curl -s -X POST localhost:3000/orders -H 'content-type: application/json' -H 'x-user-id: 2' -d '{\"item\":\"Monitor\",\"amount\":329}'\n{\"id\":1,\"userId\":2,\"item\":\"Monitor\",\"amount\":329,\"servedBy\":\"app-3470689\",\"usersServedBy\":\"app-3470689\"}\n# app log:\n[20:06:34.088Z] INFO MAILER: → linus@example.com: Order #1 confirmed (Monitor)\nSame behaviour, same single process, same deploy. servedBy and usersServedBy are the same node because everything is local. You could stop here for a year and still be better off than before: the boundaries are real, the contracts are validated, and nobody can sneak a require(\"../orders/db\") across modules any more.
This is what \"modular monolith\" should mean in practice — not a folder convention, but boundaries a runtime knows about.
\n\n![\"Same](\"https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F1y0rll2iduos8himh70x.png\")
Marketing week: mailer needs to scale on its own and must not slow down the request path. So move only mailer out.
Two changes, neither of them in service code. First, give the app a transporter (a message broker — NATS here) and tell it which services to host locally:
\n
$ TRANSPORTER=nats://localhost:4222 SERVICES=users,orders node app.js\nSecond, start mailer in its own process with moleculer-runner, the framework's CLI service host, pointed at the same services/ folder:
\n
// moleculer.config.js — for services that run OUTSIDE the app process, via moleculer-runner.\nmodule.exports = {\n nodeID: `svc-${process.env.SERVICES || \"all\"}-${process.pid}`,\n transporter: process.env.TRANSPORTER || \"nats://localhost:4222\",\n logger: { type: \"Console\", options: { level: \"info\", formatter: \"short\" } },\n};\n$ SERVICEDIR=services SERVICES=mailer npx moleculer-runner --config moleculer.config.js\nNow hit the same endpoints:
\n
$ curl -s -X POST localhost:3000/orders -H 'content-type: application/json' -H 'x-user-id: 2' -d '{\"item\":\"Monitor\",\"amount\":329}'\n{\"id\":1,\"userId\":2,\"item\":\"Monitor\",\"amount\":329,\"servedBy\":\"app-3470296\",\"usersServedBy\":\"app-3470296\"}\n\n# mailer process log:\n[20:03:06.188Z] INFO MAILER: → linus@example.com: Order #1 confirmed (Monitor)\nLook at what happened:
\n\nmailer received the order.created event in another process, over NATS. The orders code that emits it didn't change.orders → users is still app-3470296 → app-3470296: in-process. The app is connected to NATS, but the registry's default preferLocal: true routes a call to a local instance whenever one exists. You extracted one service and paid the network cost for exactly one hop — the one you chose.That's the whole method. The services/ folder is the same in both processes; which process loads which file is a deployment decision, made per environment with two environment variables. Your dev laptop runs node app.js with everything local; staging runs the hybrid; production splits further. Same code.
Let's go all the way: users, orders and mailer each in their own process, two instances of orders because it's the hot path, and the app hosting nothing but HTTP:
\n
$ SERVICEDIR=services SERVICES=users npx moleculer-runner --config moleculer.config.js\n$ SERVICEDIR=services SERVICES=orders npx moleculer-runner --config moleculer.config.js\n$ SERVICEDIR=services SERVICES=orders npx moleculer-runner --config moleculer.config.js\n$ SERVICEDIR=services SERVICES=mailer npx moleculer-runner --config moleculer.config.js\n$ TRANSPORTER=nats://localhost:4222 SERVICES= node app.js\n\n$ for i in 1 2 3 4; do curl -s -X POST localhost:3000/orders -H 'content-type: application/json' -H 'x-user-id: 1' -d '{\"item\":\"Cable\",\"amount\":9}'; echo; done\n{\"id\":1,\"userId\":1,\"item\":\"Cable\",\"amount\":9,\"servedBy\":\"svc-orders-3470323\",\"usersServedBy\":\"svc-users-3470321\"}\n{\"id\":1,\"userId\":1,\"item\":\"Cable\",\"amount\":9,\"servedBy\":\"svc-orders-3470322\",\"usersServedBy\":\"svc-users-3470321\"}\n{\"id\":2,\"userId\":1,\"item\":\"Cable\",\"amount\":9,\"servedBy\":\"svc-orders-3470323\",\"usersServedBy\":\"svc-users-3470321\"}\n{\"id\":2,\"userId\":1,\"item\":\"Cable\",\"amount\":9,\"servedBy\":\"svc-orders-3470322\",\"usersServedBy\":\"svc-users-3470321\"}\nThe good news: round-robin load balancing between the two orders instances, calls to users over the wire, no code changes — all of it just works.
The bad news is in the first column. Order IDs 1, 1, 2, 2. Remember let counter = 0 at the top of orders.service.js? Each process has its own. In the monolith it was a perfectly good ID generator; with two instances it's a duplicate-key bug that would have shipped.
This is the honest part of the article. Turning modules into services is nearly free. Running two copies of one is where the monolith's hidden assumptions surface. Here is the list I check before scaling any service past one instance:
\n\nMaps of sessions. Every instance gets its own. Move it to the database or a shared store, or make it instance-safe (UUIDs instead of counters; here id: crypto.randomUUID() is the one-line fix).Memory cacher is per node; with several instances you'll serve stale data from one and fresh from another. Switch the cacher to Redis — a broker option, not a code change.orders + inventory in one SQL transaction worked because they were one process on one connection. Across processes it's either a saga (compensating actions on failure) or you keep those two in the same service. Both are fine; pretending it's still atomic is not.ctx.meta instead of globals. The request-scoped things you used to keep in req or a module variable (user ID, locale, trace ID) now need to ride along explicitly. Moleculer propagates ctx.meta through every call and event automatically — put them there.None of these are Moleculer problems, and none of them are avoided by any other framework; they're the actual difference between one process and two. The point of the staged approach is that you hit them one service at a time, with a working system on both sides, instead of all at once on cut-over day.
\n\nIf I were doing this to a real codebase:
\n\nctx.call, every fire-and-forget a ctx.emit. Ship it. It is a refactor with no infrastructure change, and it's where you discover which modules actually depend on which.And keep node app.js — the everything-local mode — working forever. It's how a new developer runs the whole system on a laptop with no Docker, and it's how you run integration tests without a message broker. The local bus is a feature, not a stepping stone.
Code in this article was run on Moleculer 0.15.2, Express 5 and Node.js 22, with NATS 2 for stages 2 and 3. The moleculer-examples repository has a run.sh that reproduces all three stages — including the duplicate-ID bug — in one go.
I ended up choosing a hybrid: Next.js 14 for static content pages + a separately lazy-loaded client shell for the game runtime page.
\n\nBut that wasn't a snap decision. I spent 3 days building the same MVP twice, hit the Next.js static export dynamic route 404 trap, and dealt with Vue's SEO plugin problem. If you're making a similar decision, the process is probably more useful than the conclusion.
\n\n\n\n\noutput: 'export')Before writing any code, I listed three hard constraints:
\n\nThese three constraints ended up driving the entire decision.
\n\n\n\n\nNext.js 14 App Router with this route structure:
\n\n/ homepage (SSG)/games/[category] category page (SSG)/play/[id] game runtime page (client-side rendered)I used output: 'export' for pure static export and deployed to Vercel.
After next build, the homepage and category pages generated HTML correctly. But /play/[id] all returned 404.
After digging in: App Router with output: 'export' doesn't support dynamic routes by default unless you explicitly define generateStaticParams. This is heavily discussed in the community; developers on V2EX have reported that \"the latest Next.js App Router doesn't support dynamic routes with static generation.\"
Worse, even after defining generateStaticParams, all game IDs have to be pre-generated at build time. If the game count grows to hundreds, every new game triggers a full rebuild, and CI time grows exponentially.
I tried @falsefoundation/next-dynamic-exports, which supports dynamic routes by generating fallback pages, but it requires web server rewrite rules (Nginx try_files), adding deployment complexity.
Another approach was to turn the game runtime page from a dynamic route into a client-rendered static shell — the /play page reads the game ID via useSearchParams after loading. This bypasses the generateStaticParams limitation, but the game runtime page is no longer prerendered, so SEO suffers. My trade-off: the game runtime page has low SEO value anyway (users arrive from the detail page), so it's acceptable.
Vue 3.4 + Vite 5.2 + vue-router 4, same route structure as the Next.js version.
\n\nVite's dev experience is excellent. Cold start under 1 second, hot updates nearly imperceptible. Build time was only 6 seconds, half of Next.js.
\n\nFirst-load JS (gzip) was about 50KB, nearly 40% less than Next.js. Vue 3's runtime is lightweight by itself, and Vite's tree-shaking leaves nothing extra.
\n\nVue + Vite defaults to SPA. The homepage and category pages only contain <div id=\"app\"></div> in the HTML — crawlers see no content.
The solution was to install vite-plugin-seo-prerender, which prerenders the SPA into static HTML files at build time. Configuration is simple:
\n
// vite.config.ts\nimport seoPrerender from 'vite-plugin-seo-prerender'\n\nexport default defineConfig({\n plugins: [\n seoPrerender({\n routes: ['/', '/games/puzzle', '/games/sports']\n })\n ]\n})\nBut the plugin has a limitation: it's only suitable for generating static HTML for a small number of pages. If the game count grows to hundreds, every game detail page needs prerendering, and build time becomes uncontrollable.
\n\nAnother option is Nuxt 3, Vue's meta-framework with built-in SSG. But that introduces another framework, contradicting the \"lightweight\" goal.
\n\nAfter both versions were running, I did one thing: recorded the full timeline from homepage to clicking \"Start Game\" using Chrome DevTools Performance panel on both.
\n\nSomething counterintuitive came up: the performance difference between the two versions was far smaller than I expected.
\n\nThe Next.js version had 35KB more first-load JS, but on 4G that's about 200ms of download time. The real time sink while browsing the list page wasn't the framework's JS size — it was the game iframe initialization.
\n\nIn the default implementation, the iframe was initialized when the game detail page mounted. Even if the iframe src pointed to an empty placeholder page, creating the contentWindow and initializing the sandbox environment still consumed main thread time. On a Moto G Power, that single operation took about 400ms.
The correct approach is the facade pattern: render only a lightweight static placeholder (thumbnail + play button) before the iframe mounts, and inject the actual iframe only when the user clicks \"Start.\" This matches Lighthouse's recommendation for deferring third-party resources.
\n\nThere's a Next.js static wiki case in the DEV community that uses the facade pattern to move a YouTube iframe from hydration-time mount to click-time load, bringing mobile TBT down from destructive levels to acceptable.
\n\nThis means: the framework choice's impact on first-load performance is far smaller than the iframe initialization strategy's impact. I wrote this down because it directly changed my selection criteria.
\n\n\n\n\nBased on the three-day comparison, I made these decisions:
\n\nStatic content pages (homepage, category pages, detail pages) use Next.js SSG. Because:
\n\nThe game runtime page uses an independent client-rendered shell. Because:
\n\nnext/dynamic with ssr: false to lazy-load the game iframe componentThe Vue version wasn't maintained. It builds faster and has a smaller bundle, but SEO needs extra plugins, and if the game count grows, the prerendering solution's scalability is worse than Next.js's SSG system.
\n\nHere's the concrete implementation:
\n
// components/GameLauncher.tsx\n'use client'\nimport { useState } from 'react'\nimport dynamic from 'next/dynamic'\n\nconst GameIframe = dynamic(() => import('./GameIframe'), {\n ssr: false,\n loading: () => <div className=\"h-full bg-zinc-900 animate-pulse\" />\n})\n\nexport default function GameLauncher({ game }) {\n const [started, setStarted] = useState(false)\n\n if (!started) {\n return (\n <button\n onClick={() => setStarted(true)}\n className=\"relative w-full aspect-video rounded-lg overflow-hidden\"\n >\n <img src={game.thumbnail} alt={game.title} className=\"w-full h-full object-cover\" />\n <div className=\"absolute inset-0 flex items-center justify-center\">\n <svg width=\"64\" height=\"64\" viewBox=\"0 0 64 64\">\n <circle cx=\"32\" cy=\"32\" r=\"30\" fill=\"rgba(0,0,0,0.6)\" />\n <polygon points=\"26,20 26,44 46,32\" fill=\"white\" />\n </svg>\n </div>\n </button>\n )\n }\n\n return <GameIframe src={game.entry} gameId={game.id} />\n}\nssr: false ensures the iframe component isn't bundled into the HTML during server rendering, and only loads from the client after the user clicks. This matches Next.js's official lazy-loading advice: for heavy components that don't participate in SSR, use next/dynamic with ssr: false to reduce the initial bundle.
| Metric | \nNext.js 14 | \nVue 3 + Vite | \n
|---|---|---|
| First-load JS (gzip) | \n~85KB | \n~50KB | \n
| Homepage LCP (4G) | \n1.2s | \n1.5s (after prerendering) | \n
| Build time | \n12s | \n6s | \n
| Dynamic route support | \nNeeds generateStaticParams | \nBuilt-in | \n
| SEO | \nOut of the box | \nNeeds extra plugins | \n
| Game runtime lazy load | \nnext/dynamic native support | \nManual implementation | \n
Test conditions: MacBook Pro M1 build, iPhone 12 + Chrome DevTools 4G throttling, 10 runs each, median.
\n\nNote: Vue's LCP was actually slower than Next.js after prerendering. The reason is that vite-plugin-seo-prerender still includes the full Vue runtime in the generated HTML, while Next.js SSG outputs cleaner HTML with lower hydration cost.
generateStaticParams full pre-generation becomes a bottleneck, requiring ISR or a Headless CMS — but that's no longer zero-backend.vite-plugin-prerender-static supports multi-route generation and SEO meta tags, which might be enough if the game count is small.Both MVP versions are organized, including Next.js and Vue comparison branches. The test data comes from a local environment. If you get different results on real hardware, I'd love to hear about it.
","score":3},{"source":"https://dev.to/feed/tag/nuxt","sourceHost":"dev.to","title":"Nuxt Hydration Mismatch: Why It Happens and How to Fix It","link":"https://dev.to/parsajiravand/nuxt-hydration-mismatch-why-it-happens-and-how-to-fix-it-5b7i","pubDate":"Sun, 20 Sep 2026 16:26:04 +0000","description":"Your Nuxt page looks perfect. \"View Source\" shows clean, fully-rendered HTML — the hero text, the product price, the footer, all there before a single line of JavaScript ran. Then the client bundle finishes loading, and the console lights up: [Vue warn]: Hydration text mismatch. Sometimes it's cosmetic — a number flickers and settles. Sometimes it's worse: a button the user already clicked stops responding, because Vue just tore out the DOM node it was attached to and built a new one.
This is a hydration mismatch, and it's arguably the most Nuxt-specific bug you'll ever debug. It has nothing to do with your logic being wrong in the way a typo is wrong — your component can be perfectly correct JavaScript and still cause one, because the bug isn't in what you wrote, it's in the fact that Nuxt runs what you wrote twice, in two different places, and bets your app's interactivity on both runs agreeing.
\n\nThis article is written against Nuxt 4.x (verified against the v4.5 release line, August 2026), using the Composition API, auto-imports, and the app/ directory convention Nuxt 4 defaults to. Everything here also applies to Nuxt 3's compatibilityVersion: 4 mode.
By the end of this article you'll be able to:
\n\nonMounted, <ClientOnly>, or data-allow-mismatch — for each situationYou've built at least one Nuxt page with <script setup> and know roughly what server-side rendering means (the server sends back real HTML instead of an empty <div id=\"app\">). You don't need prior SSR debugging experience — that's the point of this article.
Say you're building a \"tip of the day\" widget. It's a plain computed value, no fetch, no state management — about as simple as a Vue component gets:
\n
<script setup>\nconst TIPS = [\n \"Use useAsyncData for anything that fetches.\",\n \"Auto-imports save you the import line, not the thinking.\",\n \"Nitro is just Node under the hood.\",\n]\n\nconst tip = TIPS[Math.floor(Math.random() * TIPS.length)]\n</script>\n\n<template>\n <p>Tip of the day: {{ tip }}</p>\n</template>\nNothing here looks wrong. It compiles, it runs, npm run dev shows a tip. But open the browser console and you'll see something like:
\n
[Vue warn]: Hydration text mismatch:\n- Server rendered: Tip of the day: Nitro is just Node under the hood.\n- Client rendered: Tip of the day: Use useAsyncData for anything that fetches.\nNothing crashed. The page still works. But the text the user saw for a split second — the one baked into the HTML the server sent — silently got replaced by a different one the instant the JavaScript took over. If that \"tip\" were a price, a username, or which item was in stock, this wouldn't be a curiosity, it would be a bug report.
\n\nThe same failure mode shows up with new Date(), with window.innerWidth, with anything read from localStorage inside the component's render path. The common thread: the value depends on where the code runs, and Nuxt runs your component in two different places.
The mental model: Nuxt doesn't render your app once — it renders the same component tree twice, in two different environments, and then asks the second render to adopt the DOM the first render already produced, instead of rebuilding it from scratch.
\n\nHere's the sequence for a single page request:
\n\nuseAsyncData/useFetch call and every useState, embedded in the page as a <script id=\"__NUXT_DATA__\"> block.Hydration is a reconciliation, not a second render from scratch — and reconciliation assumes the two renders agree. When they do, hydration is invisible: the DOM stays exactly as the server drew it, listeners attach, the page becomes interactive. When they don't, Vue has two options depending on how badly they disagree:
\n\n{{ tip }} that resolved differently, a class that differs): Vue patches just that value in place and — in development only — logs a warning. Production builds do this silently, which is why a mismatch can ship for weeks before anyone notices.v-if branching differently on each side): Vue can't patch that in place. It throws away the mismatched subtree and re-renders it entirely client-side. That's real, visible re-work, and if a user had already interacted with something inside that subtree, the element they clicked no longer exists.The payload exists specifically so that data is safe across hydration — useAsyncData, useFetch, and useState all serialize their results, so the client reads the exact value the server used instead of recomputing it. (If you've read the earlier episode on useAsyncData keys and dedupe, this is the same payload that makes dedupe possible — it's doing double duty.) The danger is everything outside that mechanism: any value your template reads that isn't backed by useState/useAsyncData and isn't guaranteed identical on both sides — Math.random(), Date.now(), window, navigator, localStorage — is a mismatch waiting to happen, because nothing carries it across the server→client boundary for you.
onMounted\nThe tip-of-the-day bug and the \"current time\" bug are the same shape: a value that's legitimately allowed to differ per visitor, rendered directly during setup. The fix is to give the template a stable, server-safe default, and only fill in the real value once you're certain you're client-side:
\n
<script setup>\nimport { ref, onMounted } from \"vue\"\n\nconst tip = ref(null)\n\nonMounted(() => {\n const TIPS = [\"Use useAsyncData for anything that fetches.\", \"…\"]\n tip.value = TIPS[Math.floor(Math.random() * TIPS.length)]\n})\n</script>\n\n<template>\n <p>Tip of the day: {{ tip ?? \"Loading…\" }}</p>\n</template>\nKey concept: onMounted runs only after hydration has already completed successfully. Anything it writes is a normal, client-only reactive update — Vue never has to reconcile it against server HTML, because by the time it runs, hydration is already done.
<ClientOnly>\nSome content isn't \"slightly different\" between server and client — it can't exist on the server at all. A chart that measures its container's pixel width, a widget that reads localStorage, a third-party embed that expects window. For those, don't try to make the server render something — tell Nuxt not to render it there in the first place. <ClientOnly> is auto-imported and does exactly that:
\n
<template>\n <ClientOnly>\n <UserLocalClock />\n <template #fallback>\n <span class=\"clock-placeholder\">--:--</span>\n </template>\n </ClientOnly>\n</template>\nThe default slot never runs on the server. The #fallback slot renders there instead (useful for reserving layout space so nothing jumps), and the moment the component mounts client-side, Nuxt swaps the fallback for the real content — created fresh, never hydrated.
Key concept: <ClientOnly> doesn't resolve a mismatch — it removes the possibility of one, because nothing inside it is ever compared between two renders. There's only ever one render, on the client.
It's tempting to reach for Nuxt's environment flags — import.meta.server / import.meta.client (the modern replacement for the older process.server / process.client) — and branch your template directly on them:
\n
<!-- Don't do this -->\n<template>\n <div v-if=\"import.meta.client\">Client-rendered content</div>\n <div v-else>Server-rendered content</div>\n</template>\nThis guarantees a structural mismatch, every single time. On the server, import.meta.server is true, so the server emits the <div> from the v-else branch. On the client, during hydration, import.meta.client is true, so Vue's hydration walk expects the v-if branch — a different <div> than the one actually sitting in the DOM. Vue can't reconcile two different branches in place; it discards and re-renders. import.meta.client/.server are genuinely useful for deciding what code runs (skip a browser-only import on the server, skip a Node-only one on the client) — they're the wrong tool for deciding what a hydrated template renders, because that decision has to be identical in both places by definition.
data-allow-mismatch\nOccasionally you'll have a value that will always differ by design — a relative timestamp (\"posted 3 minutes ago\") that keeps ticking, for instance — and you've already accepted that as correct behavior rather than a bug. Vue 3.5 added an attribute for exactly this: data-allow-mismatch silences the hydration warning for a specific element, scoped to the kind of mismatch you name (text, children, class, style, or attribute):
\n
<time data-allow-mismatch=\"text\">{{ relativeTime }}</time>\nThis only suppresses the console warning — it does nothing to make the values agree. Reach for it after you've decided the mismatch is cosmetic and harmless, never as a first response to a warning you haven't diagnosed yet.
\n\n<div> nested inside a <p>, or malformed <table> markup, gets silently corrected by the browser's HTML parser while it parses the server's HTML — the browser closes the <p> early, restructuring the tree Vue expected to hydrate onto. The fix is markup hygiene, not JavaScript: keep nesting valid per the HTML content model.data-allow-mismatch=\"attribute\" on the affected element is the pragmatic escape valve once you've confirmed the source.Date.now() — same fix: compute the display string in onMounted.ref seeded from a browser API at module or setup scope. const isWide = ref(window.innerWidth > 768) throws on the server (there is no window) or, if guarded, still needs a server-safe default and a client-side correction — the same onMounted pattern applies.useState vs. a plain ref if that's the symptom you're chasing.onMounted. Any value that's allowed to differ per visitor gets a server-safe placeholder and a client-side update after mount — never a direct read of a browser API during setup.<ClientOnly> for whole widgets, not individual values. If an entire component only makes sense in a browser (canvas-sized charts, window-dependent libraries), don't fight it into an SSR-safe shape — skip SSR for it.import.meta.client/.server. Use those flags to decide what code runs, not what a hydrated component renders.nuxt dev. Run nuxt build && nuxt preview before shipping something that touches SSR — dev's warnings are the same, but dev's timing can mask issues that show up under real hydration.No — Vue reconciles it either way. A text/attribute mismatch is patched in place; a structural one is discarded and re-rendered client-side. The app keeps working, but a structural mismatch means real extra work and a possible flash or loss of state in that subtree.
\n\nVue's hydration mismatch console warning is a development-only diagnostic. In a production build, the same reconciliation happens, but silently — which is exactly why these bugs can ship unnoticed for a long time. Always sanity-check SSR-sensitive pages against a nuxt preview build, not just dev.
<ClientOnly> the same thing as checking import.meta.client?\nNo. import.meta.client is a compile-time flag that decides which lines of code are included in which bundle — it's a build-time tool. <ClientOnly> is a runtime component that skips server rendering for its slot content and mounts it fresh in the browser. Using the flag to branch a hydrated template's markup causes the exact mismatch this article is about; <ClientOnly> avoids it by never hydrating that content at all.
useState prevent hydration mismatches?\nIt prevents the specific class caused by state disagreeing between server and client, because its value is serialized into the payload and read identically on both sides. It doesn't protect a value your template computes independently of useState — Math.random() inside a <script setup> block is still a mismatch even if an unrelated useState call exists elsewhere in the same component.
Yes. Third-party scripts and browser extensions can alter the DOM before your app hydrates, and that's outside your code's control. data-allow-mismatch on the specific affected attribute is the accepted mitigation once you've confirmed that's the cause.
| Situation | \nSymptom | \nFix | \n
|---|---|---|
\nMath.random() / Date.now() read during setup or render | \nText mismatch warning, value flickers on load | \nDefault to null/placeholder, set the real value in onMounted\n | \n
Reading window, navigator, localStorage in the template's data path | \nThrows on server, or mismatches if guarded naively | \n\nref(defaultValue) + onMounted to correct it | \n
| Whole widget only makes sense client-side (canvas size, browser-only lib) | \nMismatch or server crash | \nWrap it in <ClientOnly> with a #fallback\n | \n
\nv-if=\"import.meta.client\" branching a hydrated template | \nStructural mismatch, guaranteed, every load | \nDon't branch markup on the flag — use <ClientOnly>/onMounted instead | \n
| Relative time / genuinely-expected drift you've accepted | \nWarning you don't want to see | \n\ndata-allow-mismatch=\"text\" (Vue 3.5+) — after you've confirmed it's harmless | \n
\n<div> inside <p>, broken table markup | \nMismatch with no obvious cause in your JS | \nFix the HTML nesting; lint markup | \n
| Grammarly / extensions injecting attributes | \nAttribute mismatch you can't reproduce locally without the extension | \n\ndata-allow-mismatch=\"attribute\" on the affected element | \n
<script setup>\nimport { ref, onMounted } from \"vue\"\n\n// Server-safe default — identical on both renders.\nconst clientValue = ref(null)\n\nonMounted(() => {\n // Runs only after hydration succeeds — safe to diverge here.\n clientValue.value = computeSomethingClientOnly()\n})\n</script>\n\n<template>\n <p>{{ clientValue ?? \"Loading…\" }}</p>\n\n <!-- For whole subtrees that can never run on the server: -->\n <ClientOnly>\n <BrowserOnlyWidget />\n <template #fallback><span>Loading…</span></template>\n </ClientOnly>\n</template>\n▶️ Open the interactive playground →
\n\nRuns right in your browser — poke at it and watch the concept react live.
\n\nMath.random(), Date.now(), or any direct read of a browser-only API.onMounted fixes values that are allowed to differ once hydration is already done; <ClientOnly> fixes whole subtrees that can never run on the server; data-allow-mismatch only silences a warning you've already confirmed is harmless.import.meta.client/.server — that's the one \"fix\" that reliably causes the exact bug it's trying to solve.Think it clicked? Take the 9-question quiz →
\n\nInstant feedback, a hint on every question, and an explanation for each answer — right or wrong.
\n\nThat tip-of-the-day widget from the top of this article has an honest fix now — a ref that starts null and fills in after mount, instead of a Math.random() call sitting directly in the render path. The bug was never really about randomness; it was about where the randomness ran, and Nuxt was always going to run it twice.
What's the strangest hydration mismatch you've had to track down — a third-party script, a timezone, something stranger? Drop it in the comments; there's a decent chance someone else's next [Vue warn] is exactly the one you already solved.
🚀 Want more like this? Every guide, playground, and quiz lives on bestpractic.org — open it and sign up free so the next one finds you.
\n\nThanks for reading! Let's stay connected:
\n\nBuilding a high-concurrency sports data platform is no easy task. When we started developing Cocatips - Live Football Scores & AI Predictions, our goal was to process data for over 80,000 football clubs globally without crashing the server or sacrificing UX.
\n\nIn this post, I will share the architectural approach we took using Nuxt 3 and Vue.js to handle massive data structures, specifically for live sports events, standings, and algorithmic predictions.
\n\nFootball fans demand instant updates. Whether they are looking for live scores, fixtures & schedules or diving deep into head to head (H2H) & stats, the data delivery must be lightning-fast.
\n\nAdditionally, our platform processes advanced algorithmic data for sports analysts. We needed a UI that could seamlessly switch between displaying a standard match tracker and outputting deep analytical models, such as:
\n\nTo handle SEO and dynamic rendering for thousands of leagues, we utilized Nuxt 3's Nitro engine. We set up ISR (Incremental Static Regeneration) for our highly-visited pages.
\n\nFor example, when fans check the Live English Premier League standings, table & results, the page needs to show up-to-the-minute goal differences and points. By caching the initial HTML at the edge and hydrating the live data on the client side via our API (datav1.cocascore.com), we achieved a sub-second TTI (Time to Interactive).
To demonstrate how we structure our Vue components without revealing our entire proprietary backend, I created a Vanilla JS/CSS version of our Standings Widget.
\n\nThis widget fetches real-time data and can toggle between multiple leagues dynamically. Check out the embed below:
\n\n\n
\n\nOne of the most complex parts of the system was allowing users to search through 80,000+ teams and matches instantly. We built a custom scoring algorithm in TypeScript that handles fuzzy matching and ignores diacritics.
\n\nIf a user searches for a specific matchup looking for an expert correct score prediction, our search function applies tiered sorting. It prioritizes top-tier leagues (like the Champions League or La Liga) over regional youth leagues, ensuring the most relevant matches appear first in the modal.
\n\nBy combining Nuxt 3's server-side rendering with a robust Redis-backed Node.js API, we successfully created a platform that delivers both sure home win predictions and deep statistical insights without breaking a sweat.
\n\nIf you are a Vue developer interested in sports data, feel free to check out the live architecture on our platform at Cocatips.com and explore our daily mathematical predictions.
","score":3},{"source":"https://github.blog/feed","sourceHost":"github.blog","title":"Should you read the code, is RAG dead, and did Skills kill MCP?","link":"https://github.blog/ai-and-ml/should-you-read-the-code-is-rag-dead-and-did-skills-kill-mcp/","pubDate":"Fri, 18 Sep 2026 15:00:00 +0000","description":"We dive into these questions and other AI hot takes on the latest episode of the GitHub Podcast.
\nThe post Should you read the code, is RAG dead, and did Skills kill MCP? appeared first on The GitHub Blog.
","score":4},{"source":"https://dev.to/feed/tag/nuxt","sourceHost":"dev.to","title":"I Built an AI Tarot Demo in Two Hours. Shipping the Product Was a Different Job.","link":"https://dev.to/liuxinyea/i-built-an-ai-tarot-demo-in-two-hours-shipping-the-product-was-a-different-job-23ck","pubDate":"Fri, 18 Sep 2026 09:59:28 +0000","description":"My wife was interested in tarot cards, and I was a frontend developer looking for an excuse to build something. I put together a page with a deck, a card-flipping animation, and an AI-generated reading.
\n\nWith AI assistance, the basic flow worked in about two hours.
\n\n![\"](\"https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F5v6x68r5tomwy08k3abg.png\")
I thought authentication and payments would get it ready to launch. Then the questions started: What happens when someone switches devices? What if a paid reading stops halfway through? Can I change a guided exercise without changing the meaning of someone’s saved answers?
\n\nEventually, another question became harder than any of those: how do I get people to use it?
\n\nThe project is now Mystic Journey. It includes a daily card ritual, guided explorations, a personal journal, and an optional companion board.
\n\nI’m still looking for early users. This is a development retrospective—and, openly, an invitation to try what I’ve built.
\n\nThe original experience was straightforward: ask a question, draw cards, read the interpretation, leave.
\n\n![\"](\"https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ft52sjei92pek8k4p6rqy.png\")
But a general-purpose AI can already explain tarot cards. A nicer animation wasn’t enough to explain why someone should return to my website.
\n\nI started thinking about the experience around the reading. Writing in an empty journal can be surprisingly difficult. A card, a specific question, or a few choices might make it easier to begin reflecting.
\n\nThat became the daily ritual: choose your mood, reveal your daily card, read a reflection prompt, and optionally write a few words. The aim is to make a small check-in easy, even when you don’t have a major question to ask.
\n\nFor people who want to go further, I added six guided themes covering space, boundaries, change, confidence, connection, and direction. Each has five short chapters: notice the situation, consider another perspective, choose a small action, identify obstacles, and find support.
\n\nThese explorations use curated branches rather than generating every step with AI. Earlier choices influence later options. Personal notes are optional and don’t automatically trigger a model call.
\n\nThis gives me content I can review and improve consistently. Open-ended AI readings still have a place, but they don’t need to power every interaction.
\n\nCompleted rituals, explorations, and explicitly saved readings go into a personal Journey timeline. The intention is to give people something worth revisiting: their own thoughts and choices, not just a list of cards.
\n\nI also added an opt-in weekly companion board. It shows names, avatars, and activity points, but not private reflections. Points are separate from purchases and don’t depend on someone’s mood or how much they write.
\n\nThere’s a tension here: even a gentle leaderboard can create comparison. Whether it feels supportive is something I need users to tell me. These are product hypotheses, not proven retention improvements.
\n\nThe stack is Nuxt 3 for the statically generated frontend, a separate Fastify API, SQLite, and DeepSeek for generated readings. Nginx routes API requests to the backend.
\n\nFor the current scale, I want something I can deploy and troubleshoot on my own. The difficult work has mostly been in the behavior of the application, not the number of services.
\n\nA daily card becomes account data once it connects to reflections, history, and rewards. Someone opening the site on their phone should see the same record they started on their laptop. Completion and rewards need consistent server-side state.
\n\nDisabling a button helps the interface, but it doesn’t prevent retries or requests from another tab.
\n\nGuided exploration saves have a similar problem. If a laptop has already saved the next chapter while a phone still has an older revision, accepting the phone’s write could overwrite newer progress.
\n\nRelevant save requests carry a revision. A stale write gets a conflict response, and the frontend keeps the draft while offering to reload saved progress. Identical committed retries return the existing result.
\n\nThese are easy details to overlook when you only test one browser tab on a reliable connection.
\n\nOne of the more interesting problems came from changing the exploration itself.
\n\nSuppose a saved answer says the user selected option 1. If I reorder the options next week, that stored value can appear to mean something different.
This is a simplified example of the problem:
\n
Version 1, option 1: Take time to reflect privately\nVersion 2, option 1: Talk to someone you trust\nThe number didn’t change. The user’s apparent answer did.
\n\nAn exploration therefore retains the content version it started with. Old option meanings need to remain stable, and the live chapter and saved recap need to interpret answers through the same branch logic.
\n\nOnce copy gives meaning to stored answers, editing it is also a data-compatibility decision.
\n\nWeekly reflections brought another state problem. A generation request can time out, a retry can start, and the original request can finish late. Without a guard, that older result could overwrite the newer one.
\n\nThe implementation uses a generation state, an expiring lease, and a version condition when writing the result. A short database transaction protects state changes; it doesn’t stay open while waiting for the model.
\n\nThe demo treated generation as success or failure. Streaming makes that less tidy: a request can return some text, stall, lose its client connection, or finish without usable content.
\n\nDeep readings use server-sent events. The server applies a timeout and attempts to cancel the upstream request if the client disconnects early. Only a complete successful result goes into the result cache.
\n\nIf generation fails after credits have been deducted, the error path restores those in-app credits and provides a local card interpretation. Restoring credits is separate from refunding a payment through the payment provider.
\n\nWeekly reflections also have a model-call budget and a local fallback. A free feature still needs a cost boundary.
\n\nThis isn’t a complete recovery system. For example, a process crash after a deduction cannot be recovered by a catch block in that same process. Durable job state and reconciliation remain areas to improve.
That distinction matters: having an error handler is not the same as having verified recovery from every failure.
\n\nThe model generates text. It doesn’t decide account permissions, payment status, or credit balances, and it has no database or payment tools.
\n\nThat limits the consequences of a manipulated response, but it doesn’t solve prompt injection. User input can still interfere with the intended task, and model output needs to be treated as untrusted content when it reaches the UI.
\n\nThe service currently has request rate limiting, body-size limits, and account and credit checks before paid generation. These are basic controls, not a claim of comprehensive protection. IP-based limits have limitations, and input handling and output rendering require their own review.
\n\nFor accounts, passwords use salted hashes, the database stores hashes of session tokens, and session cookies use HttpOnly and SameSite settings, with Secure enabled for production. Verification codes expire and have attempt limits.
\n\nPayments have a separate trust boundary. The backend confirms payment status with the provider and verifies webhook signatures. Order-status requests check ownership. Since polling and a webhook can both confirm the same payment, crediting an order must be idempotent.
\n\nPrivacy also affects ordinary feature decisions. The feedback form doesn’t automatically attach someone’s journal entries. Analytics can record that a reflection was saved without collecting its text.
\n\nI still have security work to do. Keeping track of what each component can access—and where personal content goes—has been more useful than treating safety as a few lines in a system prompt.
\n\nStatic generation lets me serve public pages separately from account APIs, but it doesn’t automatically make the experience fast. Images, animations, authentication checks, and API latency still matter on a phone.
\n\nThe Journey timeline is paginated, details load on demand, and uploaded avatars are cropped and compressed to WebP in the browser. Streaming also needs the proxy to cooperate: response buffering can hide the incremental output the server is sending.
\n\nThe interface supports eight languages, while the card data is primarily English and Chinese, with English fallback elsewhere. Those are different levels of localization, and I shouldn’t present them as equivalent.
\n\nA recent bug was a good reminder of the extra surface area: an email placeholder contained a literal @, which the i18n message compiler interpreted as special syntax. The JSON was valid, but the page failed. A JSON parse check alone couldn’t catch it.
Even a small copy change needs the right kind of validation.
\n\nI’ve shared the product on Solo, 出海栈, 小众软件, and Indie Hackers. That has given it places to be discovered, but I don’t yet have enough evidence to call any channel a repeatable source of users.
\n\nI’m also learning to separate people who enjoy a development story from people who want the product. Developers may find concurrency handling interesting. A potential user wants to know what they can do, how much effort it takes, and whether their writing stays private.
\n\nThere’s overlap, but a well-read technical post doesn’t prove demand.
\n\nMy next experiments are technical retrospectives like this one, short product demonstrations, and content built around concrete reflection scenarios. Search is another ongoing task: a readable sitemap and a renderable page are necessary pieces, but I still need public content that answers something people actually look for.
\n\nWhat I want to measure is the path after a visit: does someone complete a first ritual, continue to another exploration chapter, or return a few days later? Knowing where that stops should help me choose between improving the entry flow, the content, or the acquisition channel.
\n\nWriting more code is the comfortable option. It gives me a visible result. Asking someone to try the product can end with “I’ll take a look” and nothing else. I’m trying not to mistake the comfort of development for evidence that another feature is needed.
\n\nMystic Journey is still early. I’m looking for a small group of people willing to try it and tell me what feels useful, confusing, or unnecessary.
\n\nThe daily ritual and guided explorations are free; deeper AI readings use credits. If tarot is unfamiliar, you can start with an exploration theme that fits something you’re thinking about.
\n\n\n\nSpecific feedback would help most: where you got stuck, what didn’t make sense, or where you stopped wanting to continue. There’s a feedback form in the app, and comments here are welcome too.
\n\nIf you’ve taken a side project beyond the demo stage, I’d also like to hear how you found your first users who came back.
","score":3},{"source":"https://medium.com/feed/tag/vuejs","sourceHost":"medium.com","title":"Building Accessible Vue Components: A Developer-First Approach","link":"https://medium.com/@guilhermebrunoreis/building-accessible-vue-components-a-developer-first-approach-46a1ae5b0eaa?source=rss------vuejs-5","pubDate":"Thu, 17 Sep 2026 19:25:05 GMT","description":"![](\"https://cdn-images-1.medium.com/max/1536/1*3bodPDf22NatkUHgh6QNGQ.png\")
Practical patterns for making accessibility part of component development before issues reach QA or production.
A rewrite this size wasn't affordable before agents. Here's what porting the Copilot agent runtime to 800,000 lines of production Rust actually took.
\nThe post Migrating the GitHub Copilot runtime to Rust, using Copilot appeared first on The GitHub Blog.
","score":6},{"source":"https://javascriptweekly.com/rss","sourceHost":"javascriptweekly.com","title":"Functional programming jargon, mapped out","link":"https://javascriptweekly.com/issues/802","pubDate":"Tue, 15 Sep 2026 00:00:00 +0000","description":"| \n \n \n
|
If you can write down how you do your work, you can automate it. Here's what I did to support GitHub's APAC marketing team.
\nThe post Marketing ops as code: Automating events from planning to follow-up on GitHub appeared first on The GitHub Blog.
","score":4},{"source":"https://github.blog/feed","sourceHost":"github.blog","title":"GitHub availability report: August 2026","link":"https://github.blog/news-insights/company-news/github-availability-report-august-2026/","pubDate":"Thu, 10 Sep 2026 02:05:17 +0000","description":"In August, we experienced five incidents that resulted in degraded performance across GitHub services.
\nThe post GitHub availability report: August 2026 appeared first on The GitHub Blog.
","score":6},{"source":"https://dev.to/feed/tag/nuxt","sourceHost":"dev.to","title":"Where Laravel Is Heading in 2026: AI, Vue, Nuxt, and Product Development","link":"https://dev.to/kavitasystems/where-laravel-is-heading-in-2026-ai-vue-nuxt-and-product-development-5290","pubDate":"Tue, 08 Sep 2026 09:48:06 +0000","description":"An AI assistant can help generate an interface quickly. Getting that interface ready for real users still involves permissions, validation, background work, deployment, monitoring, and clear feedback when something fails.
\n\nLaravel’s recent updates address more of that journey.
\n\nAcross its May–August 2026 releases and early September engineering posts, a direction emerges: Laravel is connecting development with AI, application infrastructure, and the tools needed to operate a product.
\n\nFrom a design engineering perspective, the interesting question is how this changes the way we build and maintain applications.
\n\nThis article covers official Laravel announcements available on September 7, 2026. The practical recommendations are my interpretation of those changes.
\n\nSeveral tools now support different parts of the development and product lifecycle.
\n\n| Tool | \nWhat it does | \n
|---|---|
| Laravel Boost | \nGives coding agents Laravel knowledge and project context | \n
| Laravel PAO | \nMakes development tool output easier for agents to process | \n
| Laravel AI SDK | \nProvides APIs for AI features inside an application | \n
| Laravel MCP | \nProvides MCP server and client capabilities for connecting tools | \n
For example, PAO produces compact JSON for supported testing and analysis tools and removes unnecessary decoration from Artisan output.
\n\nAn agent can more easily identify a failed assertion, the affected file, or an analysis error. Laravel introduced PAO in May and included it in new applications as a development dependency.
\n\nThe distinction between these tools matters. Boost and PAO improve how we develop applications. The AI SDK and MCP help us build applications that use AI and connected tools.
\n\nA mature application contains decisions that are easy to miss:
\n\nBoost’s convention extraction workflow examines existing code, gathers evidence, and proposes project rules for developer review.
\n\nApproved rules become files in the repository. The team can inspect them, review changes, and maintain them alongside the implementation.
\n\nThe storage approach is deliberately simple: Markdown rules, a generated index, and selective retrieval.
\n\nLaravel’s engineering post explains why a semantic search layer added too much complexity for a small collection of conventions. The authors also acknowledge that controlled evaluation of the alternatives remains future work.
\n\nFor teams working with design systems, this suggests a useful practice: document the decisions an agent needs to preserve.
\n\nFor example:
\n\nThese are examples of rules a team could define. Their value comes from describing the actual project.
\n\nIn July, the Boost team described a shift toward measuring two things:
\n\nPassing an evaluation suite provides a useful baseline, but it tells only part of the story.
\n\nFor a product team, I would extend the review to a few practical questions:
\n\nThese are familiar engineering questions. They become more valuable as generating code becomes faster.
\n\nLaravel Cloud added support for deploying Nuxt and Next.js applications in July.
\n\nA frontend and Laravel backend can share a repository while running as separate Cloud applications. Each application has its own environment variables, domains, and scaling settings.
\n\nMeanwhile, the official Vue starter kit currently combines Vue 3, TypeScript, Inertia 3, and shadcn-vue.
\n\nFor teams using Vue, this leaves two useful architectural options:
\n\n| Architecture | \nWhen I would consider it | \n
|---|---|
| Laravel + Vue + Inertia | \nA dashboard, portal, or SaaS application whose interface closely follows Laravel’s application flow | \n
| Laravel API + Nuxt | \nAn independently developed frontend, a content or commerce experience, or a product serving several API clients | \n
These are starting points for a decision.
\n\nTeam ownership, rendering requirements, deployment needs, and existing code should determine the final choice. Supporting both approaches on one hosting platform makes that choice easier to separate from infrastructure preferences.
\n\nLaravel’s AI SDK supports agents with tools, delegation to subagents, and human approval for selected tool calls.
\n\nIts documentation describes persisting a conversation so an action can pause for approval and resume later.
\n\nConsider a support assistant that prepares a change to a customer’s subscription.
\n\nThe interface needs to explain:
\n\nThe approval screen, progress state, and result history are part of the product’s reliability.
\n\nFor designers and frontend developers, this expands the work beyond a chat interface. We need to design how users understand, control, and recover from automated actions.
\n\nDocument processing, exports, media jobs, and AI tasks can take longer than a normal page request.
\n\nManaged queues on Laravel Cloud run workers separately from application compute and scale them according to queue pressure. The dashboard exposes failed jobs and retry actions.
\n\nThis supports a useful product pattern:
\n\nLaravel also rebuilt Flex scale-to-zero around checkpoint and restore, reporting wake times below 500 milliseconds.
\n\nThat is a platform claim rather than a measurement from my own application. The goal is useful for demos, staging environments, and products with intermittent traffic: reduce the resources running while nothing is happening.
\n\nNightwatch has also expanded its MCP interface to expose performance information alongside exceptions. This gives assistants more evidence when investigating slow routes, queries, and jobs.
\n\nAlongside AI and hosting, Laravel continues to improve the practical work of maintaining applications.
\n\nJune brought bulk job dispatch and support for PostgreSQL transaction poolers.
\n\nThe summer Laracon overview covers additions such as:
\n\nAugust extended semantic and hybrid search in Scout and vector support for MariaDB. It also introduced a read-through filesystem for moving between storage disks, plus more narrowly scoped Cloud API tokens.
\n\nThese changes help with the less visible work behind a product: finding relevant information, managing repeated work, moving data, and limiting automation to the resources it needs.
\n\nThe direction I see is a shorter, more connected path from a product decision to a running application.
\n\nFramework packages, development tools, and hosted services each contribute to that path. They remain separate choices to evaluate against a project’s needs.
\n\nFor a team adopting these capabilities, I would start with one complete workflow:
\n\nThen measure the outcome.
\n\nCan users complete the task? Does the interface explain what happened? Can the team diagnose failures and change the implementation confidently?
\n\nThose answers will tell us how much value the new tools create.
\n\n\n\n\nWhich part would improve your current project most: better context for coding agents, simpler deployment, or AI actions with a clear approval flow?
\n\nFor help building, modernizing, or extending a Laravel application, explore Laravel development services at Kavita Systems.
","score":7},{"source":"https://dev.to/feed/tag/nuxt","sourceHost":"dev.to","title":"Prerendering a multilingual Nuxt game catalog without shipping the database","link":"https://dev.to/mno_tao_236ab4649edf4cf9f/prerendering-a-multilingual-nuxt-game-catalog-without-shipping-the-database-36pf","pubDate":"Sun, 06 Sep 2026 01:00:00 +0000","description":"A game catalog looks like a client-side application: filters, search, cards, detail pages, and playable iframes. It is still a poor reason to ship the complete content database and ask every crawler—or every phone—to reconstruct the page after JavaScript loads.
\n\nI recently localized a Nuxt catalog with 153 games into four languages. The public result is 676 indexable routes, but the architecture has three strict properties:
\n\nHere is how those pieces fit together.
\n\nRelying only on a crawler means an accidentally missing link can remove a page from the static build. The catalog already has a source of truth, so use it to produce the complete route list.
\n\nThe base set contains:
\n\nWith 153 games and eight categories, that is 169 base routes. A locale mapping applies no prefix to English and /id/, /it/, or /pt-br/ to the other languages. The same English slugs remain stable after the prefix.
\n
![](\"https://res.cloudinary.com/cpress/image/upload/w_1280,e_sharpen:60,q_auto/yasnr77llfxhnd7g3ffz.jpg\")
![](\"https://res.cloudinary.com/cpress/image/upload/c_limit,w_480,h_480,q_auto/copm/17105ae7.png\")
![](\"https://res.cloudinary.com/cpress/image/upload/w_1280,e_sharpen:60,q_auto/wwfey07te8tmpqvviapc.jpg\")
169 base routes × 4 locales = 676 indexable routes\nLocalized 404 pages are also prerendered, but they are noindex and do not enter the sitemap.
This list feeds Nitro prerendering and the sitemap generator. The sitemap is not treated as evidence that pages probably exist; a post-build check resolves every <loc> to a generated HTML file.
Game titles, iframe URLs, developers, dates, embed types, and stable slugs are product facts. Translators should not rewrite them.
\n\nDescriptions, objectives, controls, tips, category copy, and legal text are localized. A generation step combines those translations with the factual fields and writes the Markdown documents Nuxt Content will consume during the build.
\n\nFor each non-English locale, the generator expects:
\n\nThat is 165 documents per locale and 495 localized Markdown files in total. Missing keys, extra slugs, duplicate entries, or fact drift are build errors.
\n\nThe key rule is simple: an indexable localized route cannot silently borrow English body content. A visible fallback is useful in application chrome; it is dangerous when it creates a page advertised to search engines as a different language.
\n\nThe catalog can translate its navigation, metadata, controls guide, objectives, and warnings. It does not own every embedded game’s UI.
\n\nThat boundary should be explicit. The page language changes, while the game iframe may remain in English. Trying to imply otherwise creates misleading metadata and support expectations.
\n\nThe language switcher should preserve the current route:
\n
/game/ember-vault/\n/it/game/ember-vault/\n/pt-br/game/ember-vault/\nDo not redirect based on Accept-Language or browser settings. Automatic redirects make URLs unstable for crawlers and surprising for people who intentionally chose another language.
Every page needs a self-referencing canonical and a complete alternate set:
\n\nen;id-ID;it-IT;pt-BR;x-default pointing to English.The document lang, Open Graph locale, visible copy, and Schema inLanguage must agree. The sitemap repeats the same alternates.
This is a good place for a deterministic verifier. For all 676 HTML files, check:
\n\nhtml lang;hreflang entries plus x-default;Counting is surprisingly valuable. If the expected route count is 676 and the verifier saw 675, the build fails before deployment.
\n\nThe full game record contains fields that a grid never needs: iframe URL, long controls, features, developer information, and related-game details. Importing that object into a shared composable can put the entire catalog into a client chunk.
\n\nA build step projects a slim card record containing only fields used by search and grids, such as:
\n
slug, title, description, category, tags,\nthumbnail, embed type, difficulty, updated date, popular\nDetail fields stay server/build-side. The detail route receives one game during prerendering and serializes only what that page needs. Legal and editorial pages do not preload the card catalog merely because they share a layout.
\n\nAdd a leak test with a known detail-only iframe URL. If that marker appears in a shared JavaScript chunk, the split has regressed.
\n\nNuxt Content can ship a SQLite/WASM client for browser-side queries. A fully static catalog does not need it if every content query runs during prerender and the result is hydrated from the page payload.
\n\nThe production build aliases the client database module to a stub that must never execute. Post-build checks then fail if they find:
\n\nThe last item protects more than performance. Runtime replacement can show one description without JavaScript and a shorter, different one with JavaScript, which makes accessibility and indexing unpredictable.
\n\nInternationalization has a real bundle cost. Lazy locale dictionaries help, but only if the application does not preload all languages on every route.
\n\nTrack both the largest chunk and total emitted JavaScript. Also scan locale chunks for markers from more than one language. A budget is not a universal performance score; it is a tripwire against accidental catalog or dictionary duplication.
\n\nThe browser check should visit a localized game page directly, before navigating from English. That catches implementations that work only after a locale bundle has already been loaded.
\n\nA perfectly localized wrapper is still broken if the play button cannot launch its iframe. For a small set of representative self-hosted games, browser checks should:
\n\nFor third-party embeds, record that availability is an external dependency. Do not translate or bundle their binaries as if they were catalog content.
\n\nThe reference implementation discussed here is SonoTap. The transferable pattern is to use static generation as an integrity boundary: routes, translations, metadata, content, and client payloads are all artifacts that a build can count and reject.
","score":5},{"source":"https://github.blog/feed","sourceHost":"github.blog","title":"Project HydraFusion: Frontier quality via multi-model orchestration","link":"https://github.blog/ai-and-ml/github-copilot/project-hydrafusion-frontier-quality-via-multi-model-orchestration/","pubDate":"Fri, 04 Sep 2026 16:04:14 +0000","description":"In controlled offline evaluations, HydraFusion’s selective coding workflows matched or exceeded the evaluated Opus 5 baseline while reducing estimated workflow cost. Now available as a research preview in GitHub Copilot.
\nThe post Project HydraFusion: Frontier quality via multi-model orchestration appeared first on The GitHub Blog.
","score":4},{"source":"https://github.blog/feed","sourceHost":"github.blog","title":"Decoding the new AI lingo: Loops, harnesses, squads, hill climbing… oh my!","link":"https://github.blog/ai-and-ml/decoding-the-new-ai-lingo-loops-harnesses-squads-hill-climbing-oh-my/","pubDate":"Wed, 02 Sep 2026 21:00:00 +0000","description":"From loop engineering to harnesses, squads, and open weights, the GitHub Podcast breaks down the AI terms showing up in developer conversations.
\nThe post Decoding the new AI lingo: Loops, harnesses, squads, hill climbing… oh my! appeared first on The GitHub Blog.
","score":4},{"source":"https://github.blog/feed","sourceHost":"github.blog","title":"How we make AI coding more cost efficient without sacrificing task quality","link":"https://github.blog/ai-and-ml/github-copilot/how-we-make-ai-coding-more-cost-efficient-without-sacrificing-task-quality/","pubDate":"Wed, 02 Sep 2026 18:00:00 +0000","description":"Why shorter outputs can cost more, and how GitHub Copilot reduces wasted work across the complete coding task.
\nThe post How we make AI coding more cost efficient without sacrificing task quality appeared first on The GitHub Blog.
","score":4},{"source":"https://javascriptweekly.com/rss","sourceHost":"javascriptweekly.com","title":"How to fit Minesweeper into 247 bytes","link":"https://javascriptweekly.com/issues/800","pubDate":"Tue, 1 Sep 2026 00:00:00 +0000","description":"| \n \n \n
|
OpenClaw is the fastest-growing project in GitHub history. Peter Steinberger and several maintainers share what they learned in the project's first six months.
\nThe post OpenClaw went viral. Meet the maintainers building and securing it. appeared first on The GitHub Blog.
","score":4}]}![](\"https://res.cloudinary.com/cpress/image/upload/w_1280,e_sharpen:60,q_auto/bx17eefknqp64qnr1fet.jpg\")
![](\"https://res.cloudinary.com/cpress/image/upload/c_limit,w_480,h_480,q_auto/copm/8de3904f.png\")
![](\"https://res.cloudinary.com/cpress/image/upload/w_1280,e_sharpen:60,q_auto/eo9krbjjdoksfuqz7faw.jpg\")