DEV Community

How I got 165 blog posts indexed in 30 days with zero backlinks

CarsonJ — Tue, 11 Aug 2026 18:19:42 +0000

Most SEO guides assume you have a domain authority of 30+, a backlink profile, or a budget for links. I had none of those.\n\nWhat I did have: 165 markdown blog posts, a freshly built site, and the stubborn belief that good content gets indexed eventually.\n\nHere is the exact playbook. No paid tools, no shady link schemes.\n\n## The setup\n\n- Brand new domain (3 months old at the time)\n- Next.js + Cloudflare Pages\n- 6 languages via next-intl\n- 109 free browser-based tools (the actual product)\n- 165 blog posts translated into 6 languages (~990 pages total)\n- Zero backlinks (I was starting from scratch)\n- Zero marketing budget\n\n## Step 1: Make sure Google can find you\n\nBefore any content, you need three things working:\n\n*robots.txt* - explicit allow, no surprises\n*sitemap.xml* - one entry per public URL, lastmod set correctly\n*Search Console* - submit the sitemap, watch for errors\n\nI lost 3 weeks to a trailing slash mismatch (en/tools vs en/tools/). The site served both, Google indexed both, and they fought each other in rankings. Fix: pick one canonical form and 308 redirect the other. Use hreflang tags for languages.\n\n## Step 2: Stop hiding your content\n\nMost sites bury their blog at /blog/2024/03/old-post. Google has to crawl 3 levels deep. Put everything 1-2 clicks from the homepage.\n\nMy structure:\n- /[lang]/tools/tool\n- /[lang]/blog/post\n- /[lang]/workflows (288 work flows)\n\nAll in sitemap, all 1 click from home, all interlinked.\n\n## Step 3: Internal links beat external links\n\nI have zero backlinks. But I have hundreds of internal links.\n\nEvery blog post links to 3-5 related tools. Every tool page links to 2-3 related blog posts. Every category page links to all sub-pages.\n\nThis does two things:\n1. Distributes page rank. A high-traffic blog post can pass authority to tool pages.\n2. Helps Google discover pages faster. New content gets crawled within hours, not weeks.\n\nAfter 30 days: 612/736 pages indexed (83%). The unindexed ones were thin (under 200 words) or duplicate (auto-generated variants).\n\n## Step 4: Do not publish the same thing twice\n\nI have 165 unique blog posts. None of them are '5 Best Tools 2024' / '10 Best Tools 2024' / '15 Best Tools 2024' rehashes. Each post is one specific topic, one specific angle, ~1500 words.\n\nIf I have to say the same thing, I update the old post. I do not write a new one.\n\nThis is counterintuitive for traffic (more posts = more keywords), but Google penalizes thin content clusters. 5 great posts rank better than 50 mediocre ones.\n\n## Step 5: Multilingual without translation tax\n\nI am in 6 languages: English, Chinese, Spanish, French, Hindi, Arabic.\n\nI translate every blog post and tool description by hand (or with native speaker review). No machine-translated filler.\n\nKey: hreflang tags on every page. Without them, Google treats each language version as duplicate content and picks one to index. The others never rank.\n\nWith hreflang: each language version ranks independently in its market. Spanish post ranks in Google.es, Arabic in Google.com.sa, etc.\n\nTraffic from non-English markets is now 40% of total. Would have been 0% without the hreflang setup.\n\n## Step 6: Measure, but do not obsess\n\nI check Search Console once a week. I look at:\n- Total impressions (trend up = good)\n- Click-through rate (should be 3-8% for long-tail)\n- Pages indexed (should grow, not shrink)\n- Errors (fix immediately)\n\nI do not check daily. Daily numbers are noise. Weekly numbers are signal.\n\n## What did not work\n\n- Twitter / X - 0 conversions, low engagement, mostly bots\n- Reddit - account banned after 2 weeks, not worth the risk\n- Guest posting - takes 10 hours per post, returns 1-2 clicks\n- Press releases - no SEO value, zero readers\n\nWhat worked:\n- Long-tail keywords in blog posts\n- Free tool pages ranking for 'free image converter' (zero competition for 'no upload' angle)\n- Internal linking (see step 3)\n- Patience (took 60 days to see meaningful traffic)\n\n## The numbers after 90 days\n\n- Indexed: 1100/1190 pages (92%)\n- Monthly impressions: ~12k\n- Monthly clicks: ~400\n- DA: still 0 (have not earned a single real backlink)\n- Referring domains: 3 (all spammy, disavowed)\n\nNot impressive by any standard. But the curve is exponential, not linear. Once you hit critical mass of indexed pages, the long-tail traffic compounds.\n\n## The 3 things I would do differently\n\n1. Skip Medium / Substack - they all canonicalize to themselves. Your content ranks on their domain, not yours. Build on your own site.\n2. Write less, write better - I killed 30 posts that were under 800 words. The remaining 135 outperform them 5:1.\n3. Ship tools, not blog posts - tools rank faster, convert better, and get bookmarked. Blog posts are the supporting cast.\n\n## If I had to start over with $0\n\n1. Pick a niche. Mine is 'free browser-based tools.'\n2. Build 10 tools that solve 10 real problems. Skip the ones that already exist with strong competitors.\n3. Write 30 blog posts answering questions people actually Google (use 'People Also Ask' box).\n4. Add hreflang for 2 languages max to start (English + your native language).\n5. Wait 90 days. Most people quit at day 30.\n\nThat is it. No tools, no budget, no shortcuts. Just good content + good structure + patience.\n\n---\n\nIf you want to see the site: korelyy.com - 109 free tools, 165 blog posts, 6 languages, zero ads, zero tracking.

MAI-Code-1-Flash Highlights Microsoft’s Lower-Cost Approach to Coding AI

Ali Farhat — Tue, 11 Aug 2026 18:15:31 +0000

Microsoft’s MAI-Code-1-Flash is the more concrete story behind recent claims of a cheaper, more efficient coding model. Announced at Build 2026, the model is a 5B active-parameter coding model designed for real developer workflows and integrated with GitHub Copilot and Visual Studio Code. Microsoft’s published materials emphasize lower latency, lower token use, and stronger code quality, although they do not document a separately released update with the exact 25% efficiency or cost figures circulating in recent discussion.

The key point for developers and engineering leaders is that Microsoft is treating coding-model efficiency as a product capability, not simply a benchmark exercise. MAI-Code-1-Flash uses an adaptive thinking approach and is deployed through the GitHub Copilot harness and VS Code integration. That makes its performance in everyday coding tasks, including its token consumption, directly relevant to teams using AI assistance at scale.

What Microsoft has documented about MAI-Code-1-Flash

Microsoft introduced MAI-Code-1-Flash on June 2, 2026 as part of a family of seven MAI models. According to Microsoft’s MAI-Code-1-Flash launch announcement, the model was trained from scratch on clean enterprise data and without third-party distillation. Microsoft positions it as an inference-efficient coding model intended to deliver strong software-engineering performance at a lower cost profile than larger alternatives.

The company has specifically compared its intended economics with Haiku, saying MAI-Code-1-Flash is designed to be cheaper while maintaining strong SWE-Bench results. That is a positioning claim rather than a published price card, and the supplied materials do not provide standalone API pricing, a public API rollout, or a detailed per-token rate for the model.

Microsoft’s July 29 VS Code production-results post adds evidence from deployment. It says MAI-Code-1-Flash achieved higher code quality and lower token usage in real developer workflows than other lightweight coding models. The official material also reports up to 60% fewer tokens on SWE-Bench Verified, with the associated cost benefit coming from token efficiency. On SWE-Bench Pro, Microsoft cites a 16-point lead in the referenced comparison.

Area	What official materials document	What remains unspecified
Model design	5B active parameters, adaptive thinking, trained from scratch on clean enterprise data	Detailed architecture beyond the published description
Developer delivery	Rollout to Copilot users in VS Code through the GitHub Copilot harness	A standalone public API availability announcement
Efficiency evidence	Up to 60% fewer tokens on SWE-Bench Verified and lower token usage in production workflows	A documented 25% revision in efficiency or cost versus the June launch
Cost positioning	Microsoft intends the model to be cheaper than Haiku through inference efficiency	Published model-specific pricing or a fixed fourfold reduction

Why token efficiency matters in developer tools

Token use affects both response time and the operating cost of AI coding assistance. A model that reaches a useful answer with fewer tokens can reduce the computational work required for a task. In a Copilot-style environment, that can matter across code generation, debugging, refactoring, and multi-step engineering requests, where many individual interactions accumulate across a development organization.

The model’s stated focus on real-world workflows is also significant. Coding benchmarks are useful indicators, but developer tools must work inside editors, repositories, and iterative human review cycles. Microsoft’s emphasis on production outcomes suggests that it is evaluating MAI-Code-1-Flash in the context where a lightweight model must be useful enough to earn its place alongside larger, potentially more expensive models.

Availability and the broader MAI direction

The documented rollout centers on GitHub Copilot and Visual Studio Code. That gives Microsoft a controlled distribution path: the company can deploy and assess the model within a widely used developer-assistance experience rather than relying only on a separate developer endpoint.

MAI-Code-1-Flash also fits Microsoft’s broader MAI strategy, which includes Frontier Tuning and work with Mayo Clinic. Microsoft has described that strategy as building a system that can be adapted to users’ workflows across surfaces such as Excel and Copilot Chat. For the coding model, the practical implication is a focus on tailoring AI behavior to workflow context while managing inference efficiency.

