DEV Community: Robert Tidball

Your MCP Server Doesn't Need 40 Tools

Robert Tidball — Mon, 22 Jun 2026 13:48:03 +0000

MCP demos make it look like the win is exposing everything.

"Here are all my endpoints. Here are all my database tables. Here are all my internal actions. The agent can call anything now."

That feels powerful for about ten minutes.

Then the model calls the wrong tool, passes the right argument in the wrong shape, asks for a chart from a search endpoint, retries a destructive action, or returns an answer that sounds confident because the tool name was vague enough to mean three different things.

The problem is not MCP. The problem is treating MCP like a magic adapter for your backend.

An MCP server is not just "my API, but agent-accessible." It is a product surface for a very literal, very distractible user.

That user happens to be a language model.

The trap: one endpoint, one tool

The first instinct is obvious:

GET /users/:id        -> get_user
GET /users            -> list_users
GET /invoices/:id     -> get_invoice
GET /invoices         -> list_invoices
GET /events           -> list_events
POST /events/search   -> search_events
POST /reports         -> create_report
GET /reports/:id      -> get_report

This looks clean because it mirrors the API.

It is often bad for agents.

Humans can read docs, understand product context, and choose between similar routes. Models do not really "understand" your product. They pattern-match over names, descriptions, schemas, previous messages, and whatever context still fits in the window.

If you give the model 40 similar tools, you did not give it power. You gave it 40 ways to be almost right.

What changed in production

The lesson became obvious while building the MCP layer for FXMacroData.

The backend has normal API routes for calendar events, FX pairs, rates, COT positioning, commodities, bond yields, metadata, and docs. Mirroring every route into MCP would have looked comprehensive, but it would have made the agent choose between too many near-matches.

The useful MCP boundary was smaller:

one tool for the market summary;
one for the release calendar;
one for an FX pair snapshot;
one for chartable indicator history;
one for COT positioning;
one for commodities;
one for bond yields;
one for data coverage and metadata.

That is less impressive in a demo.

It is more useful in a real chat.

The agent no longer needs to know whether a question maps to an endpoint, a cached dashboard payload, or a normalized data table. It only needs to pick the user intent.

A tool is a promise

An API route says:

If you send this request, the server will respond.

An MCP tool should say:

Use me for this exact job, with these exact inputs, and expect this kind of result.

That means a good tool description is not marketing copy. It is routing logic for the model.

Bad:

{
  "name": "get_data",
  "description": "Gets data from the API."
}

Better:

{
  "name": "lookup_release_calendar",
  "description": "Return scheduled economic release events for one currency and date range. Use this before answering questions about upcoming macro events."
}

Even if you do not care about finance, the pattern matters. The second tool tells the model when to use it, what it returns, and what kind of user question it supports.

That is the bar.

Fewer tools, sharper edges

I would rather give an agent 8 boring tools than 45 clever ones.

The boring tools should map to user intent, not to your internal route structure.

User intent	Better tool shape
"What is coming up?"	`lookup_calendar`
"What happened recently?"	`lookup_recent_events`
"Show me the chartable history"	`get_time_series`
"Explain this result"	not a tool; let the model write from tool output
"Export this"	`create_export` only if exports are a real product action

The important part is that the model does not need to assemble your backend architecture in its head before making a useful call.

That is your job.

Names matter more than you want them to

Developers love compact names.

Models need boring names.

I used to like names like:

query
fetch
resolve
search
get_context

Those names are convenient for us and mushy for a model. They force the model to infer too much from the description.

Prefer names that carry product intent:

search_docs
lookup_account_status
get_time_series
list_recent_errors
create_support_summary
check_deployment_status

Longer is fine. Ambiguous is expensive.

Do not return your whole database row

The response shape matters as much as the input schema.

If a tool returns a giant nested object, the model will happily use the wrong field. It may cite an internal note, confuse created_at with updated_at, or summarize an implementation detail that was never meant for users.

Return the smallest shape that supports the job.

{
  "status": "ok",
  "items": [
    {
      "title": "Release calendar",
      "date": "2026-06-22",
      "url": "https://example.com/calendar"
    }
  ],
  "next_action": "Use these rows to answer the user's calendar question."
}

That next_action field looks silly until you watch models behave better with it.

You are not only returning data. You are returning affordances.

Build for failure, not the happy path

Most tool demos show the successful call.

Production quality comes from boring failure states.

What should the tool return when:

