Building a Data Visualization App with Flask and React (part 2)
This is part 2 in a multi-part series describing the process of designing, building, and deploying a complex web application. This series follows the development of Narratus, a data exploration and visualization app.
You can also check out:
1. Part 1: Gathering Requirements
2. Part 2: Picking a Tech Stack
3. Part 3: Building a Data Model - (coming soon)
5. Part 5: Building the API Endpoints - (coming soon)
6. Part 6: Using Automated Testing - (coming soon)
7. Part 7: Saving Passwords with AWS's Key Management System - (coming soon)
8. Part 8: Executing User-Provided SQL Against a 3rd Party Database - (coming soon)
9. Part 9: Deploying Backend to Ubuntu server - (coming soon)
1. Part 10: Building the Views - (coming soon)
2. Part 11: Incorporating Redux - (coming soon)
3. Part 12: Pulling Data from API - (coming soon)
4. Part 13: Testing - (coming soon)
In the same way a new acquaintance at a party might ask "what do you do?", software developers will often ask each other: "what's your stack?" What we're looking for is a list of the languages and technologies they use to build and support their products. For example, a developer might describe their stack as a Ruby on Rails Monolith using Postgresql. They might also mention their operating system, a frontend framework, or any other major piece of technology they are using. The most popular tech stacks sometimes even get a cute acronym: MEAN, LAMP,
Choosing a Programming Language
So here we are, armed with our requirements doc (see Part 1) and ready to start coding. Except we don’t know what language we’ll be coding in (astute readers may have a guess based on the title of this series).
While making this decision, we should first consider the platform on which the app will be used. If we were targeting native Android we’d probably choose Java (though there are other options). Likewise, iOS is often developed in Swift. Native Mac and Windows apps can be efficiently made in a variety of languages, though Java is the most popular. We're going to be targeting the web browser, so we'll take a look at some good options for backend languages on that platform.
Ruby was invented in the mid-90s, but really took off as a language with the creation of Ruby on Rails, a web framework that allows Ruby developers to efficiently create websites. Ruby is known as a fun language to code in with a supportive developer ecosystem. Some popular websites built with RoR include: Basecamp, Hulu, Zendesk.
Pronounced "see-sharp", this language was designed by Microsoft in the early 2000s. While it is a robust general purpose language, it is most commonly used with Microsoft’s .NET framework for web development. If you like the Microsoft ecosystem this is a good option for you. Websites built with C# include: StackOverflow, Microsoft, GoDaddy.
It should be noted that many simple websites will not need a backend, either because they do not need to persist data, or they take advantage of 3rd party APIs for their advanced features.
One of the most important considerations when picking a backend is: what languages do you and your team know. While certain languages may provide some benefits for certain use-cases, often the benefit of having a development team that is comfortable and productive with the chosen language is more impactful than inherent differences in the languages.
With the above advice in mind, I've chosen Python for use with the Narratus application.
Choosing a Backend Framework
Frequently with backend languages there will be libraries that are commonly used to abstract out some of the common problems of building a web app. These libraries are often call "frameworks". Some languages have a single dominant web framework, such as C#'s .NET framework and Ruby's Rails framework. Other languages, like Python, have multiple popular web frameworks.
When deciding on a framework, the experience of your developers is important, but not as important as when choosing a language. It is a much smaller task to learn a new framework than to learn a new language.
Another criteria to consider is whether you want a lightweight framework or a full-featured (i.e. "batteries included") framework. Full-featured is nice because features like authentication and content management systems (CMS) may already be included and need only be configured. However, a full-featured framework may include features that you don't end up using and are dead weight on your application.
For Python, the most popular frameworks are Django and Flask. Django is full-featured and the most popular, while Flask is lightweight and has its own loyal following.
For Narratus I chose Flask, as it makes it easy to build a backend API service and I wouldn't be using a lot of the features that make Django popular.
Monolith vs Micro-Services Architecture
A "monolith" application describes the traditional conception of an application: a single repository of code that operates to accomplish the application's objective. "Micro-services" is an architecture where the application is broken up into multiple smaller applications that operate completely independently of each other, functioning together by interfacing each other's APIs.
There has been much debate about which paradigm is better, with no clear winner. Micro-services tend to require a bit more effort to build, so are not ideal for small projects. However, each service can be worked on independently, so larger teams of developers can work on an application without stepping on each other's toes. Another nice benefit of developing a micro-service API is that the same backend can support multiple frontends for different platforms (e.g. web browser, Android, and iPhone).
For Narratus I chose to treat the backend as a micro-service, as it is a good architecture for supporting Single-Page Applications.
Choosing a Database
A database is used to persist data, and often runs on a separate machine than the backend and frontend code. There are lots of good options for databases, the three major categories being Relational Databases, No-SQL Databases, and In-Memory Databases.
Without diving into the technical details, relational databases store their data in tables (think Excel spreadsheets), and no-SQL databases do not. Popular relational databases include Postgresql, MySQL, SQL Server, and SQLite. Popular No-SQL databases include MongoDB and Redis. In-memory databases, like Redis and SQLite, are databases that load the entire database into memory, rather that saving information to disk.
While they have interesting differences, popular relational and no-SQL databases will do their job fine and you should not agonize over which to choose. Generally, in-memory databases are used to prototyping, caching, or other special purposes, but are much less often relied upon to persist general application data.
For Narratus I chose Postgresql because I am familiar with it.
Also note that some of the popular databases are not open source and require you to pay a licensing fee (e.g. SQL Server and Oracle).
While we detailed the application's requirements in the last article, I had some of my own for this project. First, I wanted to get familiar with building a Single-Page Application in React. Next, I wanted more practice with Python unit testing. Finally I wanted to familiarize myself with Django. Unfortunately I felt Django wouldn't be the best fit with React and was worried about taking on too much, so Django got bumped in favor of Flask, a framework I am more familiar with.
There you have it. Narratus is a React Single Page App, with a Flask API backend, and a Postgresql database. Now that we have that all figured out we are ready to dive into actually building the application.