Python Stack: FastAPI, SQLAlchemy, Next.js, and more

🚩 Beyond the Hype: What FastAPI Isn’t Designed For FastAPI is often praised as the “next big thing” in Python web frameworks — and for good reason. It’s fast, modern, and developer‑friendly. But it’s not a universal solution. Knowing its limits is just as important as knowing its strengths. ⚠️ Where FastAPI Falls Short 1️⃣ Monolithic full‑stack apps → Unlike Django, FastAPI doesn’t ship with admin panels, templating engines, or opinionated conventions. You’ll need to assemble those pieces yourself. 2️⃣ CPU‑bound workloads → Async I/O shines for APIs, but it won’t speed up heavy compute tasks like image processing or ML training. 3️⃣ Teams new to async → Mixing blocking calls with async endpoints can cause subtle bugs and performance bottlenecks. 4️⃣ Tiny throwaway projects → The type‑hint + Pydantic layer adds overhead that simpler frameworks (like Flask) might avoid. 5️⃣ Feature‑rich ecosystems → FastAPI’s plugin ecosystem is growing, but it’s still smaller than Django or Flask for niche needs. 🛠️ Trade‑offs & Mitigations 1️⃣ Ecosystem gaps → Pair FastAPI with proven libraries or use Django for monoliths. 2️⃣ Async complexity → Stick to async‑compatible DB drivers and offload blocking tasks to worker pools. 3️⃣ CPU workloads → Use Celery, RQ, or separate services for compute‑heavy jobs. 4️⃣ Operational maturity → Invest in CI/CD templates and clear conventions to avoid reinventing the wheel. ✅ Quick Checklist Before Choosing FastAPI 1️⃣ Is your workload I/O‑bound and API‑centric? 2️⃣ Does your team understand async/await? 3️⃣ Are your dependencies async‑compatible? 4️⃣ Do you have a plan for CPU‑heavy tasks? 5️⃣ Have you benchmarked endpoints under expected load? 💡 The honest one‑liner:   FastAPI is a high‑velocity engine for async APIs — not a drop‑in replacement for mature monoliths or compute‑heavy platforms. #FastAPI #Python

🚀 Just shipped a full-stack URL Shortener from scratch! Here's what I built and the tech behind it: 🔗 Core Features: • Shorten any long URL to a clean short link • QR code generation for every shortened URL (downloadable as PNG) • Click tracking & analytics • Optional expiry dates on links 🛠️ Tech Stack: • Backend → FastAPI (Python) with SQLAlchemy ORM • Database → PostgreSQL on AWS RDS • Frontend → Next.js + React + Tailwind CSS • Short code algorithm → Base62 encoding on auto-incremented IDs ⚙️ Key engineering decisions: → Base62 encoding on DB primary key = zero collision short codes → Moved from local Postgres to AWS RDS for production-grade persistence → CORS-configured FastAPI to talk securely with the Next.js frontend → QR codes generated client-side using qrcode.react — no extra API calls Building this taught me a lot about full-stack architecture, cloud databases, and API design. Always more to add — custom domains, auth, dashboards — but shipping > perfecting. Open to feedback from anyone who's built something similar! 👇 #Python #FastAPI #NextJS #React #AWS #FullStack #WebDevelopment #BuildInPublic #SoftWareEngineer

Excited to share our Supabase → Django migration playbook 🚀 Over the past few months, we migrated our platform off Supabase - 109 tables, ~1,950 columns, complex RLS, multi-tenancy, and a set of Supabase Edge Functions, to a production Django REST Framework backend. It was a complex project, so we documented the complete process and are happy to share. What’s in the repo: 📦 A phase-by-phase runbook From schema extraction and inspectdb, through model splitting, migration generation, DRF scaffolding, Celery task conversion, frontend API rewrites, and seed data loading. 🛠️ Helper scripts we built along the way splitmodels.py — route 100+ models into logical Django apps generate_drf.py — scaffold serializers, views, and URLs for each app diff_models.py — compare inspectdb output with hand-edited Django models migrate_supabase.js — rewrite Supabase client calls to Django API calls across the frontend split_seed.py + verify_seed.py — split SQL exports into dependency-aware load files and verify row counts check_model_imports.py + check_class_locations.py — catch cross-app import and model location issues before runtime ⚠️ A few gotchas that cost us real time inspectdb can emit max_digits=65535 on DecimalFields, which needs bulk cleanup Supabase manages auth.users outside the public schema, so you need to stub it manually before import Seed foreign-key ordering matters — Supabase exports alphabetically, not by dependency After splitting models across apps, cross-app relations should use string references like 'app.ModelName' The README includes the actual commands, structure, and checks we used during the migration. If you’re considering moving off Supabase, this may save you a lot of time. And if you just want to see how we approached a large Django migration, have a look. Feedback is very welcome. 🔗 https://lnkd.in/gTmcsrJp *Star the repo if it is useful and help others find it. #noor #Django #Supabase #Python #BackendEngineering #OpenSource #SoftwareEngineering

