Working With the Backend and Pair Programming

Building endpoints and debugging in node.js

The Product

This last month, my team and I have had the pleasure of working with Family Promise to develop a service tracking program in order to help prevent homelessness and to get people off of the streets by providing services such as rent assistance, childcare, or just providing them with means of transportation. Family Promise has locations all across the country, and will need a program to help them grow. By tracking the services they provide, they will be able to better plan for future services. This will allow them to understand what demographics need certain services more than others. That is where our team comes in. We first got our hands on this project on May 3rd. This was the largest code base I had worked with up to that point. This would not have been possible without my amazing team. They made a truly overwhelming project very possible and enjoyable. I, along with a few others, worked on the backend repository which came out far better than I could have imagined. I have to give special credit to Trenton Grede for this. He has a special talent for working with the backend. He saw what this project was, and what it should be in the future, and designed our tables flawlessly. I also had the pleasure of working alongside a good friend of mine, Remy Vila. He and I have been working together on side projects outside of Lambda for 7 months now, and it was a great time getting to work with him on a more professional level.

Fixing Our Endpoints

A lot of work went into making Trentons vision for the back end come to life. One of the problems with a complete database overhaul is trying to figure out what other code will need to be changed in order to fit in with the new or updated tables. At first I had some doubts about doing this, but I realised that this was necessary for scaling, since the way it was set up previously was ok for a small number of recipients. Trenton saw that we needed to plan for a large scale database, and added more tables that would allow tracking different aspects of the recipients situations. For example, ethnicity was given its own table, and hence was given an ID to go with it, so now the program is able to track different programs based on the most common ethnicity to receive it. We spent the first few days diving into the code trying to figure out what needed changing and what we could keep. Once we felt we had figured out where everything was, we performed our surgery on the code.

Remy and I went through and started creating endpoints for one of the new tables in order to get that table working with the front end. This was luckily a pretty straightforward task, and seemed a lot more overwhelming before we dove in. The table we were working on holds all of the recipients information, which is vital not only to letting them create an account, but also to tracking the services that are being provided to different demographics which helps family promises plan for where they will most likely need certain services available. This will also be vital in future features such as the map.(more on that in Future of Family Promises)

Debugging

Throughout our time at Lambda, we were given many projects that were designed to have bugs and we would have to go in and fix them. A very straightforward problem, and a very straightforward solution. However, during our time working with Family Promise, this was not the case. A bug in the code looks very different when it was not put there intentionally. Some of the bugs may have actually been working code when the team before us had been working with it. This made things a lot more challenging, and gave me yet another reason I was happy to have a great team. For a lot of the problems, we wouldn’t know about them if not for the front end team. While they would be working with getting the CRUD(Creat, Read, Update, Delete) functions set up, or just while clicking through the program launched on their local host, they would encounter some problem and bring it up to the team. One tool that I found particularly useful was Whimsical, an application that allows you to visualize the flow of information throughout your code. This helped me out when Remy and I were working on some of the restricted Middleware functions by helping lay out which user should end up on which page. Towards the end of the project, we ran into another problem with getting the table on the front end to be able to perform the CRUD operations. When that was presented to the team, Remy and I hopped into a breakout room in Zoom and started looking for the problem. We started testing the endpoints on Postman and eventually we found where our bug was. We traced it back to the middleware, specifically one function called canCrudServiceType.

We eventually got it working on Postman, but when we pushed the code, it still wasn’t working on the front end. We ended up not having enough time to fix it entirely, so we documented in hope that the next team will have time to figure it out.

Future of Family Promise

The future of Family Promise looks bright from where I am sitting. Lambda does a good job preparing its students for exactly this type of thing. One challenge I can see future teams having is working on the map display. Family Promise wants a feature that is an interactive map that shows where different services are provided. For accounts with the right authorization, you can also see the recipients on the map and their information. I think this will be a challenge because it will likely require working with a library we haven’t had the time to learn in Lambda. It seems like it would probably be a bigger challenge for the front end team since the information is already there for the backend. It’s just a matter of getting it all displayed and making it interactive.

What I Learned

I feel very lucky to have gotten to work with Family Promises and the development team. Everyone was great to work with and fun to just talk to in general. This was a great experience working in a large team with a large code base already there. This last month has helped me understand how I should be managing my time in this industry. Before this month, I spent all day and night coding. 10 hours was a slow day. I was burning myself out way too quickly. I have found that if I give myself both a break in the middle of the day, and actually take the weekend to recover, my head is a lot more clear when I jump back into the code and I can spend far less time in front of a screen and yield the same r