Go Back

First Web App Deployed!

Posted by Charlie Ontiveros on 2018-10-24

So I finally completed and deployed my first full stack web application! Although, truth be told, this is the second iteration. This project initially started way back when, in the Fall of 2017. I had finished building a few trivial projects, designed mainly for learning HTML, CSS, and JS basics, and I was itching to build something of real use. Since I spent a lot of time on personal endeavors, I figured, why not build something I can use to keep track what I'm doing. And so Task Trackr was born.

What the project does

Task Trackr allows a user to create projects, define categories, and generate entries. It's a simple way to see how much time is being spent on a particular activity.

The first iteration was based on traditional web architecture, with a big exception. I created a few webpages/views with Nunjucks and loaded the libraries I needed by adding scripts directly on the pages that needed them. However, most of the application logic was done on the front end with Vuejs.

Overall, somewhat of a sloppy affair, but this was my first attempt at building a web application. Although I succeeded in creating a usable web app, I quickly found out the code was difficult to modify when adding new features. I also wanted to get my feet wet with the modern approaches to web applications. Thus, I decided to create a second iteration.

The second iteration was built using Vuejs, Node, Express, and SQLite. Unlike the previous iteration, this one followed SPA architecture a lot more closely and is the iteration that is deployed on tasktrackr.net today.

Technologies Used

I chose Vuejs mainly due to its simplicity and I absolutely love it. It's very intuitive and doesn't 'fight' me when coding, well at least most of the time. Vue Router and Vuex are also a pleasure to use. Vuejs also has great documentation and I was able to build my app after taking Maximilian Schwarzmüller's excellent course, Vue JS 2 - The Complete Guide (incl. Vue Router & Vuex).

Although my first programming language was Python and it could be used to write server-side code, I chose to use Node. As a programming newbie, why take on learning two entirely different languages at once? Since I was already using (forced to use) JS on the front end, I'd figured I should just stick to it on the back end as well. I could always go back to Python later.

Choosing Express was a no-brainer since it is a mature library with tons of tutorials. Furthermore, there is a large number of ready to use middlewares to help with basic tasks like authentication and authorization instead of building them from scratch.

Although MongoDB is very popular I decided to go with SQLite for reasons I describe in Why I Use SQLite Instead of MongoDB.

Lessons Learned

I learned so many things with this project, it's hard to list them all. For starters, I learned how to create DB schemas in the 3rd form, Vuejs, Vue Router, Vuex, CORS, how to create routes and middleware with Express, and DevsOps on Apache and Ubuntu.

Surprisingly, the biggest challenges I faced during this project was not coding itself, but rather setting up a development environment and automation. I spent many hours learning about and configuring Webpack, VS Code, and eventually Ubuntu once I was ready to deploy the app to the cloud.

Ubuntu...

Being a Windows user all my life, I tortured myself for hours on Ubuntu, a system that was never designed with user friendliness in mind, and Apache to learn the nitty gritty of serving up web content... and also to take advantage of free VM tiers on GCP and AWS ;).

I know many would point out easier ways to deploy applications, but I'm the one who likes to know how the entire process works and how all the pieces of the puzzle fit together. It was definitely worth it for me.

I did however, run into a weird issues with Vuejs. TL;DR, duplicate entries were being generated. After trying different solutions over time, with all of them failing, I finally found out the behavior was intended. I had written code with incorrect assumptions about how a Vuejs instance work when used as event bus. I go over this particular issue in more detail here Duplicate Vue Event Listeners and How I Solved Them.

The other issue I ran into was with Passport JS. It was not as easy to use as it was made out to be. I didn't like the fact that it hid way too much of what it was doing under the hood. If an issue occurred, it was never clear what it was. I spent quite a bit of time troubleshooting and trying to configure authentication until I finally got it.

Continued Challenges / Areas of improvement

Despite having a fully functional app, there are many things that can be improved. This is especially true of a first web app.

The back end that I created does not meet RESTful principles. This is somewhat of a low priority to me as the current back end services work just fine. Refactoring here would provide minimal benefits.

Error handling still has a few minor issues. I searched online during my development of Task Trackr and couldn't find anything extensive or with specific examples about how to handle error messaging across an entire application. All of the samples for error handling I found online were trivial.

One issue I wanted to solve was standarization of error messages. I was able to do this by pre-defining error messages and creating my own error object format. I wrote an article about this here. However, once I deployed my application, I ran into issues where error messages sent by Apache were not handled by the front end correctly since I was expecting an object with a specific format. Although, the app handles 90% of all errors correctly, handling the last 10% have proven challenging. I'm sure the architecture behind my error handling is flawed and needs to be corrected.

Another area of improvement is to add front end testing. With everything I had to learn just to get this app developed and deployed, I decided not to tack on front end testing. That, to my knowledge, would have required learning an entirely different framework or software, like Selenium, to perform the testing. It was just a bit too much at that point, but I will definitely look into learning more on this subject on my next web project.

What's Next

To conclude, I'm very happy with Task Trackr. As an application, it does exactly what it needs to do; track all the time I'm spending on this incredible pastime. You can check it out at tasktrackr.net.

As an aside, my next project is going to focus purely on the back end. It's going to be a RESTful API that converts complex XML files into JSON. I will also be using SQL Server since it has powerful built-in functionality to deal with XML.