Developing Our New Software: Why We Love React, Redux, and Django

Developing Our New Software: Why We Love React, Redux, and Django

By Scott Burns, and Corey Robertson, and Lisa French

As we’ve approached the release of our newest software, Launch Pathway, we have blogged about how Launch Pathway compares to other business intelligence tools, why data visualization is so important, and why hospitals and health systems should focus on the right data over big data.



Now in this post, a few members of our development team are taking the opportunity to share some of what they experienced while building this new software. As developers, this post is partly a love letter to the Stratasan tools and also an opportunity to share our philosophy on iteratively delivering large projects. With that in mind, we hope you enjoy.


We heart.png React and Redux

Introduced by Facebook in 2013, React is a library for building composable user interfaces (UIs). Before React, developers building UIs on the web had to write very descriptive code for how the browser must generate that UI, especially as events (such as data responses from the server or button clicks) change the state of the application.

React allows developers to describe exactly what needs to appear on screen and behind the scenes, then React takes the description and makes it happen. This allows developers to more easily reason through how the application should work without having to worry about transitioning from one state to the next. React seamlessly handles the transitions and makes a developer’s life much easier.

While the UI is important, there's nothing to show if you can't reliably and consistently deliver data to drive the UI. Redux is the library we use for managing the application state and how the application responds to user activity. It is a godsend for describing how user-generated actions affect the application. By constraining the data to flow in only one direction, it is easier the build a mental model of how pieces of the application interact and makes adding features comparatively simple.

It's not hyperbole to say that we couldn't have shipped Launch Pathway, given our engineering resources, on schedule and on budget without React and Redux.


Django Rest Framework Gets Out of the Way

We’ve built our platform on the Django web framework and are big fans of how much functionality it includes out the box. Django allows us to focus on delivering great products and features. We use the third-party package Django REST Framework (DRF) to simplify writing our web Application Programming Interfaces (APIs) that deliver and ingest data to and from the front-end application.

DRF simplifies building RESTful API endpoints for specific resources in our application (including pagination and filtering for effectively free) but also has no problem delivering the less modeled data, e.g. the data that drives Launch Pathway’s table, chart and mapping visualizations. We appreciate DRF’s flexibility to build APIs in whatever manner we see fit without having to fight against the library.

While these APIs are vital to Launch Pathway, they are otherwise invisible to the user. So it's important to quickly define, design, and implement our APIs so we can focus on delivering a delightful user experience and DRF allows us to do that.

We are corporate supporters of DRF and highly recommend your company monetarily support it's development if you use the package. We very much believe that corporations should play a bigger role in financially supporting the open source packages on which their applications depend.


Ship Early and Often

Launch Pathway, in some form or another, has been available internally in our production application since mid-August. In no way did it resemble what we released on April 10th, but our overriding goal throughout the project was to quickly deliver small valuable features and assemble them into a fully-integrated product along the way. This allows us to exercise new code, quickly find issues and improve performance. Because Launch Pathway has been available to our internal users for a long time, we’ve been able to worry less about serious bugs because they wouldn’t be affecting our paying customers. Generally this is known as feature-flagging and we highly recommend it as a way to ship new features that are available to a only subset of users until the feature has been better exercised.

Shipping (getting code to production so others can use it) accomplishes a few goals.

  • First it feels good to make progress, however small it may be.
  • More importantly, we get to exercise early code against actual production data. No amount of testing can foresee all the edge cases that messy, real-life data provide.
  • Finally, and most importantly, the best design for a feature or code is not fully realized until users can actually determine if it works as desired.

By shipping early and quickly getting user feedback, over the course of the project, we can make many small course corrections and be confident that the version we release will resonate with our users.


Iterate, Learn, and Refactor

When beginning a large project, it's impossible to know how all the pieces will fit together. There are simply too many unknowns. Well-defined requirements can reduce these unknowns from a code and feature perspective but there will always be things to learn about the job-to-be-done that the product is fulfilling. Building working software is the best way we know to reveal these unknowns.

We’re not afraid to ship imperfection when we have a clear vision of how the feature will evolve and we try to not become attached to any one way of doing things. Within the final three weeks leading up to Launch 1.0, we drastically changed very significant portions of the front-end code base around rendering visualizations (the bread and butter of the application). Not because it was wrong, but we discovered better ways to fit things together that opened new functionality in ways even we weren't expecting. To reiterate, the best way to learn about the next step is to complete the current step, learn from it, and do it all over again.


The Takeaway

The development of Launch Pathway has taught our team quite a few things. In summary, we learned the following:

  1. React and Redux are up to the task of keeping us on-budget and on-schedule. We will be using these tools again for future software development projects.
  2. We are big fans Django REST Framework’s flexibility to build APIs in whatever manner we see fit without having to fight against the library.
  3. For our next software development project, we will once again follow the model of shipping early and quickly to get  user feedback over the course of the project.
  4. Keep an open mind: the best way to learn about the next step is to complete the current step, learn from it, and do it all over again.

For more information about Launch Pathway or to set up a demonstration of the tool, contact Sean Conway via Calendly today. Sean will demonstrate how Launch Pathway can reduce the time you would waste data crunching and allow you to more quickly get to the valuable actionable insights you need. 

Article by Scott Burns, VP of Engineering, Corey Robertson, Lead Front End Developer, and Lisa French, Front End Web Developer for Stratasan

Connect with Stratasan on LinkedIn or follow Stratasan on Twitter and Facebook.


software development data visualization data analysis developers Django healthcare healthcare data software launch pathway react Redux development