The Problem The Problem When building frontends, I didn't want to hardcode JSON data everywhere. I wanted to build against actual API endpoints and practice the integration work, but spinning up a real backend for every prototype felt like overkill. After doing this dance too many times - writing throwaway Express servers or mocking fetch calls with static JSON - I realized other developers probably face this same friction. The typical workflow looked like this: The typical workflow looked like this: 1. Start building a React component 2. Realize I need user data 3. Choose between: hardcoded JSON arrays OR spinning up Express/Django 4. If I chose Django: pip install requirements, define models, run migrations, write views/URLs, configure CORS 5. All this before writing a single line of frontend logic This context-switching killed momentum. I'd spend 30 minutes on backend setup for a feature that takes 10 minutes to prototype. Multiply this across dozens of projects, and you've lost days to infrastructure overhead. That's why I built MockMyData.io. MockMyData.io. MockMyData.io What It Does What It Does MockMyData.io lets developers generate mock REST API endpoints in seconds. When you sign up, you're automatically assigned a subdomain and API key. Then you define your data schema (field names and types) to create your endpoints. You can either: Enter custom JSON - Full control over your mock data Enter custom JSON Auto-generate records - MockMyData.io creates realistic data based on your field types Auto-generate records Want to try it? Head to https://mockmydata.io - you can generate a demo mock API right from the landing page and start making requests immediately. No sign-up required. https://mockmydata.io Perfect for: Perfect for: Frontend developers building features before backend APIs are ready
Mobile app developers testing API integration without backend dependencies
Building portfolio projects and demos without complex backend setup
Students and bootcamp grads learning API consumption
Rapid prototyping when you need to validate ideas fast Frontend developers building features before backend APIs are ready Frontend developers Mobile app developers testing API integration without backend dependencies Mobile app developers Building portfolio projects and demos without complex backend setup Building portfolio projects Students and bootcamp grads learning API consumption Students and bootcamp grads Rapid prototyping when you need to validate ideas fast Rapid prototyping The Journey: 2.5 Months Solo The Journey: 2.5 Months Solo I went from concept to launch in about 10 weeks, building everything myself. The aggressive timeline kept me focused on shipping rather than over-engineering. Tech Stack: Tech Stack: Backend: Django REST Framework
Frontend: React with Material-UI
Database: PostgreSQL
Caching: Redis
Payments: Stripe
Auth: Firebase SSO
Hosting: Render.com Backend: Django REST Framework Frontend: React with Material-UI Database: PostgreSQL Caching: Redis Payments: Stripe Auth: Firebase SSO Hosting: Render.com Architecture Decisions Architecture Decisions Multi-Tenant Subdomain Architecture Multi-Tenant Subdomain Architecture The core challenge was giving each project its own API endpoint while keeping infrastructure simple. I went with subdomain-based routing where users get automatically assigned subdomains on signup (e.g., `random-name-123.api.mockmydata.io`). Pro users can create custom subdomains and change them anytime. How it works: How it works: - User signs up and gets assigned a subdomain - Pro users can customize: `mycompany.api.mockmydata.io` - All API requests hit their subdomain endpoint Implementation challenges: Implementation challenges: 1. DNS Management 1. DNS Management Had to set up wildcard DNS records pointing all subdomains to the same server. Used Cloudflare for DNS with a wildcard A record (`*.api.mockmydata.io`). 2. SSL Certificates 2. SSL Certificates Needed wildcard SSL certificates to handle unlimited subdomains. Render.com handles automatic SSL certificate provisioning and renewal for wildcard domains, which simplified deployment significantly. 3. Request Routing 3. Request Routing Django's URL routing doesn't natively support subdomain-based tenant isolation. Built custom middleware to: - Extract subdomain from request - Look up project in database - Attach project context to request object - Route to appropriate data # Simplified middleware example
class SubdomainMiddleware:
  def init(self, get_response):
    self.get_response = get_response
  def call(self, request):
    subdomain = request.get_host().split('.')[0]
    try:
      project = Project.objects.get(subdomain=subdomain)
      request.project = project
    except Project.DoesNotExist:
      return HttpResponse('Project not found', status=404)
    return self.get_response(request) # Simplified middleware example
