I used to think async def = concurrency. Turns out it's a promise I have to keep. Here's what clicked for me about FastAPI performance 👇 First, the mental model I had wrong: I thought async def meant "spread 40 requests across 40 threads and run them in parallel." Nope. Async doesn't use threads at all. The event loop runs everything on one thread and rapidly switches between requests at every await point. The actual waiting (DB, network) happens outside Python , so thousands of requests can be "in-flight" on a single thread. ❌ Wrong: 40 requests → 40 threads in parallel ✅ Right: 40 requests → 1 thread juggling them at every await Now the trap I almost fell into: If your endpoint has a blocking call (like requests.get() or a sync DB query), using async def is actually worse than plain def. 🔹 Plain def: FastAPI offloads to a threadpool (~40 threads). Slow requests run on separate threads. Event loop stays free. Free concurrency. ✅ 🔹 async def with blocking code inside: No await to pause at → the one thread freezes → entire event loop dies. Every other request waits. ❌ My decision guide now: 🔸 No I/O? → def 🔸 I/O with async libraries (httpx, asyncpg)? → async def + await 🔸 I/O but only blocking libraries (requests, psycopg2)? → def 🔸 Heavy CPU work? → neither. Use multiple workers or a task queue. The golden rule: async def is a promise to the event loop that you'll only do non-blocking work. If you can't keep that promise, don't make it. The trap: devs see "async = fast" and slap async def everywhere. But async without real await, is just a slower version of sync. Write async only when you can actually be async. 😀 #Python #FastAPI #WebDevelopment #BackendEngineering
Async Def in FastAPI: Understanding the Performance Myth
More Relevant Posts
-
> Callbacks solved the resource problem (too many threads) by creating an ergonomics problem (code that’s hard to write, read, and get right). What a sussinct statement about the pains of async code, particularly from asyncio in Python and Node.js in Javascript. When it's the right tool for the job, it's wonderful, but it must be applied with caution. Otherwise you'll eventually wind up in "callback hell" Definitely worth a read! https://lnkd.in/gaDTnSrs
To view or add a comment, sign in
-
Rate limiting shouldn't come with a side of dependency hell. 🐍 Most Python rate limiters force a trade-off: either use a basic "fixed-window" script or pull in a heavy framework with a dozen sub-dependencies. This library was built to provide production-grade primitives with an emphasis on architectural flexibility and a zero-dependency footprint. The Technical Breakdown: ✅ 6 Algorithms: Beyond the standard Token Bucket. Includes Fixed/Sliding Windows and ADAPTIVE logic for dynamic scaling. ✅ 3 Backends: Native support for Memory and Redis, supporting both local-first and distributed environments. ✅ Zero Dependencies: Designed for high-security environments and lean builds. No requirements.txt bloat. ✅ Implementation: Clean integration via decorators for functions or middleware for web frameworks. If you are managing API quotas or protecting services from traffic spikes, the implementation details and performance focus are worth a look. https://lnkd.in/gnikRUHa #Python #SoftwareEngineering #SystemDesign #OpenSource #Backend #DistributedSystems
To view or add a comment, sign in
-
-
Wrap any LangGraph agent in one line and get loop detection, budget guards, and a live local-first dashboard. Open source, no SaaS, both TypeScript and Python. I've been building GraphOS — a small but serious observability + policy layer for LangGraph agents. Three things every team eventually hits in production: • Agents loop silently and burn tokens • Budgets blow before anyone notices • Runs are black boxes until they finish GraphOS gives you: ✓ LoopGuard — halts repeated state OR N visits to the same node ✓ BudgetGuard — hard USD ceiling with a built-in OpenAI/Anthropic price table ✓ MCPGuard — allow/deny MCP servers + per-tool call caps ✓ Local React Flow dashboard with time-travel replay (SQLite-backed) This week, I shipped the Python SDK at full feature parity with the TypeScript one, same wrap shape, same dashboard, both languages stream into the same UI. How I validated it: wrapped a real open-source Python LangGraph agent I didn't write (langchain-ai/retrieval-agent-template) end-to-end. The integration caught a bug that 60 green unit tests had missed — the cost extractor only recognized dict-shaped messages, but real LangChain Python ships AIMessage as a Pydantic model. BudgetGuard always saw $0.00. One-line fix, regression test, shipped 1.0.1. That's exactly the kind of bug that handcrafted demos cannot surface. Full story (TS Act I + Python Act II + the bug-find): https://lnkd.in/esHBTTBw Star, fork, feedback all welcome: https://lnkd.in/e3eVrMG3 #OpenSource #LangGraph #AIAgents #Python #Observability
To view or add a comment, sign in
-
-
We lost a week because we treated n8n and Python as interchangeable. They’re not, each fails differently in production. Real Scenario: A team starts in n8n to validate an integration (API auth, payload shape, happy-path). Then it grows: versioned releases, CI/CD, complex branching, unit tests, perf tuning, and a few “we need this auditable” requests. Suddenly the workflow is hard to review, and failures become hard to reproduce. Why It Happens: - n8n optimizes for iteration speed; Python optimizes for control + testability. - Visual flows make state/retries easy to wire, but diffs/reviews are weak vs code. - Python makes contracts/idempotency explicit, but you have to build the guardrails. Production Guardrails: - Use n8n for prototypes, backoffice automations, and low-QPS glue. - Use Python (FastAPI + workers) for high-QPS, strict SLAs, complex logic, regulated environments. - Go hybrid: n8n orchestrates, calls versioned Python “tool” services. - Define interfaces early: schemas, idempotency keys, timeouts, retry budgets. Where do you draw the line what stays in n8n, and what must graduate to Python? #DataEngineering #DataPlatform #WorkflowOrchestration #n8n #Python #Microservices #DataArchitecture #LLMOps #BigData #APIIntegration #EventDrivenArchitecture #Observability For more details please feel free to reach: https://lnkd.in/daPKDHid
To view or add a comment, sign in
-
-
Mastered the HTTP Request-Response Cycle & Methods! 🐍 Moving deeper into my Python Backend journey, I’ve realized that a great API isn't just about the code—it’s about how it communicates. Today, I took a deep dive into HTTP (HyperText Transfer Protocol), the backbone of every interaction on the internet. Here is what I explored today: 🔄 The Request-Response Cycle: Learned how a Client (Browser) and Server (Backend) talk to each other. Understanding that every request I send from the frontend needs a structured response from my FastAPI server. 🛠️ The "Big Four" HTTP Methods: GET: Fetching data safely (The "Read" operation). POST: Sending new data to the server (The "Create" operation). PUT: Replacing or updating existing data (The "Update" operation). DELETE: Removing data from the system (The "Delete" operation). 🚦 Status Codes & Headers: Started identifying the "secret language" of servers—from the successful 200 OK to the dreaded 404 Not Found and 500 Internal Server Error. This knowledge is the bridge between my local Python scripts and the global web. I'm now ready to start building RESTful APIs that can handle real-world traffic! #Python #WebDevelopment #HTTP #BackendDeveloper #CodingJourney #FastAPI #SoftwareEngineering #RESTAPI #TechCommunity #ContinuousLearning
To view or add a comment, sign in
-
-
Most developers use "async" and "parallel" interchangeably. They're not. And confusing them can cost you hours of debugging. 🟢 ASYNCHRONOUS — One task at a time, but smart A single thread starts a task and moves on while it waits. No blocking. No idle time. Tasks don't run simultaneously — they just don't wait around. 🟣 PARALLEL — Multiple tasks at the same time Multiple threads/cores run tasks truly simultaneously. More CPU cores = more throughput. It's about simultaneous execution, not waiting. 🍳 The kitchen analogy: One chef making coffee → toast → eggs while each item cooks = Async Three chefs each cooking a different dish at the same time = Parallel Key differences: → Async solves I/O bottlenecks — API calls, file reads, DB queries. (Node.js, Python asyncio, JS Promises) → Parallel solves CPU bottlenecks — image processing, ML training, data crunching. (Threads, multiprocessing, Go goroutines) → Can they combine? Yes. Async handles waiting. Parallel handles computing. Modern systems use both. Which one do you reach for first in your projects? Drop it below 👇 #programming #javascript #python #softwareengineering #devtips #concurrency #asyncprogramming
To view or add a comment, sign in
-
The worst bugs are the ones where everything looks correct. I was building WebSocket-based camera streaming for my home automation setup. Multiple RTSP cameras, single Python server, no external dependencies. The server-side test? Perfect. Every camera streaming over one WebSocket connection. 209 frames in 12 seconds. Open it in a browser? Code 1006. Connection closed. No reason. No error message. Multiple browsers. Hours of debugging: - TLS certificates? Regenerated with mkcert. Still failed. - Response buffering? Tried raw sendall, wfile, send_response. Still failed. - HTTP version? Forced HTTP/1.1. Still failed. - ALPN negotiation? Set to http/1.1. Still failed. - Built a standalone WebSocket server on a separate port, bypassing the entire HTTP handler. Still. Failed. The 101 Switching Protocols response was byte-for-byte correct. Python clients accepted it. Browsers refused it. The fix? One constant. The WebSocket magic GUID in my code was wrong. Not a typo in one character - the entire last segment was different from what RFC 6455 specifies. Python clients don't validate the Sec-WebSocket-Accept header. They see "101" and proceed. Browsers validate it strictly and silently close with no explanation. Two takeaways: 1. Your test client isn't your user. If you're building for browsers, test with browsers from minute one. 2. Error code 1006 is the most useless error in web development. It means "something went wrong" and tells you nothing about what. Full write-up with the debugging timeline, architecture details, and the exact one-line fix: https://lnkd.in/gtHRqAEc #WebSocket #Python #Debugging #HomeAutomation #RFC6455
To view or add a comment, sign in
-
Sub-100ms APIs Serving 10K+ Requests/Day-Here's What That Actually Takes Spinning up a FastAPI endpoint takes 10 minutes. Making it production-ready takes a lot more. At my current role, I build and maintain REST APIs in Python (FastAPI) and Node.js that serve over 10,000 requests per day — with sub-100ms latency requirements. Here's what "production-ready" actually meant for us: Schema design before code. Every endpoint started with a PostgreSQL schema review. Badly normalized data shows up in latency later. Multithreading is not optional at scale. Single-threaded Python collapses under concurrent load. I built multithreaded data-processing pipelines that improved throughput by 30% under real-world concurrency. Observability from day one. Latency SLAs mean nothing if you can't measure them. Instrumentation and logging were part of the PR, not an afterthought. OOP principles keep it maintainable. Services that grow fast get messy fast. Clean object-oriented design was the only thing that kept the codebase sane as features stacked up. 10K requests/day is not massive by internet scale — but it taught me what production really means. What's the hardest production lesson you've learned? #BackendEngineering #FastAPI #PythonDevelopment #SoftwareEngineering #APIDesign
To view or add a comment, sign in
-
JSON wasn't built for LLMs. TOON was. 🧵 TOON = Token-Oriented Object Notation ✅ Same data model as JSON ✅ ~40% fewer tokens ✅ 74% accuracy vs JSON's 70% (across 4 models) ✅ No curly braces — indentation does the work ✅ Tabular arrays — field names declared once ✅ Minimal quoting — cleaner for models to parse When you're pumping structured data into LLM prompts — user records, API responses, product tables — format efficiency matters. TOON is MIT licensed, spec-driven, and supports TypeScript, Python, Go, Rust, .NET and more. Playground + docs at toonformat.dev #iamabhinav30 #LLM #JSON #TOON #AIEngineering #GenerativeAI #TokenEfficiency #MachineLearning #JavaScript #TypeScript
To view or add a comment, sign in
-
-
Improving Retrieval Quality in RAG and Search Pipelines When retrieval quality breaks down in RAG and search pipelines, it's often due to issues at the document and context layer, long before the model layer. This is where Fincept-Corporation/FinceptTerminal comes in – a modern finance application offering advanced market analytics, investment research, and economic data tools, designed for interactive exploration and data-driven decision-making in a user-friendly environment. Built with Python and leveraging native performance through C++20 with Qt6, FinceptTerminal provides a single binary with no Electron/web overhead, Node.js, browser runtime, or JavaScript bundler. This streamlined approach enables faster and more reliable retrieval, making it an attractive solution for developers working with RAG and search pipelines. What sets FinceptTerminal apart is its focus on the often-overlooked document and context layer. By addressing these issues directly, FinceptTerminal improves retrieval quality and reduces the likelihood of breakdowns further down the pipeline. Key benefits include: - Native performance through C++20 with Qt6 - Single binary with no additional runtime dependencies - Advanced market analytics, investment research, and economic data tools - Built with Python for flexibility and ease of use The traction FinceptTerminal is gaining makes sense: with around 1,169 new stars in the current trending window, it's clear that developers are recognizing the value of its streamlined approach to retrieval quality. As an organization account, FinceptTerminal also benefits from increased trust and distribution. Repo: https://lnkd.in/gbTzmn9k #GitHub #OpenSource #GitHubTrending #LinkedInForDevelopers #Python #FinceptTerminal #BloombergTerminal #ContributionsWelcome
To view or add a comment, sign in
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development