Integrating maps and adding interactivity to them can be a bit tricky at first. In this post, I’ll show you how to easily add a basic map using Mapbox in your Angular project.

Mapbox offers several ways to use their maps, but the most straightforward approach is through their official npm package: mapbox-gl.

Step 1: Install the Mapbox GL JS package

npm i --save mapbox-gl

Step 2: Include the Mapbox CSS in index.html
In your index.html file, inside the

tag, add the following:

<link href='https://api.mapbox.com/mapbox-gl-js/v3.13.0/mapbox-gl.css' rel='stylesheet' />

Don’t just copy-paste, always check Mapbox’s official docs for the latest version.

Step 3: Get Your Mapbox Access Token
Log into your Mapbox account and generate a public access token (pk.).
If you’re using Mapbox on a frontend-only app, a public token is enough.
For backend services, use a secret token (sk.), but never expose it in frontend code.

Step 4: Create Map Component
map.ts

import { AfterViewInit, Component } from '@angular/core';
import mapboxgl, { Map } from 'mapbox-gl';

@Component({
  selector: 'app-map',
  templateUrl: 'map.html',
  styleUrls: ['map.css']
})
export class MapComponent implements AfterViewInit {
map!: Map;
accessToken = ''; // Add your public token here
mapStyle = 'mapbox://styles/mapbox/streets-v12'

ngAfterViewInit(): void {
    mapboxgl.accessToken = this.accessToken;
    this.map = new mapboxgl.Map({
      container: 'map', // matches the div ID
      style: this.mapStyle,
      center: [20, 50], // [lng, lat]
      zoom: 3,
    });
  }
}

map.html

<div id="map"></div>

map.css

#map {
  width: 100%;
  height: 100%;
}

Important:
Make sure that the parent element of your map (and the map container itself) has a defined width and height.
If either of them is missing, Mapbox won’t know how big the map should be, and you might just see a blank box.

Example fix:
map.css

.map-section {
  width: 100vw;
  height: 100vh;
}

#map {
  width: 100%;
  height: 100%;
}

map.html

<section class="map-section">
  <div id="map"></div>
</section>

If your map still overflows or causes scrollbars, make sure you reset global margins and paddings:

styles.css

html,
body {
  margin: 0;
  padding: 0;
}

This is the most basic way to include Mapbox in your project.
In upcoming posts, I’ll show you how to make your map more interactive using real-world data.

Here’s a scene that plays out a dozen times a day if you use an AI coding agent: you ask it to build something that calls an external API — a payment service, a notification system, an OAuth flow — and it writes beautiful code. Clean types, proper error handling, good structure. Then it stops. It can’t actually run any of it, because the API it’s calling doesn’t exist locally and the agent has no way to spin one up.

So you get code that looks right but hasn’t been tested against anything. The agent wrote a Stripe integration without ever seeing a Stripe response. It built a webhook handler without ever receiving a webhook. You’re the one who has to close that gap, manually, every time.

I kept hitting this wall, and it’s the reason mockd ships with 18 MCP tools built in.

What MCP gives your agent

MCP — Model Context Protocol — is the standard that lets AI agents call external tools programmatically. Instead of just reading and writing files, your agent can interact with services, APIs, and infrastructure through a structured interface.

mockd implements an MCP server that exposes everything an agent needs to create mock endpoints, send test traffic, inspect request logs, verify call counts, and inject failure conditions. All over stdio, no API keys required for local use.

The agent doesn’t just develop against a mock server. It provisions and manages the mock server itself.

Setup: two minutes, zero config

Claude Code

Add this to your Claude Code MCP configuration:

{
  "mcpServers": {
    "mockd": {
      "command": "mockd",
      "args": ["mcp"],
      "env": {}
    }
  }
}

Cursor

In Cursor’s MCP settings (Settings → MCP Servers), add the same configuration:

{
  "mcpServers": {
    "mockd": {
      "command": "mockd",
      "args": ["mcp"],
      "env": {}
    }
  }
}

