The FieldKit Portal

A project log for FieldKit

Environmental sensing for everyone.

Jacob LewallenJacob Lewallen 09/25/2019 at 15:290 Comments

Most of the development effort for FieldKit has been focused on the hardware, its firmware, and the app. There's another component in the platform that hasn't gotten much attention, because in the grand scheme of human undertakings it's Just Another Website. It's what we internally call the Portal.

The portal is where users register and manage their accounts. It's got tools for administrative tasks and listing, monitoring and cataloging their FieldKit stations. It's reactive, but primarily meant to be consumed on a desktop because of the data visualization tools the portal provides for exploring the data streaming in from actively running FieldKit stations.

Approaching the development of the portal was done like most of the other efforts. Even though it's the lowest priority, it's grown as we've needed functionality to support the most important user stories being developed in the mobile app and the firmware. Things like authentication, accepting data from the app and WiFi enabled stations, querying of that data and basic visualization support to allow the team to monitor the data coming from the early hardware. Regardless, we started wire-framing the portal early on, as you can see in these images. Once the User Experience is dialed in and mostly settled, our talented designer(s) start to add color and apply our style guide.

From a technical perspective, the portal looks like any other modern site you're likely to see:

One technical note that some readers may find interesting is that architecturally there's actually two separate backend services. The first is monolithic and embodies what most people imagine as the backend. It implements the API, acting as the arbiter of state and business logic. The other, which we call the ingester, is extremely small and rarely modified. It's job is to accept data from stations and apps in the field and store them on S3. 

One of the main reasons the portal is a lower priority is that it's the component with the fastest turnaround on development. Hardware has the longest cycle, followed by firmware and then the mobile app. Even though the mobile app is a hybrid and built on similar technology to modern websites, there's still the process of running on phones and testing on multiple devices and platforms. Today's web, thankfully, is a much more cohesive platform.