DECLARATION

I, Student Name, bearing Register Number USN, student of VI semester Course at College Name, hereby declare that the internship report entitled “MERN Full Stack Web Development” has been prepared by me based on the internship undertaken at Petisoft Technologies Pvt Ltd, Bengaluru, during the period from start to end, under the guidance of Guide Name, Designation.

I further declare that this report is the result of my own work and has not been submitted earlier, either in part or in full, to this or any other university or institution for the award of any degree, diploma or other similar title.

The work reported here is genuine and the observations, learnings and conclusions presented are based on my own experience during the internship period.

ACKNOWLEDGEMENT

The successful completion of this internship and the preparation of this report required guidance, encouragement and assistance from many people, and I am sincerely grateful to everyone who supported me through it.

I would like to express my sincere gratitude to Petisoft Technologies Pvt Ltd, Bengaluru, for providing me the opportunity to undertake this internship and for allowing me to work alongside their development team. I am especially thankful to Mr. Preetham Paul Socrates P, Chief Executive Officer, and to the mentors who reviewed my work, answered my questions patiently and pushed me to write code to a professional standard.

I extend my heartfelt thanks to HOD Name, Head of the Department, College Name, for the constant support and for granting me the opportunity to carry out this internship.

I am deeply thankful to my internal guide, Guide Name, Designation, for the valuable guidance, timely suggestions and encouragement offered at every stage of this internship and during the preparation of this report.

I also thank the Principal and the entire faculty of College Name for providing an academic environment that made this internship possible.

Finally, I am grateful to my parents for their constant encouragement and to my friends for their support and cooperation throughout this period.

TABLE OF CONTENTS

EXECUTIVE SUMMARY

This report presents the work carried out during my internship at Petisoft Technologies Pvt Ltd, Bengaluru, from start to end. The internship was centred on MERN Full Stack Web Development — the combination of MongoDB, Express.js, React and Node.js that allows a complete web application to be built end to end in a single programming language, JavaScript.

Objective

The objective of the internship was to move beyond classroom theory and develop the practical ability to design, build, test and deploy a complete web application. Rather than studying each technology in isolation, the programme was structured so that every topic built directly on the previous one, ending in a working full stack application.

Scope of work

The programme progressed through five connected stages: web foundations with HTML and CSS; core and modern JavaScript; front-end application development with React; server-side development with Node.js, Express and MongoDB; and finally the integration of all layers into a single deployed application. Practical exercises accompanied every stage, and two projects — a Student Management System and contribution to the company's live ZipBeam product — provided the context in which the skills were applied.

Key outcomes

• Built responsive, accessible interfaces using semantic HTML5 and modern CSS layout techniques including Flexbox and Grid.
• Gained working proficiency in JavaScript, from fundamentals through to ES6+ features, asynchronous programming with Promises and async/await, and consuming REST APIs with the Fetch API.
• Developed component-based single page applications in React using hooks (useState, useEffect), client-side routing, controlled forms and input validation.
• Designed and implemented RESTful APIs in Node.js and Express supporting full CRUD operations, backed by MongoDB collections modelled through Mongoose schemas.
• Integrated the React front end with the Express back end and MongoDB database to produce a complete, working full stack application.
• Contributed to ZipBeam, a live production file-transfer application, and experienced the professional workflow of code review, testing, debugging and deployment.

Conclusion

The internship successfully bridged the gap between academic study and industry practice. Beyond the technical skills gained, it provided an understanding of how professional software is actually planned, written, reviewed and shipped — knowledge that is difficult to acquire from textbooks alone and that will directly support my future work in software development.

CHAPTER 1

INTRODUCTION TO FULL STACK WEB DEVELOPMENT

1.1 Background

A modern web application is rarely a single program. It is normally divided into a front end, which runs inside the user's browser and is responsible for everything the user sees and interacts with, and a back end, which runs on a server and is responsible for business logic, security and data storage. Between the two sits an application programming interface (API), the agreed contract through which the two halves exchange information.

A developer who is capable of working competently on both halves, and on the database beneath them, is described as a full stack developer. The term is significant in industry because a developer who understands the whole system can reason about problems that cross boundaries — a slow page caused by an inefficient database query, for example — instead of being limited to one layer.