For now, teams should separate the official record from more precise performance claims that may emerge around subsequent iterations. The model launch and its VS Code production results are documented. A newly announced model revision with exact 25% improvement and cost-reduction figures is not established in the supplied official material.

For businesses standardizing AI-assisted development, model efficiency affects both engineering experience and long-term spend. Scalevise can help assess where coding assistants fit into your delivery process, identify high-value automation opportunities, and design governance around real usage rather than benchmark headlines. A focused AI workflow automation consultation can turn tool experimentation into a measurable implementation plan. Discuss an AI automation project with Scalevise.

Frequently Asked Questions

What is MAI-Code-1-Flash?

MAI-Code-1-Flash is Microsoft’s 5B active-parameter coding model. It is designed for inference-efficient developer workflows and is integrated with GitHub Copilot and Visual Studio Code.

Where is MAI-Code-1-Flash available?

Microsoft’s June 2026 materials state that the model is rolling out to Copilot users in Visual Studio Code. The supplied research does not document a standalone public API launch.

What efficiency results has Microsoft published?

Microsoft reports up to 60% fewer tokens on SWE-Bench Verified. Its VS Code production-results material also describes higher code quality and lower token usage than other lightweight coding models in real developer workflows.

Has Microsoft published a 25% cost reduction for a new MAI-Code-1-Flash version?

The supplied official materials do not document an update with that exact figure. They attribute lower cost potential to token efficiency and position the model as intended to be cheaper than Haiku.

Conclusion

MAI-Code-1-Flash gives Microsoft a lightweight, workflow-oriented coding model inside GitHub Copilot and VS Code. Its documented results make token efficiency central to the model’s value proposition, while the exact claims attached to a possible newer iteration remain outside the supplied official record. The most meaningful development is Microsoft’s effort to pair coding quality with lower-cost inference in tools developers already use.

I Made an AI Project Manager PMI-Aligned—Without Turning It Into Bureaucracy

yysun — Tue, 11 Aug 2026 18:12:41 +0000

We’ve started working with AI like a colleague, not just using it as a tool.

We ask it to plan work, coordinate people, surface risks, and tell us what should happen next. But an AI colleague with that much responsibility needs more than intelligence. It needs professional discipline.

That is why I made Project Manager PMBOK 7 principles-aligned through documented tailoring: so an AI PM can operate with autonomy without confusing confidence for evidence—or rigor for bureaucracy.

This is not a claim of PMI certification. It is a concrete design decision about how the system decides which management disciplines apply, which do not, and how those decisions stay honest.

The employee model changes the product boundary

A chatbot attached to a task board still leaves the user operating the project-management software.

You move cards. You update fields. You repair dependencies. You rebuild the report. The chat box may make each operation easier, but you still translate project reality into tool operations.

An AI PM employee should reverse that relationship.

You should be able to say:

The vendor API is delayed until September 15. The launch date cannot move. Show me the credible options.

That statement may affect dependencies, schedules, risks, scope, ownership, evidence, and the next decision. The AI PM should trace those consequences together and maintain the working plan.

That requires autonomy.

It also creates risk.

Autonomy without discipline creates confident chaos

A language model can produce a plausible plan even when ownership is missing, dates are unsupported, and completion has no evidence.

The output may look polished while the project underneath it is incoherent.

The answer is not to bury every project under a heavyweight process. That would destroy the reason to use an AI PM in the first place.

The answer is to make process a deliberate, inspectable decision.

That is where PMI tailoring becomes useful.

“PMI aligned” needs a precise meaning

Project Manager is aligned with PMBOK 7 principles through documented tailoring.

PMBOK 7 makes tailoring central: the management approach should fit the project rather than forcing every project through the same machinery.

For a concrete declaration, Project Manager uses the ten familiar PMBOK 6 knowledge areas. Each area must be recorded as one of two things:

Applied
Tailored out, with a rationale

A discipline cannot disappear silently.

That distinction matters. A small internal project may genuinely have no procurement activity or dedicated cost budget. Omitting those areas can be correct. Omitting them because nobody considered them is not the same thing.

A tailoring declaration might look conceptually like this:

Area	Decision	Rationale
Integration	Applied	Changes must propagate across the plan
Scope	Applied	Success criteria and boundaries must remain explicit
Risk	Applied	Launch depends on an external vendor
Cost	Tailored out	Work is absorbed by the standing team
Procurement	Tailored out	No external purchasing is involved

The useful part is not the table. It is the fact that every omission becomes a recorded decision.

Tailoring is not checkbox theatre

A declaration is worthless if the system lets the project contradict it.

Project Manager therefore fails validation when the project says an area is tailored out but configures the corresponding management structure.

For example:

Tailor out risk management, then add a risk register: validation fails.
Tailor out stakeholder management, then add a stakeholder register: validation fails.
Claim an area is applied, then report missing information as zero or “on track”: not allowed.

The declaration cannot become fiction.

This also changes reporting. A tailored-out area is reported as tailored out with its rationale. It is never silently omitted, represented as zero, or painted green.

“Cost: not tracked—no project budget; work is absorbed by the standing team” is honest.

“Cost: $0” may be completely false.

The system expands only when the project needs it

The smallest Project Manager project still has three files:

PROJECT.md
TASKS.md
STATUS.md

That is enough to define the outcome, organize the work, and derive current status.

Additional management modules appear only when they answer a real operating need:

assumptions
issues
risks
stakeholders
decisions
milestones
lessons learned
closure records
traceability
source and change history

This is the practical value of tailoring: rigor without mandatory ceremony.

A project can stay small without looking negligent. A controlled project can add the structures it needs without changing the underlying operating model.

Evidence is the counterweight to agent confidence

PMI alignment addresses management discipline. Evidence addresses execution truth.

An AI agent saying “done” is not proof that a task met its acceptance criteria.

Project Manager separates ordinary presentation from a stricter internal lifecycle:

planned  ready  in_progress  implemented  verification  verified  done

Completion must be supported by evidence mapped to the task’s acceptance criteria.

A closed issue is not automatically proof.

A commit is not automatically proof.

A file existing is not automatically proof.

Confident prose is definitely not proof.

The AI PM can coordinate people, agents, external systems, and software workflows, but they meet at the same boundary: a task contract defines the expected result, and an evidence manifest proves what happened.

That is how autonomy stays accountable.

Unknown must remain unknown

Project-management software is good at displaying false precision:

confident dates without a real schedule
green status without acceptance evidence
percentage complete without a defensible calculation
zero cost when cost was never tracked

An AI PM makes this problem worse if it treats every missing fact as an invitation to generate one.

Project Manager instead keeps unknown information explicit. It should challenge:

a target date with no schedule evidence
completion with no acceptance evidence
work marked ready while a dependency is unfinished
a plan that does not cover its success criteria
a combination of scope, capacity, and date that cannot all hold

A useful project manager exposes the conflict. It does not decorate it.

What is deliberately not implemented

“PMI aligned” should not become a license to imply capabilities that do not exist.

Project Manager does not currently implement:

cost accounting
Earned Value Management
critical-path scheduling

If a project needs those disciplines, they must be tailored out with a rationale or managed in another system with that boundary recorded.

That limitation is part of the design, not an embarrassing footnote.

A trustworthy AI PM should state where its authority ends.

The larger idea

The interesting shift is not from manual task management to AI-assisted task management.

It is from software you operate to an AI employee that maintains a coherent project with you.

You provide the outcome, constraints, evidence, and decisions that require human authority.

The AI PM keeps the plan aligned with reality.

PMI-aligned tailoring gives that employee discipline without forcing every project into the same process. Evidence-backed completion keeps its confidence from becoming project truth.

That combination—autonomy, tailoring, and evidence—is what makes an AI project manager credible.

Try it

Project Manager is open source:

github.com/yysun/project-manager

In your AI agent app, ask:

Install the project-manager skill from yysun/project-manager.

Then brief it like a colleague:

We need to launch the new website by October 15 without interrupting the current site. Rollback must be proven before launch. Establish the project, challenge anything vague, and surface the decisions I need to make.

Do not start with the board configuration.

Start with reality.

47 free AI tools that live in your browser (2026)

CarsonJ — Tue, 11 Aug 2026 18:10:12 +0000

I built 47 small AI helpers that run entirely in your browser. No signup. No upload. No tracking. They live at Korelyy ? a tool garden I've been curating for the past few months.

Here's why I went this route, and what's in there.

Why browser-only?

Every AI tool I tried wanted the same three things: my email, my files, and my patience. So I started porting the ones I actually use to plain HTML + vanilla JS. They run offline, they never phone home, and they cost me nothing to host.

What's in the box

Writing & text (8 tools)

Character counter that shows platform limits (X / LinkedIn / Meta)
Case converter (Title / sentence / camelCase)
Whitespace cleaner
Markdown previewer
Lorem generator
Typographic quotes fixer
Diff checker (side-by-side)
Text statistics (readability + grade level)

Image & files (11 tools)

Image converter (PNG / JPG / WebP)
Image to PDF
PDF to images
Image resizer (aspect-ratio aware)
Image cropper
EXIF stripper
SVG optimizer
Favicon generator (16/32/180/192/512)
QR code generator
Barcode generator
HEIC to JPG

Calculators & life (12 tools)

Life weeks (how many Saturdays left)
Life progress bar
Sleep cycle calculator
Tip calculator
Loan calculator
Compound interest
Age in days
Date diff
Working days calculator
BMI
Calorie estimator
Random picker

Dev helpers (9 tools)