class SubdomainMiddleware:
  def init(self, get_response):
    self.get_response = get_response
  def call(self, request):
    subdomain = request.get_host().split('.')[0]
    try:
      project = Project.objects.get(subdomain=subdomain)
      request.project = project
    except Project.DoesNotExist:
      return HttpResponse('Project not found', status=404)
    return self.get_response(request) Database Design Used PostgreSQL with a shared schema approach rather than separate databases per tenant. Each endpoint and record has a `project_id` foreign key. This keeps infrastructure simple while maintaining data isolation through application-level filtering. Why not separate databases per tenant? Why not separate databases per tenant? - Simpler infrastructure (one database to manage) - Easier backups and migrations - Cost-effective for free tier users - Row-level security handles isolation Technical Challenge #1: Multi-Tier Rate Limiting This was trickier than expected. I needed two types of rate limiting: two types Daily Quotas - Tier-based limits Daily Quotas - Free: 100 requests/day, - Pro: Unlimited Request Throttling - Spam prevention Request Throttling - All tiers: Max 60 requests/minute Why Redis? Why Redis? Needed atomic increments and TTL support. Redis handles both perfectly: def check_daily_quota(self, user):
  """Hard limits for FREE users"""
  daily_count = self.get_daily_count(user.id)

  DAILY_LIMIT = 100

  if daily_count >= DAILY_LIMIT:
    return False, f'Daily limit reached ({DAILY_LIMIT} requests/day)'

  return True, 'OK'

# CloudFlare helps with rate limiting and makes it simple and reliable def check_daily_quota(self, user):
  """Hard limits for FREE users"""
  daily_count = self.get_daily_count(user.id)

  DAILY_LIMIT = 100

  if daily_count >= DAILY_LIMIT:
    return False, f'Daily limit reached ({DAILY_LIMIT} requests/day)'

  return True, 'OK'

# CloudFlare helps with rate limiting and makes it simple and reliable The Challenge: Making this performant at scale The Challenge: - Redis calls add latency - Need to fail fast for rate-limited requests - Must be accurate (can't lose count data) Solution: Batched Redis commands using pipelines reduced roundtrips, cutting rate-check latency significantly. I also implemented a circuit breaker pattern - if Redis goes down, requests pass through to prevent complete service outage. Solution: Technical Challenge #2: Handling Pro-to-Free Downgrades Free users can create up to 3 endpoints. However, when Pro users downgrade to Free, they might already have dozens of endpoints created. Rather than force them to delete endpoints, I let them choose which 3 remain active and accessible via API. This required: - Real-time enforcement in middleware before database queries - Caching to avoid N+1 queries on every API request - Graceful Redis fallback if caching fails The system checks endpoint access on every API request: #(Sample code)
def _check_endpoint_selection(self, request, user, project):
    """Check if endpoint is accessible for downgraded free users"""
    # Pro users: all endpoints accessible
    if user.is_pro_active:
        return True, None   

    # Count total endpoints (cached)
    endpoint_count = cache.get(f'project:{project.id}:endpoint_count')
    # If <=3 endpoints total, all are accessible
    if endpoint_count <= 3:
        return True, None

    # They have >3 endpoints (downgraded from Pro)
    # Check if THIS endpoint is in their selected 3
    endpoint = cache.get(f'endpoint:{project.id}:{path}')
    if not endpoint.default_selected:
        return False, JsonResponse({
            'error': 'Endpoint Not Selected',
            'message': 'This endpoint is not in your active selection. Free users can only have 3 active endpoints.',
            'action_required': 'Visit your dashboard to manage active endpoints'
        }, status=403) 
        
    # If cache miss then we fetch from database #(Sample code)