1.2 The three layers of a web application

1.3 The MERN stack

A stack is a specific, commonly used combination of technologies that covers all three layers. The MERN stack is one of the most widely adopted in the industry today and takes its name from its four components:

1.4 Why the MERN stack

The principal advantage of the MERN stack is that JavaScript is used throughout. The same language runs in the browser, on the server and in the database query layer. In practical terms this means a developer does not need to mentally switch between languages such as Java on the server and JavaScript in the browser, and code such as validation rules can often be shared between the two.

The other advantages identified during the internship were:

• JSON end to end. MongoDB stores documents in a JSON-like format, APIs exchange JSON, and JavaScript handles JSON natively. Data therefore flows through the system without repeated format conversion.
• Flexible schema. MongoDB does not require a fixed table structure to be defined in advance, which suits applications whose requirements evolve during development.
• Component reuse. React encourages interfaces to be broken into small, independent components that can be reused across an application, reducing duplicated code.
• Large ecosystem. The npm registry provides an enormous library of ready-made packages, and the community support available for MERN significantly shortens problem-solving time.
• Strong industry demand. MERN and closely related JavaScript stacks are widely used by startups and established companies alike, making these skills directly employable.

1.5 Objectives of the internship

• To understand the architecture of modern web applications and the responsibilities of each layer.
• To gain practical command of HTML, CSS and JavaScript as the foundation of all web development.
• To learn component-based front-end development using React and its hooks.
• To design and build RESTful APIs using Node.js and Express.js.
• To model, store and query data using MongoDB and Mongoose.
• To integrate all three layers into a single working application and deploy it.
• To experience professional development practice — version control, code review, testing, debugging and documentation.

1.6 Structure of this report

Chapter 2 describes Petisoft Technologies Pvt Ltd, the organisation where the internship was carried out. Chapter 3 presents the experiential learning in detail, organised into the technical modules covered. Chapter 4 describes the project work undertaken, principally the ZipBeam file transfer application. Chapter 5 sets out the outcomes of the internship, the challenges encountered and the conclusions drawn.

CHAPTER 2

DESCRIPTION OF THE ORGANIZATION

2.1 Company profile

2.2 About the organisation

Petisoft Technologies Pvt Ltd was established in 2014 by Mr. Preetham Paul Socrates P, who serves as the Chief Executive Officer of the company. Headquartered in Bengaluru, the company has successfully completed over 200 projects and has contributed to the community by offering free education to more than 500 girls.

The company is recognised for its commitment to delivering high-quality IT solutions and for fostering talent through real-world project experience and hands-on training. With a solid infrastructure, experienced mentors and a focus on industry-relevant technologies, Petisoft ensures that every intern and employee gains the skills necessary to work effectively in a competitive technology landscape.

2.3 Services and areas of work

• Custom software development — web platforms, internal business tools and systems built to client requirements.
• Mobile application development — applications for the Android and iOS platforms.
• SaaS products — the company designs, builds and operates its own software-as-a-service products.
• Internship and training programmes — structured, mentor-led programmes in which students work on live products rather than isolated exercises.

2.4 Technologies used by the organisation

Petisoft works across a range of technologies and development stacks, including Java, Python, Django, the MERN stack, React, Node.js, Express and MongoDB. Interns are exposed to the tools and workflows actually adopted by modern technology companies, including version control, code review and cloud deployment.

2.5 Internship philosophy

Although Petisoft is not a traditional training academy, it provides practical internship opportunities in which students work directly on live projects. These internships are focused on experiential learning rather than classroom-based instruction. Interns are mentored by experienced developers and are exposed to the latest tools, technologies and workflows used in professional software development.

The working environment is collaborative, fast-paced and inclusive, designed to help budding developers become capable professionals. Interns actively contribute to real products, thereby bridging the gap between academic knowledge and industry expectations.

2.6 Products developed by the organisation

Among the products built and operated by the company are ZipBeam, a QR-code-based instant file transfer service; Audivoix, a live audience engagement platform for presentations; and Muzafair.com, an e-commerce solution. Interns are given the opportunity to contribute to these live products, which forms the practical core of the internship experience. The project work described in Chapter 4 of this report was carried out on ZipBeam.

CHAPTER 3

EXPERIENTIAL LEARNING