JSON formatter / validator
JWT decoder
UUID generator
Hash (MD5/SHA-1/SHA-256)
Base64 encoder/decoder
URL encoder
Color picker (with contrast checker)
CSS unit converter
HTML entity encoder

AI / productivity (7 tools)

Emoji mixer (combine any two)
Tone rewriter (formal / casual / friendly)
Meeting agenda template
Standup notes generator
Daily planner
Pomodoro timer
Habit tracker

Total: 47.

How they're built

100% client-side. The server only ships static files.
No analytics, no cookies, no third-party calls.
Most are under 300 lines of vanilla JS.

A note on "free"

There's no catch, no upsell, no "premium" tier hidden behind a paywall. The whole point was building things I would use myself. If a tool saves you five minutes a week, that's the deal.

Try it

Browse the full collection at korelyy.com/en. Available in 6 languages: English, ??, Espa?ol, Fran?ais, ??????, and ???????.

If a tool is missing or broken, drop me a line. I'm shipping new ones every week.

Building AI-Powered Flutter Apps with Gemini

vmodal_ai — Tue, 11 Aug 2026 18:02:59 +0000

Building AI-Powered Flutter Apps with Gemini

Generative AI can be integrated into Flutter applications for chat, summarization, classification, content generation, document processing, and intelligent assistants.

A production application should avoid putting sensitive API credentials directly in the mobile application.

A safer architecture is:

Flutter App
    |
    | HTTPS
    v
Backend API
    |
    v
Gemini API
    |
    v
AI Response

Why use a backend?

Embedding a production AI API key directly in an APK makes it possible for attackers to extract the key.

Instead:

Flutter -> FastAPI/Node/Laravel -> Gemini

The backend can implement:

authentication
rate limiting
prompt templates
logging
usage limits
response validation

Step 1: Create the Flutter UI

A simple chat screen can contain:

final controller = TextEditingController();

TextField(
  controller: controller,
  decoration: const InputDecoration(
    hintText: 'Ask something...',
  ),
)

Send the message through a repository:

class AiRepository {
  Future<String> generate(String prompt) async {
    // Call your backend here.
    throw UnimplementedError();
  }
}

Step 2: Define a clean architecture

A scalable Flutter AI application can use:

Presentation
    |
BLoC / Cubit
    |
AI Repository
    |
API Client
    |
Backend
    |
Gemini

This makes it possible to replace Gemini later without rewriting the UI.

Step 3: Backend example with FastAPI

Install dependencies:

pip install fastapi uvicorn google-genai

Example:

import os

from fastapi import FastAPI
from pydantic import BaseModel
from google import genai

app = FastAPI()

client = genai.Client(
    api_key=os.environ["GEMINI_API_KEY"]
)

class ChatRequest(BaseModel):
    message: str

@app.post("/chat")
async def chat(request: ChatRequest):
    response = client.models.generate_content(
        model="gemini-2.5-flash",
        contents=request.message,
    )

    return {"response": response.text}

Keep the API key in an environment variable:

export GEMINI_API_KEY="your-key"

Never commit it to Git.

Step 4: Call the backend from Flutter

Using the http package:

import 'dart:convert';
import 'package:http/http.dart' as http;

class AiApi {
  final String baseUrl;

  AiApi(this.baseUrl);

  Future<String> chat(String message) async {
    final response = await http.post(
      Uri.parse('$baseUrl/chat'),
      headers: {
        'Content-Type': 'application/json',
      },
      body: jsonEncode({
        'message': message,
      }),
    );

    if (response.statusCode != 200) {
      throw Exception('AI request failed');
    }

    final data = jsonDecode(response.body);

    return data['response'] as String;
  }
}

Step 5: Add loading and error states

AI requests are asynchronous, so explicitly represent:

Idle
  ↓
Loading
  ↓
Success

or

Loading
  ↓
Failure

With BLoC:

sealed class AiState {}

class AiInitial extends AiState {}

class AiLoading extends AiState {}

class AiSuccess extends AiState {
  final String response;

  AiSuccess(this.response);
}

class AiFailure extends AiState {
  final String message;

  AiFailure(this.message);
}

Prompt engineering

Instead of:

Explain this.

Use structured instructions:

You are an assistant for a Flutter developer.

Task:
Explain the following Dart error.

Requirements:
1. Identify the root cause.
2. Provide corrected code.
3. Keep the explanation concise.

Error:
{{error}}

Structured prompts make application behavior more predictable.

Streaming responses

For chat applications, streaming can improve perceived responsiveness:

User message
     |
     v
Backend
     |
     +---- token
     +---- token
     +---- token
     +---- token
     |
Flutter renders progressively

Consider Server-Sent Events or WebSockets depending on your backend architecture.

Security checklist

Never expose:

Gemini API keys
database credentials
private backend secrets

Add:

authentication
request validation
rate limiting
logging
abuse protection

Conclusion

Flutter is an excellent client platform for AI applications, but a maintainable architecture separates the UI from the AI provider. A backend gives you control over security, prompts, model selection, cost, and business logic.

Useful Links

SDK Flutter: https://github.com/v-modal/vmodal_sdk_flutter

SDK Android: https://github.com/v-modal/vmodal_sdk_android

Discord: https://discord.gg/K72z28KUx

My Pest test passed because I added a helpful failure message

Michael Yousrie — Tue, 11 Aug 2026 18:02:39 +0000

I write marketing copy about my own products and I have a bad habit of leaving claims in it that stop being true. Prices change, a feature moves tier, and the blog post from March keeps happily saying the old thing. So I wrote a test that reads the published posts and asserts the dead claims are gone.

expect($post)->not->toContain('$29/mo', 'pricing changed in June, this post is stale');

Green. Every one of them green. The string $29/mo was still sitting in the post.

What that second argument actually does

Here is the signature, straight out of vendor/pestphp/pest/src/Mixins/Expectation.php:

public function toContain(mixed ...$needles): self
{
    foreach ($needles as $needle) {
        if (is_string($this->value)) {
            Assert::assertStringContainsString((string) $needle, $this->value);
        } else {
            if (! is_iterable($this->value)) {
                InvalidExpectationValue::expected('iterable');
            }
            Assert::assertContains($needle, $this->value);
        }
    }

    return $this;
}

It is variadic. My careful explanatory message was never a message. It was needle number two.

The positive expectation is therefore a conjunction: contains A and contains B. Which means the negation is "missing at least one of them", and my sentence about June pricing was guaranteed to be missing.

How `not` gets there

Pest does not implement a separate negative assertion. OppositeExpectation::__call runs the positive one and catches the failure:

public function __call(string $name, array $arguments): Expectation
{
    try {
        $this->original->{$name}(...$arguments);
    } catch (ExpectationFailedException|AssertionFailedError) {
        return $this->original;      // positive failed, so `not` succeeds
    }

    $this->throwExpectationFailedException($name, $arguments);
}

So follow my call through. The loop checks $29/mo, finds it, passes. Then it checks pricing changed in June, this post is stale, does not find it, throws. That throw is caught, and not reports success.

The first needle was checked. The result was thrown away.

Why this one is so easy to walk into

I counted the public methods on that mixin. There are 68 expectations. 66 of them take a real message parameter.

public function toBe(mixed $expected, string $message = ''): self
public function toBeFalse(string $message = ''): self
public function toStartWith(string $expected, string $message = ''): self

Two do not: toContain and toContainEqual.

toStartWith is defined forty lines below toContain in the same file, and it takes a message. So the habit is correct 66 times out of 68 and you are not misremembering the library, you are remembering the other 97% of it. At the call site a variadic parameter and an optional trailing string are the same keystrokes. Nothing about ('needle', 'my message') looks different from ('needle', 'other needle').

The four cases, run

Pest 4.4.1 on PHP 8.4.13, value is 'hello world':

assertion	result
`not->toContain('zzz', 'qqq')`	passes, correctly
`not->toContain('hello', 'qqq')`	passes, and 'hello' is right there
`not->toContain('qqq', 'hello')`	passes
`not->toContain('hello')`	fails, correctly

Only the single-needle form does what you read it as doing. Add anything after it and the assertion turns into a coin flip you always win.

What I do now

For the check I actually wanted:

expect(str_contains($post, '$29/mo'))->toBeFalse('pricing changed in June, this post is stale');

toBeFalse has a real $message, so the sentence lands where I meant it to and the assertion is about one thing.

The wider habit I picked up from this: if an assertion is load-bearing, make it fail once on purpose before you trust it. I had written a test specifically to catch a stale claim, the stale claim was present, and the test was green. Deleting the second argument turned it red immediately. That took ten seconds and I had not done it, because the test was passing and passing tests do not feel like they need investigating.

That is the actual failure. Not the variadic signature, which is documented and reasonable. It is that a green test reads as evidence, and a test that cannot fail is green in exactly the same shade as a test that just did its job.

Flutter Platform Channels: Calling Kotlin from Dart

vmodal_ai — Tue, 11 Aug 2026 18:02:38 +0000

Flutter Platform Channels: Calling Kotlin from Dart

Flutter gives you a single codebase for Android and iOS, but sometimes you need functionality that is specific to the native platform. This is where Platform Channels become useful.

In this tutorial, we will build a simple Flutter-to-Kotlin bridge using MethodChannel.

What are Platform Channels?

A platform channel allows Dart code to communicate with native Android or iOS code.

Flutter / Dart
      |
      | MethodChannel
      v
Android / Kotlin
      |
      v
Native API

Flutter provides:

MethodChannel — request/response calls
EventChannel — continuous streams of events
BasicMessageChannel — asynchronous messages

