VidyaNet
Project Overview
VidyaNet is an enterprise-grade School ERP (Enterprise Resource Planning) portal designed to run uniformly across web and mobile viewports. By architecting a unified Kotlin Multiplatform (KMP) shared core layer, the client apps share domain models, authentication state logic, localized string resource mapping, and client database schemas. The UI is built using Compose Multiplatform to draw high-fidelity, responsive screens on both Android and Web platforms. The server uses Ktor to handle security interceptors, role-based authorization rules, and persistent student record management stored inside high-integrity PostgreSQL database servers.
Technologies Used
💻 Desktop and Web Dashboard
Management dashboards and operational screens displayed inside web browser mockup frames. Click any screen card to open in fullscreen preview.
Admin Overview Dashboard
Consolidated overview of active classes, teacher assignments, and general student analytics.
Access Control Manager
Granular role-based permissions editor setting rules for student enrollment records.
⚙️ Kotlin Multiplatform Architecture
Kotlin shared student models and Ktor database schema tables files displayed inside IDE code editors. Click any screen card to open in fullscreen preview.
shared model
Shared Compose Multiplatform state objects and student serialization models.
server model
Ktor route database relation definitions mapping PostgreSQL tables.
⚙️ Case Study Breakdown
A granular review of the technical challenges, architecture specifications, and tradeoffs made during implementation.
1. Project Overview
VidyaNet is a school ERP and student management ecosystem. It coordinates student profiles, daily attendance databases, and package allocations across Android applications and serverless web clients.
2. The Problem
Educational institutions frequently suffer from intermittent or slow internet connectivity. The platform had to support fully offline data updates (like attendance marking) and sync cleanly once connections restored without complex custom merging logic.
3. My Role
I was the lead system architect, building the shared KMP core logic, designing SQLDelight database schemas, and setting up the server backend deploying Ktor microservices and Cloudflare storage.
4. Technical Challenges
Ensuring that local databases remain synchronized, conflicts are resolved systematically (using vector timestamps), and network operations automatically queue and retry in the background.
5. System Architecture
Implemented Clean Architecture. The common KMP module hosts the Synchronization Manager engine, which interfaces with local database drivers and background synchronization service loops.
6. Kotlin Multiplatform Usage
All database models, SQL queries, network request mappings (Ktor), background queuing state machines, and CSV export logic are bundled inside the shared KMP engine.
7. Shared Code Details
SQLDelight entity models, offline queue synchronization drivers, and data validation rules are shared across both the Android client and the Web/API environments.
8. Platform-Specific APIs
Injected local database drivers using expect/actual bindings. Deployed Android SQLite drivers on the client app, and standard server-side SQL connections in back-end environments.
9. Key Decisions
Chose SQLDelight for local database structures over traditional ORMs due to its type-safe Kotlin query generation. Deployed Cloudflare R2 for storing student/staff profile attachments.
10. Tradeoffs & Challenges
Sharing SQLite Delight operations across Android and Web was successful, but required configuring customized multi-target Gradle tasks to compile correct JS and JVM modules.
11. Execution Results
Developed a client-side architecture that functions completely offline. Achieved 70% code reuse across Android and web client applications, significantly decreasing release overhead.
12. Key Lessons Learned
When sharing logic across Web and Mobile, database drivers must handle async connections carefully, as Javascript/WASM is single-threaded while Kotlin JVM relies on multi-threaded thread pools.