This chapter describes the technical learning undertaken during the internship. The programme was organised as a progression of connected modules, each building on the one before it, so that by the end of the internship every layer of a full stack application had been covered and practised. Each module combined a short explanation of concepts with substantial hands-on implementation work.

3.1 Web Foundations — HTML and CSS

3.1.1 HTML — structure of a web page

The first module covered HyperText Markup Language, the language that defines the structure and meaning of content on a web page. The emphasis was placed on writing semantic HTML — choosing elements for their meaning rather than their appearance — because semantic markup improves accessibility for screen-reader users and helps search engines interpret a page correctly.

The topics covered and practised were:

• Document structure — the <!doctype> declaration, and the <html>, <head> and <body> elements; metadata including the character set, viewport and page description.
• Text content — headings <h1> to <h6>, paragraphs, lists, and the correct hierarchical use of headings.
• Links and images — the anchor element and relative versus absolute paths; the image element, and the importance of the alt attribute for accessibility.
• Tables — <table>, <thead>, <tbody>, <tr>, <th> and <td> for presenting tabular data.
• Forms — the <form> element, input types including text, email, password, number, date, checkbox and radio, together with <select>, <textarea> and <button>; the association of <label> elements with inputs, and built-in validation attributes such as required and pattern.
• Semantic layout elements — <header>, <nav>, <main>, <section>, <article> and <footer>.

3.1.2 CSS — styling and layout

Cascading Style Sheets control the visual presentation of HTML. This module covered how styles are applied, how conflicting rules are resolved, and in particular the two modern layout systems that have replaced older float-based techniques.

• Selectors and the cascade — element, class and ID selectors; descendant and pseudo-class selectors such as :hover and :focus; and how specificity and source order determine which rule wins.
• The box model — content, padding, border and margin, and the effect of box-sizing: border-box on predictable sizing.
• Typography and colour — font families, sizes, weights, line height, and colour notation including hexadecimal, RGB and HSL.
• Flexbox — one-dimensional layout, used for navigation bars, toolbars and evenly distributed rows of items, through properties such as display: flex, justify-content, align-items and gap.
• CSS Grid — two-dimensional layout, used for page structures and card galleries, through display: grid, grid-template-columns and the fr unit.
• Responsive design — media queries, relative units, and the mobile-first approach in which the base styles target small screens and larger layouts are added progressively.
• Custom properties — CSS variables for maintaining a consistent colour and spacing system across a project.

A representative example of the semantic structure and form markup practised in this module is shown below.

Listing 3.1 — Semantic HTML form with labelled inputs

The corresponding layout was produced with the two modern CSS layout systems. The following listing shows a responsive card grid that reflows from three columns on a desktop to a single column on a mobile screen without any change to the markup.

Listing 3.2 — Responsive layout using CSS Grid, Flexbox and a media query

Practical outcome: a responsive multi-section web page was built using semantic HTML and laid out with Flexbox and Grid, tested at mobile, tablet and desktop widths.

3.2 JavaScript Programming

3.2.1 Language fundamentals

JavaScript provides the behaviour of a web page. This module began with the core language before moving on to how it interacts with the browser.

• Variables — declaration using let and const, the concept of block scope, and why var is avoided in modern code.
• Data types — the primitive types (string, number, boolean, null, undefined) and the reference types (object, array, function).
• Operators — arithmetic, assignment, comparison and logical operators, and in particular the difference between loose equality (==) and strict equality (===).
• Control flow — if, else if, else, the ternary operator, switch statements, and the for, while and for…of loops.

3.2.2 Functions, arrays and objects

• Functions — function declarations, function expressions and arrow functions; parameters, default values, return values and the concept of scope.
• Arrays — creation and indexing; mutating methods such as push, pop, shift, splice; and the higher-order methods map, filter, find, reduce, forEach and sort, which proved central to working with data in React later in the programme.
• Objects — properties and methods, dot and bracket notation, nested objects, and iteration using Object.keys, Object.values and Object.entries.

3.2.3 DOM manipulation and event handling

The Document Object Model is the browser's in-memory representation of a page, exposed to JavaScript as a tree of objects. Manipulating the DOM is how a static page is made interactive.

