Dan Parks

Single-Page Web App Development, Part 1: Setting the Stage

 

fast-single

A client recently came to us with a request to build an application unlike anything we had built in the past. Arriving at the best solution for them would challenge our thinking and our usual approach to software design and construction, but we (and the client) are quite happy with how it all worked out.

We have built many full-stack web applications in the past, consisting of a front-end of some sort, application code running on a server, and data persisted in a database. However, it turned out that a modern, JavaScript-based single-page application would best suit this client’s needs. Developing an application in JavaScript can be messy. There are many frameworks and build tools to choose from. There are many different ways to architect the application. You could spend hours on configuration alone.

We didn’t want to spend hours on configuration for this client. Instead, we wanted to be delivering usable, valuable and functioning software to them as soon as possible. After discussing their needs and gathering the requisite documentation of the “business rules” of their yet-to-be-created software, we went through an internal discussion of what form a solution to their problem would take and what tools and technologies we’d need to use to solve it.

Project Context

For this project, a single-page app made perfect sense. The client’s users would enter minimal but essential information. The software should then evaluate the data and output a response to the user in line with the business rules being executed and followed. The application needed to have visual appeal and a smooth workflow embodied in the user interface -- no time for back-and-forth server trips and web page transitions. Furthermore, the data was transitory in nature, and didn’t need to be persisted from session to session, so an architecture with a back end would have been inappropriate.

On the development side of things, we needed to work with tooling that would let us:

  • Implement and execute the client’s business rules
  • Design, lay out, and construct a smoothly-functioning UI of moderate complexity
  • Use stylesheets and graphical design elements in a consistent fashion from screen to screen
  • Bundle all these elements up into a package suitable for deploying on the open Internet

With those constraints, we were able to gather and configure a small set of development tools and languages, including JavaScript, that let us quickly produce working software and deploy it (to a staging server) where the client could use and interact with the system as it was being developed.

What tools did we select, and why? How did we configure and use them? How did we avoid the “messy” parts of modern JavaScript development? In this blog post, and continuing on for one or two more, we’ll answer those questions. We’ll start with a general overview, and in the later posts we’ll go into the details of the solution. If you want to see a demo of and code for an application with this style of architecture, we have provided a working demo and sample code at the end of this article.

Selected Tools And Rationale For Their Selection

First, it made most sense to implement the core of the application in JavaScript. Reasons were practical -- it needed to execute in a web browser -- but we also had “softer” constraints. Other developers and designers would probably be working with the codebase in the future, and though there are many appealing alternatives to plain old JavaScript, it is a well-understood and popular language.

react-redux

Second, given the complex and dynamic nature of the UI that the system required, using a flexible but powerful web framework would work to our benefit. We chose React for this, and were able to make good use of its declarative nature and the straightforward mapping of visual elements on the screen to React “components”. Closely related to this decision was the choice of Redux to help manage application state. Though the system wouldn’t deal with volumes of data, the process of entering and evaluating the data would happen in several steps as the user worked his or her way through the application, and a library like Redux helps to ensure that there is only one “single source of truth” for the application’s data.

Thirdly, we like managing our styles with SASS. We like how easy (nearly foolproof) it makes maintaining consistent styles – think color palette, spacing/grid/gutters, fonts, etc. We’ve also found that if your modularize at least some of your stylesheets similarly to how you factor out visual elements and components on the screen, it is really easy to keep track of what files need to be updated if you want to change some aspect of the design.

Finally, we’d need a way to package all these elements: raw JavaScript code, JSX (the syntax extension to JavaScript commonly used when coding with React), SASS, and image assets. The core of our solution for this was to use to use webpack. During the project, we used some additional tooling outside of webpack to help process the assets, but while working on the demo application, we discovered that webpack can do it all: it can (among other things) load, process, and bundle your code, styles, and image assets.

 

what-is-webpack

Conclusion of Part I

With that context, we can now start to explain the implementation. In the not-too-distant past, setting up a JavaScript-based development project involved lots of configuration and pulling in various tools to help manage and build things. It’s gotten much more straightforward to go about this task. Certainly, yes, there were some finicky bits related to setting up and building the project, but be sure to check back and read forthcoming articles in this series to see how we implemented solutions or could take advantage of streamlined configuration provided by new versions of the tools we chose.

Finally, check out the demo site: http://weather-rock.aws.leandog.com/

... and you can find the sample code here: https://github.com/leandog/weather-rock-spa

Share Post