The technologies I was most surprised to find in our stack used together after learning what our project was, was Next JS and Flask. I knew that React was certainly going to be used here, it is a web application after all, but it was a strange choice to me to pair the two. We didn’t need to play the SEO game most of the web did; we are building a tool for a specific audience, not a social media platform. Speed isn’t exactly a requirement here either. This blog post will discuss why I think our project predecessors picked the two, and what I would have done differently.

I’ve worked with Next JS quite a lot. Every day in fact I work with Next. And I’d worked with flask a handful of times before for work and school. But together to build a web application? I certainly hadn’t thought of that. I have some hypotheses about why these two technologies were picked. For flask, I think the thinking was that opening this API up for other organizations to use was going to be a larger part of the MVP. I think the idea was to use the API created with flask as a central point for everything going on here, it was where we could interface with the data and where we could easily provide it for others. As for Next, I think npm packages were picked out that everyone wanted to build things off of. I don’t hate Next, but that’s about the only reason I could see to use it in this situation.

Working with the two has been interesting for sure. My biggest gripe is that it feels like we’re just using the VC part of the MVC pattern when the M(odel) part of it would be particularly useful. We do a lot of interesting things with related pieces of data in our program. It would be nice to use a framework that leverages the relationships between these models in a really abstract way in the code. What I mean by that is it would be nice to do something like:

Collection.create!()

Instead of this:

DatabaseConnection.execute_insert("""INSERT INTO rev2.seed_collection (a ton of columns) VALUES(%s, %s, %s, %s, %s, %s, %s, %s, %s)""", (grab_val(request, "speciescode"), grab_val(request, "collected_date"), grab_val(request, "collection_provenance"), grab_val(request, "id_method"), grab_val(request, "id_person"), grab_val(request, "id_confidence"), grab_val(request, "cleaning_effectiveness"), grab_val(request, "cleaned_weight"), grab_val(request, "collection_history_ref")))

While these two examples are in different languages (the first it ruby using rails), the point still stands. I would have picked a framework like Django or Rails that we could define models and use the models relationships in the controller instead of writing into the database using raw SQL queries.

I can kind of see why they chose to do things this way… but not really. If I could go back in time and talk to last years students, I would have suggested using Django if they were dead set on building this in python.