no records match;
the user asked for something outside their permissions;
the input is valid but too broad;
the upstream data is stale;
the operation is risky and needs confirmation;
the model picked the wrong tool?

Do not make the model infer all of that from a 500 or an empty array.

For example:

{
  "status": "no_results",
  "message": "No matching rows were found for that date range.",
  "suggested_next_action": "Ask the user whether they want to widen the date range."
}

This is not just nicer UX. It reduces hallucination pressure. The model has something accurate to say instead of filling the silence.

Your OpenAPI schema still matters

MCP does not replace API design.

If anything, it makes sloppy API design more visible.

A clean OpenAPI schema gives you a source of truth for types, descriptions, auth requirements, and examples. An MCP layer can then expose a smaller set of agent-friendly tools on top.

The stack I like looks like this:

Backend API
  -> documented OpenAPI schema
  -> small MCP tool layer
  -> agent instructions and examples
  -> smoke tests that call tools like a model would

The MCP server should not become a second undocumented API. That just creates two surfaces to debug.

Test the tool list like a UI

If a button says "Delete draft", you review the label.

If an MCP tool says run_action, you should review that label too.

I like a simple test that dumps the tool list and asks human questions:

Can I tell when each tool should be used?
Do two tools sound like they do the same thing?
Is any tool name too generic?
Are destructive tools clearly marked?
Are required arguments obvious?
Does each tool return a shape the model can summarize safely?

Then run actual tool calls with boring prompts:

What changed this week?
Show me recent errors.
Find docs about API keys.
Create a short summary for a new user.

If the model keeps choosing the wrong tool, do not just "improve the prompt." Fix the tool boundary.

Where this came from

I have been thinking about this while working on the public API, OpenAPI, docs, and MCP surfaces around FXMacroData.

The domain is not the point. The lesson is.

Once you expose product data to agents, your API is no longer only for deterministic callers. It is also for a model that needs strong names, tight schemas, clear failures, and fewer choices than a human developer.

The better the boundary, the less "agentic" magic you need.

The checklist I use now

Before adding a new MCP tool, I ask:

Is this a real user intent, or just an endpoint I happen to have?
Could an existing tool answer the same question?
Is the name boring and specific?
Does the description say when to use it?
Are the arguments narrow enough?
Is the response shape smaller than the internal object?
Does it handle no-results and permission failures clearly?
Would I be comfortable with the model quoting the response directly?
Do I have at least one smoke prompt that should call this tool?

If the answer is fuzzy, I probably do not need a new tool yet.

Closing

MCP is useful because it gives agents a standard way to use external systems.

But standards do not save bad boundaries.

Your MCP server does not need to expose everything your backend can do. It needs to expose the few things an agent should do, with names and schemas that make the right call obvious.

The best agent tool is not the most powerful one.

It is the one the model cannot easily misunderstand.

Introducing the FXMacroData Economic Data Embed Widget

Robert Tidball — Wed, 03 Dec 2025 13:34:36 +0000

Today, we’re launching a major new feature on FXMacroData — fully embeddable, real-time charts that you can drop into any website, blog, or research portal with a single copy-and-paste.

Each chart on FXMacroData now includes a dedicated “Embed Graph” button. Clicking it reveals a ready-to-paste HTML snippet.

You can view the full data and chart on the dashboard here: https://fxmacrodata.com/dashboard/EUR_USD To embed the chart above on your own site, use this snippet:

<!-- FXMacroData Chart Embed -->
<div
    id="fxmacro-carryChart"
    style="width: 100%; max-width: 800px; margin: 20px auto;"
>
    <iframe
        src="https://fxmacrodata.com/dashboard/embed/EUR_USD/carryChart"
        width="100%"
        height="450"
        frameborder="0"
        style="border: 1px solid #e5e7eb; border-radius: 8px;"
    ></iframe>
</div>

How Embeds Work

Embedding is as simple as copying the snippet and pasting it into your page. Each FXMacroData embed:

Updates in real time as new announcements are released
Requires zero maintenance or API integration
Loads quickly thanks to a lightweight hosting layer
Automatically adapts to your layout and device size
Built for Analysts, Traders, and Educators

Whether you’re building models, writing research, teaching, or running a fintech product, these embeds let you present live macroeconomic data without engineering work.

Designed for Reliability and Performance

Each widget runs on the same architecture powering the FXMacroData dashboards, backed by:

