Forem: Vitalii

Why I Bet on FastAPI Over Django (After 10 Years of Using It)

Vitalii — Tue, 09 Sep 2025 19:32:31 +0000

A senior developer's honest take on switching from Django to FastAPI in 2025

The Switch That Surprised Me

Ten years ago, I started my career building web applications with Django. It was 2015, Django was mature, and the ecosystem was rich. I built everything from e-commerce platforms to SaaS dashboards, and Django served me well. The admin panel was magic, the ORM was intuitive, and the "batteries included" philosophy meant I could ship fast.

But today? Almost everything I build – whether it's client work or my own products – runs on FastAPI.

This isn't a "Django is dead" story. It's about choosing the right tool for how we build software in 2025. Let me show you the data, share my real experience, and explain why this shift happened.

The Numbers Don't Lie

First, let's look at the momentum:

GitHub Stars (September 2025):

FastAPI: ~89,300 ⭐
Django: ~84,900 ⭐
Flask: ~70,300 ⭐

Release Timeline:

Django: July 2005 (20 years old)
FastAPI: December 2018 (7 years old)

FastAPI overtook Django in GitHub stars despite being 13 years younger. That's not just hype – that's developers voting with their commits.

Performance Reality:
According to TechEmpower benchmarks, Uvicorn/Starlette (FastAPI's foundation) consistently ranks among the fastest Python web frameworks. While real-world performance depends on your specific use case, the foundation matters when you're building API-heavy applications.

Async-First vs. Async-Added

This is where the philosophical difference becomes practical.

FastAPI was built on ASGI, Starlette, and Pydantic from day one. Everything is async-native:

# FastAPI - async is natural
@app.post("/process-data")
async def process_data(data: DataModel):
    result = await external_api_call(data)
    await save_to_database(result)
    return {"status": "processed"}

Django added async support in version 3.0, and it's genuinely good today. But it's still layered on top of a sync-first architecture:

# Django - async works but feels added-on
@sync_to_async
def get_user_sync(user_id):
    return User.objects.get(id=user_id)

async def process_user(request):
    user = await get_user_sync(request.user.id)
    # Mix of sync/async patterns

My Experience: When building IO-heavy applications – APIs that call external services, Slack bots, streaming endpoints, cloud integrations – FastAPI feels cleaner. The async patterns are consistent throughout the stack.

Type Hints as a Superpower

This might be FastAPI's killer feature: it treats Python type hints as a first-class citizen.

FastAPI leverages types for:

Request/response validation
Automatic API documentation
Editor autocompletion
Runtime parsing

# FastAPI - types do the work
from pydantic import BaseModel

class CreateUserRequest(BaseModel):
    email: str
    name: str
    age: int

@app.post("/users")
async def create_user(user: CreateUserRequest):
    # Automatic validation, docs, and IDE support
    return {"user_id": 123, "email": user.email}

Django doesn't leverage type hints for validation or documentation:

# Django - manual validation
def create_user(request):
    data = json.loads(request.body)
    # Manual validation needed
    if 'email' not in data or '@' not in data['email']:
        return JsonResponse({'error': 'Invalid email'})
    # ... more manual checks

Concrete Benefit: I spend less time debugging "what's this payload shape again?" issues. The types are the documentation, and they're enforced at runtime.

Batteries-Included vs. Pick-Your-Stack

This is the classic trade-off, and both approaches have merit.

Django ships with:

ORM (Django Models)
Admin interface
Authentication system
Form handling
Template engine
URL routing

FastAPI is minimal:

You choose your ORM (SQLAlchemy, SQLModel, Tortoise)
You pick your admin solution
You select auth strategies
You decide on task queues

The Trade-off:

Django is faster for CRUD-heavy back offices and content management
FastAPI is better for API-first products where you want control over your stack

My Take: For internal tools and admin-heavy applications, Django's batteries are still unmatched. But for modern SaaS backends, I prefer choosing my components.

Real-World Usage

FastAPI isn't just for side projects. Here's who's using it:

Netflix uses FastAPI for Dispatch, their incident management system. When Netflix has an outage, FastAPI helps coordinate the response.

Uber leverages FastAPI in Ludwig for serving machine learning models. High-performance ML inference demands async capabilities.

Microsoft uses FastAPI for several Azure services and internal tools.

Django still powers massive applications:

Instagram's backend (though they've heavily customized it)
Mozilla's websites
The Washington Post
Pinterest (parts of it)