For calling a Kotlin function and receiving a result, MethodChannel is usually the best choice.

Step 1: Create the Flutter project

flutter create platform_channel_demo
cd platform_channel_demo

Step 2: Create the Dart platform channel

Create lib/native_service.dart:

import 'package:flutter/services.dart';

class NativeService {
  static const MethodChannel _channel =
      MethodChannel('com.example.platform/native');

  static Future<String> getPlatformMessage() async {
    final result = await _channel.invokeMethod<String>(
      'getPlatformMessage',
    );

    return result ?? 'No response';
  }
}

The channel name must match the channel name used by Kotlin.

Step 3: Call Kotlin from MainActivity

Open:

android/app/src/main/kotlin/.../MainActivity.kt

Use:

package com.example.platform_channel_demo

import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.MethodChannel

class MainActivity : FlutterActivity() {

    private val CHANNEL = "com.example.platform/native"

    override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)

        MethodChannel(
            flutterEngine.dartExecutor.binaryMessenger,
            CHANNEL
        ).setMethodCallHandler { call, result ->

            when (call.method) {
                "getPlatformMessage" -> {
                    result.success("Hello from Kotlin!")
                }

                else -> {
                    result.notImplemented()
                }
            }
        }
    }
}

Step 4: Use it from Flutter

import 'package:flutter/material.dart';
import 'package:flutter/services.dart';
import 'native_service.dart';

class HomePage extends StatefulWidget {
  const HomePage({super.key});

  @override
  State<HomePage> createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  String message = 'Waiting...';

  Future<void> loadMessage() async {
    try {
      final value = await NativeService.getPlatformMessage();

      if (!mounted) return;

      setState(() {
        message = value;
      });
    } on PlatformException catch (e) {
      if (!mounted) return;

      setState(() {
        message = 'Native error: ${e.message}';
      });
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Platform Channel')),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Text(message),
            const SizedBox(height: 20),
            ElevatedButton(
              onPressed: loadMessage,
              child: const Text('Call Kotlin'),
            ),
          ],
        ),
      ),
    );
  }
}

Passing arguments

Dart:

final result = await _channel.invokeMethod(
  'greet',
  {'name': 'Nauman'},
);

Kotlin:

"greet" -> {
    val name = call.argument<String>("name") ?: "User"
    result.success("Hello, $name!")
}

Returning structured data

Kotlin can return maps:

result.success(
    mapOf(
        "platform" to "Android",
        "version" to android.os.Build.VERSION.RELEASE
    )
)

Dart:

final Map<dynamic, dynamic> data =
    await _channel.invokeMethod('deviceInfo');

print(data['platform']);
print(data['version']);

Error handling

Native code should return meaningful errors:

result.error(
    "DEVICE_ERROR",
    "Unable to access device information",
    null
)

Dart:

try {
  await NativeService.getPlatformMessage();
} on PlatformException catch (e) {
  debugPrint(e.code);
  debugPrint(e.message);
}

Production recommendations

Avoid scattering MethodChannel calls throughout widgets. A cleaner architecture is:

UI
 |
BLoC / ViewModel
 |
Repository
 |
NativeService
 |
MethodChannel
 |
Kotlin

This keeps platform-specific code isolated and testable.

Common mistakes

Channel names do not match

These must be identical:

MethodChannel('com.example.platform/native')

and:

private val CHANNEL = "com.example.platform/native"

Calling native code directly from many widgets

Create a service or repository layer instead.

Blocking the UI thread

Native code should not perform long-running work on the Android main thread.

Conclusion

Platform Channels are one of Flutter's most useful escape hatches when you need native Android functionality. A clean MethodChannel abstraction lets you combine Flutter's UI productivity with Kotlin's native APIs.

Useful Links

SDK Flutter: https://github.com/v-modal/vmodal_sdk_flutter

SDK Android: https://github.com/v-modal/vmodal_sdk_android

Discord: https://discord.gg/K72z28KUx

What Is Technical Documentation, and What Should It Include?

Ninad Pathak — Tue, 11 Aug 2026 18:02:28 +0000

Originally published at https://ninadpathak.com/articles/what-is-technical-documentation-and-what-should-it-include/.

Technical documentation is the material that helps someone understand, use, integrate with, or safely operate a system. It works when a reader can take the next step without guessing.

Think of it as a route through a product. A tutorial gets someone moving, reference answers an exact question, explanation gives a decision context, and troubleshooting helps when the route breaks.

What technical documentation should include

Start with the reader task, not a list of page types. A developer evaluating a product needs different information from someone sending a first API request or investigating an error.

Reader task	Document that owns it	What must be visible	What shows it is enough
Decide whether the product fits	Orientation or README	Scope, non-scope, supported use cases, and a starting link	The reader can name the first relevant path
Complete a first integration	Quickstart or tutorial	Prerequisites, one supported path, expected output, and a failure link	The reader reaches a recognizable result
Understand a system choice	Explanation	Terms, model, constraints, and links to task pages	The reader can explain the choice before implementing it
Change an existing behavior	How-to guide	Starting state, procedure, success state, and recovery boundary	The reader can perform the change safely
Look up an exact question	Reference	Names, types, defaults, constraints, and exceptions	The reader can find the answer without inference
Diagnose a failure	Troubleshooting	Symptom, diagnostic check, cause, recovery, and escalation boundary	The reader can choose the next safe action
Respond to a product change	Release note or migration guide	Impact, required action, version or date, and a migration path	The reader can decide whether action is required

The idea is, one page should not teach a beginner, document every field, explain the architecture, and debug production failures. Split those jobs so each page can answer its question completely.

The Diátaxis framework separates tutorials, how-to guides, reference, and explanation for the same reason. The names help, but the reader task decides whether a page belongs in one category or another.

Build the smallest package that lets someone succeed

A small team does not need seven finished document types before launch. It needs enough material for the first reader to understand the product, finish one supported task, and locate the stable details or recovery guidance that task depends on.

For an API, that often means an orientation page, a quickstart, and reference for the endpoint or SDK used in that quickstart. Add troubleshooting when a failed setup has a meaningful diagnostic path, then add release material when product changes can affect an existing integration.

For a CLI, orientation should explain the tool’s job and supported environments. The quickstart should produce one visible command result, while reference owns commands, flags, exit behavior, and configuration.

An internal platform may need a different starting package. Access, a supported setup path, ownership, and the operating rules that change a team’s next action can matter before a public-style product portal.

Use the internal vs. external documentation decision when the same subject needs both private operating context and a public task-focused treatment.

Google’s technical writing guidance recommends defining scope, non-scope, and audience before expanding a draft. That decision keeps a page from collecting unrelated jobs as it grows.

Give each document a boundary

An orientation page helps a reader decide where to begin. It should answer what the product does, who it is for, what it does not cover, and where the first supported task starts.

A quickstart proves one supported path. It should link to reference when exact options matter and to troubleshooting when a failure would block the first result.

An explanation page gives a model for a design choice. It should make the next task easier without forcing the reader to learn every concept before they can do useful work.

A how-to guide changes one behavior from a known starting state. Keep details that remain stable across many tasks in reference, and keep recurring failures in troubleshooting.

Reference owns the public API surface. Google’s API reference guidance calls out methods, parameters, returns, and exceptions because implementation depends on exact behavior rather than narrative approximation.

Troubleshooting starts from a recognizable symptom and gives a diagnostic check, likely cause, safe recovery, and escalation boundary. A generic support link cannot tell someone whether a retry is safe.

Release notes explain changed behavior and required action. They should link to the canonical guide or migration page instead of repeating every instruction.

Make coverage inspectable before writing prose

A document list can hide missing ownership. I ran a small documentation deliverables manifest for a webhook API example so every planned page has one reader task, success signal, owner, review trigger, and deferral condition.

.venv/bin/python static/templates/validate_documentation_deliverables.py

The validator passed with seven owned reader tasks. That result does not tell you whether every paragraph is good, but it does expose a missing task owner before a repository fills with overlapping pages.

Documentation deliverables manifest validation

<img src="/static/images/articles/what-is-technical-documentation-and-what-should-it-include/documentation-deliverables-manifest.png?v=0c2f9fe6" alt="Terminal output showing a documentation deliverables manifest with seven owned reader tasks passed validation">

The validator checks each planned deliverable for a reader task, completion signal, owner, update trigger, and deferral condition.

Use this kind of check before writing a documentation site from scratch. It is planning evidence, not a replacement for task testing, source checks, or editorial review.

Assign an owner and an update trigger

A review date alone does not keep documentation current. Give each deliverable an owner and a product change that requires review, such as a schema change, permission change, new release behavior, support issue, or incident.

GitLab’s documentation guidance treats documentation as maintained product material for configuring, using, and troubleshooting a system. Update the page when product behavior makes its existing instructions unsafe or incomplete.

A useful review trigger connects the document to the change that can invalidate it. A schema change should prompt reference review, a revised onboarding flow should prompt quickstart review, and a recurring failure should prompt troubleshooting work.

Use a technical documentation template when you are ready to turn these decisions into a repository. Then test whether a page helps someone finish a task before calling it complete.

Use the documentation review checklist before publication. If duplicate or stale answers are the problem, start by organizing documentation that has drifted instead of adding another page.

DDD no seu CRUD é canhão pra matar mosquito

Denis Augusto — Tue, 11 Aug 2026 18:01:57 +0000

Sete arquivos pra salvar um cadastro