• Selecting elements — getElementById, querySelector and querySelectorAll.
• Modifying the DOM — changing textContent, attributes and styles; adding and removing CSS classes through classList; creating and appending new elements.
• Events — registering handlers with addEventListener for events such as click, input, submit, change and keyboard events.
• The event object — reading event.target, and the use of preventDefault() to stop a form's default page reload so that it can be handled in JavaScript.
• Event bubbling and delegation — attaching a single handler to a parent element to manage events from many children efficiently.

3.2.4 Modern JavaScript — ES6 and asynchronous programming

The ECMAScript 2015 standard, commonly called ES6, together with later revisions, introduced features that make JavaScript considerably more concise and readable. These features are used throughout React and Node.js code, so this module was essential preparation for what followed.

• Template literals for readable string construction with embedded expressions.
• Destructuring of arrays and objects, used constantly in React to extract props and state.
• Spread and rest syntax (…) for copying and merging arrays and objects, and for collecting function arguments.
• Modules — import and export for splitting code across files.
• JSON — the JavaScript Object Notation data format, and conversion using JSON.stringify() and JSON.parse().
• Asynchronous programming — why JavaScript is single-threaded and non-blocking; callbacks and the problem of deeply nested callbacks; Promises with .then() and .catch(); and the async/await syntax that allows asynchronous code to be written in a clear, sequential style with try…catch error handling.
• The Fetch API — making HTTP requests from the browser, handling the response, parsing JSON, and dealing with network and server errors.

The difference between the older callback style and modern asynchronous syntax was studied directly by rewriting the same request both ways. The listing below shows the final form, using async/await with proper error handling.

Listing 3.3 — Fetching data with async/await, including loading and error states

Two points were emphasised here. First, every network request has three possible outcomes — loading, success and failure — and an interface that handles only the success case will appear broken the moment anything goes wrong. Second, the response.ok check is necessary because fetch does not treat an HTTP error status such as 404 or 500 as a failed promise; without that check, an error page would be parsed as though it were valid data.

Practical outcome: an interactive application was built that fetched data from a public REST API, handled the loading and error states correctly, and rendered the results dynamically into the DOM.

3.3 Front-End Development with React

3.3.1 Introduction, Vite, JSX and components

React is a JavaScript library for building user interfaces from small, self-contained pieces called components. Rather than manipulating the DOM directly, a developer describes what the interface should look like for a given state, and React efficiently updates the real DOM to match by comparing against a lightweight copy known as the virtual DOM.

• Project setup with Vite — creating a React project using Vite, which provides a fast development server with hot module replacement and an optimised production build. The structure of the generated project and the role of each file were examined.
• JSX — the syntax extension that allows markup to be written inside JavaScript, and the rules that distinguish it from HTML, such as className in place of class, the requirement for a single root element, and the embedding of expressions in braces.
• Components — writing function components, composing them, and organising them into separate files.

3.3.2 Props, lists and conditional rendering

• Props — passing data from a parent component to a child, which makes components reusable with different content; the principle that props are read-only.
• Reusable components — designing a single component, such as a card or button, that can be used throughout an application.
• Rendering lists — using the map method to transform an array of data into an array of elements, and the importance of a stable, unique key prop so that React can track items correctly across updates.
• Conditional rendering — using the logical AND operator and ternary expressions to show or hide parts of the interface based on state.

3.3.3 State management with useState

State is data that belongs to a component and that changes over time. When state changes, React re-renders the component so that the interface reflects the new value.

• The useState hook — declaring state, reading it and updating it with the setter function.
• The rule that state must never be mutated directly; a new value or a new copy of an object or array must be provided instead.
• Updating state based on its previous value using the functional form of the setter.
• Lifting state up — moving shared state to the nearest common parent so that sibling components can stay synchronised.

The listing below shows a complete function component using the useState hook. It demonstrates state declaration, an event handler, conditional rendering and the rendering of a list with a stable key — the core React concepts covered in this module.

Listing 3.4 — React component using useState, conditional rendering and list keys

3.3.4 Forms, input handling and validation

• Controlled components — binding an input's value to state and updating that state on every change, so that React remains the single source of truth.
• Handling multiple inputs efficiently with a single state object and a shared change handler.
• Handling form submission, preventing the default browser behaviour, and resetting the form afterwards.
• Validation — checking for required fields, validating email format with regular expressions, enforcing minimum lengths, displaying clear error messages next to the relevant field, and disabling the submit button while a request is in progress.