Both frameworks have proven they can scale. The question is which one fits your project better.

Developer Velocity: My Personal Experience

After building with both frameworks extensively, here's where I see differences:

Scaffolding Speed:

FastAPI: Less boilerplate, more explicit composition
Django: More setup, but more decisions made for you

API Documentation:

FastAPI: Auto-generated OpenAPI docs that developers actually use
Django: DRF can generate docs, but it requires more setup

Testing:

FastAPI: httpx + pytest feels natural and fast
Django: Great testing framework, but more ceremony

Example - Simple POST Endpoint:

# FastAPI (8 lines)
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float

@app.post("/items/")
async def create_item(item: Item):
    return {"item": item, "status": "created"}

# Django + DRF (20+ lines across multiple files)
# models.py
from django.db import models
class Item(models.Model):
    name = models.CharField(max_length=100)
    price = models.DecimalField(max_digits=10, decimal_places=2)

# serializers.py
from rest_framework import serializers
class ItemSerializer(serializers.ModelSerializer):
    class Meta:
        model = Item
        fields = '__all__'

# views.py
from rest_framework import generics
class CreateItemView(generics.CreateAPIView):
    serializer_class = ItemSerializer

# urls.py
from django.urls import path
urlpatterns = [path('items/', CreateItemView.as_view())]

The Caveat: Django's admin interface still rules for internal tools. If you need a quick admin panel, Django wins hands down.

Performance Realities

Let's be honest about performance:

CPU-bound workloads: Both frameworks hit the same Python bottleneck. If you're doing heavy computation, the framework choice won't save you.

IO-bound workloads: This is where FastAPI shines. Async concurrency handles database calls, API requests, and file operations more efficiently.

Real numbers from my experience:

API serving mostly database queries: Similar performance
API with external service calls: FastAPI handled 3x more concurrent requests
WebSocket connections: FastAPI's async nature made this much simpler

Django ASGI is improving rapidly, but FastAPI's defaults are simpler to configure and reason about.

Migration Notes

If you're a Django developer considering FastAPI:

Good news: The learning curve is gentle. You already understand web concepts, ORMs, and Python patterns.

Key difference: Django uses "magic" (conventions, metaclasses, implicit behavior). FastAPI uses explicit composition. You make more decisions upfront, but the code is more predictable.

Team considerations:

Junior developers might prefer Django's conventions
Senior developers often appreciate FastAPI's explicitness
Both have excellent documentation and community support

Decision Framework

Here's how I choose between them today:

Choose Django when:

Building a monolith with admin interface needs
Team prefers conventions over configuration
Content-heavy applications (CMS, blogs, e-commerce)
Rapid prototyping of CRUD applications
You need Django's mature ecosystem (packages, hosting, etc.)

Choose FastAPI when:

Building API-first services
Async workflows are central to your app
You want modern Python patterns (type hints, async/await)
Machine learning or data science integration
Microservices architecture
You prefer explicit over implicit

Deployment in 2025

Both frameworks deploy well, but the patterns differ:

FastAPI:

# Simple container deployment
uvicorn main:app --host 0.0.0.0 --port 8000
# Or with Gunicorn for production
gunicorn main:app -w 4 -k uvicorn.workers.UvicornWorker

Django:

# Traditional deployment
gunicorn myproject.wsgi:application
# Or ASGI for async features
daphne myproject.asgi:application

Both work great with Docker, Kubernetes, and modern hosting platforms. FastAPI's async nature can be more resource-efficient for IO-heavy workloads.

The Honest Conclusion

