Over the past few months I have been attending Lambda School as a web development student and I'm rapidly nearing my graduation. This last month of being a lambda student involves taking part in a team environment and working on a project for a real company or client.
I am on a team with six other web and data science developers all working with the company Human Rights First. The goal for this month long project is to build a web tool that aggregates data on asylum cases, allow users to explore that data, and predict and visualize how a judge might rule on a specific asylum case—as well as what specific elements of an asylum case seem to most impact a favorable or unfavorable ruling.
The web tech stack for this project mainly consists of React and Ant Design for the front-end, Node/Express for the back-end, and using Okta for handling the authentication.
Some initial concerns for this project was mainly around working with pdf's since that was new for everyone on the team.
Technical Challenges Popped Up Along The Way
This may be a small feature but one of the first technical challenges I ran into was on how to hide the header only on the login screen but nowhere else throughout the application.
An easy but ineffective solution would be to just copy and paste the header over each component, or page, but that doesn't follow the DRY principle of coding.
I did not have an immediate solution but eventually came up with a line of code that precedes the routes of the application as shown below.
The logic behind it is that whenever the route is not on '/login' then the header will be displayed; if the route is on '/login' then the header will not show up and be null. This solution allowed me to only use one line of code instead of having to put some form of the header instance in other files and components.
Features Of The Application
Currently, as shown below this table is the core of the application and where most of the logic is focused on.
The table displays some basic data retrieved from case files to be easily viewable and filterable. The data right now is just filler data since the data science team is still finalizing their side of the application and just recently released a partly functioning endpoint for the web side to use. We are on our last week so I am hoping that we can connect the endpoint successfully and fill in the table with real case data.
Additionally, we have an upload button in the header which allows the user to upload case file pdf's which will then be sent to the data science team to scrape data from which has been a successful process.
What Next?
In its current form, the application is still a skeleton and a minimal viable product that still needs a lot of work to be put into it. However, that was to be expected since me and my other teammates were just the first wave and team to take on this product. The plan is to have a few more teams iterate onto our greenfield product and I truly believe we set up a good foundation for them.
Future features would probably include more columns in the main table, functionality set up for viewing the original pdf's, give the ability to change the user's name or password, and possibly a scannable and highlightable text conversion displayed of the uploaded case file pdf.
Some future technical challenges I can see is mainly around the pdf's. On the data science side they had memory issues with pdf's over 5 pages, so that needs to be addressed. If there isn't a solution by the data science side then it has also been proposed to see if the web side can split up the pdf's into smaller chunks and post them separately, but that is a bit inefficient.
Personally, I improved during this whole process and appreciate being able to even work on this project. I even received some new helpful feedback from my peers; for example, my peer showed me a new way to separate my Styled-Component styles into a separate file to clean up the component. This month has been a great experience to push me further towards my goals of starting a career as a web developer.
Top comments (0)