3.3.5 The useEffect hook and API integration

• Side effects — operations such as fetching data, setting timers or subscribing to events, which must not be performed during rendering.
• The useEffect hook and its dependency array: running an effect once after the first render, running it whenever a particular value changes, and the cleanup function that prevents memory leaks.
• Fetching data from an API inside an effect, and managing the three states every such request has — loading, success and error — so that the user always receives appropriate feedback.

The following listing shows data being fetched inside useEffect with the three interface states handled explicitly, and a cleanup flag that prevents a state update after the component has been removed from the screen.

Listing 3.5 — Data fetching in useEffect with loading, error and cleanup handling

3.3.6 Routing and navigation

• The concept of a single page application, in which navigation updates the view without a full page reload.
• React Router — configuring routes, rendering the matched component, and linking between pages with the Link and NavLink components.
• Dynamic route parameters for detail pages, programmatic navigation after an action such as a successful form submission, and a catch-all route for unmatched URLs.

3.3.7 Mini project — Student Management System

To consolidate the React modules, a Student Management System was built as a front-end application. It allowed student records to be added through a validated form, displayed in a searchable and filterable list, edited and deleted, with navigation between a list view and a detail view handled by React Router. The project required every React concept covered up to that point to be used together, and was the first point at which the separate topics came together into something that behaved like a real application.

3.4 Back-End Development with Node.js and Express

3.4.1 Node.js

• Node.js as a runtime that executes JavaScript outside the browser, built on Chrome's V8 engine.
• Its event-driven, non-blocking input/output model, and why this makes it efficient for applications that handle many simultaneous connections.
• The npm package manager, the role of package.json, and the distinction between dependencies and development dependencies.
• Core built-in modules including fs for the file system, path for file paths and http for creating a basic server.
• Environment variables for configuration and for keeping secrets such as database credentials out of source code.

3.4.2 Express.js

• Creating an Express application and listening on a port.
• Routing — defining handlers for different HTTP methods and paths, and reading route parameters, query strings and request bodies.
• Middleware — functions that run between the request and the response, used for parsing JSON bodies, logging, authentication and error handling.
• Organising routes into separate modules as an application grows.
• CORS — understanding why a browser blocks requests from a front end running on one origin to an API on another, and configuring the server to permit them.

3.4.3 REST API design

Representational State Transfer is an architectural style for designing networked applications. A REST API exposes resources at predictable URLs and uses standard HTTP methods to act on them. The conventions studied and applied were:

The meaning of HTTP status codes was studied in particular: the 2xx range for success, 4xx for errors caused by the client such as 400 Bad Request and 404 Not Found, and 5xx for errors on the server. Returning the correct status code, rather than always returning 200, was emphasised as an important part of API quality. APIs were tested independently of any front end using tools such as Postman and Thunder Client.

A minimal Express server illustrating routing, middleware and a parameterised route is shown below.

Listing 3.6 — Express server with middleware and routes

3.5 Databases with MongoDB and Mongoose

3.5.1 MongoDB

• The difference between relational databases, which store data in tables with a fixed schema, and document databases such as MongoDB, which store flexible JSON-like documents.
• MongoDB terminology — databases, collections and documents — and how these correspond to databases, tables and rows in a relational system.
• The _id field and the ObjectId type automatically assigned to every document.
• Basic query operations and operators such as $set, $gt and $in.
• MongoDB Atlas — creating a free cloud-hosted cluster, configuring a database user and network access, and obtaining a connection string.
• MongoDB Compass — the graphical client used to browse collections, inspect documents and test queries visually, which proved valuable when debugging.

3.5.2 Mongoose

• Mongoose as an Object Data Modelling library that adds structure and validation on top of MongoDB.
• Schemas — defining the expected shape of a document, including field types, required fields, default values and validation rules.
• Models — the constructors compiled from schemas, through which documents are created and queried.
• Query methods including find, findById, findByIdAndUpdate and findByIdAndDelete.
• Connecting to MongoDB Atlas from an Express application and handling connection errors properly.
• Timestamps, and relationships between collections using references and populate.