Django isn't obsolete. It's still rock-solid for many use cases, and the ecosystem is unmatched for certain types of applications.

But for API-first products in 2025, FastAPI gives me:

Faster iteration cycles
Cleaner developer experience
Better async patterns
Fewer integration headaches
More predictable code

That's why I bet on it for my new projects.

The real winner? Python developers. We have two excellent frameworks that excel in different areas. Choose based on your project needs, not framework wars.

Want to learn FastAPI hands-on? I built FastAPI Interactive where you can code FastAPI directly in your browser with real-time testing and feedback. Perfect for Django developers making the switch.

Ready to build your next product with FastAPI? Check out Craft Your Startup - a production-ready FastAPI + React SaaS boilerplate that handles auth, payments, and deployment so you can focus on your core features.

What's your experience switching between Python frameworks? Share your thoughts in the comments below.

Learn FastAPI the Interactive Way — A Hands-On Tutorial Platform

Vitalii — Fri, 29 Aug 2025 20:38:35 +0000

Learn FastAPI the Interactive Way

FastAPI is one of the fastest-growing Python frameworks for building APIs.

It’s async-first, leverages type hints, and comes with automatic validation and documentation.

But the first hurdle for many learners is setup: installing dependencies, configuring uvicorn, and managing environments before you even write code.

FastAPI Interactive solves this by bringing everything into the browser — so you can start coding right away.

What is FastAPI Interactive?

👉 fastapiinteractive.com

It’s a free browser-based learning platform for FastAPI.

Each lesson includes:

Short theory sections (concept explained clearly)
An editor + console to write and run FastAPI code
Instant feedback with automated checks
Progress tracking across lessons

Think of it as "learn by coding" instead of "learn by reading".

The Learning Path: FastAPI Basics

The first course, FastAPI Basics, has 30 lessons (about 35 hours total).

Here’s the full list so far:

⚡ This isn’t the full curriculum yet. I’m actively working on adding more lessons and plan to release bigger, project-oriented tutorials — like building standalone APIs for blogs, chatbots, and other real-world apps.

What Makes It Different?

FastAPI Interactive is not just about reading theory. It’s about doing.

Here’s what you can do inside the platform:

Write and run code directly in the browser
Execute real tests against your solutions
Send custom payloads to your endpoints and see how they respond
Experiment with variations of your code and get instant feedback

This means you’re not just learning concepts — you’re practicing how to build and test APIs like you would in a real project.

Example Lesson: File Uploads

In the Request Files lesson you’ll learn two ways to upload files:

from fastapi import FastAPI, File, UploadFile

app = FastAPI()

@app.post("/files/")
async def create_file(file: bytes = File()):
    return {"file_size": len(file)}

@app.post("/uploadfile/")
async def create_upload_file(file: UploadFile):
    return {"filename": file.filename}

File() → gives you file content as bytes (good for small files).
UploadFile → provides metadata + streaming, better for larger files.

Why This Approach Works

Hands-on → You actually build endpoints, not just read docs.
No setup → Everything runs in the browser, no Docker hell.
Instant feedback → Tests confirm if your code works.
Real-world concepts → From query params to file uploads, it’s what you’d use in production.

Accessibility & Good Practices

Each lesson encourages validation (using Pydantic models, enums, unions).
Exercises highlight security considerations like sanitizing filenames and checking content types.
The course structure keeps a natural heading flow (H2/H3), making it easy to follow for screen readers.

How to Start

Visit 👉 fastapiinteractive.com

Open the first lesson and code directly in your browser — no Python installation required.

Final Thoughts

FastAPI is quickly becoming a go-to for backend developers.

If you want a practical, zero-setup way to learn, FastAPI Interactive gives you that path: short theory + real coding + instant feedback.

Try it here: fastapiinteractive.com

Stop Writing API Types Twice: How Auto-Generated TypeScript Clients Save 10+ Hours Per Week

Vitalii — Tue, 15 Jul 2025 08:25:10 +0000