Real-time streaming data from our announcement pipeline
Optimized caching for low latency
Cloud Run auto-scaling for high-volatility events

Your embeds stay fast, accurate, and stable — even during major releases when traffic spikes.

Start Embedding Today

Visit any dashboard on FXMacroData and click “Embed Graph” to generate your snippet instantly.

Creating a python SDK for FXMacroData

Robert Tidball — Tue, 25 Nov 2025 13:46:19 +0000

🐍 Building an FX Trading Edge: Creating a Python Client for the FXMacroData API

Robert Tidball for FXMacroData ・ Nov 25

#python #api #github #programming

🐍 Building an FX Trading Edge: Creating a Python Client for the FXMacroData API

Robert Tidball — Tue, 25 Nov 2025 13:45:20 +0000

When building a Python library, the goal is to turn a complex, boilerplate-heavy process (raw API calls) into a simple, elegant one-liner. The FXMacroData API provides real-time macroeconomic indicators for major currency pairs—a goldmine for quant traders and analysts.

Raw API calls force developers to repeat code for authentication, error checking, and URL construction. Embracing the DRY (Don't Repeat Yourself) principle, I set out to build a dedicated Python library on top of it, creating a user-friendly wrapper. This article walks you through the core components of that wrapper, covering synchronous and asynchronous clients, proper exception handling, and utility functions.

1. Project Scaffolding and Handling Authentication

A good library starts with an intuitive entry point. My goal was to turn an HTTP request into a clean Python method call like:

client.get("aud", "inflation")

The Client Constructor

The Client class holds the base URL and API key. The FXMacroData API has a unique feature: USD data is public, but other currencies require an API key. The constructor handles this requirement upfront.

# client.py or async_client.py
from typing import Optional
from .exceptions import FXMacroDataError

class Client:
    BASE_URL = "https://fxmacrodata.com/api"

    def __init__(self, api_key: Optional[str] = None):
        """
        Synchronous FXMacroData Client.
        api_key: Required for non-USD currencies. USD is public.
        """
        self.api_key = api_key

2. Core Logic: The Synchronous Client (`Client`)

The synchronous Client uses the popular requests library. The main logic resides in the get method, which dynamically constructs the URL and enforces the API key requirement.

The `get` Method: Dynamic URL Construction and Key Check

# client.py
def get(
    self,
    currency: str,
    indicator: str,
    start_date: Optional[str] = None,
    end_date: Optional[str] = None,
) -> dict:
    currency = currency.lower()
    url = f"{self.BASE_URL}/{currency}/{indicator}"

    headers = {}
    if currency != "usd":
        if not self.api_key:
            # Custom exception is crucial for user-friendly errors
            raise FXMacroDataError(f"API key required for {currency.upper()} endpoints.")
        headers["X-API-Key"] = self.api_key

    params = {}
    # ... params and API call logic ...

Robust Error Handling with Custom Exceptions

A robust library must handle failures gracefully. I created a custom exception, FXMacroDataError, to catch network issues and non-200 status codes, returning a clear, actionable message.

# exceptions.py
class FXMacroDataError(Exception):
    """Custom exception for FXMacroData client errors."""
    pass

Core request logic with the error wrapper:

# client.py (continued)
try:
    response = requests.get(url, headers=headers, params=params)
except Exception as e:
    raise FXMacroDataError(f"Request failed: {e}")

if response.status_code != 200:
    # Raise a clear error if the API returns a problem
    raise FXMacroDataError(f"API Error ({response.status_code}): {response.text}")

return response.json()

3. Advanced Feature: The Asynchronous Client (`AsyncClient`)

For automated trading bots or high-traffic dashboards, asynchronous programming is essential for performance. The AsyncClient uses the aiohttp library for non-blocking I/O.

Asynchronous Session Management

I implemented async context managers (__aenter__ and __aexit__) to ensure the aiohttp.ClientSession is created and properly closed, preventing resource leaks.

# async_client.py
import aiohttp
# ... imports ...

class AsyncClient:
    # ... init ...

    async def __aenter__(self) -> "AsyncClient":
        self.session = aiohttp.ClientSession()
        return self

    async def __aexit__(self, exc_type, exc_val, exc_tb) -> None:
        if self.session:
            await self.session.close()
            self.session = None

This allows concurrent execution, where the total time is the maximum delay, not the sum:

import asyncio
from fxmacrodata import AsyncClient

async def main():
    async with AsyncClient(api_key="YOUR_KEY") as client:
        # Concurrent calls are now trivial
        data_aud = client.get("aud", "inflation")
        data_eur = client.get("eur", "gdp")

        aud_data, eur_data = await asyncio.gather(data_aud, data_eur)
        # ...

4. Utility: Cleaning Up the Data

Data consumers expect chronologically sorted data, but APIs don't always guarantee it. A small utility function ensures the output is always clean time-series data, checking for either a 'date' or 'release_date' key.

# utils.py
def sort_by_date(data_list):
    """Sorts a list of indicator data dictionaries by 'date' or 'release_date'."""
    return sorted(data_list, key=lambda x: x.get('date') or x.get('release_date'))

Building this wrapper solidified my understanding of Object-Oriented Design, the crucial performance trade-offs between Synchronous vs. Asynchronous networking, and the importance of a great Developer Experience through custom exceptions. You can explore the full source code on GitHub.

The final step was packaging the library and publishing it to PyPI. If you're building a tool to integrate real-time FX macro data, or just want a pattern for creating your own wrapper, the structure of this library is a solid foundation. Happy coding!

— Rob @ FXMacroData

How SuburbStory Uses Asyncio to Pull Multi-Source Government Data in Parallel

Robert Tidball — Mon, 24 Nov 2025 07:16:16 +0000

SuburbStory publishes local updates for every suburb in NSW. The data behind each update comes from several government and public feeds: police, fire, traffic, transport, and various agency alerts. Each of these sources is independent, updated on its own schedule, and exposed through completely different HTTP endpoints.

Because of that variety, the core engineering problem isn’t processing the data. It’s getting it fast enough, from all sources, without creating a slow and fragile chain of sequential API calls. The entire workload is I/O: pulling remote webpages, parsing lightweight text, and sending the processed information to Gemini to generate suburb-level summaries.

The only way to make this practical at state-wide scale is to run everything in parallel. That’s where Python’s asyncio becomes the centre of the system.

The Problem With Sequential Fetching

If you fetch each source one at a time, you create an artificial bottleneck. A single slow feed (for example a public incident feed that occasionally takes a few seconds to respond) blocks all other data from being processed. When you multiply that across hundreds of suburbs, you lose freshness and your cron job runtime becomes unpredictable.

But none of these tasks depend on each other. Each fetch is just an isolated HTTP call. There’s no reason to wait for one to finish before starting the next.

Using asyncio.gather to Hit Every Source at Once
The actual workflow is simple: as soon as the cron job starts, every data source is queried in parallel. Instead of a loop like:

for source in sources:
    data = fetch(source)
    process(data)

the pipeline builds a list of coroutines and launches them simultaneously:

results = await asyncio.gather(*tasks, return_exceptions=True)

Every request goes out at the same time. Each one resolves whenever the remote server responds. A slow feed no longer slows down anything else. A fast feed is processed immediately. When you have tens of government sources multiplied across thousands of suburbs, this difference is enormous.

Parsing and Grouping on the Fly

Once the fetches complete, the content is parsed and normalised. These steps are lightweight — mostly HTML extraction, field cleaning, text slicing, and location matching — so they run inline without blocking the loop. By the time all tasks in the gather call have resolved, you already have a full snapshot of every government update that matters for that cycle.

The next step is grouping by suburb. Because all sources arrive together, the system can assemble a complete picture of what happened in a suburb across police, fire, traffic, and other feeds in a single pass. That grouped data becomes the input to the NLG stage.

Parallel Model Requests to Gemini

Model calls are also I/O. They involve sending the suburb-level dataset to Gemini and waiting for a generated summary. Running these sequentially would be even slower than sequential scraping. But they fit the same pattern as the fetches: independent, high-latency network operations.

So the pipeline builds another batch of tasks (one model call per suburb) and fires them all at once using asyncio.gather, with concurrency limits where needed. While the model is working on one suburb, dozens of other tasks are in flight. No time is spent waiting for NLG work to complete before starting the next one.

This effectively compresses what would be minutes of serialized model calls down to the latency of a single batch.

The entire cycle looks like this:

All data sources fetched concurrently
All parsing done immediately after responses arrive
All suburb summaries generated concurrently
All output stored without blocking the loop

The cron job doesn’t wait on anything except the slowest item in each batch. Everything else is overlapped. Even though the system touches many external endpoints and calls an LLM at scale, the total runtime stays short and predictable because every part of the pipeline runs in parallel.

Why Asyncio Suits This Problem Exactly

The workload behind SuburbStory isn’t CPU-heavy. There’s no local ML model, no heavy processing, no long transformations. It’s almost entirely network-bound. Asyncio is designed for this exact shape of problem: many independent I/O operations that can safely run together.

Using threads or processes would add overhead and resource waste. Using synchronous requests would stretch each cron cycle unnecessarily. Asyncio sits neatly in the middle with minimal overhead, maximum concurrency, and predictable performance.

Flexible Flask Endpoints for Hierarchical Local News on SuburbStory

Robert Tidball — Mon, 17 Nov 2025 03:40:03 +0000

SuburbStory publishes automated local news pages for every suburb in NSW (Australia). The site’s URLs follow a clear geographic hierarchy:

https://suburbstory.com/<country>/<state>/<area>/<suburb>/

Each page is built by aggregating structured data from multiple government sources such as police, fire, traffic, and council feeds. This data is then processed via the Gemini API to generate readable content.

A key challenge is efficiently mapping thousands of geographic URL combinations to a single Flask application.

Dynamic Routing in Flask

Rather than creating a route for each suburb, SuburbStory uses a single, flexible Flask route:

@app.route("/<country>/<state>/<area>/<suburb>/")
def suburb_page(country, state, area, suburb):
    key = f"{country}/{state}/{area}/{suburb}"
    data = fetch_suburb_doc(key)  # fetch data from Firestore
    return render_template("suburb.html", data=data)

Flask automatically parses the URL segments and passes them as function arguments. The handler then retrieves the corresponding Firestore document and renders it with a single template. This allows one route to serve thousands of unique pages across different areas and suburbs without modifying the code.

Real Examples

Two suburbs under the same area illustrate the approach:

These pages use the same route and template while aggregating their own data, demonstrating how hierarchical Flask endpoints efficiently handle multiple suburbs.

Why Hierarchical URLs Matter

The hierarchical pattern country/state/area/suburb has several advantages:

Predictable and SEO-friendly URLs – easy to link externally and for search engines to index.
Direct mapping to Firestore – each page can be stored under a document key like "au/nsw/willoughby/chatswood", simplifying retrieval.
Template reusability – the same suburb.html template dynamically adjusts based on the URL variables.
Scalable architecture – Cloud Run handles all routes in one Flask app, allowing horizontal scaling without additional routing configuration.

Takeaways for Python Developers

SuburbStory demonstrates how flexible Flask routing enables:

Serving thousands of hierarchical pages from a single route
Efficiently handling independent data fetches per page
Scaling a serverless Flask app on Cloud Run without duplicating code
Maintaining clean, predictable, SEO-friendly URLs that map directly to Firestore

This is a practical model for building large-scale local or multi-tenant content systems in Python.

🚀 Scaling Up: Why I Chose FastAPI Over Flask and Django for a Data API

Robert Tidball — Thu, 13 Nov 2025 04:23:02 +0000

As a developer, when you set out to build a new data service—like my recent project, FXMacroData (check out the live API at FXMacroData - Real-time Forex Data) the framework choice is crucial. My goal was simple: serve high-frequency macroeconomic data instantly and reliably.

I narrowed the field down to the Python giants: Flask, Django, and FastAPI. While Flask is famously lightweight and Django is the enterprise powerhouse, I ultimately landed on FastAPI. Here's why that decision was a game-changer for building a performant, modern data API designed for the cloud.

The API Mandate: Speed, Concurrency, and Serverless

The core requirement for the FXMacroData API is high concurrency and an architecture optimized for modern cloud deployments, specifically serverless environments like Google Cloud Run.

Flask (Sync): Standard Flask is synchronous (WSGI), meaning it blocks a worker thread while waiting for I/O (like a database query). This inefficiency makes it harder to scale cost-effectively in a serverless environment where every millisecond of CPU time matters.
Django (Monolithic): Django is excellent, but it’s a heavyweight framework. For a pure API backend, its many built-in components were simply overkill. Deploying a massive framework just to serve a few data endpoints is inefficient, especially when using a flexible NoSQL backend like Firestore. Its complexity and synchronous default were hurdles to fast, cost-effective serverless deployment.

⚡️ FastAPI: Natively Async for Cloud Run

FastAPI is built on the modern ASGI standard, making it asynchronous (async/await) from the ground up. This was the single biggest performance advantage:

Non-Blocking I/O: Most API operations are I/O-bound (waiting for the database or network). Because FastAPI's worker doesn't block, it can efficiently handle hundreds of concurrent requests using minimal resources. This is essential for Cloud Run's scaling model.
Serverless Integration: Being lightweight and ASGI-native means FastAPI runs perfectly within the brief lifespan of a serverless container. It integrates cleanly with external services like Firestore, making it the ideal choice for a stateless, instant-scaling microservice.

The Code Difference: I/O Concurrency

The benefit of native asynchronous programming is immediately clear when requesting data from multiple sources.

➡️ Flask (Synchronous/Blocking)

The total execution time is the sum of the two delays (approx. 2 seconds), as the second call must wait for the first to complete.

# Flask (Synchronous)
import time
from flask import Flask
app = Flask(__name__)

# Execution runs sequentially: A waits for B to finish.
@app.route("/")
def sync_example():
    time.sleep(1)  # Wait for Source A
    time.sleep(1)  # Wait for Source B
    return "Total Time: ~2.0s"

➡️ FastAPI (Asynchronous/Non-Blocking)

The total execution time is the maximum of the two delays (approx. 1 second), as both I/O operations are initiated concurrently.

# FastAPI (Asynchronous)
import asyncio
from fastapi import FastAPI
app = FastAPI()

# Execution runs concurrently: A and B start at the same time.
@app.get("/")
async def async_example():
    await asyncio.gather(
        asyncio.sleep(1),  # Wait for Source A
        asyncio.sleep(1)   # Wait for Source B
    )
    return "Total Time: ~1.0s"

🧠 The Productivity Bonus: Clean Code and Auto-Docs

Beyond performance and cloud architecture, FastAPI delivered on developer experience:

It uses Pydantic models and Python type hints for automatic data validation and serialization.
It generates interactive OpenAPI documentation (Swagger UI) automatically.

Ultimately, FastAPI allowed me to build a high-performance, stateless API that perfectly matches the pay-per-use efficiency of Google Cloud Run, making it technically superior and far more cost-effective than using an over-engineered framework like Django for this specific task.

If you're building a new API focused on speed, data movement, and cloud-native scaling, the choice is clear: go async with FastAPI.

DEV Community: Robert Tidball

Your MCP Server Doesn't Need 40 Tools

The trap: one endpoint, one tool

What changed in production

A tool is a promise

Fewer tools, sharper edges

Names matter more than you want them to

Do not return your whole database row

Build for failure, not the happy path

Your OpenAPI schema still matters

Test the tool list like a UI

Where this came from

The checklist I use now

Closing

Introducing the FXMacroData Economic Data Embed Widget

How Embeds Work

Designed for Reliability and Performance

Start Embedding Today

Creating a python SDK for FXMacroData

🐍 Building an FX Trading Edge: Creating a Python Client for the FXMacroData API

Robert Tidball for FXMacroData ・ Nov 25

🐍 Building an FX Trading Edge: Creating a Python Client for the FXMacroData API

1. Project Scaffolding and Handling Authentication

The Client Constructor

2. Core Logic: The Synchronous Client (Client)

The get Method: Dynamic URL Construction and Key Check

Robust Error Handling with Custom Exceptions

3. Advanced Feature: The Asynchronous Client (AsyncClient)

Asynchronous Session Management

4. Utility: Cleaning Up the Data

How SuburbStory Uses Asyncio to Pull Multi-Source Government Data in Parallel

The Problem With Sequential Fetching

Parsing and Grouping on the Fly

Parallel Model Requests to Gemini

The entire cycle looks like this:

Why Asyncio Suits This Problem Exactly

Flexible Flask Endpoints for Hierarchical Local News on SuburbStory

Dynamic Routing in Flask

Real Examples

Why Hierarchical URLs Matter

Takeaways for Python Developers

🚀 Scaling Up: Why I Chose FastAPI Over Flask and Django for a Data API

The API Mandate: Speed, Concurrency, and Serverless

⚡️ FastAPI: Natively Async for Cloud Run

The Code Difference: I/O Concurrency

➡️ Flask (Synchronous/Blocking)

➡️ FastAPI (Asynchronous/Non-Blocking)

🧠 The Productivity Bonus: Clean Code and Auto-Docs

2. Core Logic: The Synchronous Client (`Client`)

The `get` Method: Dynamic URL Construction and Key Check

3. Advanced Feature: The Asynchronous Client (`AsyncClient`)