3.5.3 CRUD API development

The back-end and database modules were brought together by building a complete CRUD API. Each of the five REST endpoints was implemented against a Mongoose model, with validation of incoming data, correct HTTP status codes, consistent JSON response shapes and proper error handling using try…catch. Every endpoint was tested independently before any front end was connected to it.

The Mongoose schema and the create endpoint built against it are shown below. The schema enforces the shape of each document and validates incoming data before it reaches the database, while the route returns appropriate HTTP status codes for success and failure.

Listing 3.7 — Mongoose schema with validation and CRUD endpoints

3.6 Full Stack Integration

3.6.1 Connecting the layers

The final technical module joined the React front end, the Express back end and the MongoDB database into a single working application. The practical issues addressed were:

• Running the front-end development server and the back-end API server simultaneously on different ports.
• Resolving cross-origin request failures by configuring CORS correctly on the server.
• Calling the API from React inside useEffect and on form submission, and keeping the interface synchronised with the database after create, update and delete operations.
• Storing the API base URL in an environment variable so that the same code works in development and in production.
• Handling loading and error states so that the interface never appears frozen or silently fails.

3.6.2 Testing, debugging and deployment

• Debugging the front end — the browser developer tools, the console, and the network tab for inspecting requests, response bodies and status codes.
• Debugging the back end — reading server logs, inspecting request payloads, and isolating whether a fault lay in the front end, the API or the database.
• Testing — verifying each endpoint independently, then testing complete user journeys through the interface, including invalid input and empty states.
• Deployment — environment variables and configuration, production builds, and the general process of deploying an application to a cloud platform.
• Version control — using Git for commits, branches and collaboration, and the discipline of writing clear commit messages.

3.7 Tools and Development Environment

Equal attention was given to the tools used day to day. Familiarity with a professional toolchain proved to be as important as knowledge of the languages themselves, because most time in practice is spent reading, running and diagnosing code rather than writing it.

3.7.1 System requirements

The development environment used during the internship had the following minimum requirements.

3.7.2 Working practices observed

• Small, frequent commits. Changes were committed in small logical units with descriptive messages, so that a fault could be traced to the change that introduced it.
• Reading the error before changing code. Error messages and stack traces were read carefully first; guessing at a fix without understanding the cause usually created a second problem.
• Testing one layer at a time. When something failed, the API was tested independently before the interface was examined, which isolated the fault quickly.
• Keeping secrets out of source code. Database credentials and keys were held in environment variables and never committed to the repository.
• Consistent formatting. Automatic formatting was used so that code style remained uniform and code reviews could focus on logic rather than layout.

CHAPTER 4

PROJECT WORK — ZIPBEAM FILE TRANSFER APPLICATION

4.1 Introduction to the project

In addition to the structured learning modules, interns were given the opportunity to work on ZipBeam, a live product built and operated by Petisoft Technologies Pvt Ltd and available publicly at zipbeam.in. Working on an application that real users depend on was a markedly different experience from building practice exercises, and it formed the most valuable part of the internship.

4.2 Problem statement

Transferring a file from a mobile phone to a computer is a routine task that remains surprisingly awkward. The common approaches each carry a cost: a USB cable requires the correct connector and often a driver; emailing a file to oneself imposes attachment size limits and clutters the mailbox; messaging applications compress photographs and reduce their quality; and cloud storage services require an account, an installed application and a wait for the file to synchronise.

ZipBeam was designed to remove this friction entirely. The requirement was a transfer that needs no application installation, no user account and no cable — the user simply opens a web page on the computer, scans the displayed QR code with the phone, selects the files, and they appear on the computer within seconds.

4.3 Objectives of the project

• To enable file transfer from a mobile device to a computer through the browser alone.
• To remove the need for account creation, installation or physical connection.
• To deliver files in real time, so that they appear on the receiving device as soon as they are uploaded.
• To keep the service secure through session-based access, automatic expiry and one-time downloads.
• To provide an interface that works comfortably on both mobile and desktop screens.

4.4 System architecture

ZipBeam follows a client–server architecture in which a single Node.js server handles both the web interface and the file transfer sessions. The flow of a transfer is as follows:

1. The user opens ZipBeam on the computer. The server creates a new session with a unique, randomly generated token and a limited lifetime.
2. The session token is encoded into a QR code and displayed on the computer screen.
3. The user scans the QR code with a mobile phone camera, which opens the upload page for that specific session.
4. The user selects one or more files on the phone and uploads them. Upload progress is shown for each file.
5. The server receives the files and notifies the waiting computer in real time using Server-Sent Events, a browser standard for pushing updates from a server to a page over a single long-lived HTTP connection.
6. The files appear in the computer's browser and can be downloaded. Once downloaded, they are removed from the server.

4.5 Technologies used

A notable engineering decision in ZipBeam is that the server is written using only the built-in modules of Node.js, with no external npm dependencies in the server code. This keeps the application small, fast to start and free from the security and maintenance burden that accompanies a large dependency tree — a design consideration that is rarely encountered in academic projects and was instructive to study.

4.6 Key features

• QR-code sessions — each transfer session has a unique code that expires automatically after a set period.
• Real-time delivery — files appear on the receiving device immediately, without the page being refreshed.
• Multiple file upload — several files can be sent at once, each with its own progress indicator.
• Large file support — files of substantial size are supported through streaming rather than loading the whole file into memory.
• One-time download — files are deleted from the server after being downloaded, limiting how long data is retained.
• Security measures — session tokens, rate limiting and the blocking of dangerous file types.
• Responsive, mobile-first interface with support for the operating system's dark mode preference.

4.7 Contribution and learning from the project

Working on ZipBeam provided exposure to aspects of software development that practice exercises cannot reproduce. The areas of involvement and learning were:

• Reading an existing codebase. Professional work usually begins with understanding code written by other people. Tracing how a request travelled from the interface through the server and back was an essential skill to develop.
• Interface work. Applying the HTML, CSS and JavaScript skills from earlier modules to a real interface, including responsive behaviour and accessibility considerations.
• Understanding real-time communication. Studying how Server-Sent Events maintain an open connection and deliver updates, and how this differs from repeatedly polling the server.
• Testing on real devices. Verifying behaviour across different phones, screen sizes and network conditions, which revealed issues that never appeared on a desktop browser.
• Debugging in a live context. Using the browser network tab and server logs to trace faults, and learning to reproduce a problem reliably before attempting to fix it.
• Code review. Submitting work for review and responding to feedback, which improved code quality and introduced the standards expected in a professional team.

4.8 Testing

Testing was carried out manually against the behaviour expected of each feature. Rather than checking only that a feature worked when used correctly, each case was also exercised with invalid input and under adverse conditions, since that is where defects usually hide. The principal test cases and their outcomes are summarised below.

Testing on real devices proved particularly instructive. Several issues appeared only on an actual mobile handset and never in the desktop browser's device simulator — differences in how the file picker behaves, how the on-screen keyboard resizes the viewport, and how a slower mobile connection changes the perceived responsiveness of the interface. This reinforced a lesson that recurred throughout the internship: an application is not tested until it has been tested in the conditions its users will actually experience.

4.9 Results

ZipBeam operates as a live, publicly accessible service. Through this project I was able to observe how a complete product is maintained in production — how changes are tested before release, how failures are diagnosed, and how decisions are weighed between adding features and keeping a system simple and reliable. The experience of contributing to software that real users depend on, rather than to an exercise that is discarded once marked, was the single most valuable outcome of the internship.

4.10 Scope for Further Work

Studying a live product naturally raises the question of what could be added next. The following enhancements were identified during the internship as realistic directions for future development, and considering them was itself a useful exercise in thinking about a product rather than only about code.

• End-to-end encryption. Encrypting files in the browser before upload so that the server never holds readable content, at the cost of added complexity in key exchange.
• Transfer in the reverse direction. Allowing files to be sent from the computer to the phone using the same session mechanism.
• Resumable uploads. Allowing an interrupted large transfer to continue from where it stopped rather than restarting.
• Optional accounts. A lightweight account for users who want a history of transfers, while keeping the anonymous flow as the default.
• Progressive web app installation. Allowing the service to be added to a phone's home screen for faster access.
• Transfer statistics. Aggregate, anonymous data on transfer sizes and success rates to guide future performance work.

