Deploying Web Applications at Full Sail University

This post covers my experience with WDV463 Deployment of Web Applications at Full Sail University. Every course up to this point had the finish line in the same place: a working project on my local machine that I could demonstrate in a browser. This course moved the finish line. Working on a local machine is not the same as deploying something that anyone with an internet connection can actually open. This class closed that gap. My project for the course was a migraine log, a personal tool for tracking episodes, symptoms, and patterns over time. It was a project I actually wanted to exist, which made every deployment step feel meaningful rather than academic. Below is a breakdown of each week and what it taught me.

---

Week 1: Deploying a Static Site and Making It Publicly Accessible

My thoughts at the time

The first week set the context for everything that followed. The assignment was to build and deploy a static website that was accessible from any device with an internet connection. The technical bar for a static deployment is lower than what came later in the course, but that simplicity made it a useful starting point. For the first time I was not running a local server and pretending it was production. I was putting something on the internet.

Getting the migraine log's static front-facing layer deployed early also gave me a foundation to iterate on. Seeing the project live, even in its most basic form, changed how I thought about the remaining weeks. Every addition would need to actually work in a real environment, not just on localhost.

Retrospective insight

This week reframed how I think about development environments. The difference between something that works locally and something that works in production is not always small, and the earlier you expose that gap by deploying, the less painful it is to close. I also gained a better understanding of what static hosting actually means from an infrastructure perspective, separating it cleanly in my mind from server-rendered or dynamically served applications. That distinction has come up repeatedly in conversations about architecture and cost tradeoffs since.

---

Week 2: API First Development and Multi-Device Deployment

My thoughts at the time

Week two introduced API First development as a design philosophy, which reframed how I thought about building the migraine log's backend. Rather than treating the API as a detail attached to the frontend, I started thinking about it as the core of the application that the frontend would consume. Creating a secondary interface for the application made that separation concrete. The migraine log needed to accept and return data in a way that worked regardless of what was consuming it.

The multi-device deployment theme added a practical constraint that raised the quality of the work. Knowing that the application needed to function properly across different screen sizes and network conditions pushed me to think more carefully about how data was fetched, how errors were handled, and how the interface adapted.

Retrospective insight

API First thinking is one of the more durable shifts in perspective that came out of this course. It is easy to build a tightly coupled application where the frontend and backend assumptions are baked into each other in ways that make future changes painful. Designing the API as a clean contract first makes everything downstream more flexible. For the migraine log specifically, this meant the data structure I defined in week two stayed stable through the rest of the course even as the frontend and authentication layer changed around it.

---

Week 3: Building the Full Stack and Connecting All Three Layers

My thoughts at the time

Week three was the most technically dense week of the course. The goal was a fully deployed web application using modern client, server, and database technologies together. For the migraine log this meant the frontend interface, the Node.js backend, and the MongoDB database all needed to be running and connected in a live environment, not locally, but actually deployed and accessible.

Getting all three layers working together in production surfaced issues that local development had hidden. Environment variables needed to be configured correctly on the host, database connection strings pointed to a real instance rather than localhost, and error handling that had never been triggered locally suddenly mattered. Working through those issues on a project I genuinely cared about made the troubleshooting feel less frustrating and more purposeful.

Retrospective insight

This week gave me the most complete picture of full stack deployment I had encountered in the program to that point. Understanding that each layer of an application has its own deployment concerns, and that they interact in ways that require deliberate configuration, is knowledge that does not fully transfer from reading. You have to go through the process of something breaking in a production environment and then figure out why. The migraine log gave me a real enough context that the problems felt worth solving carefully, and the solutions stuck in a way that they might not have with a generic assignment.

---

Week 4: Adding User Authentication and Finishing the Application

My thoughts at the time

The final week added user authentication to the deployed application, which was the feature that made the migraine log feel like a real product rather than a demonstration. Without authentication, the data belonged to whoever was looking at the screen. With it, the log became something that could plausibly be used by a real person to track their own health data privately over time.

Implementing authentication in a deployed environment also introduced a category of security considerations that local development had completely obscured. Session persistence, token handling, secure routes, and protecting data so that one user cannot access another person's records all required more careful thought than any frontend or API work I had done before.

Retrospective insight

Authentication was the last piece that made the application coherent as a product. It also introduced the most direct overlap with security concerns I have encountered in any course in the program. Understanding how user sessions work, how authentication state is maintained across requests in a stateless protocol, and what can go wrong when those pieces are implemented carelessly has influenced how I evaluate authentication solutions in every project since. The migraine log ended the course as something I was genuinely proud of, a working, deployed, authenticated application built around a real personal need.

---

Closing Thoughts

Deployment of Web Applications was one of the most perspective-shifting courses in the program. It took skills I had been building for months and asked a different question: not whether I could build something, but whether I could ship it. Learning to close the gap between local development and a live production environment, deploy across multiple devices, architect around an API First approach, and implement user authentication in a real deployed context all compounded into a significantly more complete understanding of what modern web development actually involves. The migraine log was a surprisingly fitting vehicle for all of it.

Credits and Collaboration

A huge thank you to Esther Allin for designing the blog banner art! If you're looking for a professional digital media specialist, Connect with her on LinkedIn!