This works with any MCP-compatible agent — Claude Code, Cursor, GitHub Copilot, Windsurf, JetBrains AI. The mockd mcp command speaks standard MCP over stdio, so anything that implements the protocol can use it.

One detail worth calling out: mockd mcp automatically starts a background daemon if one isn’t already running. You don’t need to manually run mockd start first. The agent connects, mockd boots up on port 4280 (mock server) and 4290 (admin API), and everything just works. Pass --data-dir if you want project-level isolation between different codebases.

A real workflow: “Build me a payment service”

Here’s what actually happens when you ask an agent to build something against an external API, with mockd connected as an MCP tool.

You: “Build a payment service that integrates with Stripe. It should create charges, handle webhooks, and refund failed payments.”

The agent’s first move isn’t writing application code. It calls manage_mock to create the Stripe endpoints it knows it’ll need:

• POST /v1/charges → returns a charge object with status: "succeeded"
• POST /v1/refunds → returns a refund object
• GET /v1/charges/:id → returns charge details
• POST /webhook → a local endpoint for receiving Stripe events

Each mock returns realistic response structures — the agent knows what Stripe responses look like and configures the mocks accordingly.

Then it writes the application code. The payment service, the webhook handler, the refund logic. But here’s the key difference: it can test every function as it writes it. The code hits http://localhost:4280/v1/charges, gets back a real HTTP response with a real JSON body, and the agent can verify the code actually works.

After writing the code, the agent calls verify_mock to check that the right endpoints were called the expected number of times. It calls get_mock_invocations to inspect the exact request bodies its code sent. It finds a bug — the refund handler is sending charge_id instead of charge in the request body — fixes it, and tests again.

Then it pushes further. It calls set_chaos_config to inject intermittent 500 errors on the charge endpoint, reruns the payment flow, and discovers the retry logic doesn’t handle idempotency keys correctly. It fixes that too.

The agent just completed a development loop that would normally require you to set up a Stripe test account, manage API keys, deal with rate limits, and manually inspect webhook payloads. Instead, it did the whole thing itself in a few minutes.

The tools that matter most

mockd exposes 18 MCP tools total. You don’t need to memorize them — the agent discovers them automatically through the MCP protocol. But these are the ones that get used constantly:

manage_mock — The workhorse. Create, list, get, update, delete, and toggle mock endpoints. This is how the agent builds out the API surface it needs.

verify_mock — Assert that a mock was called a specific number of times. The agent uses this to confirm its code is actually making the requests it should be.

get_mock_invocations — Retrieve the full request details for every call that hit a specific mock — headers, body, query parameters, timestamps. This is how the agent debugs what its code is actually sending.

get_request_logs — View all traffic that hit the mock server, not just matched requests. Useful when the agent’s code is calling an endpoint that doesn’t have a mock yet.

set_chaos_config — Inject latency, errors, and connection failures. The agent uses this to test its own error handling and retry logic.

manage_state — Create, read, update, and delete stateful resources. When the agent needs a mock that remembers data between requests — like a user record that persists after creation — this is how.

import_mocks — Import mock endpoints from an OpenAPI spec, Postman collection, or other formats. If the API the agent is integrating with has a spec, this bootstraps the entire mock surface in one call.

Resources: read-only context for the agent