Peguei um projeto uma vez pra fazer uma alteração pequena: adicionar o campo "telefone secundário" no cadastro de cliente. Coisa de dez minutos, né?

Uma hora e meia depois eu tinha mexido em: a entidade Cliente, o value object Telefone, o DTO de entrada, o mapper que traduz DTO pra entidade, a interface do repositório, a implementação Eloquent do repositório, o use case AtualizarClienteUseCase, e o request do controller.

Oito arquivos. Pra um campo de texto que vai direto pra uma coluna varchar.

O sistema não fazia nada de mirabolante com esse cliente. Cadastrava, listava, editava, apagava. Um CRUD. Mas estava vestido com o terno de um sistema bancário.

Já pegou um projeto assim? Ou — pergunta mais desconfortável — já escreveu um?

O que parece sofisticação e é só cerimônia

Olha o caminho que um POST /clientes percorria naquele projeto:

// 1. Controller recebe e converte pra DTO
$dto = new CriarClienteDTO(
    nome: $request->nome,
    email: $request->email,
    telefone: $request->telefone,
);

// 2. Use case recebe o DTO
$useCase->executar($dto);

// 3. Dentro do use case: DTO vira entidade de domínio
$cliente = new ClienteEntity(
    nome: new Nome($dto->nome),
    email: new Email($dto->email),
    telefone: new Telefone($dto->telefone),
);

// 4. Repositório recebe a entidade
$this->repositorio->salvar($cliente);

// 5. Dentro do repositório: entidade vira Model
$model = new ClienteModel();
$model->nome = $cliente->nome->valor();
$model->email = $cliente->email->valor();
$model->telefone = $cliente->telefone->valor();
$model->save();

// 6. E aí volta tudo, agora no sentido contrário 🙃

Cinco traduções do mesmo dado. Nome vira Nome, Nome vira string de novo, string vira coluna.

Agora a pergunta honesta: qual bug isso evitou? Qual regra de negócio ficou protegida? Nesse projeto, nenhuma. O ClienteEntity era um saco de propriedades sem nenhum comportamento — exatamente o que a gente acusa de "modelo anêmico", só que espalhado em quatro camadas.

DDD nunca foi sobre pastas

Aqui mora a confusão. A maior parte do que a galera chama de DDD é a parte tática: entidade, value object, agregado, repositório, use case. É a parte fácil de copiar, porque é estrutura de pasta.

Só que o DDD é sobre a parte estratégica: entender o negócio a fundo, conversar com quem trabalha nele, descobrir que "pedido" pro pessoal do estoque não é a mesma coisa que "pedido" pro financeiro, e desenhar fronteiras a partir disso. Linguagem ubíqua, contextos delimitados.

A estrutura de pastas é consequência disso. Não substituto.

Quando você copia só as pastas, o que sobra é o custo — mais arquivos, mais indireção, mais tempo pra qualquer mudança — sem o benefício, que seria um código que fala a língua do negócio.

A régua: complexidade de dado ou complexidade de regra?

A pergunta que eu faço hoje antes de montar qualquer camada:

Esse dado tem regra ou só tem formulário?

Se o fluxo é "recebe do form, valida formato, salva no banco, mostra numa listagem", isso é complexidade de dado. Laravel já resolve isso lindamente com Form Request, Eloquent e Resource. Adicionar camada aí só aumenta a distância entre você e o varchar.

Agora, se o fluxo é "recebe a solicitação, verifica se o cliente tem limite, calcula juros conforme a modalidade, aplica desconto de fidelidade, agenda a cobrança e emite o título" — aí é complexidade de regra. É aqui que separar as coisas te salva, porque a regra vive mais tempo que o framework e muda por motivos diferentes.

E o ponto que quase ninguém fala: os dois convivem no mesmo projeto. Não precisa escolher.

Como fica na prática

O CRUD continua CRUD. Sem culpa nenhuma:

class ClienteController extends Controller
{
    public function store(StoreClienteRequest $request)
    {
        $cliente = Cliente::create($request->validated());

        return new ClienteResource($cliente);
    }
}

Três linhas. Todo mundo entende, inclusive o dev que entrar no time semana que vem.

O que tem regra ganha uma Action: o caminho do meio que resolve 90% dos casos.

final class AprovarEmprestimo
{
    public function __invoke(Emprestimo $emprestimo, User $analista): void
    {
        // aqui mora a regra, isolada e testável, sem quatro camadas
    }
}

E as peças táticas você usa avulso, onde valem a pena. Value Object pra CPF e Dinheiro, Enum pra status, DTO na fronteira de integração. Não é pacote fechado — dá pra pegar só as ferramentas que resolvem o seu problema.

A pegadinha: "mas e quando o projeto crescer?"

Esse é o argumento que eu mais ouço. E ele tem um erro escondido: assume que refatorar depois é mais caro do que carregar a estrutura desde o começo.

Quase nunca é. Transformar um controller gordo em Action é trabalho de uma tarde, e você faz isso sabendo qual é a regra de verdade, porque o negócio já se revelou.

O contrário é que dói: desmontar uma arquitetura de quatro camadas que ninguém entende e que já espalhou tradução de dado por trinta arquivos. Aí é semana, não tarde.

E tem o custo que não aparece no gráfico: cada dev novo no time leva três semanas pra fazer o primeiro CRUD, porque precisa aprender o dialeto local antes de escrever a primeira linha.

Bônus: o teste do "conta pro estagiário"

Antes de adicionar uma camada, tenta explicar em voz alta pra alguém que acabou de chegar qual problema aquilo resolve.

Se a resposta sair como "é pra desacoplar do framework" ou "é boa prática", segura a onda. Não é justificativa, é slogan.

Se a resposta for "porque a regra de cálculo de comissão muda por estado e a gente precisa testar as 27 combinações sem tocar no banco" — aí sim. Isso é um problema concreto, e a camada tem endereço.

Antes de você fechar a aba

Não estou dizendo que DDD é ruim. Em domínio complexo de verdade, com regra de negócio que muda toda semana e gente do negócio discutindo termo por termo, ele é o que segura o sistema em pé.

O que eu tô dizendo é que arquitetura é resposta a um problema. Sem o problema, ela é só custo com aparência de sofisticação.

Cadastro de cliente não precisa de camada anticorrupção. Precisa de Cliente::create().

E aí, você já pegou (ou construiu) um projeto vestido pra uma complexidade que ele não tinha? Ou é do time que acha que camada nunca é demais? Vem discutir nos comentários — esse tema divide a comunidade ao meio e eu quero ouvir os dois lados. 🍿

Code review: como apontar o problema sem parecer babaca

Denis Augusto — Tue, 11 Aug 2026 18:01:56 +0000

O comentário tecnicamente correto que estraga o dia

Você abre o pull request e lá está:

"Isso tá errado."

Três palavras. Tecnicamente, pode até estar certíssimo. Mas o efeito na pessoa do outro lado é o mesmo de levar um empurrão no corredor.

E aí o PR trava. A pessoa responde defendendo a escolha. Você responde explicando melhor. Ela responde meio seca. Dois dias depois o código sai igual ao que ia sair, só que agora tem um clima estranho na daily.

Já viveu isso? De um lado ou do outro? Eu já vivi dos dois — e o lado de quem escreve o comentário ruim é mais fácil de estar do que a gente imagina.

O problema é o meio, não a maldade

Quase ninguém escreve comentário de review querendo ferir. O problema é estrutural.

Code review é texto, assíncrono e público. Não tem tom de voz, não tem cara, não tem o "risinho" que na mesa amaciaria a frase. E o time inteiro lê.

Quando falta tom, quem lê preenche sozinho. E a pessoa que acabou de passar seis horas naquele código, insegura sobre o resultado, vai preencher pro lado ruim. Sempre.

O mesmo comentário dito de pé, ao lado da mesa, com uma pausa e um "cara, olha só", passa liso. Escrito, vira julgamento.

Então não é sobre ser bonzinho. É sobre compensar o que o meio tira.

Sete coisas que mudaram meus reviews

1. Comente o código, não a pessoa

Trocar "você" por "esse método" muda tudo, e não custa nada:

❌ "Você esqueceu de tratar o retorno nulo aqui."
✅ "Esse retorno pode vir nulo quando o cliente não tem endereço — dá exception na linha de baixo."

Mesma informação. Só que a segunda fala do código, e a primeira aponta o dedo.

2. Diga o porquê e o impacto

Comentário sem motivo vira gosto pessoal — e ninguém aceita gosto pessoal de bom grado.

❌ "Não usa all() aqui."
✅ "Esse all() carrega a tabela inteira na memória. Em produção são uns 800 mil registros, o job vai estourar o limite. chunkById() resolve."

A segunda versão não precisa de autoridade nenhuma pra convencer. O argumento se defende sozinho, e a pessoa aprende algo em vez de só obedecer.

3. Separe o que bloqueia do que é preferência

Essa é a que mais melhora review em time, e é a mais fácil de adotar. Prefixo no comentário:

bloqueante: — não pode subir assim (bug, falha de segurança, quebra de contrato)
sugestão: — melhoraria, mas é decisão sua
nit: — implicância mínima, pode ignorar sem culpa
dúvida: — eu não entendi, me explica

Sem isso, todo comentário pesa igual. Quem recebe dez apontamentos não sabe se tem um problema sério ou dez preferências, e trata tudo como reprovação.

Com prefixo, "nit: acho que esse nome ficaria melhor no plural" é lido em dois segundos e resolvido em cinco.

4. Pergunta de verdade, não pergunta retórica