Every time I add a new API endpoint, I write the same code twice. Once in Python. Once in TypeScript. Then I spend more time writing the actual HTTP calls. Until I discovered this solution...

The Problem Every Full-Stack Developer Knows

You just spent 30 minutes building a perfect FastAPI endpoint:

@app.post("/users")
def create_user(user: UserCreate) -> UserResponse:
    # Your brilliant code here
    return UserResponse(id=new_user.id, email=new_user.email)

Now you need to use it in React. Time to manually write TypeScript types:

interface UserCreate {
  email: string;
  name: string;
  // ... 15 more fields
}

interface UserResponse {
  id: string;
  email: string;
  // ... and again
}

Then write the actual API call:

const createUser = async (userData: UserCreate): Promise<UserResponse> => {
  const response = await fetch('/api/users', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(userData)
  });

  if (!response.ok) {
    throw new Error('Failed to create user');
  }

  return response.json();
};

Sound familiar? You're not alone. Every full-stack developer does this dance.

The Hidden Costs

This manual approach costs you:

Time: 10+ hours per week writing duplicate code
Bugs: API changes but frontend types don't get updated
Frustration: Why am I writing the same thing twice?
Maintenance: Keeping types in sync becomes a nightmare

The Solution: Auto-Generated TypeScript Clients

Here's the secret: FastAPI already generates OpenAPI specs. Your API documentation at /docs proves it. Why not use that to generate your frontend code?

One command generates everything:

npm run generate-client

This creates:

✅ All your TypeScript types (automatically synced)
✅ Complete API service methods (no more manual HTTP calls)
✅ Type-safe error handling (catch issues at compile time)
✅ Request/response validation (runtime safety)

Before vs After

Before (manual nightmare):

// You write this by hand... every time
const response = await fetch('/api/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify(userData)
});

if (!response.ok) {
  const error = await response.json();
  throw new Error(error.detail || 'Request failed');
}

const user = await response.json();

After (generated magic):

// Auto-generated, type-safe, handles everything
const user = await AuthService.createUser(userData);

That's it. One line. Fully typed. Error handling included.

What Gets Generated

The openapi-typescript-codegen library creates a complete TypeScript client:

1. Type-Safe Models

// Generated from your Pydantic models
export interface UserCreate {
  email: string;
  name: string;
  age?: number;
}

export interface UserResponse {
  id: string;
  email: string;
  name: string;
  created_at: string;
}

2. Service Classes

// Generated API methods
export class UsersService {
  public static createUser(
    requestBody: UserCreate
  ): CancelablePromise<UserResponse> {
    return __request(OpenAPI, {
      method: 'POST',
      url: '/api/users',
      body: requestBody,
      mediaType: 'application/json',
    });
  }
}

3. Error Handling

// Built-in error types
export class ApiError extends Error {
  public readonly status: number;
  public readonly statusText: string;
  public readonly body: any;
}

4. Request Configuration

// Automatic base URL handling, authentication, headers
export const OpenAPI: OpenAPIConfig = {
  BASE: '',
  CREDENTIALS: 'include',
  // ... all configuration handled
};

How to Set This Up (5 Minutes)

Step 1: Install the Generator

npm install openapi-typescript-codegen --save-dev

Step 2: Add Generation Script

{
  "scripts": {
    "generate-client": "openapi --input http://localhost:8020/openapi.json --output ./src/client --client axios"
  }
}

Step 3: Generate Your Client

# Make sure your FastAPI server is running
uvicorn main:app --reload

# Generate the client (in a new terminal)
npm run generate-client

Step 4: Use It

import { UsersService, UserCreate } from '@/client';

// Type-safe API calls
const newUser = await UsersService.createUser({
  email: 'user@example.com',
  name: 'John Doe'
});

Real-World Development Workflow

Click to see the complete development workflow

# 1. Start your FastAPI backend
uvicorn main:app --reload

# 2. Add/modify an endpoint in Python
# 3. Regenerate the client (30 seconds)
npm run generate-client

