A 24-Hour Frontend Web Development Challenge

Photo by Michael Marais on Unsplash. The only man who could ever stand against a Mandalorian was Gustavo Fring, owner of multiple chicken restaurants.

I submitted a Vue.js application as part of a challenge, and it did not go well — the reviewers had issues, which they documented fairly well in an email. I got two things out of this — their feedback, and some code that I can actually talk about in my blog. Up to this point, my focus here has mostly been on major open source projects that already existed. Now I can talk about my own open source project that was written solely by me, something that consists of JavaScript code, Vue.js, Vuetify, and common topics like APIs and async/await…though maybe it would be pretentious to open source license it. I cannot imagine why anyone would contribute to this, unless it was to attempt to complete the challenge themselves. If that were the case, why would they pick this one? The joke would be on them.

Here was their feedback:

This was using SWAPI, a Star Wars API (I am not 100% clear on why it exists, but here we are), and I called mine ThisIsTheWay. I put it on GitHub. One thing to add to their criticism above: It does not work on Boba Fett. Any application that lets you search for Star Wars characters but does not work on Boba Fett is garbage.

Diving In

The challenge is over, so I did make one of the fixes they suggested.


I was not using SWAPI correctly. This is the kind of thing I may have identified, had I used Jest to integrate some test cases.

For the time being, let’s ignore lines 182 through 190, and just talk about async/await and fetch. Let’s see how much time I can dedicate to literally two lines of code.

There are a number of concepts that this relates to, and I will try to cite sources closely because I find them confusing myself. This code attempts to use this thing called the Star Wars API to search for a character name and get related fields if it exists. That is really all there is to it. I think it will be simplest to start there, and unwind after having established that example.


We had an intern who did not really know web concepts but knew computer science fundamentals, which is about where I would expect a college student to be after his/her second year. I pointed him to this, an article I read when I was first looking up APIs, but added that I thought this analogy was a lot more confusing than the thing it was attempting to describe. Jarvis Johnson said that when thinking of an API, you can think of the commands you can give to a dog — you can tell a dog to sit, and you can tell a dog to fetch, but you cannot tell a dog to file your taxes. The commands are defined, and I refuse to acknowledge the irony of how I just used an analogy.

By the way, I am still a little disappointed no one cared when I blogged about using the Dog API to filter for corgis only. You know what I used? That’s right. Fetch.

I thought it was way simpler to just show the intern some actual code. We have this thing called an endpoint, and if you literally type https://swapi.dev/api/people/1/ into your browser you can check it out.

Source: https://swapi.dev/documentation#people

It’s just data. We can get the data. Then we can serve up that data however we want, graphically, via a UI. Is this really it? No, that is a huge simplification, and one very specific example. Can data get more complex than this? Oh yeah. Maybe a backend, instead of giving us this simple bit of Luke Skywalker data one time because we asked for it, wants to give us geolocation data every second and we have to listen for events. Maybe there is a lot of nested data, and we need to create a parent vue component and a child vue component to encapsulate it. Maybe the data has to be put on a map, as in a world map. Here, it is pretty simple: If the user types “Luke Skywalker” and hits a button, then we ask the API to get us some data about Luke Skywalker.

More JavaScript Concepts…

This article talks about REST APIs, then segues into XMLHttpRequest, then explains that the Fetch API is simply an updated version of XMLHttpRequest. The whole article is well-written and very succinct, as content from FreeCodeCamp often is. If you want to learn to code, use good paywall-free resources like FreeCodeCamp and HackerNoon. Do not use some garbage mainstream blogging platform where the worst content is paywall-blocked, clickbait runs rampant, and controversy is prioritized over quality.

Just kidding. This is a wonderful blog platform.

A fetch is promise-based, meaning you can use async/await with it.

We make a promise, meaning the promise is either met or failed. Async/Await is just syntactical sugar to make promises easier to work with.

How it Looked

One of their main complaints with ThisIsTheWay was how it looked, and…

…I don’t know if I can complain about that in turn. It was very “vanilla” looking. Someone even asked me if this was plain JavaScript, and no…this was Vuetify, meaning it should have brought Material Design to the table almost inherently. I thought they might have given me some brownie points for deploying it on GitHub pages, thanks to this guy, but I don’t really know if they cared. They also wanted more utilization of HTML/CSS.

Everyone loves to make fun of HTML because it is not technically a programming language, but I personally have the controversial opinion that it can be complex to work with. Maybe you want to use a vuetify tooltip in unison with a dialog, and maybe things are not responding correctly to where you click, and you are not sure why. You have a lot of nesting going on in your html, and it turns out your bindings are wrong…this can get pretty complex pretty quickly.

We Can Work With This

In the end I had an app that…kind of worked. I mean, you could search. You would get results.

Did it have test cases? No, and that really would have helped. “Boba Fett” would have been one of the first test cases, obviously. That probably would have been Jest. Oh, except that test cases usually mock API calls…test cases actually could be really interesting.

Obviously it needs to look better.

There is a ton of convoluted content that can be included for the sole purpose of giving the blog something to write about. I kind of want to explore Vue parent/child relationships. Maybe we represent ALL characters as little boxes, and each box is treated as its own component? And they have tooltips and bring up dialogs, too! Sounds completely pointless. I love it. This is going to be so much fun.

By the way, this is all Vue2. Vue2 came out in 2016, meaning any frontend developer reading this will think I am a dinosaur and everything I think and feel is, from now until the moment I switch to Vue3, irrelevant.

And by then I am sure they will be on Vue4.

Closing Thoughts

Between this and maybe a random series about Splunk, I think this blog will have quite a bit of content going forward.

Here is a video you may enjoy:




A software engineer who writes about software engineering. Shocking, I know.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

React State and Dom Events

RxJS: Rate Limiting and the Quest for the Perfect Throttle

Make custom configurations Translatable in Drupal

How to Build a REST API With Express JS and Typescript

Setting Up Auth0 OTP Authentication with an 8base Workspace

Data visualization with Recharts

Jump-starting Slack bot projects: bot-zero

35+ JavaScript Shorthand Coding Methodologies

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Evan SooHoo

Evan SooHoo

A software engineer who writes about software engineering. Shocking, I know.

More from Medium

Refactoring React Apps for Active Record Query Methods

Day 3 of Game Dev: The basics of branching using Git!

Why You Should Learn JavaScript Even in 2022

JavaScript Framework vs Library