Beyond tools, mockd also exposes MCP resources — read-only data the agent can access for context. There are 5 static resource URIs (mock://config, mock://mocks, mock://logs, mock://state, mock://chaos) and 8 dynamic resource patterns for drilling into specific mocks, invocations, and state entries.

In practice, the agent uses resources to understand the current state of the mock server before making changes. It reads mock://mocks to see what’s already configured, checks mock://logs to see recent traffic, and uses that context to make informed decisions about what to create or modify next.

Why this changes the development loop

The fundamental shift is that your AI agent can now iterate on code and its test environment simultaneously. It’s not writing code in a vacuum and hoping it works when it hits a real service. It’s running a full development loop — write, test, inspect, fix, test again — with a real HTTP server returning real responses.

No rate limits. No API keys. No cost per request. No dependency on staging environments that might be down. No “works on my machine but I can’t test the integration” gaps.

The agent gets real HTTP responses, not simulated ones. The code it writes has been tested against actual network calls. When you review the PR, the integration code has already been through dozens of iteration cycles against a mock that behaves like the real thing.

That’s the gap I kept running into, and it’s the gap that disappears when your agent has a mock server it controls.

What to know

The MCP transport is stdio only right now — local use. There’s no remote or SSE transport, so this is a “your machine, your agent” setup. If you’re hoping to share a mock server across a team via MCP, that’s not how it works yet. The agent also can’t change server configuration through MCP. It can create and manage mocks all day, but things like port numbers, TLS settings, and server-level config still require CLI flags or a config file. That’s a deliberate boundary, not an oversight.

MCP tool responses can get chatty. If your agent has a small context window and you’ve got fifty mocks configured, calling manage_mock with action: "list" is going to eat a chunk of that context. Something to keep in mind if you’re working with a constrained model. Trim your mocks or use targeted get calls instead of listing everything.

One more thing: mockd mcp auto-starts a background daemon, which is convenient right up until you forget it’s running. The daemon doesn’t shut down when the MCP session ends. You’ll want to run mockd stop when you’re done, or you’ll find port 4280 still occupied next time you try to start something else there. Ask me how I know.

Get started

Install mockd, add the MCP config to your agent, and point it at a project that talks to external APIs. The agent will figure out the rest.

# Install mockd
curl -fsSL https://get.mockd.io | sh

# Start mockd — the MCP server auto-connects to this
mockd start

For detailed setup instructions, tool reference, and advanced configuration:

• MCP Server Guide — Setup, tool reference, and resource URIs for all 18 MCP tools
• Why AI Agents Need Mock Servers — The broader case for mock infrastructure in AI development

This is a submission for the Notion MCP Challenge

What I Built

Every engineering team has the same graveyard: folders full of blurry whiteboard photos that were supposed to become

documentation. They never do. The meeting ends, the momentum dies, and that brilliant architecture sketch slowly rots in

someone’s camera roll.

Trace AI kills that problem dead.

Trace is an autonomous pipeline that watches your Notion Design Inbox, your Slack workspace, and your Discord server

simultaneously. The moment you drop in a whiteboard photo, Trace wakes up, reasons through the sketch using Claude vision,

and uses the official Notion MCP server to build a complete, structured system design document — entirely on its own.

Not a summary. Not a description. A full engineering document:

• Mermaid.js architecture diagrams — flowchart and sequence, auto-generated from your ink
• Component breakdown — every service, database, and load balancer identified and described
• Security analysis — potential vulnerabilities flagged with recommendations
• Bottleneck detection — performance risks spotted before they hit production
• Actionable task cards — your handwritten To-Dos extracted and created as real entries in your Notion engineering board,
  with Priority, Category, and Status pre-filled
• AWS cost estimates — rough monthly infrastructure projections for every component
• Complexity scoring — team size and build timeline estimates

The entire process takes under 2 minutes from photo to polished doc.

In a large company, information decays. A project manager marks a project as “completed”, but the task database still has 5 open items. A budget page says ‘$10k’, but the invoice page says ‘$12k’. Usually, these contradictions stay hidden until something breaks.

Sentinel fixes this. Using the new Model Context Protocol (MCP), Sentinel acts as a “shared brain” across your entire workspace. It observes every edit and cross-references it against a set of global truths you define. If a contradiction occurs, Sentinel doesn’t just watch—it acts.

Video Demo

Show us the code

https://github.com/Boweii22/Arch-Vision
Deployed live on Render using Docker (nikolaik/python-nodejs for Python + Node.js in one container — required to run the MCP
server subprocess).

How I Used Notion MCP

This is where Trace AI goes beyond a simple API wrapper.

Trace spawns the official @notionhq/notion-mcp-server as a live subprocess using the MCP Python SDK. Claude then enters an

agentic tool-use loop — it doesn’t receive a rigid set of instructions and execute them blindly. It reasons about what

blocks to append, how to structure the content, and how to handle edge cases like long Mermaid diagrams that exceed Notion’s
2000-character rich text limit.

Whiteboard photo
↓
Claude Vision → Architecture Analysis (structured JSON)
↓
npx @notionhq/notion-mcp-server ←→ Claude agentic loop
↓ ↓
Notion Page created MCP tool calls:
(direct API, correct parent) – append_block_children
– create_database_page
– (up to 25 iterations)
↓
Tasks Database ← action items extracted
Projects DB ← relational mapping

MCP unlocks something that raw API calls can’t: judgment. Claude decides when to split a code block, how to format a

callout, when to skip a section because the data isn’t there. The document isn’t templated — it’s reasoned.

On top of that, Trace runs a bi-directional sync loop: if you manually edit the Mermaid diagram in Notion, Trace detects the change, re-analyzes the modified architecture, and updates the analysis sections to stay consistent with your edits. Your

Notion workspace stays alive, not static.

Three ways to trigger it — Notion Inbox, Slack, Discord — because great tools meet teams where they already live.

I’ve been running FastAPI in production for a payment processing platform in Mexico for the past couple of years. We handle SPEI transfers (Mexico’s interbank transfer system), OXXO Pay (cash payments at convenience stores), and crypto on-ramps through multiple PSP integrations.
I wanted to share some real lessons from production that I don’t see discussed much.
The stack

FastAPI + async SQLAlchemy 2.0 + asyncpg
PostgreSQL + Redis (rate limiting + caching)
Docker → AWS ECS Fargate
GitHub Actions CI/CD
Alembic for migrations

Lesson 1: Webhook state machines save your life
When you process payments, you receive webhooks from payment providers. The naive approach is to just update the payment status directly. Don’t do this.
We built a webhook state machine where each payment goes through defined states: pending → processing → completed/failed. Every state transition is logged with timestamps. When a payment provider sends duplicate webhooks (and they will), the state machine just ignores transitions that don’t make sense.
This saved us during a reconciliation where we found timezone boundary issues between UTC and CST that were causing mismatches at midnight.
Lesson 2: Alembic migrations + ECS = restart loops
This one hurt. We had an Alembic migration that was taking too long, and ECS health checks were killing the container before the migration finished. Container restarts, migration starts over, health check fails again. Infinite loop.
Fix: Run migrations as a separate ECS task before deploying the new container. Never run migrations on startup in production.
Lesson 3: psycopg2 + LIKE queries will bite you
If you use % in LIKE queries with psycopg2 and parameterized queries, you need %% for literal percent signs when mixed with %s placeholders. We had a bug where a search endpoint was silently returning empty results.

Wrong

cursor.execute(“SELECT * FROM users WHERE name LIKE ‘%s%'”, (search,))

Right

cursor.execute(“SELECT * FROM users WHERE name LIKE %s”, (f”%{search}%”,))
Lesson 4: VARCHAR timestamps are a trap
One of our PSP integrations stores created_at as VARCHAR instead of TIMESTAMP. Every time we need to do date comparisons, we have to CAST(created_at AS TIMESTAMP). If you’re designing your schema, always use proper TIMESTAMP columns.
Lesson 5: Rate limiting is not optional
We got hit with a brute force attack on our auth endpoints within the first month. Redis-backed rate limiting with SlowAPI saved us. 5 attempts per minute on login, 20 requests per minute on general endpoints.
Lesson 6: Connection pooling matters more than you think
Our KYC service was falling over under load. The fix? Increasing the connection pool from 10 to 50 connections. That’s it. Went from random 500 errors to zero issues.
The architecture pattern that works
After iterating through multiple services, this is the pattern I settled on:
Repository (data access)
→ Service (business logic)
→ Endpoint (HTTP layer)
Each layer only talks to the one below it. Dependencies are injected via FastAPI’s Depends(). Testing becomes trivial — just mock the repository layer.

After refining this over 10+ deployments, I packaged the boilerplate into a starter kit with the full auth system, async DB, Docker, CI/CD, and tests. It’s on my Gumroad if anyone wants it. But the lessons above are the real value — the code is just the implementation.
I also deploy production AWS infrastructure for teams that don’t want to deal with Terraform/ECS — details here if that’s useful.
Happy to answer questions about running FastAPI in production, dealing with Mexican payment providers, or anything else.

If you’ve spent more than a week in web development, you’ve encountered REST APIs. They are the glue of the modern internet, connecting front-end frameworks to back-end databases and enabling third-party integrations that we take for granted.

But there is a massive difference between “making an API call” and “understanding RESTful architecture.” Today, we’re going deep. We’ll start with the basics and move into the advanced patterns that separate junior developers from senior architects.

Want to dive deeper into full-stack patterns? Check out more resources at NeedleCode.

What Exactly is REST?

REST (Representational State Transfer) isn’t a protocol like HTTP; it’s an architectural style. Introduced by Roy Fielding in his 2000 dissertation, it was designed to make the web more scalable and flexible.

When an API is “RESTful,” it means it follows a specific set of rules that allow different systems to communicate seamlessly, regardless of the language they are written in.

The 5 Pillars of RESTful Design

To build a truly RESTful system, you must adhere to these constraints:

1. Client-Server Separation: The UI (Client) and the Data (Server) are independent. You can swap your React frontend for a mobile app without changing a single line of your backend logic.
2. Statelessness: This is the most critical constraint. The server does not store any “session” data about the client. Every single request must contain all the information (including credentials) needed to process it.
3. Cacheability: Responses must define themselves as cacheable to prevent clients from requesting the same data repeatedly, reducing latency.
4. Uniform Interface: This simplifies the architecture. Whether you are fetching a user or a product, the method of interaction (URLs, HTTP verbs) should feel consistent.
5. Layered System: A client shouldn’t know if it’s connected directly to the database server or an intermediate proxy/load balancer.

The Developer’s Toolbox: HTTP Methods

In REST, we treat everything as a Resource. We manipulate these resources using standard HTTP verbs.

Pro-Tip: A common interview question is the difference between PUT and PATCH. Remember: PUT replaces the entire object, while PATCH only modifies the specific fields you send.

Deciphering the Server: Status Codes

As a dev, you need to speak “Status Code.” They tell you exactly what happened without parsing a huge JSON body.

• 2xx (Success): 200 OK (Standard success), 201 Created (Success after POST).
• 4xx (Client Error): 400 Bad Request (Your JSON is malformed), 401 Unauthorized (You forgot the token), 404 Not Found (Endpoint doesn’t exist).
• 5xx (Server Error): 500 Internal Server Error (Your backend code crashed).

Moving to Advanced Territory

Once you’ve mastered the basics, you’ll face real-world challenges like performance and scale.

1. Pagination and Filtering

Never return SELECT * FROM users. If you have 100,000 users, your API will crash. Use query parameters:
GET /api/v1/orders?page=2&limit=50&status=shipped

2. Stateless Auth with JWT

Since REST is stateless, we don’t use server-side sessions. Instead, we use JSON Web Tokens (JWT). The client sends the token in the Authorization header with every request.

3. API Versioning

Change is inevitable. To avoid breaking your users’ apps, version your URL:
https://api.needlecode.com/v1/products
https://api.needlecode.com/v2/products

4. The “Final Boss”: HATEOAS

HATEOAS (Hypermedia as the Engine of Application State) means your API provides links to guide the client.

{
  "user_id": 123,
  "name": "Dev",
  "links": [
    { "rel": "self", "href": "/users/123" },
    { "rel": "delete", "href": "/users/123", "method": "DELETE" }
  ]
}

This makes your API self-discoverable, though it is often skipped in simpler internal projects.

Summary

REST APIs are popular because they are predictable and scalable. By mastering these constraints and methods, you aren’t just “coding an endpoint”—you’re designing a system.

What’s your biggest struggle with API design? Let’s chat in the comments!

For more deep dives into system architecture and backend development, visit us at NeedleCode.