# 4. Use new types/methods immediately
# Your IDE now has full autocomplete and type checking

The magic happens when you change your API. Instead of manually updating types in multiple places, you just regenerate and everything syncs automatically.

Pro tip: If you're using a production boilerplate, this gets even smoother with commands like task generate-client that handle environment loading automatically.

The Results

After implementing this approach:

✅ Zero duplicate typing - Write your API once in Python
✅ Always in sync - Types update automatically with your API
✅ Type safety everywhere - Catch errors at compile time
✅ No manual HTTP code - Service methods handle everything
✅ Better error handling - Structured error responses
✅ 10+ hours back in your week for actual features

Common Questions

Q: What if I need custom HTTP logic?
A: The generated client is configurable. You can add interceptors, modify headers, or override individual methods.

Q: Does this work with authentication?
A: Yes! Configure JWT tokens, cookies, or any auth mechanism once in the OpenAPI config.

Q: What about file uploads?
A: Fully supported. The generator handles FormData, multipart uploads, and file downloads.

Beyond Just Time Savings

This isn't just about efficiency. It transforms how you build full-stack apps:

Confidence: Your frontend will never make invalid API calls
Speed: Add features in minutes, not hours
Quality: Compile-time safety prevents runtime errors
Documentation: Your API spec becomes living documentation

💡 Pro Tip: Set up the generation command to run automatically in your development workflow. Some teams run it on git hooks or as part of their build process.

Taking It Further

Auto-generated clients are just the beginning. Once you experience this workflow, you'll want to optimize other parts of your development process:

Automatic environment loading
One-command database migrations
Integrated deployment workflows
Type-safe database models that sync with your API

When you combine all these patterns, you reach what we call "AI Velocity" - where you stop fighting with tooling and start building features at the speed of thought.

The Complete Solution

The setup above works great for any FastAPI + React project. But if you want to skip the configuration and get all the modern patterns working together, we've built a complete boilerplate that includes:

✅ This auto-generation system (with task generate-client)
✅ Automatic environment loading
✅ One-command setup and deployment
✅ Production-ready authentication & payments
✅ 20+ other time-saving developer experience improvements

Check out CraftYourStartup.com - where we've taken every frustrating part of full-stack development and made it automatic.

The age of writing the same code twice is over. Your API is your contract. Make it generate everything else.

What's your biggest pain point in full-stack development? Let me know in the comments! 👇

If this helped you, please ❤️ and share with other developers who are tired of writing the same code twice!

Setting Up Cursor Rules: The Complete Guide to AI-Enhanced Development

Vitalii — Sun, 13 Jul 2025 16:30:54 +0000

Transform your coding experience with properly configured Cursor Rules that actually work

What Are Cursor Rules?

Think of Cursor Rules as your AI assistant's instruction manual. They're custom guidelines that tell Cursor's AI how to behave when writing code, making suggestions, and helping with your project. Instead of generic responses, you get context-aware help that understands your specific tech stack, coding patterns, and project structure.

Why Most Developers Set Up Cursor Rules Wrong

Most developers either:

Skip rules entirely - Missing out on 80% of Cursor's potential
Copy-paste generic rules - Getting mediocre, one-size-fits-all responses
Write overly complex rules - Confusing the AI with too many instructions
Use outdated .cursorrules files - Missing the new powerful features

The Right Way: Project Rules vs Global Rules

Project Rules (Recommended)

Store rules in .cursor/rules/ directory - they're version-controlled and specific to your project.

Global Rules

Set in Cursor Settings for preferences that apply to all projects (coding style, communication preferences).

Setting Up Your First Rule

Step 1: Create a Basic Rule File

# Create the rules directory
mkdir -p .cursor/rules

# Create your first rule
touch .cursor/rules/project-overview.mdc

Step 2: Write Your Rule

Create a file with this structure:

---
description: "Core project context and patterns"
globs: 
alwaysApply: true
---

Then add your rule content:

# My Project Rules

