Frontend, Backend, and the Dinosaur in Between
One of the many reasons JavaScript has taken off in recent years is the success of NodeJS, an open-source, cross-platform JavaScript run-time environment for executing JavaScript code server-side. Now, full-stack projects can be completed with this one language alone… as well as about 400 libraries and packages alongside.
A week before writing this, myself and another coding newbie wanted to build an app that recommended interests based on past likes. We would use the TasteDive API, which contains a database of books, movies, and music built upon similarities. Long story short, this would be the biggest project I’ve ever tackled.
Schemes of Schema
I didn’t sleep much this past week. Quiet night hours were spent researching how to do specific things like create a schema using Mongoose, then add a sub-schema within that first schema.
The point of the schema is to hold onto users in a database (living on mLab), then having each of those users have a curated list of things they enjoy. If you take a look at the listSchema, after adding a particular movie (let’s say Die Hard) to his/her list, a user could give the date which the film was seen and a rating out of five. While that was the initial plan, timing only allowed my partner and I to add names to the database. I’d also like to mention that the userSchema currently has all required fields set to false. When you do as much testing as we have, constantly logging in is a burden that we did not want to deal with.
Connecting front to back
When first planned, I didn’t realize the intricacies of connecting the front-end (where all my event handlers and things were living) to the backend (where all my endpoints were living). What we ended up doing was creating a cookie that logs a username on the front-end, then is brought to the backend for storing the user in a database. While I’m an advocate for frequent cookie eating, the use of a cookie for this purpose is still a bit new to me, so it ended up causing more of a headache than anything.
Testing… 1, 2, 3
Before I make any promises, the current state of this app is ‘in progress’ so while we are using Travis CI to check our tests and Heroku for deployment, there are still a few bugs that need to be worked out. This means the app is currently only working properly on my machine (UPDATE! The app is currently living here).
Starting this app, I wasn’t too keen on testing. It seemed like a waste of time that I didn’t necessarily have. However, the integration of Mocha and Chai has led me to believe I went about this project all wrong. Testing is important, especially for a big project that has plenty of bells and whistles. The initial planning stage should have included more of a documented chart of the user experience. If I click this button, at which endpoint do I end up? When I update this entry, am I correctly using a PUT request?
The biggest takeaway from this first seemingly huge app is that the amount that I’ve learned outweighs the amateur look and feel for my code. I know this can be done cleaner.
The “Finished” Product
Finished is a strong word, but at least there is a semi-working app now.