Existe uma diferença enorme entre curiosidade e ironia disfarçada de pergunta:

❌ "Tem certeza que isso funciona?"
❌ "Por que você fez desse jeito?"
✅ "Fiquei em dúvida no caso do cliente sem contrato ativo — esse where cobre isso? Posso ter perdido alguma coisa."

As duas primeiras são acusação com ponto de interrogação no fim. Todo mundo sente.

E tem um bônus real na terceira: às vezes quem não entendeu foi você. Manter a abertura de "posso ter perdido alguma coisa" já me salvou de várias sugestões erradas ditas com confiança demais.

5. Sugira o código, não só o problema

O GitHub e o GitLab têm bloco de sugestão. Usa. Escrever a alternativa custa trinta segundos e muda a natureza do comentário: em vez de tarefa, vira ajuda.

E força você a conferir se a sua ideia realmente funciona ali. Já desisti de uns bons comentários no meio da escrita da sugestão. 😅

6. Comente o que tá bom também

Não é bajulação nem "elogio sanduíche". É calibragem.

Se você só aparece pra apontar problema, seus comentários viram sinal de perigo — a pessoa vê seu nome na notificação e já se contrai. Um "esse teste do cenário de borda ficou ótimo, eu não tinha pensado nesse caso" custa dez segundos e muda como todo o resto é lido.

E tem um efeito colateral bom: elogiar o que você quer ver mais espalha padrão muito mais rápido do que criticar o que você não quer.

7. Passou de três idas e voltas, sai do texto

Se o mesmo ponto já teve três rodadas de comentário, o problema não é mais técnico. Ou vocês estão discutindo coisas diferentes, ou tem contexto que não cabe em caixa de texto.

Cinco minutos de call resolvem o que dez comentários não resolvem — e depois alguém registra no PR o que ficou combinado.

A pegadinha: review de gosto pessoal

Metade dos comentários azedos do mundo são sobre coisa que máquina deveria resolver.

Aspas simples ou duplas, quebra de linha, ordem dos imports, espaço antes da chave. Se isso aparece em review, o problema não é a pessoa — é que falta Pint (ou Pint + PHPStan) no pipeline.

Configura uma vez, o robô aponta, ninguém se ofende com robô. E aí o review humano fica livre pro que importa: regra de negócio, caso de borda, nome que não descreve o que faz, teste que não testa nada.

Regra que eu tento seguir: se um linter poderia ter dito, um humano não deveria dizer.

Do outro lado: recebendo review

Vale dizer, porque é mão dupla.

Todo comentário é sobre o código. Mesmo o mal escrito — quem escreveu provavelmente estava com pressa entre duas reuniões, não com raiva de você. Se um comentário te irritou, espera vinte minutos antes de responder. E se foi grosseiro mesmo, dá pra falar direto: "esse comentário soou meio seco, o que você quis dizer?". Quase sempre a resposta é "ih, desculpa, escrevi correndo".

E quando discordar, discorda com argumento. Review não é ordem, é conversa — quem revisa também erra.

Bônus: combinem uma página de regras

Meia hora de conversa e um documento de uma página resolvem 80% do atrito: o que é bloqueante de verdade, em quanto tempo se espera resposta num PR, tamanho máximo de PR (o maior favor que você faz pro revisor é o PR pequeno), quem pode aprovar e os prefixos de comentário.

Não é burocracia. É parar de negociar as mesmas coisas em todo PR.

Antes de você fechar a aba

Code review é o único momento em que o time inteiro conversa sobre código de verdade. É onde padrão se espalha, onde gente nova aprende rápido e onde bug morre barato.

E é também onde relação se desgasta silenciosamente, um comentário seco de cada vez, até alguém começar a aprovar tudo só pra evitar a conversa. Aí acabou o review — sobrou o carimbo.

Trinta segundos a mais escrevendo o comentário é o melhor investimento de tempo que existe no processo.

Agora conta: qual o comentário mais babaca que você já recebeu num PR? Ou — se tiver coragem, e eu tenho — qual foi o mais babaca que você já escreveu? Eu abro os trabalhos: já escrevi um "isso não faz sentido" às 19h de sexta e passei o fim de semana inteiro me arrependendo. 🙈

Mastering Advanced Server-Side Caching Patterns in Next.js

Tamiz Uddin — Tue, 11 Aug 2026 18:01:08 +0000

Originally published on tamiz.pro.

Next.js, a robust React framework, has significantly evolved its caching mechanisms, moving beyond simple client-side strategies to embrace powerful server-side patterns. This deep-dive explores the intricacies of advanced server-side caching in Next.js, focusing on how developers can leverage Data Cache, Full Route Cache, and custom memoization techniques to build highly performant and scalable applications.

Optimizing application performance is a continuous endeavor. In the context of server-rendered or statically generated applications like those built with Next.js, efficient caching on the server-side can drastically reduce response times, lower database load, and improve overall user experience. We'll dissect the various layers of caching available and provide practical insights into their implementation.

1. Understanding Next.js Caching Fundamentals
2. Next.js Data Cache: fetch and revalidate
- 2.1. Automatic Caching with fetch
- 2.2. On-Demand Revalidation
- 2.3. Time-Based Revalidation
- 2.4. unstable_cache for Non-fetch Operations
3. Full Route Cache: next/cache
- 3.1. How Full Route Cache Works
- 3.2. Cache Invalidation Strategies
- 3.3. When to Opt-Out of Full Route Cache
4. Custom Server-Side Memoization and Caching
- 4.1. In-Memory Caching with lru-cache
- 4.2. Leveraging Redis for Distributed Caching
5. Edge Caching with CDNs
6. Best Practices and Considerations
7. Frequently Asked Questions

1. Understanding Next.js Caching Fundamentals

Next.js provides a sophisticated caching system that operates on both the client and server sides. While client-side caching (browser cache, service workers) is crucial for static assets, server-side caching is paramount for dynamic data and server-rendered content. The framework's caching mechanisms are designed to work seamlessly across different deployment targets, from Vercel's Edge Network to self-hosted Node.js servers.

The core idea behind server-side caching in Next.js is to avoid re-fetching or re-computing data that hasn't changed, thereby serving content faster and reducing the load on upstream services (databases, APIs).

Key server-side caching layers in Next.js include:

Data Cache: Primarily managed by the native fetch API, it caches responses from HTTP requests. This cache is persistent across requests and deployments.
Full Route Cache: Caches the entire rendered HTML of a route, along with its static assets. This is highly effective for routes that don't change frequently.
Custom Caching: Implementing your own caching logic using libraries like lru-cache or external services like Redis for fine-grained control.

Understanding how these layers interact and when to apply each is crucial for building high-performance Next.js applications.

2. Next.js Data Cache: `fetch` and `revalidate`

The Next.js Data Cache is a powerful feature that automatically caches the results of fetch requests on the server-side. This cache is persistent and can be revalidated on demand or after a certain time.

2.1. Automatic Caching with `fetch`

When you use the native fetch API within getServerSideProps, getStaticProps, Server Components, or Route Handlers, Next.js automatically caches the data. This is a significant improvement, as it offloads the burden of manual caching.

Consider a simple data fetch in a Server Component:

// app/page.tsx
async function getPosts() {
  // This fetch request will be automatically cached by Next.js
  // The cache key is derived from the URL and request options.
  const res = await fetch('https://jsonplaceholder.typicode.com/posts', {
    // cache: 'force-cache' is the default for static generation (SSG)
    // For SSR, default is 'no-store' if not explicitly set.
    // Here, we explicitly opt-in for caching.
    next: { revalidate: 3600 } // Revalidate every hour
  });
  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }
  return res.json();
}

export default async function HomePage() {
  const posts = await getPosts();
  return (
    <main>
      <h1>Latest Posts</h1>
      <ul>
        {posts.map((post: any) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </main>
  );
}

In this example, the fetch request for posts will be cached. Subsequent requests to HomePage within the revalidation period will hit the cache, avoiding an external API call.

2.2. On-Demand Revalidation

On-demand revalidation allows you to purge specific cached data when external data changes. This is critical for ensuring data freshness without sacrificing performance.

You can revalidate data using the revalidatePath or revalidateTag functions from next/cache.

First, tag your fetch requests:

// lib/data.ts
export async function getProduct(id: string) {
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: { tags: ['products', `product-${id}`] } // Assign tags to the cache entry
  });
  if (!res.ok) throw new Error('Failed to fetch product');
  return res.json();
}

export async function getProducts() {
  const res = await fetch('https://api.example.com/products', {
    next: { tags: ['products'] }
  });
  if (!res.ok) throw new Error('Failed to fetch products');
  return res.json();
}

Then, create a Route Handler (or API Route) to trigger revalidation:

// app/api/revalidate/route.ts
import { revalidatePath, revalidateTag } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function GET(request: NextRequest) {
  const secret = request.nextUrl.searchParams.get('secret');
  const path = request.nextUrl.searchParams.get('path');
  const tag = request.nextUrl.searchParams.get('tag');

  if (secret !== process.env.MY_SECRET_TOKEN) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  if (path) {
    revalidatePath(path);
    return NextResponse.json({ revalidated: true, now: Date.now(), path });
  }

  if (tag) {
    revalidateTag(tag);
    return NextResponse.json({ revalidated: true, now: Date.now(), tag });
  }

  return NextResponse.json({ message: 'Must provide path or tag' }, { status: 400 });
}