## Tech Stack
- Frontend: React 18 + TypeScript + Vite
- Backend: Node.js + Express + MongoDB
- Styling: Tailwind CSS

## Code Standards
- Use TypeScript for all new files
- Prefer functional components over classes
- Always include error handling
- Use descriptive variable names

## File Structure
- Components in `/src/components/`
- Utilities in `/src/utils/`
- API calls in `/src/services/`

Rule Types Explained

1. Always Applied Rules

YAML Configuration:

---
description: Core project context
alwaysApply: true
---

Perfect for: Project overview, tech stack, coding standards

2. Auto-Attached Rules

YAML Configuration:

---
description: React component patterns
globs: ["**/*.tsx", "**/*.jsx"]
alwaysApply: false
---

Perfect for: File-type specific patterns (React components, API routes, etc.)

3. Manual Rules

YAML Configuration:

---
description: Database migration guide
alwaysApply: false
---

Perfect for: Specific workflows you trigger with @rule-name

Real-World Example: CraftYourStartup Boilerplate

Let me show you how we set up Cursor Rules for our production FastAPI + React boilerplate:

Core Project Rule

File: .cursor/rules/000-core-project.mdc

Configuration:

---
description: CraftYourStartup boilerplate architecture
alwaysApply: true
---

Rule Content:

# CraftYourStartup Boilerplate

## Architecture
- **Backend**: FastAPI + SQLModel + PostgreSQL
- **Frontend**: React 18 + TypeScript + MUI v6
- **Authentication**: JWT + OAuth (Google)
- **Payments**: Stripe integration

## Clean Architecture Pattern
ALWAYS follow: Controllers → Services → Models
- **Controllers** (`app/controllers/`): HTTP handling only
- **Services** (`app/services/`): Business logic
- **Models** (`app/models.py`): Database models

## Development Commands

# Backend
task run-backend              # Start server
task alembic-upgrade-local    # Run migrations

# Frontend  
npm run dev                   # Start frontend
npm run generate-client       # Sync API types

Backend-Specific Rules

File: .cursor/rules/backend/backend-patterns.mdc

Configuration:

---
description: FastAPI backend patterns
globs: ["app/**/*.py"]
alwaysApply: false
---

Rule Content:

# Backend Development Patterns

## Service Layer Pattern

Example Service:

class ArticleService:
    def __init__(self, db: Session):
        self.db = db

    async def create_article(self, data: ArticleCreate, user_id: uuid.UUID):
        # Validation
        if len(data.title.strip()) < 3:
            raise ValidationException("Title too short")

        # Business logic
        article = Article(**data.model_dump(), user_id=user_id)
        self.db.add(article)
        self.db.commit()

        return ArticleRead.model_validate(article)

Example Controller:

@router.post("/articles", response_model=ArticleRead)
async def create_article(
    article_data: ArticleCreate,
    current_user: User = Depends(get_current_user),
    service: ArticleService = Depends(get_article_service),
):
    return await service.create_article(article_data, current_user.id)

Frontend-Specific Rules

File: .cursor/rules/frontend/frontend-patterns.mdc

Configuration:

---
description: React component patterns
globs: ["frontend/**/*.tsx", "frontend/**/*.ts"]
alwaysApply: false
---

Rule Content:

# Frontend Development Patterns

## Component Structure

Example Component:

interface ComponentProps {
  title: string;
  onAction?: (id: string) => void;
}

const Component: React.FC<ComponentProps> = ({ title, onAction }) => {
  const { data, isLoading, error } = useQuery();
  const { handleError } = useErrorHandler();

  if (error) {
    handleError(error);
    return null;
  }

  return (
    <Container>
      {isLoading ? <CircularProgress /> : <Content />}
    </Container>
  );
};

Example API Integration:

export const useCreateArticle = () => {
  return useMutation({
    mutationFn: ArticlesService.createArticle,
    onError: handleApiError,
  });
};

Advanced Rules: Templates and References

Using Template References

File: .cursor/rules/templates/service-guide.mdc