🚀 Why FastAPI feels easier than Node.js (Express) for backend APIs As someone coming from a Node.js background, I noticed a huge difference while building APIs with FastAPI… 👉 In Node.js (Express), I had to: • Access `req.body` manually • Write validation logic (Joi/Zod or custom) • Handle edge cases myself ⚡ But in FastAPI: I just define a Pydantic model… and that’s it. FastAPI automatically: ✔ Validates input ✔ Converts data types ✔ Returns clean, structured objects 💡 The biggest realization: 👉 Pydantic acts as both *schema + validator* using Python type hints. This removes a lot of boilerplate and makes the code much cleaner. 🔧 Under the hood: • Starlette → routing & web layer • Pydantic → data validation • Uvicorn → high-performance ASGI server 📌 Currently building CRUD APIs and diving deeper into backend systems. If you're learning backend or switching from Node.js, FastAPI is definitely worth exploring 🚀 #FastAPI #Python #BackendDevelopment #NodeJS #APIDevelopment #LearningInPublic #BuildInPublic

🔧 The best apps in the world are powered by bulletproof backends. Are yours? If you're serious about backend engineering, it's time to level up — HARD. Modern Backend Engineering: Node.js & FastAPI is a 12-week intermediate course built for developers ready to build secure, high-performance systems that can handle the real world. 💪 What's on the menu: ✅ Node.js Event Loop, Streams & Async Patterns ✅ Express.js & Fastify for blazing-fast APIs ✅ FastAPI with Python: Pydantic & Dependency Injection ✅ JWT, OAuth2 & API Key Authentication ✅ PostgreSQL, MongoDB & Redis integration ✅ Prisma, SQLAlchemy & TypeORM ✅ Background jobs with BullMQ & Celery ✅ WebSockets & real-time communication ✅ AWS S3 & Cloud file storage ✅ Swagger/OpenAPI documentation ✅ Capstone: Ship a production-ready backend API 🏗️ 📦 22 modules. 12 weeks. 3 sessions/week. All online. 🏆 Industry certificate included 💰 $20 — use code 43%coupon to save big! Real backends. Real challenges. Real skills. 🔥 🚀 Enroll now and engineer backends that don't break! 🔗 https://lnkd.in/drViaK4N #NodeJS #FastAPI #BackendDevelopment #APIs #PostgreSQL #Redis #Docker #SoftwareEngineering #Python #OnlineLearning

𝙁𝙧𝙤𝙢 𝘿𝙖𝙩𝙖𝙨𝙚𝙩 𝙩𝙤 𝘿𝙚𝙥𝙡𝙤𝙮𝙚𝙙 𝘼𝙋𝙄: 𝙈𝙤𝙫𝙞𝙚 𝙍𝙚𝙘𝙤𝙢𝙢𝙚𝙣𝙙𝙖𝙩𝙞𝙤𝙣 𝙎𝙮𝙨𝙩𝙚𝙢🎬🚀 I’m really enjoying the journey of bridging the gap between ML and Full-Stack Development . From data preprocessing → model building → API → containerization → deployment → web integration, this project helped me understand the complete workflow of deploying a machine learning system T𝐞c𝐡 𝐒t𝐚c𝐤: Python (Scikit-learn) | FastAPI | Docker | .NET Core | Vue.js 𝑻𝒉𝒆 𝑾𝒐𝒓𝒌𝒇𝒍𝒐𝒘 :- 𝐃𝐚𝐭𝐚𝐬𝐞𝐭: Used the TMDB dataset to train a movie recommendation model. 𝐃𝐚𝐭𝐚 𝐏𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠: Performed preprocessing, selected relevant fields, and generated tags for each movie. 𝐓𝐞𝐱𝐭 𝐕𝐞𝐜𝐭𝐨𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧: Applied Bag of Words to convert text into vectors. 𝐓𝐞𝐱𝐭 𝐂𝐥𝐞𝐚𝐧𝐢𝐧𝐠: Implemented stop-word removal and stemming to improve the quality of features. 𝐒𝐢𝐦𝐢𝐥𝐚𝐫𝐢𝐭𝐲 𝐂𝐚𝐥𝐜𝐮𝐥𝐚𝐭𝐢𝐨𝐧: Used cosine similarity to identify the closest movies and generate recommendations. 𝐀𝐏𝐈 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭: Exposed the model through a FastAPI endpoint. 𝐂𝐨𝐧𝐭𝐚𝐢𝐧𝐞𝐫𝐢𝐳𝐚𝐭𝐢𝐨𝐧: Containerized the application using Docker. 𝐃𝐞𝐩𝐥𝐨𝐲𝐦𝐞𝐧𝐭: Pushed the Docker image to Docker Hub and served the model. 𝐅𝐫𝐨𝐧𝐭𝐞𝐧𝐝 & 𝐖𝐞𝐛 𝐈𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐢𝐨𝐧: Built the web interface using ASP.NET Core MVC with Vue.js. 𝐖𝐚𝐧𝐭 𝐭𝐨 𝐩𝐫𝐚𝐜𝐭𝐢𝐜𝐞 𝐰𝐢𝐭𝐡 𝐦𝐲 𝐦𝐨𝐝𝐞𝐥? If you are learning Frontend, Backend, or API Integration and want a working ML model to test your skills , don't worry . You can pull my trained model directly from Docker Hub and start building your own interface around it: 👉 𝒅𝒐𝒄𝒌𝒆𝒓 𝒑𝒖𝒍𝒍 𝒉𝒂𝒎𝒛𝒂1086/𝒎𝒐𝒗𝒊𝒆-𝒓𝒆𝒄𝒐𝒎𝒎𝒆𝒏𝒅𝒂𝒕𝒊𝒐𝒏-𝒎𝒐𝒅𝒆𝒍 #MachineLearning #DataScience #DotNet #Docker #FastAPI #VueJS #WebDev

