How Technology Can Help Asylum Lawyers
Published: 2021-04-28 15:54:48

Since its founding in 1978, Human Rights First (HRF) has worked in the U.S. and abroad on various issues related to human rights, from protection of minorities, victims of crimes against humanity and other forms of discrimination and persecution. One of the issues they help address is aiding refugees seeking asylum on as victims of discrimination, persecution and violence. As a part of my experience in Lambda Labs, I had the privilege of working on a project designed to aid lawyers working on asylum cases by providing them with data and analytics in order to find relevant patterns and informations for preparing their cases. My participation in the project ran for most of the month of April. The majority of the work I did was on server-side functionality.

![Screen Shot 2021-04-26 at 1.46.07 PM](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/60hilzimjmrxrb7dgvm5.png)
 
**Getting into the Technicals**

The team I worked with consisted of full-stack web developers and data science developers. We worked together to translate user stories like "as a user, I can upload case data in PDF or CSV format" and "as a user, I will be able to view the uploaded PDF file" into actionable tasks to create the described feature. One task I worked on was to work on the server functionality in order to allow the user to download or view PDF documents that had previously been uploaded for a specific case. This is important to the user as it will allow them to reference original documents related to a case for additional context. To go about solving this problem, I began by tracing through the existing code, finding gaps in the existing functionality and then building out what was needed.

As I read through the code base, I was able to find some existing functionality for accessing the AWS (Amazon Web Services) backend that could be re-used for building out the download and viewing functions. I mostly worked through this myself, but worked with one of my teammates, Matthew Justice, to double check to see if some database functionality was missing or not. As I traced through the code I was able to identify what I could use and what would be needed to complete the functionality. I broke this up into tasks based on each piece of functionality: updates to router, updates to model, updates to database table and updates to the AWS middleware. The timeline I gave for this was three days. I determined this by giving myself two days to get the code written and one extra day for testing and any unforeseen issues I would encounter.

The specific tasks I had for implementing PDF download and viewing were to update the database table for each case, so that there would be a unique filename key for every case uploaded, update the model for cases to reflect the changes in the database and finally update the AWS middleware to the changes in the database and the router. For this, I used Node and Express for the backend framework, AWS S3 for storage and retrieval of PDFs and PostgreSQL for the database. One of the challenges I initially faced was in the existing documentation, it was described that a filename was being assigned to each case during the upload process:

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oi65i3kakdaospxghfsr.png)
 
But, when reviewing the code, I was unable to find any point where this happens. When looking over the database table, I couldn't find a field for a PDF filename. To make sure this functionality was truly missing, I worked with my teammate, Matthew Justice, to make sure this functionality was truly missing. He confirmed that the functionality was missing and during his review gave me some suggestions of how to use UUID (universally unique identifier) to create the unique key that was needed, which I was able to use when modifying the PDF upload code. One of the technical decisions that I made during the process of implementing this feature was to reuse code from the PDF upload endpoint and the AWS middleware with some modifications in order to keep consistency and speed up the process of implementation. The big risk of doing this was that if I could not rework the existing code to work as expected, it would have been a time waste and require rewriting the functionality myself. But I felt the risk would be worth it, because it would make understanding and updating the code easier in the future for whomever needed to make changes.

![image](https://media.giphy.com/media/p55W1ZXrvxZQXymr2b/giphy.gif)
 
Ultimately I was successful in implementing the update. Now, when uploading a PDF, a UUID is assigned to the filename field of the case table and to the filename when stored in AWS S3. There is an endpoint for both viewing and downloading PDFs. I even managed to identify an edge case bug in the front end, where if a file is downloaded once successfully, a second attempted and aborted upload would send an empty file to the server. In the end I was able to implement everything I planned regarding this feature. One future challenge I foresee is implementing a bulk download feature that is currently on the product roadmap. Currently, downloading PDFs is done in a way that allows only one file to be retrieved at a time. To do a bulk download of PDFs would require either a front-end implementation where downloads are either queued up, which could be tricky to implement or run concurrently which would be a bandwidth strain. The feature could also be done on the backend, but would require bundling the files in a ZIP archive file, which would take some research on how to implement, and would result in a file that not all users may be able to extract.

My biggest Labs experience takeaway has been that I've been able to grow more confident in tackling a large, vaguely defined problems and break them down into atomized tasks that can be worked upon. I now understand how important it is to make planning a priority. Once we understand the product and features to build, it's a progressive process of breaking concepts down into more defined tasks that can be assigned to individuals and then specific tasks for the individual to implement. I also learned how important it is to choreograph steps in planning, because certain tasks require completion of the tasks of others. Which emphasized to me how important communication within a team is. Feedback has been very important in helping me realize what my weaknesses are. Having multiple eyes reviewing code submissions sometimes results in finding improvements that I didn't see. I feel my technical skills have grown because when going into this project, I felt more inclined to front-end development as thats what I was more comfortable working in. But I was assigned many tasks that were related to back-end work that I wasn't as confident working with. My soft skills have also grown as a result of this experience, as I am now more familiar and comfortable with working on a large project with multiple team members and feel confident navigating and communicating in order to achieve our goals.