Configuration:

---
description: Service template for new features
---

Rule Content:

# Service Template

When creating new services, use this template:

@templates/service-template.py

This ensures consistent patterns across all services.

Template File Example

File: .cursor/rules/templates/service-template.py

from sqlmodel import Session, select
from app.core.exceptions import NotFoundException, ValidationException
from app.models import {ModelName}
from app.schemas.{schema_name} import {ModelName}Create, {ModelName}Update, {ModelName}Read

class {ModelName}Service:
    def __init__(self, db: Session):
        self.db = db

    async def create_{model_name}(self, data: {ModelName}Create, user_id: uuid.UUID) -> {ModelName}Read:
        # Add validation logic here

        # Create instance
        instance = {ModelName}(**data.model_dump(), user_id=user_id)
        self.db.add(instance)
        self.db.commit()
        self.db.refresh(instance)

        return {ModelName}Read.model_validate(instance)

    async def get_{model_name}(self, {model_name}_id: int, user_id: uuid.UUID) -> {ModelName}Read:
        statement = select({ModelName}).where(
            {ModelName}.id == {model_name}_id,
            {ModelName}.user_id == user_id
        )
        result = self.db.exec(statement).first()

        if not result:
            raise NotFoundException(f"{ModelName} not found")

        return {ModelName}Read.model_validate(result)

Testing Your Rules

Quick Test Commands

# Test if rules are loading
ls -la .cursor/rules/

# Test auto-attached rules
# Open a Python file and ask: "Create a new service following our patterns"
# Open a React file and ask: "Create a new component following our conventions"

# Test manual rules
# Type: @database-migration help me create a migration

Validation Checklist

[ ] Rules appear in Cursor's sidebar when active
[ ] Auto-attached rules trigger in correct file types
[ ] Manual rules respond when using @rule-name
[ ] Templates are referenced correctly
[ ] AI responses follow your established patterns

Common Mistakes to Avoid

1. Rules Too Long

❌ Bad: 1000+ line rules that overwhelm the AI

✅ Good: Focused rules under 500 lines each

2. Vague Instructions

❌ Bad: "Write good code"

✅ Good: "Use TypeScript interfaces for all props"

3. Missing Context

❌ Bad: Just listing technologies

✅ Good: Explaining how technologies work together

4. No Examples

❌ Bad: "Follow our patterns"

✅ Good: Including actual code examples

Best Practices

1. Start Simple

Begin with one core rule covering your tech stack and basic patterns.

2. Use Clear Descriptions

---
description: "React component patterns with MUI and error handling"
---

3. Reference Real Files

Look at @components/UserCard.tsx for component structure examples.

4. Keep Rules Updated

Update rules when you change patterns or add new technologies.

5. Test Regularly

Regularly test that your rules produce the expected behavior.

Advanced Organization

Directory Structure

.cursor/rules/
├── 000-core-project.mdc        # Always applied
├── 100-api-workflow.mdc        # Manual workflows
├── backend/
│   └── backend-patterns.mdc    # Auto-attached to .py files
├── frontend/
│   └── frontend-patterns.mdc   # Auto-attached to .tsx files
└── templates/
    ├── service-template.py
    └── component-template.tsx

Rule Naming Convention

000-099: Always applied rules
100-199: Manual workflow rules
200-299: Auto-attached rules
templates/: Referenced templates

Troubleshooting

Rules Not Working?

Check file extension (must be .mdc)
Verify frontmatter syntax
Ensure correct glob patterns
Restart Cursor after changes

AI Ignoring Rules?

Rules might be too long
Multiple conflicting rules
Need more specific examples
Try breaking into smaller rules

The AI Velocity Advantage

When you properly configure Cursor Rules, you unlock what we call "AI Velocity" - the ability to build features dramatically faster while maintaining quality. With our CraftYourStartup boilerplate, developers report:

10x faster feature development - From idea to working code in minutes
Consistent code quality - AI follows your established patterns
Reduced context switching - AI understands your entire stack
Better documentation - Rules serve as living documentation

