Why We Chose Next.js Over React for Our Privacy Search Engine
Frontend frameworks seem interchangeable. For a privacy-focused product, the choice matters more than you'd think.
The Privacy Problem with SPAs
Traditional React SPAs:
- Execute all logic in the browser
- Make API calls directly to third parties
- Expose the user's IP to every service
- Require JavaScript (fingerprinting surface)
For asearchz.online, this was unacceptable. Every API call a user made would expose their IP to Bing, Brave, or other search sources.
Why Next.js (Server-Side Rendering)
With Next.js SSR:
- The server makes API calls to search sources
- User IP stays between user and our server only
- Results are rendered server-side, sent as HTML
- JavaScript is optional (works without it)
Performance Benefits
SSR is actually faster for search:
- First contentful paint: 200-300ms
- No hydration delay (content is already HTML)
- No client-side state management complexity
- CDN caching of rendered pages
Trade-offs
Next.js SSR has costs:
- Server compute per request (higher than static)
- Less interactive without client JS
- Harder to implement real-time features
For a search engine, these trade-offs are minimal. Users want fast results, not real-time collaboration.
The Architecture
User → Cloudflare CDN → Next.js Server → FastAPI Backend → Search APIs
The user's browser never talks to Bing, Brave, or any search source. Our server does. The user's IP is known only to us — and we don't log it.
Graham Miranda builds privacy-first infrastructure at Graham Miranda UG (Berlin, HRB 36794).
Top comments (0)