def _check_endpoint_selection(self, request, user, project):
    """Check if endpoint is accessible for downgraded free users"""
    # Pro users: all endpoints accessible
    if user.is_pro_active:
        return True, None   

    # Count total endpoints (cached)
    endpoint_count = cache.get(f'project:{project.id}:endpoint_count')
    # If <=3 endpoints total, all are accessible
    if endpoint_count <= 3:
        return True, None

    # They have >3 endpoints (downgraded from Pro)
    # Check if THIS endpoint is in their selected 3
    endpoint = cache.get(f'endpoint:{project.id}:{path}')
    if not endpoint.default_selected:
        return False, JsonResponse({
            'error': 'Endpoint Not Selected',
            'message': 'This endpoint is not in your active selection. Free users can only have 3 active endpoints.',
            'action_required': 'Visit your dashboard to manage active endpoints'
        }, status=403) 
        
    # If cache miss then we fetch from database This gracefully handles downgrades without data loss - users keep all their endpoints but must choose which 3 are live. Technical Challenge #3: Handling Anonymous Demo Endpoints Users can create temporary mock APIs without signing up. These urls expire within a short time and have strict limits on the total requests. The challenge was: - Storing temporary projects in Redis (not database) - Enforcing limits without database writes - Supporting full CRUD operations on anonymous data - Updating Redis cache after POST/PUT/PATCH/DELETE All anonymous endpoints get a `demo-` prefix and live entirely in Redis with proper cache updates after mutations. Technical Challenge #4: Storage Limits & Payload Validation Technical Challenge #4: Storage Limits & Payload Validation Implemented 4-layer protection to prevent abuse: Layer 1: Request payload size Layer 1: Request payload size - Free: 5KB per request - Pro: 30KB per request Layer 2: Individual field size Layer 2: Individual field size - Free: 2KB per field - Pro: 10KB per field Layer 3: Item count per endpoint Layer 3: Item count per endpoint - Free: 20 items - Pro: 200 items Layer 4: Total endpoint storage Layer 4: Total endpoint storage - Free: 15KB per endpoint - Pro: 400KB per endpoint This prevents users from storing massive datasets while keeping the service performant and cost-effective. What's Next: Django Project Generator I'm building a feature that exports your mock API as production-ready backend code starting with Django. Here's how it works: Input: Your MockMyData.io project with endpoints defined Input: Output: Complete Django REST Framework project with: Output: - Models generated from your schema - Serializers for each endpoint - CRUD operations - URL routing configured - Authentication setup (Optional) - README with additional instructions & Suggestions Example transformation: Example transformation: Your MockMyData endpoint: {
  "name": "users",
  "fields": {
  "username": "string",
  "email": "email",
  "age": "integer"
  }
} {
  "name": "users",
  "fields": {
  "username": "string",
  "email": "email",
  "age": "integer"
  }
} Generates Django model: class User(models.Model):
username = models.CharField(max_length=255)
email = models.EmailField()
age = models.IntegerField()
created_at = models.DateTimeField(auto_now_add=True) class User(models.Model):
username = models.CharField(max_length=255)
email = models.EmailField()
age = models.IntegerField()
created_at = models.DateTimeField(auto_now_add=True) Plus serializers, views, and URLs - everything a user need to run their server right away. I also plan on exploring other backends too Why this matters: Why this matters: Turns MockMyData.io from a testing tool into a full development accelerator. Prototype with mock data, export to production code when ready. MockMyData.io Lessons Learned Lessons Learned 1. Ship fast, iterate faster 1. Ship fast, iterate faster The 2.5-month timeline was aggressive but kept me focused on shipping. Rather than building every possible feature upfront, I launched with the core product working and plan to aggressively iterate based on what users actually need. 2. Rate limiting is harder than you think 2. Rate limiting is harder than you think Especially across multiple tiers and preventing race conditions. Redis pipelines were essential. 3. Cache everything strategically 3. Cache everything strategically Redis saved my infrastructure costs. Without caching, I'd be paying 3-4x more for database and compute. 4. Stripe webhooks are your friend 4. Stripe webhooks are your friend Once you understand them. The documentation is excellent, and webhook-driven subscription management is reliable 6. Build for failure 6. Build for failure My circuit breaker pattern for Redis means the service stays up even when caching fails. Graceful degradation is better than complete outages. Try It Out 🚀 https://mockmydata.io - Free tier available, no credit card required https://mockmydata.io 🎉 Launching on Product Hunt January 14th - Would love your support! Launching on Product Hunt January 14th 💬 Questions I'd love feedback on: Questions I'd love feedback on: What backend frameworks would you want for code export? (Django, Express, FastAPI, Rails?) What backend frameworks would you want for code export? (Django, Express, FastAPI, Rails?) What's missing that would make this a must-have tool for you? What's missing that would make this a must-have tool for you? Drop a comment below - happy to answer questions about Django, React, multi-tenant architecture, or building a SaaS solo! You can also connect with me @marcuscodes.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

I Built a Mock API Platform in 2.5 Months (Django + React + Redis + PostgreSQL)

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

110 Stories To Learn About Graphql

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

The Noonification: Getting Your API Into Production (10/28/2022)

110 Stories To Learn About Graphql

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps