Why We Built a Web App Instead of a CLI

Blog Image

Why We Built a Web App Instead of a CLI

We chose to build a web application rather than a command-line interface (CLI) for this project. The decision was driven by goals around usability, accessibility, maintainability, and the desire to provide a richer, interactive experience for multiple users and devices.

Quick comparison: Web App vs CLI

  • Web App

    • Pros: Accessible from any browser, graphical UI, easy onboarding for non-technical users, multi-user and remote access, richer visuals (charts, previews), easier to integrate authentication and localization.
    • Cons: Slightly more complex deployment and hosting, requires frontend + backend coordination.

  • CLI

    • Pros: Lightweight, scriptable, great for power users and automation pipelines.
    • Cons: Steeper learning curve for non-technical users, limited UX for rich previews/visualizations, harder to securely share access with multiple users.

Why we picked a web app (concrete reasons)

  • Accessibility: Users can upload files and manage printers from any OS and device with a browser—no local installs required.
  • Usability: Interactive drag-and-drop, confirmation modal, and visual feedback greatly reduce user errors vs typed commands.
  • Visuals & Interaction: We needed charts, status badges, and optional 3D previews that are impractical in a CLI.
  • Multi-user & Remote: The app can be used by multiple people across the network and integrates with printer services/APIs.
  • Internationalization: Easier to provide localized UIs (we included i18n support).
  • Testing & Mocking: With tools like Mock Service Worker (MSW) it’s easy to simulate API responses during development and testing.

Technology stack (what we used and why)

Frontend

  • React — core UI library for component-driven development.
  • TypeScript — static typing for better developer experience and safer refactors.
  • Vite — fast development server and build tool.
  • @mantine/core / @mantine/charts / @mantine/notifications / @mantine/nprogress — UI components, charts and notifications with consistent styling.
  • react-router-dom — client-side routing.
  • react-i18next / i18next — internationalization and translation management.
  • Axios — HTTP client for API requests.
  • Recharts — charting library used for printer analytics.
  • lucide-react / @tabler/icons-react — lightweight iconography.
  • ESLint / @eslint/js / types packages — linting and development tooling.
  • MSW (Mock Service Worker) — API mocking for local development and tests.

Project tooling & dev experience

  • TypeScript (tsc) — type checking and builds.
  • Vite plugin for React — fast refresh & bundling.
  • @react-buddy/ide-toolbox — optional developer visualization tooling.

Backend / Services (integrations)

  • Frontend communicates with service-layer modules (e.g., Moonraker service) that wrap REST/WebSocket APIs provided by printers or third-party services. This keeps the UI decoupled from transport details.

Architecture overview

  • Pages (e.g., PrintingPage) handle composition and high-level flows (select printer → upload → confirm → send).
  • Components (Uploader, PrinterCard, NotificationCenter, etc.) are small, reusable, and tested in isolation.
  • Contexts (AuthContext, PrinterContext, NotificationContext) provide app-wide state (auth, printers, notifications).
  • Services (api clients) encapsulate HTTP and WebSocket logic and can be mocked with MSW during development.
  • UX pattern: immediate feedback + confirmation modal before destructive actions (e.g., send file).

Testing, deploy & maintenance

  • Local dev: Vite provides instant feedback; MSW lets us iterate offline.
  • CI: run TypeScript type checks, lint, and build tasks to catch regressions.
  • Deployment: built static frontend artifacts (Vite build) can be hosted on any static hosting (Netlify, Vercel, S3 + CDN) and talk to an API/bridge to the printer(s).
  • Monitoring: add error/telemetry hooks for production issues and usage analytics.

Conclusion & next steps

Building a web app gave us the UX, accessibility, and extensibility we needed. Next steps could include:

  • Add progressive enhancement for offline/unstable networks.
  • Add role-based access control for multi-user scenarios.
  • Implement server-side rendering or authentication hooks if needed.

If you want, I can also:

  • Turn this into a README section.
  • Generate a shorter social post version.
  • Add a small architecture diagram (ASCII or SVG).