Just under a year ago, I made the eventful decision to enroll in the Lambda School of Web Development and Computer science, an online-only Web Dev Boot Camp. I chose Lambda largely because they ticked off all the boxes I needed to be filled: ISA, Part-Time, and Online. I also, after checking on the reviews, came to the conclusion that Lambda was much loved by the vast majority of students.
There are 6 units atLambda: The first 4 are HTML/CSS, JS, and two full units of React. The next unit is a computer science unit exploring Python and algorithmic problem-solving. Finally, we come to the labs unit: An intensive 2-month build project with other students, where we are presented with an app to be built and must collaborate on cross-functional teams (In addition to my web team, there was also a Data Science team, and an iOs team, who built the mobile version of the app).
There was a choice of two different apps to build. The team I was assigned to was working on CitySpire, a Zumper/Teleport style app designed to allow users to search and compare various US cities, on scores such as overall livability, walkability, crime rates, etc. I was on the web team and handled most of the back-end, an Express app that handled authentication and retrieving compiled data from the FastApi app built by the Data Science team. It was the first app I’ve worked on with a team where I was largely responsible for the back-end, so I was a bit nervous, but I tried to turn the pressure into motivation to succeed. We also had to work with an already largely designed scaffolding of an Express app; One of the biggest challenges I faced was understanding this scaffolding, as it was set up entirely different than any Express app I had built or worked with previously.
The front end of the app was built with React, also using a pre-built scaffolding provided by Lambda, and used Okta to authenticate the user, as well as the MapBox API for location finding. Authenticating with Okta was the most difficult part, but works very well once you figure out the nuances.
Embracing the Chaos: Learning to Work with Others Code
In our first Web meetings, we were trying to divide up the work into who was going to do what. I initially offered to handle the majority of the styling, as it would give me a good excuse to learn AntD, and I am a huge proponent of learning a new library or API any chance you get. Also, unlike many people, I actually enjoy writing CSS. But somehow, I ended up going in quite a different direction and mostly worked on the backend. Which, despite using quite different parts of the brain, I also enjoy.
I find writing basic CRUD apps to be a somewhat zen-like, repetetive experience. Once you’ve written a few, they tend to largely write themselves, at least until you come upon a piece of data that really doesn’t want to cooperate. The challenge, in this case, was that I had been used to setting up Express apps from scratch, in a largely similar manner, and this one was already laid out, in a way completely different from how I would normally do it.
The first challenge I encountered was setting up Postgres for development. In the past, I would use Postgres for deployment, and SQLite for testing and development. However, on this project, that wasn’t an option. We were presented with several routes for getting this going. I initially attempted to set it up with Docker, a technology that I had never worked with before, in an attempt to learn a very valuable skill. It wasn’t going well, and also, I reached the conclusion that Docker might be overkill for a relatively small database.
In the end, I went with ElephantSQL, which was not only super easy to set up, but also allowed me to make the project much more readable by allowing me to remove over 10,000 lines of unneeded Docker code.
Ultimately, what was most challenging was coordinating with the Data Science team to get the correct data from the FastApi app that they created. Our backend was relatively straight forward: Authenticate that the user was logged in with Okta, and if so, retrieve the requested data from the FastApi app, and pass it on to the client.
CitySpire: Now and Later
Currently, CitySpire is functioning at MVP with one unfortunate exception: the fastAPI app deployment is no longer sending back data, as can be seen in the below video. It is beyond frustrating to have an app that is ready to ship on your end, but is completely broken in a way you have no control over.
Currently, a user is able to login using Okta, and they are able to search for cities, see the cities on a map, and save favorite cities for future comparison. Clicking on the city will show data for that city, once the fastAPI deployment is fixed.
In terms of building on this app, there are a few features I would like to see added. For one, the styling needs to be improved, especially the brandless Okta login page. In addition, I would love to see more data from the Data Science team. Currently, there is only full data for under a hundred US cities, and the available data for each city is slim. Nice touches like showing photos of a selected city would make the whole user experience much more enjoyable.
As far as entirely new features, I think the ability to directly compare a list of selected cities on a specific score (ie. walkability, overall livability, etc.) would improve the usability of the app. I’d also like to see the ability for users to leave their own comments/opinions on things about a city, like where to get the best tacos, where traffic cameras are located, etc.
The main thing I learned while building this app was how to get things done on a tight schedule, as a team. We have worked with other students on projects numerous times prior to Labs, but this was way more intensive, and I value this experience more than anything else I got out of Lambda. It will give me an advantage in the interviewing process over someone who knows how to write code, but maybe not how to ship apps. And in a largely over-saturated job market, one needs all the advantage they can get.