This velocity advantage becomes your competitive edge, allowing you to iterate faster, ship more features, and respond to market needs with unprecedented speed.

Ready to Transform Your Development?

Cursor Rules aren't just a nice-to-have - they're essential for any developer serious about leveraging AI effectively. Start with a simple project rule, add auto-attached patterns for your main file types, and watch your productivity soar.

The future of development is AI-assisted, and properly configured Cursor Rules are your ticket to that future.

Want to see these patterns in action? Check out our complete startup boilerplate at CraftYourStartup.com - it includes production-ready Cursor Rules that have helped hundreds of developers ship faster.

Modern Full-Stack Setup: FastAPI + React.js + Vite + MUI with TypeScript

Vitalii — Wed, 06 Nov 2024 18:43:05 +0000

Creating a scalable full-stack application can be daunting, but with the right tools, it can be efficient and even enjoyable. In this tutorial, I’ll walk you through building a full-stack application using FastAPI for the back-end, React.js with Vite for the front-end, and Material-UI (MUI) for a clean user interface—all with TypeScript.

If you’re looking for a production-ready, feature-rich setup, I also offer a boilerplate with built-in features like authentication and database integration.

Why This Stack?

FastAPI: Known for its speed and asynchronous capabilities, making it ideal for modern APIs.
React + Vite: Provides a fast development environment and modular frontend structure.
MUI: Gives a polished, professional look with minimal custom styling.

1. Project Structure Overview
Here’s the structure we’ll follow to keep things organized:

my-fullstack-app/
├── backend/               # FastAPI app (Back-End)
│   ├── app/
│   └── pyproject.toml     # Poetry dependencies
└── frontend/              # React (TypeScript) Front-End with Vite
    ├── src/
    ├── package.json
    └── vite.config.ts     # Vite configuration

2. Setting Up FastAPI (Back-End)
First, let’s set up FastAPI:

mkdir -p my-fullstack-app/backend/app
cd my-fullstack-app/backend
pip install poetry
poetry init
poetry add fastapi uvicorn

In backend/app/main.py:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def root():
    return {"message": "Hello from FastAPI!"}

Run the server:

poetry run uvicorn app.main:app --reload

3. Setting Up React with Vite and MUI (Front-End)
Let’s set up the React front-end using Vite and TypeScript.

mkdir ../frontend
cd ../frontend
npm create vite@latest frontend -- --template react-ts
cd frontend
npm install @mui/material @emotion/react @emotion/styled @mui/icons-material axios

Add proxy settings to vite.config.ts:

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

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8000',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
    },
  },
});

4. Connecting React to FastAPI (API Calls)
In src/App.tsx:

import React, { useEffect, useState } from "react";
import axios from "axios";
import { Container, Typography, Button } from "@mui/material";

const App: React.FC = () => {
    const [message, setMessage] = useState<string>("");

    useEffect(() => {
        axios.get("/api/")
            .then(response => setMessage(response.data.message))
            .catch(error => console.error("Error fetching data", error));
    }, []);

    return (
        <Container>
            <Typography variant="h3" gutterBottom>
                FastAPI + React + Vite + MUI (TypeScript)
            </Typography>
            <Typography variant="body1">
                {message || "Loading..."}
            </Typography>
            <Button variant="contained" color="primary" style={{ marginTop: '20px' }}>
                Material UI Button
            </Button>
        </Container>
    );
};

export default App;

5. Running and Testing the App
Run both the back-end and front-end:

# Back-End
cd backend
poetry run uvicorn app.main:app --reload

# Front-End
cd frontend
npm run dev

Your app should now be accessible at http://localhost:3000, with the API proxying requests to FastAPI.

Wrapping Up
In this guide, we set up a full-stack app using FastAPI and React with Vite. This stack provides a clean, scalable structure perfect for modern applications.

If you’re looking for an extended setup with features like user authentication and database integration, feel free to check out the full boilerplate designed for production readiness and startup projects.