DEV Community

Aditya Sorathiya
Aditya Sorathiya

Posted on

I built an E2EE paste utility with 12K users (1,800+ commits). Is a local HTML/CSS/JS Android wrapper a good idea?

#kotlin #android #webdev #architecture

Hey DEV community! 👋

I'm a 10th-grade self-taught developer, and for the past several months, I've been working as a one-man army (handling coding, testing, DevOps, and SEO) on my project: PasteDB.

To give you an idea of the scale, the ecosystem currently spans across a web interface, an npm CLI tool (pastedb-cli), two SDKs (Node.js/Python), and a live VS Code Marketplace extension. The core repository alone has over 1,800+ verified commits, and we just crossed 12,000+ active users completely organically.

🚀 Our Current Tech Stack (Running at ₹0)

Because I am a student, I've architected everything to run smoothly on cloud free-tiers with a strict ₹0 maintenance budget:

  • Frontend: Vanilla HTML, CSS, JavaScript (Hosted on Netlify)
  • Backend: FastAPI / Python (Deployed on Render's free tier)
  • Database: MongoDB Atlas (Free tier cluster) + Cloudinary for images

🔐 The Core Problem & Features

PasteDB isn't just a standard text dump. It features client-side End-to-End Encryption (E2EE) where encryption keys never touch my database server. It also supports automated "Burn After Read" pastes, an in-viewer code execution engine, automatic rolling version control history (up to 10 versions), and a 3-finger gesture-based Nearby Transfer protocol and many more…

📱 The Upcoming Milestone: A Native Android App

Now that my 1st-term school exams are wrapping up, my next major goal during vacation is to launch an official PasteDB Android App.

Because I want to minimize development time, maintain our tight browser-side cryptographic logic, and ensure the app loads instantly on slow networks, I am planning to build a Local Hybrid Architecture.

Instead of pulling the UI over the internet, my plan is to:

  1. Embed our exact web index.html, style.css, and crypto-heavy script.js files directly inside the Android project's assets/ folder.
  2. Build a lightweight Kotlin wrapper using Jetpack Compose.
  3. Use Android's view container to render the UI entirely from local disk storage via loadUrl("file:///android_asset/index.html").
  4. Point all fetch requests in the JS script to the absolute Render URL of our FastAPI backend.

This means no web browser layout is involved for the user, and the application interface will load instantaneously without costing a rupee in frontend bandwidth.

🤔 My Question to Senior Engineers: Is this a good idea?

Since this is my first time deep-diving into Android deployment, I want to know your thoughts on this approach. Specifically:

  1. Security & Cryptography: Our client-side E2EE relies entirely on browser-based JS crypto execution. Will loading these scripts locally via file:/// inside an Android WebView introduce any native sandbox security leaks or quirks?

  2. Performance Constraints: Are there significant performance penalties for letting local vanilla JS handle DOM updates inside a Kotlin wrapper compared to writing a completely native Kotlin UI?

  3. Hardware Access: Will the local asset container successfully allow hardware-level access if I request native Android permissions (like Location/Bluetooth for our Nearby Transfer feature, or Camera access for scanning QR codes)?

I'd love to hear your feedback, architectural warnings, or library recommendations (should I stick to standard Android WebViews, or explore engines like QuickJS for the crypto backend?).

Drop your advice in the comments below! 👇

Top comments (0)