To trigger revalidation, you would send a request to YOUR_APP_URL/api/revalidate?secret=YOUR_SECRET_TOKEN&tag=products or YOUR_APP_URL/api/revalidate?secret=YOUR_SECRET_TOKEN&path=/products.

2.3. Time-Based Revalidation

Time-based revalidation (Incremental Static Regeneration or ISR) is configured using the revalidate option in fetch or getStaticProps.

For fetch:

// In a Server Component or a data fetching function
const res = await fetch('https://api.example.com/data', {
  next: { revalidate: 60 } // Revalidate data every 60 seconds
});

For getStaticProps (Pages Router):

// pages/products/[id].tsx
export async function getStaticProps({ params }: { params: { id: string } }) {
  const res = await fetch(`https://api.example.com/products/${params.id}`);
  const product = await res.json();
  return {
    props: { product },
    revalidate: 60 // In-seconds
  };
}

2.4. `unstable_cache` for Non-`fetch` Operations

While fetch handles caching for HTTP requests, what about data fetched from databases, file systems, or other non-HTTP sources? Next.js provides unstable_cache (which will eventually be stabilized) to cache the results of any data-fetching function.

// lib/db.ts
import 'server-only';
import { unstable_cache } from 'next/cache';

interface User {
  id: string;
  name: string;
  email: string;
}

// Simulate a database call
async function fetchUserFromDB(userId: string): Promise<User> {
  console.log(`Fetching user ${userId} from DB...`);
  await new Promise(resolve => setTimeout(resolve, 500)); // Simulate network delay
  return { id: userId, name: `User ${userId}`, email: `${userId}@example.com` };
}

export const getUser = unstable_cache(
  async (userId: string) => fetchUserFromDB(userId),
  ['user-data'], // Key parts for cache invalidation
  { tags: ['users'] } // Tags for on-demand revalidation
);

// In a Server Component
export default async function UserProfile({ params }: { params: { id: string } }) {
  const user = await getUser(params.id);
  return (
    <div>
      <h1>User Profile</h1>
      <p>Name: {user.name}</p>
      <p>Email: {user.email}</p>
    </div>
  );
}

unstable_cache takes three arguments:

fn: The asynchronous function whose result you want to cache.
keyParts: An array of strings used to create a unique cache key. If any part changes, the cache is busted.
options: An object containing revalidate (time-based) or tags (on-demand revalidation) similar to fetch.

This provides a universal caching mechanism for any server-side data fetching.

3. Full Route Cache: `next/cache`

The Full Route Cache (also known as the HTTP cache for routes) works at a higher level than the Data Cache. It caches the entire rendered output of a route (HTML, CSS, JS) at the edge or on the server. This is the fastest form of caching for complete pages.

3.1. How Full Route Cache Works

Next.js leverages HTTP caching headers (Cache-Control) to instruct browsers and CDNs (like Vercel's Edge Network) on how to cache entire routes. When a request comes in for a cached route, the CDN can serve the content directly without ever hitting your Next.js application server.

By default, Next.js implements intelligent caching strategies:

Static Routes: Routes generated using getStaticProps (Pages Router) or fully static Server Components (App Router) are highly cacheable, often with public, max-age=31536000, immutable.
Dynamic Routes with revalidate: Routes using getStaticProps with revalidate or fetch with next.revalidate will have appropriate Cache-Control headers (e.g., s-maxage=60, stale-while-revalidate).
Dynamic Routes without revalidate (SSR): Routes rendered server-side without explicit revalidation often have Cache-Control: private, no-cache, no-store, must-revalidate to prevent caching of potentially user-specific content.

3.2. Cache Invalidation Strategies

Full Route Cache invalidation typically happens through two primary methods:

Time-Based Revalidation: As discussed with revalidate in fetch or getStaticProps. The s-maxage (shared cache max-age) header controls CDN caching duration.
On-Demand Revalidation: Using revalidatePath and revalidateTag not only invalidates the Data Cache but also signals the Next.js runtime (especially on Vercel) to purge the Full Route Cache for the affected paths or routes that depend on the invalidated tags. This ensures that the next request fetches fresh data and re-renders the page.

3.3. When to Opt-Out of Full Route Cache

While highly beneficial, there are scenarios where you might want to bypass or disable the Full Route Cache for specific requests or pages:

Highly Personalized Content: Pages that display user-specific data (e.g., a dashboard, shopping cart) should generally not be cached at the edge or publicly. Next.js typically handles this by default for getServerSideProps or dynamic Server Components without explicit revalidate.
Real-time Data: If data changes extremely rapidly and needs to be reflected instantly (e.g., stock tickers), aggressive caching might be counterproductive. You might rely on client-side polling/websockets for such scenarios.
User-Generated Content (pre-moderation): For content that requires moderation before public display, you might want to ensure the latest version is always fetched for moderators.

To explicitly opt-out of caching for a route in the App Router, you can use export const dynamic = 'force-dynamic' in a layout or page, or set cache: 'no-store' in your fetch requests. For the Pages Router, using getServerSideProps without revalidate implicitly prevents static caching.

// app/dashboard/page.tsx
// This page will always be rendered dynamically on the server and not cached by the Full Route Cache
export const dynamic = 'force-dynamic';

export default function DashboardPage() {
  // ... fetch and display user-specific data ...
}

4. Custom Server-Side Memoization and Caching

Beyond Next.js's built-in caching, there are situations where you need more granular control or need to cache data that doesn't fit neatly into the fetch or unstable_cache paradigms. This is where custom server-side memoization and caching come into play.

4.1. In-Memory Caching with `lru-cache`

For short-lived, frequently accessed data within a single Node.js process, an in-memory cache like lru-cache is an excellent choice. It automatically evicts the least recently used items when the cache reaches its maximum size.

npm install lru-cache

// lib/lru-cache-service.ts
import { LRUCache } from 'lru-cache';

interface CacheValue {
  data: any;
  timestamp: number;
}

const options = {
  max: 500, // Max number of items in cache
  ttl: 1000 * 60 * 5, // 5 minutes time-to-live for cache entries
  updateAgeOnGet: true, // Update age of item on get
};

const cache = new LRUCache<string, CacheValue>(options);

export async function getCachedData<T>(key: string, fetcher: () => Promise<T>): Promise<T> {
  const cached = cache.get(key);
  const now = Date.now();

  if (cached && (now - cached.timestamp < options.ttl)) {
    console.log(`Cache hit for key: ${key}`);
    return cached.data as T;
  }

  console.log(`Cache miss for key: ${key}, fetching...`);
  const data = await fetcher();
  cache.set(key, { data, timestamp: now });
  return data;
}

// Example usage in a Server Component or Route Handler
// app/api/products/route.ts
import { NextResponse } from 'next/server';
import { getCachedData } from '../../lib/lru-cache-service';

async function fetchExpensiveProductData(productId: string) {
  // Simulate an expensive operation or database query
  console.log(`Fetching expensive data for product ${productId}...`);
  await new Promise(resolve => setTimeout(resolve, 1000));
  return { id: productId, name: `Expensive Product ${productId}`, price: Math.random() * 100 };
}

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const productId = searchParams.get('id') || '1';

  const product = await getCachedData(`product-${productId}`, () => fetchExpensiveProductData(productId));

  return NextResponse.json(product);
}

Caveat: lru-cache is process-specific. In a serverless environment or with multiple Node.js instances, each instance will have its own cache, leading to potential cache misses across instances.

4.2. Leveraging Redis for Distributed Caching

For distributed environments, serverless functions, or when you need a shared, persistent cache across multiple instances, an external caching store like Redis is essential.

npm install redis

// lib/redis-service.ts
import { createClient } from 'redis';

const redisClient = createClient({
  url: process.env.REDIS_URL || 'redis://localhost:6379',
});

redisClient.on('error', (err) => console.log('Redis Client Error', err));

async function connectRedis() {
  if (!redisClient.isReady) {
    await redisClient.connect();
    console.log('Connected to Redis');
  }
}

export async function getOrSetCache<T>(key: string, fetcher: () => Promise<T>, ttlSeconds: number = 300): Promise<T> {
  await connectRedis();

  const cachedData = await redisClient.get(key);
  if (cachedData) {
    console.log(`Redis Cache hit for key: ${key}`);
    return JSON.parse(cachedData) as T;
  }

  console.log(`Redis Cache miss for key: ${key}, fetching...`);
  const freshData = await fetcher();
  await redisClient.setEx(key, ttlSeconds, JSON.stringify(freshData));
  return freshData;
}

export async function invalidateCache(key: string) {
  await connectRedis();
  await redisClient.del(key);
  console.log(`Redis Cache invalidated for key: ${key}`);
}

// Example usage in a Server Component or Route Handler
// app/api/long-computation/route.ts
import { NextResponse } from 'next/server';
import { getOrSetCache, invalidateCache } from '../../lib/redis-service';

async function performLongComputation() {
  console.log('Performing long computation...');
  await new Promise(resolve => setTimeout(resolve, 3000)); // Simulate 3-second computation
  return { result: 'Computed Value', timestamp: Date.now() };
}

export async function GET(request: Request) {
  const data = await getOrSetCache('my-long-computation', performLongComputation, 60);
  return NextResponse.json(data);
}

// Example for invalidation
export async function POST(request: Request) {
  await invalidateCache('my-long-computation');
  return NextResponse.json({ message: 'Cache invalidated' });
}

Redis offers robust features like persistence, replication, and pub/sub, making it suitable for complex caching scenarios. Remember to secure your Redis instance and manage connections efficiently.

5. Edge Caching with CDNs