⚙️ Ever wondered what actually happens when you hit a Django API? You send a request. You get a response. But internally, Django follows a structured pipeline 👇 👉 1. Request hits the server (WSGI/ASGI) Django receives the HTTP request via WSGI (sync) or ASGI (async). 👉 2. Middleware kicks in Before your view runs, middleware can: Authenticate users Handle sessions Modify request/response 👉 3. URL Routing (urls.py) Django checks your URL patterns and maps the request to the correct view. 👉 4. View logic executes This is where your core logic lives: Process request data Call services Interact with models 👉 5. ORM interacts with Database Django ORM converts Python queries into SQL and fetches/saves data. 👉 6. Serializer / Template (if API or frontend) DRF → converts data to JSON Templates → render HTML 👉 7. Response travels back (again via middleware) Response passes through middleware and returns to the client. 💡 Simple flow: Client → Server → Middleware → URL → View → ORM → Response Why this matters 👇 Helps in debugging real issues Makes you confident in interviews Improves how you structure backend code I’m currently deep-diving into Django while building backend projects and understanding how things work under the hood. Let’s connect & grow together 🤝 #Django #Python #BackendDevelopment #WebDevelopment #Developers #LearningInPublic

Most backend developers are solving problems they don't have. Hot take: if your app serves under 10,000 requests per minute, you probably don't need: ❌ Microservices ❌ Kubernetes ❌ Event-driven architecture ❌ A message queue for every operation I've seen teams spend 3 months building a "scalable" microservice architecture for an app with 200 daily users. You know what would've worked? A single Django app on a $20 VPS. Here's my rule of thumb: 🔹 Start with a monolith. Always. Django or FastAPI — pick one and build fast. 🔹 Add Celery only when you have actual background work that blocks user requests. Not because "we might need it later." 🔹 Split into services only when you have a clear boundary AND a team large enough to own each service independently. 🔹 PostgreSQL handles more than you think. I've seen single instances handle 50K transactions/second with proper indexing. Before you add Redis, Kafka, or RabbitMQ — ask: did I optimize my queries first? The best architecture is the one your team can debug at 3 AM. I'm not anti-microservices. I've built them. They solve real problems — at scale, with dedicated teams. But premature complexity is technical debt disguised as best practice. Ship the monolith. Optimize when data tells you to. Split when pain forces you to. Disagree? I'd genuinely love to hear your counterargument. When did microservices save your project early on? #SoftwareEngineering #BackendDevelopment #Python #Django #WebDevelopment

Hot take: "monolith vs microservices" is not about the number of RPMs or users. It's about the nature of your services and their lifecycles. Good luck with "hot-reloading" a monolith that's running some "background work" EVEN if it doesn't "block users requests". Same about long-running connections. - Did streaming crash? Oh it's because we rolled an update. But at least we don't have a cognitive load overhead! Same about stateful services, like game bots. Oh, and different services also have different stability and recoverability requirements. Fail fast? Well not with a monolith!

Hot take: I've seen engineers spend 2 hours configuring a Docker Compose file just to test a 10-line function. You don't need a full Postgres instance to test a user service. You don't need a Redis container to test a cache layer. You need fast, isolated, reliable tests. That's why I open-sourced @backend-master/test-utils. package- https://lnkd.in/guWmyCRe github- https://lnkd.in/gtx9GYPR Here's what it solves: ❌ Before: Spinning up databases just to test a findOne query ✅ After: MockDatabase with full CRUD in 3 lines of code ❌ Before: Manually building mock HTTP response objects ✅ After: HttpTestBuilder.ok({ userId: 1 }) — done ❌ Before: Hardcoded test data that breaks randomly ✅ After: Fixtures.user(), Fixtures.products(10) — realistic every time ❌ Before: let wasCalled = false; someService.fn = () => { wasCalled = true; } ✅ After: Spy.create() — call count, args, errors, all built-in Built with TypeScript. Zero runtime dependencies. MIT licensed. I'd love feedback from backend engineers — what testing pain point should I tackle next? What should I build next? Drop a comment 👇 → PostgreSQL adapter → GraphQL test utilities → Stream mocking → Event emitter mocks #TypeScript #BackendEngineering #SoftwareTesting #NodeJS #OpenSource #NPM #JavaScript