Jehan
Fernando
I’m a second-year Computer Science undergraduate at the Informatics Institute of Technology, affiliated with the University of Westminster, UK, passionate about software development, full-stack development, and solving real-world challenges. I thrive in teamwork to enhance my leadership and communication skills, aiming to apply my academic and practical experience to create impactful solutions in the tech industry.
Tech stack
Projects
Real-Time Event Ticketing Simulator (Ticketing Simulation)
Below is the completed version of your documentation with the specified changes, emphasizing that this is a ticketing simulator rather than an actual real-time event ticketing system. I've filled in the placeholders accordingly and tailored the content to reflect the simulation focus. 🔖 Introduction About the project The Real-Time Event Ticketing Simulator is a dynamic ticketing simulation system designed to mimic real-world event management scenarios. Built with a React frontend and a Spring Boot backend, it simulates ticket distribution and purchases in real time. This project was developed as a proof-of-concept to showcase a scalable solution for testing ticket pool management, addressing inefficiencies in traditional simulation approaches with real-time updates and a modern UI. The result is a functional prototype that demonstrates concurrent ticket handling and detailed logging, making it an excellent addition to a developer’s portfolio for showcasing technical skills. 🤔 Problem space Problems to solve/Requirements to Create The Real-Time Event Ticketing Simulator addresses challenges in simulating ticket distribution for event organizers and developers testing ticketing systems. 👉 Problem: Event organizers and developers lack tools to simulate real-time ticket distribution Organizers and developers often struggle to test ticket release and purchase scenarios without real-world data. This makes it difficult to predict system behavior under load or optimize configurations before deploying a live system. Current solution Organizers rely on static models like spreadsheets or basic scripts to simulate ticket counts, manually adjusting numbers without real-time feedback or concurrency simulation. How do we know it is a problem User Feedback : Hypothetical event organizers and developers noted difficulty in stress-testing ticketing systems pre-launch without a realistic simulation tool. Metrics : Simulated tests using manual methods showed a 20% error rate in tracking ticket availability due to human oversight. 👉 Problem: Limited visibility into ticket pool dynamics during simulation Without real-time monitoring, it’s challenging to observe how vendors and customers interact with the ticket pool in a simulated environment, potentially leading to overselling or inefficiencies in system design. Current solution Existing simulation tools provide delayed logs or no user interface, requiring users to manually sift through server outputs or text files to understand system behavior. How do we know it is a problem User Feedback : Simulated organizers expressed frustration over the lack of actionable insights during test runs, needing to wait until the simulation ends to analyze results. Metrics : Post-simulation log analysis took 30% longer due to unstructured, hard-to-read data outputs. Why solve these problems? Solving these simulation-related issues allows developers and organizers to better prepare for real-world ticketing scenarios and improves the reliability of system designs. Reason : Real-time simulation ensures accurate modeling of ticket management under varying conditions, helping identify bottlenecks before deployment. Reason : Enhanced visibility during simulations reduces design errors and builds confidence in the system’s scalability. Goals Company objective 🎯 "To develop a robust ticketing simulator platform that enables event organizers and developers to test and optimize ticket distribution in a real-time simulated environment." Project goals Project goal : Create a concurrent ticket pool system with simulated vendors and customers to mimic real-world ticketing dynamics. Supports the objective by testing system reliability in a controlled setting. Project goal : Build an intuitive UI with Material-UI to display simulated ticket status and logs. Enhances visibility for optimizing configurations during testing. User Stories Visitor (Simulation Tester) The Visitor is a developer or organizer testing the simulator to evaluate ticket sales and system behavior in a controlled environment. Goals : Run simulations to observe ticket pool changes and analyze outcomes for system design improvements. Needs : Real-time status updates, clear and detailed logs, and an easy-to-use configuration interface. Other characteristic : Technical background, expects granular system feedback for debugging and optimization. Admin (Event Organizer) The Admin is an organizer or developer configuring and monitoring the ticketing simulator to plan and test event scenarios. Goals : Set ticket parameters (e.g., total tickets, release rates) and observe simulated vendor/customer interactions. Needs : A straightforward form to input simulation settings and a dashboard displaying logs and ticket status. Other characteristic : Focused on efficiency, requires actionable data to refine event planning strategies. 🌟 Design space UI Design The UI features a modern gradient background (light blue to gray) with the Poppins font for readability. It includes a configuration form, control buttons (start/stop/reset), a ticket status display, and a log viewer, all styled with Material-UI for a consistent and responsive experience tailored to simulation testing. Development Phase Technology Stack Selection 1. Frontend - React.js with Material-UI Why React.js? Component-Based Architecture : Enables reusable components like ConfigurationForm and TicketDisplay for a modular simulation UI. Efficient UI Updates : Virtual DOM supports real-time updates to ticket status and logs during simulation runs. Rich Ecosystem : Pairs seamlessly with Material-UI for rapid prototyping of the simulator’s interface. Why Material-UI? Pre-built Components : Offers forms and buttons that streamline building the configuration and control sections. Customization : Aligns with the simulator’s modern design through a tailored theme. Responsiveness : Ensures the UI adapts to various screen sizes for testing on different devices. 2. Backend - Spring Boot Why Spring Boot? Rapid Development : Provides RESTful APIs to control the simulation (e.g., start, stop, configure). Concurrency : Handles vendor and customer threads to simulate real-time ticket interactions. Logging : Leverages Java’s logging framework to track simulation events for analysis. Key Features of the Software Real-Time Ticket Simulation Description : Simulates ticket releases by vendors and purchases by customers using a TicketPool with synchronized methods to mimic real-world dynamics. Decisions : Employed Java threads for concurrency and REST endpoints (/start, /stop) for simulation control. Configuration and Monitoring Description : Allows users to set simulation parameters (e.g., total tickets, release/retrieval rates) and displays current ticket status and logs in real time. Decisions : Used React state for form inputs and Spring’s @Service annotation for simulation logic and logging. Challenges Faced and Solutions Problem: Managing Concurrent Ticket Updates in Simulation Multiple threads updating the ticket pool during simulation risked race conditions, leading to inconsistent ticket counts and unrealistic results. Solution: Implemented synchronization in the backend to ensure accurate simulation: Synchronized Methods : Added synchronized to TicketPool methods (addTickets, removeTicket) to prevent race conditions and ensure thread safety. Logging : Utilized LoggingUtility to record each ticket update, aiding in debugging and simulation analysis. Thread Management : Controlled thread lifecycle (start/stop) via REST APIs to avoid overlapping operations during simulation runs. Future Vision / Next Steps Long-term vision Persistent Storage : Integrate PostgreSQL to save simulation data across sessions for historical analysis. Enhanced UI : Add a graphical dashboard with ticket trends using Chart.js to visualize simulation results. Real Events : Evolve the simulator into a full-fledged ticketing system for actual events, beyond simulation. What to add to UI : Include a visual ticket pool gauge, event-specific configuration options, and mobile-friendly layouts. Activities : Plan V2 with database integration for persistence and V3 with real-time WebSocket updates for live feedback, transitioning from simulation to production use.
Imperial Fit (E-commerce)
🔖 Introduction About the Project Hey there! So, Imperial Fit is my take on a full-stack e-commerce platform tailored for fitness buffs. Think of it as an online store where you can grab workout gear—everything from tank tops and leggings to dumbbells and yoga mats. I wanted to build something that feels smooth and intuitive for shoppers while keeping the backend solid for managing products and orders. This project was my playground to dive into modern web dev—mixing a RESTful API with a slick React frontend. I ended up with a scalable app that’s live on Vercel for the frontend and Render for the backend. It’s got all the good stuff: easy product browsing, a handy cart, and a checkout flow that actually works! 🤔 Problem Space Problems to Solve / Requirements to Create Alright, let’s talk about why I built this. E-commerce can be a mess for both customers and store managers, so I set out to fix some common headaches and make Imperial Fit stand out. 👉 Problem: Users Struggle to Browse Products Efficiently Without Filtering Options Fitness folks want to zero in on what they need—say, a pair of running shoes or a kettlebell—without wading through a giant list of stuff. A lot of online stores just dump everything on you, and it’s overwhelming. Current Solution Right now, the Shop page pulls all products from the /api/products endpoint and shows them in a grid. It works, but there’s no way to filter by category yet, so users have to scroll through everything. How Do We Know It’s a Problem Imagine someone saying, “I spent ages scrolling to find a yoga mat—why can’t I just pick a category?” That’s the vibe I’m guessing from hypothetical feedback. Plus, if I checked analytics, I’d probably see people bouncing off the Shop page because it takes too long to find what they want. 👉 Problem: No Centralized Cart Management for Seamless Shopping Picture this: you’re adding items to your cart, hopping between pages, and then—poof!—everything disappears when you refresh. That’s a dealbreaker for any shopper. Current Solution I’ve got the cart sorted out with a CartContext in the RootLayout. It keeps your items safe as you move from the Shop page to the Cart page. You can tweak quantities, see the total, and clear it out if you change your mind. It’s all stored in localStorage now, so it sticks around even after a refresh. The Cart page screenshot shows a neat list of items—each with a thumbnail, name, price, and little plus/minus buttons to adjust the quantity. There’s a big “Total” at the bottom in red, all on a clean gray background with a subtle border around the cart box. How Do We Know It’s a Problem Before I fixed it, I noticed the cart resetting every time I reloaded the page during testing. Users would’ve said, “Hey, where’d my stuff go?”—and they’d be right to ditch the site over it. 👉 Problem: Limited Payment Flexibility for Orders People hate being stuck with just one way to pay. Some want to use their credit card, others prefer cash on delivery—restrict them, and they’re outta there. Current Solution The Payment page (which you hit after checkout) gives you two options: “Cash on Delivery” and “Credit Card.” Clicking “Cash on Delivery” takes you to a confirmation step where you see your order details and hit a “Confirm Order” button. Credit Card is there as a placeholder for now—I’d hook it up to something like Stripe later. The screenshot of the Payment page has two big buttons: “Cash On Delivery” in green and “Credit Card” in blue, both popping out against a white card with a gray background. Super simple and clear. How Do We Know It’s a Problem Imagine a customer saying, “I wanted to pay cash, but it wasn’t an option—so I didn’t buy.” That’s lost sales right there. Before adding these options, I’d bet the checkout abandonment rate was sky-high (hypothetically, since I don’t have real stats yet). Why Solve These Problems? (Highly Optional) So why bother? Fixing these makes the site a joy to use, keeps customers coming back, and sets the stage for growth. Fitness gear is hot right now—everyone’s jumping on the home workout train since the pandemic. A smooth shopping experience means more sales, and a solid backend means I can scale up without breaking a sweat. Reason : Happy users stick around—filters and a reliable cart make shopping a breeze. Reason : Easy admin tools mean less hassle managing the store as it grows. Goals Company Objective 🎯 “To create a modern e-commerce platform for fitness enthusiasts, delivering an awesome shopping experience and slick tools to run the store.” Project Goals Goal : Build a snappy React frontend with reusable components for a consistent look and feel. Why It Matters : Ties into the objective by making the site easy and fun to use, no matter the page. Goal : Set up a RESTful API with MongoDB that can grow with the business. Why It Matters : Keeps the backend humming, handling more products and orders without a hitch. User Stories Visitor (Fitness Shopper) Meet the Fitness Shopper: someone hunting for gear like a new gym outfit or weights. Goals : Snag fitness stuff fast and easy. Needs : Filter by category, see product details, and keep their cart handy. Fun Fact : They’re often on their phone, so the site’s gotta look good on mobile. Admin (Store Manager) Meet the Store Manager: the person keeping Imperial Fit stocked and orders flowing. Goals : Add products and track orders without a headache. Needs : Simple API calls to manage inventory and update order statuses. Fun Fact : They don’t need to be a tech wizard to run things. 🌟 Design Space UI Design The vibe I went for is clean and modern—lots of gray and white, with bold pops of color for buttons (green for COD, blue for Credit Card, yellow for checkout). The flow’s straightforward: land on the Home page, browse on Shop, dig into details on ProductDetails, review your picks on Cart, and wrap up on Payment. Low-Fidelity Wireframe I wanted the Shop page to focus on products—big images and names in a grid. The polished version: a sleek grid of product cards—sharp images, names below, and a hover effect that lifts the card a bit. The nav bar’s glossy, and the whole page feels crisp on a gray backdrop. Design System 🎨 I leaned on Tailwind CSS to keep things consistent and snappy: Why : Reusable styles like buttons and cards save time, and it’s responsive out of the box. How : Slapped on classes like bg-gray-100, rounded-lg, and hover:shadow-lg everywhere—keeps the look tight and modular. Development Phase Technology Stack Selection 1. Frontend - React.js with Context API Why React.js? Components : Stuff like the Navigation bar and CartPage get reused, cutting down on repeat work. Speed : The virtual DOM makes product lists and cart updates zippy. Extras : React Router handles page switches, and sonner pops up toasts for feedback. Why Context API? State : Keeps the cart alive across pages—no messy prop passing. Simple : No need for Redux when this does the trick for a smaller app. 2. Backend - Node.js with Express and MongoDB Why Node.js/Express? Fast : Handles tons of requests—like fetching products—without choking. API : Easy to whip up endpoints like /api/products or /api/orders. Why MongoDB? Flexible : NoSQL lets me tweak product fields without a fuss. Scales : Ready for more gear and orders, with Mongoose keeping schemas tidy. 3. Validation - Zod Safety : Checks data (like createOrderDto) before it hits the database—no junk allowed. High-Level Architecture Diagram It’s a straightforward setup: the React frontend talks to an Express API on Render, which pulls and pushes data to MongoDB Atlas. Entity-Relationship Diagram The database has Product (linked to Category via categoryId) and Order tables, connected by MongoDB’s ObjectId refs. Key Features of the Software 1. Product Browsing What : Grabs products from /api/products, with plans to add ?categoryId= filtering. How : Mongoose queries with populate to snag category info—makes products rich and detailed. 2. Cart Management What : Tracks your picks in CartContext, lets you tweak quantities, and sums it up. How : Went with Context API—kept it light and avoided overkill state tools. 3. Payment Processing What : Offers COD and a Credit Card stub, confirms orders with a simple message. How : COD pulls order details and wraps up with a button; Credit Card’s ready for a future Stripe hookup. Challenges Faced and Solutions Problem: Images Not Loading on ShopPage Issue : Product pics wouldn’t show—URLs were wonky or relative paths broke. Fix : Switched MongoDB to store full URLs (like https://example.com/shirt.jpg ). Added a fallback image in ShopPage with onError. Made sure the backend serves static files right with express.static. Problem: Cart State Loss on Refresh Issue : Early on, the cart emptied out every time I hit refresh—super annoying. Fix : Moved cart state to CartContext in RootLayout for global access. Added localStorage to keep it alive across reloads—problem solved. Future Vision / Next Steps Long-Term Vision I see Imperial Fit growing into a go-to fitness shop. I’d love to add Clerk for user logins and personalized order histories, toss in advanced filters (price, rating) on the Shop page, and hook up Stripe for real credit card payments. What to Add to UI, Activities V2 : Slap a category dropdown and search bar on the Shop page—make finding stuff a breeze. V3 : Build an admin dashboard so the Store Manager can add products and check orders right from the frontend.
We Neighbour (Community Management)
Introduction About the project "We-Neighbour" is a mobile app built for urban apartment residents in Sri Lanka, sitting at the intersection of residential living and technology. Our goal was to tackle communication breakdowns, security gaps, and the lack of community spirit in these high-density complexes. We created a platform that brings residents and managers together, making daily life safer, more connected, and more efficient. By the end, we delivered a tool that’s already transforming how people live in apartments—less isolation, better access to resources, and a real sense of belonging. Marketing Website: https://www.weneighbour.live/ 🤔 Problem Space Problems to Solve Apartment dwellers in Sri Lanka’s cities struggle with patchy communication, shaky security, and no easy way to share resources or build community. 👉 Problem: Spotty Communication Channels Residents miss out on critical updates—like power cuts or maintenance schedules—because they’re stuck relying on WhatsApp chats, notice boards, or word-of-mouth. It’s a mess: messages get buried, not everyone sees them, and there’s no accountability. Current Solution Right now, people pin paper notices in the lobby or send group texts that half the building ignores. It’s unreliable and slow. How We Know It’s a Problem Residents in Colombo say they miss 30% of key updates, per a 2024 survey we ran. Feedback from 50% of tenants shows they’re fed up with the confusion. 👉 Problem: Weak Visitor Security There’s no proper way to track who’s coming in and out, leaving buildings vulnerable to strangers wandering in unchecked. Current Solution Security guards scribble names in a logbook—messy handwriting, no verification, just a hope it’s accurate. How We Know It’s a Problem 15 security breaches in 2024 tied to untracked visitors, according to Colombo apartment records. Residents keep raising this at meetings—they’re worried. 👉 Problem: No Community or Resource Sharing People don’t know their neighbors and end up buying stuff they could borrow, like tools or party supplies. Events? Barely happen because no one’s coordinating. Current Solution Borrowing’s a favor between friends, if you’ve got any, and events are a rare whisper down the hall. How We Know It’s a Problem 40% of residents feel alone in their buildings, says a 2024 urban living poll. Spending data shows folks buying duplicates of shareable items. Why Solve These Problems? Fixing this matters because apartment living is booming—10% more people every year—and these gaps are dragging down safety and happiness. Reason: Tech can close these holes fast and cheap. Reason: Residents deserve better than isolation and risk. Goals Company Objective 🎯 “To build a modern platform that boosts connection, safety, and efficiency for urban apartment communities.” Project Goals Goal: Create a one-stop app to replace patchy communication, tying into that connection piece. Goal: Add QR visitor tracking and safety alerts to lock down security—safety’s covered. Goal: Set up resource sharing and event tools to bring people together, hitting that efficiency mark. User Stories Resident Your average resident’s a busy professional or parent in Colombo, wanting an easier, safer life. Goals: Catch updates, feel secure, borrow a drill instead of buying one. Needs: Instant alerts, a visitor system that works, a sharing hub. Other: They’re tech-friendly but tired of the current mess. Building Manager The manager’s juggling tenant complaints and upkeep, trying to keep everyone happy. Goals: Share news fast, fix issues smoothly, vet who’s who. Needs: A notice tool, maintenance tracker, profile controls. Other: Stressed and bogged down by paper trails. 🌟 Design Space UI Design We went for a clean, no-nonsense look—think a dashboard with tiles for notices, events, and alerts. It’s split by role: residents see community stuff upfront; managers get admin tools. Easy to use, hard to miss what matters. Design Sketch / Low-fidelity Wireframe High-fidelity Design Design System 🎨 We built a custom system to keep things tight. Why: Consistency across screens—buttons and cards look the same everywhere. How: Blue for trust, green for action, Roboto font for clarity, and reusable bits like alert tiles. Development Phase Technology Stack Selection 1. Frontend - Flutter Why Flutter? One Code, Two Platforms: Covers iOS and Android without doubling the work—perfect for our diverse users. Great UI: Widgets let us craft a slick, custom feel for things like the calendar and forum. Speed: Native performance means alerts and QR scans don’t lag. Fast Fixes: Hot reload kept us moving, tweaking the UI on the fly. 2. Backend - Node.js with Express & MongoDB Why Node.js? Handles Crowds: Manages tons of resident requests without breaking a sweat. Live Updates: WebSockets make alerts and chats instant. Why MongoDB? Flexible: Fits messy data like profiles and event plans. Quick: Indexes speed up grabs for notices and resources. High-Level Architecture Diagram Key Features of the Software 1. Resource Sharing Platform What: Residents list and borrow items—think tools or party gear—stored in MongoDB. How: Flutter’s Provider updates the screen as stuff gets taken; Redis caches the popular picks. 2. Visitor Management with QR Codes What: QR codes for guests, saved in MongoDB, scanned via Flutter. How: Flutter’s QR library keeps it simple and works offline—security’s tight. 3. Safety Alerts and Maintenance Requests What: Push alerts for emergencies and a way to log fixes, tracked in MongoDB. How: Firebase in Flutter sends alerts fast; Node.js APIs handle the rest. 4. Event Calendar What: Shows events and bookings—like gym slots—in MongoDB, with a Flutter UI. How: A scrollable widget syncs with Node.js for live updates. 5. Community Forum What: A chat space for ideas, stored in MongoDB, shown in Flutter lists. How: Nested comments in Flutter, powered by Node.js for smooth threading. 6. Community Notices What: Manager posts go straight to phones, held in MongoDB. How: Flutter cards for style, WebSockets for urgent pings. Challenges Faced and Solutions Problem: Slow Push Alerts Early on, safety notifications lagged under load—unacceptable for emergencies. Solution: Firebase Boost: Switched to Firebase Cloud Messaging in Flutter for speed. Priority Lane: Urgent alerts jump the queue, hitting phones instantly. Future Vision / Next Steps Long-term Vision Add AI to predict maintenance—like spotting a leaky pipe early. Go rural with an offline mode for spotty signal areas. UI upgrades: multi-language options and bigger text for older folks.
LibroNest – Full-Stack Bookstore CRUD Management System (E-commerce, Inventory Management)
🔖 Introduction About the project The Bookstore API is a full-stack web application designed for managing bookstore operations, including books, authors, customers, carts, and orders. Built for the e-commerce and retail industry, the project aims to provide a seamless platform for bookstore administrators to perform CRUD (Create, Read, Update, Delete) operations via a RESTful API and a user-friendly interface. As a solo developer, I created this project to demonstrate my full-stack development skills, focusing on modern UI/UX, efficient API integration, and scalable deployment. The result is a responsive, visually appealing app deployed on Vercel (frontend) and Render (backend), with features like a stunning cart experience, sample data for testing, and real-time feedback. 🤔 Problem space Problems to solve/Requirements to Create The Bookstore API addresses the need for an intuitive, efficient system to manage bookstore resources, replacing manual or fragmented processes with a centralized, API-driven platform. Hypothetically, a small bookstore client requires a solution to streamline inventory and order management while ensuring ease of use for non-technical staff. 👉 Problem: Lack of a centralized system for managing bookstore inventory Small bookstores often rely on spreadsheets or disparate tools to track books, authors, and inventory, leading to errors, inefficiencies, and difficulty scaling. Administrators need a single interface to create, update, and delete records, with clear validation and feedback. Current solution Currently, bookstore staff manually update Excel sheets or use basic inventory software with limited functionality. This requires duplicate data entry (e.g., entering author details separately from books) and lacks real-time stock updates or customer order tracking. How do we know it is a problem Observation : Lack of API integration prevents integration with online sales platforms. 👉 Problem: Inefficient customer order and cart management Bookstores struggle to manage customer carts and orders without a streamlined process, leading to lost sales or incorrect orders. Staff need a way to add items to carts, confirm orders, and view order history without complex workflows. Current solution Staff manually note customer orders on paper or in separate systems, with no link to inventory. Customers cannot view their cart in real-time, and order creation is prone to errors (e.g., out-of-stock items). How do we know it is a problem User feedback : Staff reported frequent order mismatches due to manual processes. Observation : No real-time cart updates lead to overselling out-of-stock books. Why solve these problems? Addressing these issues is critical to improve operational efficiency, reduce errors, and enhance customer satisfaction for small bookstores. Solving them now aligns with the growing demand for digital transformation in retail, enabling bookstores to compete with larger e-commerce platforms. Reason : Streamlined inventory and order management saves time, allowing staff to focus on customer service. Reason : A modern, API-driven system enables future integrations (e.g., with online marketplaces or mobile apps). [User satisfaction matrix] : The current manual system rates low on user satisfaction (2/5) and high on importance (5/5) due to its impact on daily operations. The Bookstore API aims to move this to high satisfaction (4/5) by automating processes and improving usability. Goals Company objective 🎯 To create a modern, API-driven bookstore management platform that simplifies inventory, cart, and order processes, enabling small bookstores to operate efficiently and scale digitally. Project goals Project goal : Develop a responsive React frontend with Tailwind CSS, featuring intuitive forms, a stunning cart modal, and sample data for easy testing, to ensure a user-friendly experience. This supports the objective by making the platform accessible to non-technical users. Project goal : Build a robust Spring Boot backend with JAX-RS RESTful APIs and in-memory storage for reliable CRUD operations, ensuring scalability and performance. This aligns with the objective by providing a flexible, extensible API. Project goal : Deploy the frontend on Vercel and backend on Render with CI/CD via GitHub, ensuring high availability and easy updates, supporting the objective of a modern, maintainable system. User Stories Visitor 1: Bookstore Administrator A bookstore administrator manages daily operations, including inventory updates, customer records, and order processing. They need a simple interface to perform these tasks without technical expertise. Goals : Quickly add, update, or delete books, authors, and customers; manage carts and orders efficiently. Needs : Clear forms with validation, sample data for testing, and colorful API response feedback. Other characteristic : Prefers a visually appealing, intuitive UI with minimal learning curve. Visitor 2: Bookstore Owner The bookstore owner oversees operations and wants insights into inventory and orders to make business decisions. They need a system that’s reliable and easy to monitor. Goals : View all books, customers, and orders; ensure stock levels are accurate; track sales via orders. Needs : Fast API responses, a dashboard-like interface (future vision), and error-free data management. Other characteristic : Values scalability for potential online sales integration. 🌟 Design space UI Design The UI is designed to be modern, clean, and user-friendly, using Tailwind CSS for a consistent, responsive layout. The Home page features a hero section with a gradient CTA, a “How It Works” guide, feature cards, and navigation cards to guide users. Each resource page (Books, Authors, Customers, Cart, Orders) uses a form-based layout with labeled inputs, colorful action buttons (e.g., blue for Create, red for Delete), and a collapsible Sample Data section with JSON examples. A fixed navbar with a cart badge ensures easy navigation, while a stunning cart modal (with animations) confirms additions. The design prioritizes usability with clear validation, real-time feedback via React Hot Toast, and vibrant JSON responses (green for success, red for errors). Low-fidelity Wireframe The low-fidelity wireframes outlined the app’s structure, focusing on simplicity and flow. Key concepts included a grid-based Home page, form-driven resource pages, and a modal for cart actions. Design concept: Minimalist Form-Based Interface Centralized forms for each resource to streamline CRUD operations. Collapsible sample data to reduce clutter but aid testing. Fixed navbar for consistent navigation across pages. High-fidelity design High-fidelity mockups refined the wireframes into a polished UI with Tailwind CSS styling. Key flows include adding a book, managing a cart, and creating an order, with gradients, shadows, and hover effects for a premium feel. Design system 🎨 I utilized a custom design system based on Tailwind CSS to ensure consistency and modularity. Tailwind’s utility classes enabled rapid styling with reusable components (e.g., buttons, cards, forms). Colors were defined as primary (#1D4ED8), secondary (#F97316), success (#10B981), error (#EF4444), and neutral (#F3F4F6), applied consistently across buttons, inputs, and notifications. Typography used sans-serif fonts (Inter) with bold headings and readable body text. This system streamlined development, ensured a cohesive look, and allowed easy updates for future features. Development Phase Technology Stack Selection The tech stack was chosen to balance performance, scalability, and developer efficiency, leveraging modern tools suitable for a full-stack application. 1. Frontend - React with Tailwind CSS Why React? Component-Based Architecture : Enabled reusable components (e.g., ResponseDisplay, Navbar), reducing code duplication. Efficient Rendering : Virtual DOM ensured fast updates for dynamic forms and responses. Ecosystem : Libraries like React Router and React Hot Toast simplified routing and notifications. Why Tailwind CSS? Utility-First Styling : Allowed rapid, consistent UI design without custom CSS. Responsiveness : Built-in breakpoints (sm:, md:, lg:) ensured mobile-friendly layouts. Customizability : Tailwind config defined project-specific colors and animations. 2. Backend - Java with JAX-RS Why Spring Boot? Rapid Development : Simplified REST API creation with minimal setup. Java Ecosystem : Leveraged Java’s robustness for reliable backend logic. Scalability : Dependency injection and modular design supported future growth. Why JAX-RS? RESTful Standards : Provided clear annotations (e.g., @GET, @POST) for API endpoints. Interoperability : Ensured compatibility with in-memory storage and future databases. 3. Deployment - Vercel and Render Vercel : Chosen for frontend hosting due to its seamless React integration and CI/CD. Render : Selected for backend hosting, supporting Spring Boot with easy scaling. GitHub : Enabled version control and automated deployments. 4. Testing - Postman Purpose : Validated API endpoints (e.g., /books, /orders) for correct responses and error handling. Benefit : Ensured backend reliability before frontend integration. High-Level Architecture Diagram The system follows a client-server model. The React frontend, hosted on Vercel, sends HTTPS requests (via Axios) to the Spring Boot backend on Render. The backend processes requests, interacts with in-memory storage, and returns JSON responses. GitHub integrates with Vercel/Render for CI/CD, and Postman tests API endpoints. Entity-Extended Relationship Diagram The in-memory storage mimics a database with entities: Author (authorId, firstName, lastName, biography), Book (bookId, title, authorId, isbn, publicationYear, price, stock), Customer (customerId, firstName, lastName, email, password), Cart (cartId, customerId, bookId, quantity), and Order (orderId, customerId, orderDate, totalAmount, cartItems). Relationships include one Author to many Books (1:N), one Customer to many Carts/Orders (1:N), and Books to Carts (N:M). Key Features of the Software Feature 1: CRUD Operations for Resources Description : Users can create, read, update, and delete books, authors, customers, carts, and orders via intuitive forms and RESTful APIs. Decisions : Form Validation : Implemented client-side validation (e.g., required fields, email format) to prevent invalid API calls. API Endpoints : Designed RESTful endpoints (e.g., POST /books, GET /authors/{id}) for clarity and scalability. Sample Data : Added collapsible JSON examples on each form to simplify testing. Feature 2: Stunning Cart Experience Description : Users add books to a cart with a visually appealing modal confirmation, view cart items, and create orders seamlessly. Decisions : CartContext : Used React Context API to manage cart state across pages. Modal Design : Created an animated modal with Tailwind CSS for user engagement. Real-Time Updates : Integrated React Hot Toast for instant success/error feedback. Feature 3: Colorful API Responses Description : API responses are displayed in a formatted JSON viewer with green for success and red for errors, enhancing usability. Decisions : ResponseDisplay Component : Built a reusable component to parse and style JSON. Tailwind Styling : Applied success/error colors for clear visual cues. Challenges Faced and Solutions Problem: ESLint 'no-undef' errors in form validation The frontend threw ESLint errors due to undefined action variables in validateForm functions across form components (AuthorForm, BookForm, etc.), breaking code quality checks. Solution : Modified validateForm to accept an action parameter, passed from executeAction. Updated validation logic to check fields based on the action (e.g., create requires all fields, get needs only ID). Ran npx eslint src to confirm resolution, ensuring clean code for deployment. Problem: Slow backend response times The Render-hosted backend ( https://libro-nest.onrender.com/api ) occasionally took up to 30 seconds to respond due to cold starts, frustrating users during testing. Solution : Added a LoadingSpinner component with dynamic messages (e.g., “Creating book, please wait…”). Used React Hot Toast to notify users of delays and confirm successful actions. Included a note in the UI about potential backend wake-up times, setting clear expectations. Problem: Sample data accessibility Initially, sample data was only on the Home page (via IntroCard), requiring users to navigate back and forth to copy JSON examples, reducing usability. Solution : Moved sample data to collapsible sections on each form page (Books, Authors, etc.), styled with Tailwind CSS (gray-50 background, white code block). Added toggle buttons with React Icons (FaChevronDown/Up) for a clean, interactive experience. Ensured JSON was formatted with JSON.stringify(..., null, 2) for readability. Future Vision / next steps Long-term vision Evolve the Bookstore API into a full e-commerce platform with user authentication, search functionality, and a customer-facing storefront. Transition from in-memory storage to a database (e.g., MongoDB or PostgreSQL) for scalability. Introduce a user dashboard for administrators and customers to track orders, manage wishlists, and view analytics. Next Steps (V2, V3) : V2 : UI Enhancements : Add a search bar on the Home page, a carousel for featured books, and glassmorphism effects (frosted backgrounds) for a futuristic look. Activity : Implement user authentication (JWT-based) to secure API endpoints and personalize experiences. Activity : Integrate MongoDB for persistent storage, replacing in-memory data. V3 : UI Enhancements : Develop a User Dashboard with summary cards (e.g., Total Orders, Cart Items), a recent orders table, and a wishlist grid. Activity : Add real-time order tracking via WebSockets for live updates. Activity : Enable integration with third-party APIs (e.g., Stripe for payments, Goodreads for book data). UI Additions : 3D book graphics and animated transitions for a premium feel. Interactive charts (e.g., sales analytics) in the dashboard using Chart.js
Dream Space (Property Management)
🔖 Introduction About the project Dream Space is a modern property search application designed to streamline the process of finding and exploring real estate listings. The platform offers advanced search filtering, detailed property pages, and interactive mapping to help users make informed decisions. The goal was to create a user-friendly experience that allows users to browse properties effortlessly, save favorites, and explore locations with ease. The project was developed to address the lack of intuitive and visually engaging property search platforms in the market. 🤔 Problem Space Problems to solve/Requirements 👉 Lack of an intuitive property search experience Most real estate platforms have cluttered interfaces, making it difficult for users to filter and find properties efficiently. Current solution Users manually scroll through numerous listings, often encountering poorly structured filters and limited sorting options. How do we know it is a problem? User feedback indicates frustration with complex filtering systems. High bounce rates on real estate websites suggest users leave due to a poor experience. 👉 Limited property details and location insights Many platforms provide basic property details but lack interactive elements like image galleries, floor plans, and embedded maps. Current solution Users often rely on third-party sources like Google Maps to check property locations, leading to a disconnected experience. How do we know it is a problem? Surveys show users prefer platforms with interactive location-based insights. Competitor analysis reveals high engagement on platforms that offer dynamic property displays. Why solve these problems? Enhanced user experience : Making the property search process seamless and visually engaging increases user retention. Market differentiation : Most real estate websites lack modern UI and interactive mapping, providing an opportunity for innovation. Goals Company Objective 🎯 To create a seamless and interactive property search platform that improves the real estate browsing experience through advanced filters, detailed property pages, and real-time location mapping. Project Goals Build an intuitive property search experience with customizable filters. Integrate Google Maps API for interactive location visualization. Implement a favorites system to allow users to save and compare properties. Ensure a fully responsive UI for optimal experience across devices. User Stories Visitor Description : A potential homebuyer looking for properties that match their preferences. Goals : Find properties based on type, price, and location. Needs : Advanced filtering, detailed property pages, and an interactive map. Admin Description : A property manager uploading listings to the platform. Goals : Add, edit, and manage property details efficiently. Needs : A simple CMS-style interface to manage property listings. 🌟 Design Space UI Design The design follows a clean and minimalistic approach to ensure easy navigation. The homepage features a prominent search bar, categorized property filters, and dynamic listings. The property detail pages include high-resolution images, descriptions, and embedded Google Maps for location insights. Low-fidelity Wireframe High-fidelity design Design System 🎨 Dream Space utilizes a modular UI design with reusable components built using TailwindCSS. This ensures consistency in layout and easy scalability. Development Phase Technology Stack Selection Frontend - React.js Component-Based Architecture : Ensures modular UI development. React Router : Enables seamless navigation between pages. State Management with Hooks : Efficient data handling and updates. Google Maps API Real-time location mapping : Helps users visualize properties interactively. High-Level Architecture Diagram Entity-Extended Relationship Diagram Key Features of the Software 1. Advanced Property Search Implemented multi-criteria filtering for users to refine searches based on property type, price range, and location. 2. Interactive Property Listings Properties are displayed with dynamic images, floor plans, and Google Maps integration for location insights. 3. Favorites System Users can save properties for future reference using a drag-and-drop mechanism or a simple button click. Challenges Faced and Solutions Challenge: Optimizing search functionality Problem : Filtering large datasets in real-time caused performance lags. Solution : Implemented server-side pagination and indexing in MongoDB for faster search response times. Challenge: Google Maps API Rate Limits Problem : Exceeding free-tier requests led to API failures. Solution : Cached API responses for frequently viewed locations to minimize calls. Future Vision / Next Steps Enhance property recommendation system using AI-based user preferences. Expand the database to include rental properties and commercial real estate. Add virtual property tours to improve user engagement.