An important observation here was that not every possible feature should be built. Part of the reason ZipBeam works well is that it does one thing with very little friction, and each addition carries a cost in complexity, maintenance and loading time. Deciding what to leave out proved to be as considered a decision as deciding what to include.

CHAPTER 5

INTERNSHIP OUTCOMES AND CONCLUSION

5.1 Technical skills acquired

5.2 Professional skills developed

• Problem solving. Breaking an unfamiliar problem into smaller parts, and forming a hypothesis about a fault before changing code rather than guessing.
• Reading documentation. Learning to consult official documentation as a first resort, which is faster and more reliable than searching for an answer elsewhere.
• Communication. Describing a technical problem clearly enough for a mentor to help, and explaining completed work to others.
• Receiving feedback. Treating code review as a means of improvement rather than criticism.
• Time management. Working to deadlines and making steady progress on a task spread over several sessions.
• Attention to detail. Appreciating that small matters — a missing error state, an unhandled edge case, an inaccessible form field — are what separate working code from professional code.

5.3 Challenges faced and how they were addressed

5.4 Outcomes of the internship

• Gained the ability to build a complete web application independently, covering the interface, the server-side API and the database.
• Developed a working understanding of how the three layers of a web application communicate, and of where responsibility for a given problem lies.
• Produced tangible project work, including a Student Management System and contributions to the live ZipBeam application, which form the basis of a practical portfolio.
• Experienced professional development practice at first hand — version control, code review, systematic testing and deployment.
• Significantly increased confidence in approaching unfamiliar technologies, having learned how to read documentation and reason through problems methodically.
• Gained clarity about career direction within software development and about the areas warranting further study.

5.5 Relevance to academic study

The internship complemented academic study directly. Concepts encountered in coursework — data structures, database design, networking and software engineering principles — appeared in practical form and became considerably easier to understand once their purpose was visible. Equally, the internship demonstrated that writing correct code is only part of professional software development; understanding requirements, handling failure cases, documenting work and communicating clearly matter just as much.

5.6 Conclusion

The internship at Petisoft Technologies Pvt Ltd provided a comprehensive, practical introduction to full stack web development using the MERN stack. Beginning with the fundamentals of HTML and CSS and progressing through JavaScript, React, Node.js, Express and MongoDB, the programme built a complete picture of how modern web applications are constructed and how each layer depends on the others.

The most significant outcome was not the list of technologies learned but the change in how I approach problems. Working on a live product made clear that professional software development is less about knowing every answer in advance and more about investigating methodically, reading documentation carefully, testing assumptions and asking precise questions. The opportunity to contribute to ZipBeam, an application in genuine public use, gave the work a sense of consequence that practice exercises cannot provide.

I am grateful to Petisoft Technologies Pvt Ltd for the opportunity, to the mentors who guided the work and reviewed it patiently, and to my college for enabling the internship. The experience has strengthened my technical foundation, clarified my career direction and prepared me for the professional responsibilities that lie ahead.

BIBLIOGRAPHY

Official documentation

1. MDN Web Docs — HTML, CSS and JavaScript reference. Mozilla. https://developer.mozilla.org/
2. React — Official documentation. https://react.dev/
3. Node.js — Official documentation. https://nodejs.org/docs/
4. Express.js — Official guide and API reference. https://expressjs.com/
5. MongoDB — Official manual. https://www.mongodb.com/docs/
6. Mongoose — Official documentation. https://mongoosejs.com/docs/
7. Vite — Official guide. https://vite.dev/
8. React Router — Official documentation. https://reactrouter.com/
9. MongoDB Atlas — Cloud database documentation. https://www.mongodb.com/docs/atlas/

Standards and specifications

10. ECMAScript Language Specification. Ecma International. https://tc39.es/ecma262/
11. HTML Living Standard. WHATWG. https://html.spec.whatwg.org/
12. Server-Sent Events specification. WHATWG HTML Standard. https://html.spec.whatwg.org/multipage/server-sent-events.html
13. Web Content Accessibility Guidelines (WCAG). W3C. https://www.w3.org/WAI/standards-guidelines/wcag/

Organisation and project references

14. Petisoft Technologies Pvt Ltd — Official website. https://petisoft.in/
15. ZipBeam — Instant QR-based file transfer. https://zipbeam.in/