For maximum performance, combine Next.js's built-in caching with a Content Delivery Network (CDN) like Vercel's Edge Network, Cloudflare, or AWS CloudFront. CDNs cache static assets and entire HTML pages at geographically distributed points of presence (PoPs), serving content closer to users and reducing latency.

When deploying to Vercel, much of the edge caching is automatically managed based on your Next.js build output and Cache-Control headers. For self-hosting, you'll need to configure your CDN to respect these headers and potentially add custom rules for caching and invalidation.

Key aspects of CDN caching:

Static Assets: JavaScript bundles, CSS, images, fonts are aggressively cached by CDNs.
HTML Pages: Pages generated via SSG or ISR are cached at the edge, providing near-instant load times for subsequent visits.
Cache-Control Headers: Next.js sets appropriate Cache-Control headers. s-maxage is particularly important for instructing shared caches (like CDNs) how long to store a resource.
Stale-While-Revalidate: This HTTP header strategy allows CDNs to serve stale content immediately while asynchronously revalidating it in the background, providing a great balance between freshness and speed.

# Example Cache-Control header for a page with ISR (revalidate: 60)
Cache-Control: public, s-maxage=60, stale-while-revalidate=59

This header tells the CDN to serve the cached content for 60 seconds (s-maxage=60). If a request comes in after 60 seconds but before stale-while-revalidate expires (e.g., 59 seconds after s-maxage), the CDN will serve the stale content immediately and trigger a revalidation request to the origin in the background. Once the origin responds, the cache is updated.

6. Best Practices and Considerations

Granularity: Cache at the most granular level possible. Cache individual data fetches rather than entire pages if only parts of the page change frequently.
Invalidation Strategy: Plan your cache invalidation strategy carefully. On-demand revalidation is often preferred for dynamic data to ensure freshness, while time-based revalidation (ISR) is great for content that updates periodically.
Cache Keys: Design clear and consistent cache keys. For custom caches, ensure keys are unique and reflect the data they represent.
Server-Side vs. Client-Side: Distinguish between server-side caching (for performance and reduced origin load) and client-side caching (for faster subsequent user visits and offline capabilities). Both are important.
no-store vs. no-cache: Understand the difference. no-store means the response should never be stored by any cache. no-cache means the cache must re-validate with the origin server before serving a cached copy.
Security: Be mindful of caching sensitive user data. Use private cache control or no-store for authenticated and personalized content.
Monitoring: Monitor your cache hit rates and performance metrics. This helps identify areas for improvement and diagnose caching issues.
Local Development: Caching behaves differently in development vs. production. Be aware of next dev not always reflecting production caching behavior accurately. Use next build and next start to test production caching locally.
'use server' and Caching: Server Actions (functions marked with 'use server') can also benefit from caching. If they call data-fetching functions that are cached (e.g., fetch with revalidate or unstable_cache), those results will be cached. However, the action itself is a mutation, so ensure you revalidate any affected data after a successful action.

7. Frequently Asked Questions

Q: What's the difference between `revalidatePath` and `revalidateTag`?

A: revalidatePath invalidates the cache for a specific path (e.g., /products/1). This is useful when you know exactly which page needs to be updated. revalidateTag invalidates all fetch requests (and unstable_cache calls) that were associated with a specific tag (e.g., products). This is more powerful for batch invalidation when multiple pages or components depend on the same dataset.

Q: Can I use server-side caching with `getServerSideProps` in the Pages Router?

A: Yes, getServerSideProps does not participate in getStaticProps-style static generation or ISR. However, you can still use fetch with next: { revalidate: N } inside getServerSideProps to cache individual data fetches. The overall HTML response of the getServerSideProps page won't be cached at the edge by Next.js by default, but you can configure your CDN to cache it if Cache-Control headers allow.

Q: How does caching work with dynamic routes like `/blog/[slug]`?

A: For dynamic routes, if you're using getStaticProps with getStaticPaths (Pages Router) or a generateStaticParams function (App Router) combined with revalidate, Next.js will pre-render and cache each unique page at build time or on demand. If you're using fetch with revalidate in a Server Component for a dynamic route, each unique path will have its data cached independently based on the fetch options.

Q: What are the implications of caching on SEO?

A: Server-side caching, especially of full routes, generally has a positive impact on SEO. Faster page load times are a ranking factor, and cached content is served more quickly to search engine crawlers. Ensure your caching strategy doesn't accidentally serve stale content to crawlers for extended periods, especially for rapidly changing information. On-demand revalidation helps maintain freshness for SEO-critical content.

The 3 3D animation principles by RingCentral that make black-box AI feel tangible - Explained by Advids

Harshal Patil — Tue, 11 Aug 2026 17:55:56 +0000

"We've noticed a persistent hurdle in launching enterprise AI: users simply do not trust what they cannot see or spatialize. When artificial intelligence just operates silently in the background of a dashboard, contact center agents often feel displaced or confused rather than supported. RingCentral circumvents this in their RingCX rollout by utilizing depth, layering, and spatial motion to make their RingSense AI feel like a physical, observable entity in the workspace.

Visualizing the invisible algorithm

The core design assumption in many platforms is that an AI should just be a frictionless output text box. The truth is that AI needs a spatial presence and physical boundaries in the UI to build real user trust.

Why does background AI fail to gain agent trust?

Agents ignore flat text insights that appear without a clear origin or visual hierarchy.
Supervisors struggle to intervene when real-time sentiment shifts lack visual urgency or motion.
Coaching plans generated instantly feel overly automated and impersonal when dumped into a standard, flat data table.

What the Video Actually Does

Notice how the RingCX interface handles real-time agent alerts during the video. Concentric, radar-like ripples animate behind the typography, signaling visually that the AI is actively ""listening"" and processing the live voice channel. When an agent needs help with an auto claim, the ""Insurance 101"" insight doesn't just appear—it pops up on an elevated card with a soft drop shadow.

This deliberate use of the Z-axis separates the AI's real-time suggestions from the flat CRM data beneath it. A glowing AI spark icon anchors these floating elements, giving the algorithm a distinct visual footprint within the workflow. By treating the AI as an overlapping physical layer rather than embedded background text, the interface makes complex LLM operations feel tangible and predictable.

AI adoption isn't just about the underlying model's accuracy—it's about giving the algorithm a tangible, observable presence in the user's environment.

How are you handling the UI/UX challenge of surfacing proactive AI insights without overwhelming your existing operational dashboards?"

DEV Community

How I got 165 blog posts indexed in 30 days with zero backlinks

MAI-Code-1-Flash Highlights Microsoft’s Lower-Cost Approach to Coding AI

What Microsoft has documented about MAI-Code-1-Flash

Why token efficiency matters in developer tools

Availability and the broader MAI direction

Frequently Asked Questions

Conclusion

I Made an AI Project Manager PMI-Aligned—Without Turning It Into Bureaucracy

The employee model changes the product boundary

Autonomy without discipline creates confident chaos

“PMI aligned” needs a precise meaning

Tailoring is not checkbox theatre

The system expands only when the project needs it

Evidence is the counterweight to agent confidence

Unknown must remain unknown

What is deliberately not implemented

The larger idea

Try it

47 free AI tools that live in your browser (2026)

Why browser-only?

What's in the box

How they're built

A note on "free"

Try it

Building AI-Powered Flutter Apps with Gemini

Building AI-Powered Flutter Apps with Gemini

Why use a backend?

Step 1: Create the Flutter UI

Step 2: Define a clean architecture

Step 3: Backend example with FastAPI

Step 4: Call the backend from Flutter

Step 5: Add loading and error states

Prompt engineering

Streaming responses

Security checklist

Conclusion

Useful Links

My Pest test passed because I added a helpful failure message

What that second argument actually does

How not gets there

Why this one is so easy to walk into

The four cases, run

What I do now

Flutter Platform Channels: Calling Kotlin from Dart

Flutter Platform Channels: Calling Kotlin from Dart

What are Platform Channels?

Step 1: Create the Flutter project

Step 2: Create the Dart platform channel

Step 3: Call Kotlin from MainActivity

Step 4: Use it from Flutter

Passing arguments

Returning structured data

Error handling

Production recommendations

Common mistakes

Channel names do not match

Calling native code directly from many widgets

Blocking the UI thread

Conclusion

Useful Links

What Is Technical Documentation, and What Should It Include?

What technical documentation should include

Build the smallest package that lets someone succeed

Give each document a boundary

Make coverage inspectable before writing prose

Assign an owner and an update trigger

DDD no seu CRUD é canhão pra matar mosquito

Sete arquivos pra salvar um cadastro

O que parece sofisticação e é só cerimônia

DDD nunca foi sobre pastas

A régua: complexidade de dado ou complexidade de regra?

Como fica na prática

A pegadinha: "mas e quando o projeto crescer?"

Bônus: o teste do "conta pro estagiário"

Antes de você fechar a aba

Code review: como apontar o problema sem parecer babaca

O comentário tecnicamente correto que estraga o dia

O problema é o meio, não a maldade

Sete coisas que mudaram meus reviews

How `not` gets there

2. Next.js Data Cache: `fetch` and `revalidate`

2.1. Automatic Caching with `fetch`

2.4. `unstable_cache` for Non-`fetch` Operations

3. Full Route Cache: `next/cache`

4.1. In-Memory Caching with `lru-cache`

Q: What's the difference between `revalidatePath` and `revalidateTag`?

Q: Can I use server-side caching with `getServerSideProps` in the Pages Router?

Q: How does caching work with dynamic routes like `/blog/[slug]`?