By: Malcom Calivar

Published: March 10, 2020

Project description

ApecMDB was my first "real" project I worked on in university. What I mean by "real" is that this was the first completely unguided project of my academic career. Up until that point, I had been given somewhat simple tasks, which the professor would have us complete alongside them. In this case, I was simply given a task(create a movie database) and a language(Java) and set loose on the world to come up with my own solutions for doing so. 

Despite being one of my earliest projects, and one of my messiest, I've chosen to include it because it was the first time I had to research on my own and solve my own problems using documentation and the internet. 


Preparing the project

The first thing I had to decide was the technologies I would use. As far as IDE, our university had Netbeans installed in every lab, so it was what our professor suggested we use for our own project. My next step was figuring out how I would tackle the project. Would I create my own database? Would I use an existing one, and if so, how would I query it?

The answer to that question came in the form of public APIs. I had not tried consuming public APIs beforehand within my applications, so this was something I would have to learn. On top of that, though I had created webapps before, it had been using C# or PHP frameworks; I had little to no knowledge of Java or any of its web frameworks.

Thus, my challenges were laid in front of me:

1. Figure out and learn one of Java's web frameworks.

2. Learn how to consume a web API within a web app.

Early issues

I had a rough idea now of what I needed to do. Unfortunately, I learned very quickly that using a Java framework would not be as simple as creating a .NET web app project in Visual Studio and having at least a very basic web app running in a few minutes. The words 'Gradle' and 'Maven' kept showing up in my searches as I looked for ways to create a web app through the Netbeans IDE. It seemed that for every Google attempt, all I ended up with was more and more words that I was unfamiliar with.

Worse still, given how long Java's been around, a lot of the information I ended up finding was incredibly outdated. How could I be sure I'd learn something that was actually useful and relevant? The amount of terms I was bombarded with was so large, that when I thought about which tags I could attach to this post, I had to restrict myself; I could easily end up including a dozen project dependencies.

Finding the right tools

A day or so had passed since the beginning of my journey and so far all I had was a bunch of new terms that were completly alien to me. However, a certain name kept showing up over and over: Spring. I learned that Spring MVC was a popular framework for web app development in Java. Not only that, their Spring Initializr would allow me to generate a project file I could import directly into my IDE, and I'd have something to work with similar to what I'd have if I created a Visual Studio project.

I had yet to write a single line of code, but I was now working with something that I was much more familiar with, at least. Within a few hours of tutorials and reading through documentation, I now had a basic grasp of how to develop an app using Spring. I'll abridge the part where on top of all this, I had to learn to use a template engine, Thymeleaf, to be able to render the pages properly. As I said, if I talked about every dependency, this blog post would end up being longer than my code. 

Public API

I had not worked with API endpoints up until now. Everything we'd done during our first year at university was fed by models we'd created ourselves. One of my earliest web projects used ASP.NET MVC and Entity Framework to create CRUD functionality in an app. It was as easy as defining models in C# or within a database, then watching as Visual Studio created controllers and views based on those models. Put some data into the database using these CRUD views then play around with it in the web app. 

After trying a few public APIs that serve movie information, I managed to find one that I liked. A week or so had passed now, and I finally had the back-end part of this application working. I could query the API endpoints and get movie data in return that I could render on my template pages. All that was left now was to design the way this data would be presented to the user.

Final design

This, in a nutshell, is what the final design ended up looking like. 


Lessons learned

The importance of having a plan before beginning any project was really driven home for me during this activity. I went into it knowing very little, I tried a bunch of different things before I finally found a solution that would work. It was a lot of trial and error at first that I could've spared myself if I had done some research beforehand. Since then, if I'm going to work with frameworks I'm not familiar with, I'll make a habit not only of going through their docs, but also of researching alternatives. Given the vast amount of frameworks out there, it's relatively easy to find one that'll work for your project.

That was another important lesson taken away from this: find tools that fit the project, not the other way around. Don't try to force a simple web app to a framework that's used for large-scale or enterprise project. Yes, it will work, much in the same way explosives will work for fishing. With the existence of so-called "micro" frameworks like Flask, why use something with a steep learning curve and an MVC or MVT design pattern you may not ultimately end up needing?