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:
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.
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
Auto-generate records – MockMyData.io creates realistic data based on your field types
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.
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
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:
- Backend: Django REST Framework
- Frontend: React with Material-UI
- Database: PostgreSQL
- Caching: Redis
- Payments: Stripe
- Auth: Firebase SSO
- Hosting: Render.com
Architecture Decisions
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:
– 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:
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
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
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)
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?
– 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:
Daily Quotas – Tier-based limits
– Free: 100 requests/day,
– Pro: Unlimited
Request Throttling – Spam prevention
– All tiers: Max 60 requests/minute
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
The Challenge: Making this performant at scale
– 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.
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
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
Implemented 4-layer protection to prevent abuse:
Layer 1: Request payload size
– Free: 5KB per request
– Pro: 30KB per request
Layer 2: Individual field size
– Free: 2KB per field
– Pro: 10KB per field
Layer 3: Item count per endpoint
– Free: 20 items
– Pro: 200 items
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
Output: Complete Django REST Framework project with:
– Models generated from your schema
– Serializers for each endpoint
– CRUD operations
– URL routing configured
– Authentication setup (Optional)
– README with additional instructions & Suggestions
Example transformation:
Your MockMyData endpoint:
{
"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)
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:
Turns MockMyData.io from a testing tool into a full development accelerator. Prototype with mock data, export to production code when ready.
Lessons Learned
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
Especially across multiple tiers and preventing race conditions. Redis pipelines were essential.
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
Once you understand them. The documentation is excellent, and webhook-driven subscription management is reliable
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
🎉 Launching on Product Hunt January 14th – Would love your support!
💬 Questions I’d love feedback on:
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?
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.
![13 best social listening tools for brands [free + paid]](https://blog.hootsuite.com/wp-content/uploads/2025/05/social-listening-tools-1.png "13 best social listening tools for brands [free + paid]")
