Most developers assume that scaling requires a backend. A database. Load balancers. DevOps nightmare.
I built a tool that handles 100K concurrent users without any of that. It runs entirely in the browser.
Here's how, and why it matters for your next project.
The Challenge
When I first launched Grow a Garden Calculators, I expected 100 users max. Maybe 1,000 if I got lucky.
Then Roblox pushed a game update. Players flooded in.
Day 1: 10,000 concurrent users
Day 2: 25,000 concurrent users
Week 1: 100,000+ monthly active users
I had exactly zero backend infrastructure.
GitHub Pages was hosting it (free tier). No database. No server. Just static HTML and JavaScript.
And it still worked perfectly.
This was accidental architecture at its best.
Why Backend-Only Scaling Fails
Let me explain why I accidentally stumbled into the right decision.
Most scaling problems come from the backend:
Database bottlenecks
API rate limits
Server processing time
Memory constraints
Network latency
Each of these becomes an obstacle when you have many users.
The "solution" is to throw infrastructure at it:
Database replication
Caching layers (Redis, Memcached)
Load balancers
Auto-scaling groups
More servers
This works, but it's expensive. Complex. Fragile.
What if you eliminated the backend entirely?
The Frontend-Only Architecture
For Grow a Garden Calculators, I structured it like this:
User Input → Browser JavaScript → Calculation → Result
(No backend involved)
Everything runs locally in the user's browser:
javascript
// All data is bundled in the app
const crops = {
watermelon: {
baseValue: 500,
mutations: { rare: 1.5, legendary: 2.5 }
},
pumpkin: {
baseValue: 450,
mutations: { rare: 1.6, legendary: 2.8 }
}
// ... more crops
};
// User clicks "Calculate"
function calculateCropValue(cropName, weight, mutations) {
let value = crops[cropName].baseValue;
value *= weight / 2; // Weight multiplier
mutations.forEach(m => {
value *= crops[cropName].mutations[m];
});
return value;
}
// Result is instant, no API call needed
Benefits:
✅ Zero latency (calculation runs locally)
✅ Zero server cost (GitHub Pages = free)
✅ Infinite scalability (each user runs their own calculation)
✅ Works offline (after first load)
✅ No database to maintain
✅ No security vulnerabilities from APIs
When This Architecture Works
Not every app can be frontend-only. But if your app meets these criteria, it's perfect:
✅ Stateless calculations (no user accounts needed)
✅ Immutable data (crop values don't change per-user)
✅ Real-time performance requirements (instant feedback needed)
✅ High concurrency (many simultaneous users)
✅ Low infrastructure budget (startup or side project)
If you're building:
Calculators ✅
Converters ✅
Planning tools ✅
Games ✅
Real-time analysis ✅
Frontend-only might be perfect for you.
If you're building:
Social networks ❌
Chat apps ❌
Multiplayer games ❌
Anything with user data ❌
You need a backend.
Handling Data Updates
"But wait," you might ask. "What if the game changes crop values?"
Good question. Here's my solution:
javascript
// Version control for data
const dataVersion = "2.5.1";
const lastUpdated = "2026-10-08";
const crops = { ... };
// On page load, check if we have newer data
async function checkForUpdates() {
const response = await fetch('/data-manifest.json');
const manifest = await response.json();
if (manifest.version > dataVersion) {
// Newer data available
console.log("Updated crop values available");
// Suggest user refresh
}
}
When the game updates, I update the JSON file in the repo. Users see a notification to refresh. No database query needed.
Performance: The Numbers
Let's compare to a traditional backend architecture:
Frontend-Only (My approach):
Initial load: 150ms
Calculation time: <1ms
Concurrent users: Infinite
Server cost: $0/month
Complexity: Low
Typical Backend:
Initial load: 300ms (includes API call)
Calculation time: 50-200ms (network latency)
Concurrent users: 1,000-10,000 (depends on servers)
Server cost: $500-5,000/month
Complexity: High
For a calculator, frontend-only wins on every metric.
Real-World Stress Test
When 25,000 users hit simultaneously:
What happened:
GitHub Pages served static files perfectly
Each user's browser did its own calculation
Total server load: Unchanged (still just serving static files)
What DIDN'T happen:
No server crashes
No timeouts
No scaling issues
No DevOps emergency
The architecture simply scaled because there was nothing to scale. Each user was self-contained.
The Limitations (Be Honest)
This architecture isn't perfect:
❌ No real-time sync (users see different data if you update)
❌ No personalization (everyone gets the same experience)
❌ No analytics (hard to track user behavior)
❌ No user accounts (no login/signup)
❌ Data constraints (all data must fit in browser memory)
If you need any of these, you need a backend.
But for many tools, you don't.
Analytics Without a Backend
Want to know how users are using your tool? You can do it client-side:
javascript
// Track what users calculate (anonymously)
function trackUsage(cropName) {
// Store locally
let stats = JSON.parse(localStorage.getItem('usage') || '{}');
stats[cropName] = (stats[cropName] || 0) + 1;
localStorage.setItem('usage', JSON.stringify(stats));
// Optional: Send aggregated stats (still no backend DB needed)
// Just post to a logging service like LogRocket
}
Result: You know what's popular without invading privacy.
Deployment Strategy
Since there's no backend to manage, deployment is simple:
bash
1. Update your data/code locally
git add .
git commit -m "Update crop values for v2.6 game patch"
2. Push to GitHub
git push origin main
3. GitHub Actions auto-deploys
(or GitHub Pages auto-deploys from main)
4. Users see updates on next refresh
That's it. No CI/CD complexity. No deployment pipeline. Just git push.
When I'd Add a Backend
If Grow a Garden Calculators needs to scale beyond what frontend-only offers:
User accounts → Need backend to store preferences
Trading marketplace → Need backend to match buyers/sellers
Social features → Need backend for user data
Real-time multiplayer → Need backend for sync
At that point, I'd add a minimal backend (maybe just an API) while keeping calculations client-side.
But for now? Pure frontend. Pure simplicity.
The Lesson
The most scalable architecture is the one that doesn't need to scale.
If every user runs their own calculation, you have infinite scalability for free.
Before you build a backend, ask:
Do I actually need one?
Can this run client-side?
What's the simplest solution?
Too many developers over-engineer from day one. Frontend-only forces you to think differently.
Try It Yourself
You can see this in action right now at Grow a Garden Calculators.
Open your DevTools. Check the Network tab. You'll see:
Index.html (the page)
app.js (the calculator)
Maybe one CSS file
That's it. No API calls. No backend requests.
Everything runs in your browser.
Questions?
What other frontend-only tools have you built? Or do you think this approach won't work for your use case?
Drop your thoughts in the comments. I read every one.
Tags: #javascript #webdev #performance #architecture #scalability
Top comments (0)