Building Opsview's cross platform mobile app

11/02/2017 • 3 minute read • Go home

Where we started

I've spent a while now hacking around with React and when a mobile app project came up at work I was quick to add React's native friend into the list of potential solutions. After reviewing a number of solutions including Ionic, ExtJS 6 (our current front-end solution) and real native, and a few prototypes later, it became clear React Native ticked all the boxes we were looking for:

An omission some readers may have noticed from our list of potential solutions is a progressive web app. This was something I would have loved to have looked into, however we were constrained by the lack of mobile support for many of the technologies that make PWAs great: ServiceWorkers (for offline and background sync), HTTP/2, web notifications and as we're purely focused on mobile and not desktop (we already have a client) it didn't seem like an option that was feasible. Additionally a hosted PWA solution would require a lot of infrastructure implementations that we don't currently have. It is something I would like to prototype and add to Opsview in the future.

And we're back

After selecting React Native I spent a good week developing and iterating the current prototype; investigating deployment practices and more advanced features. When the groundwork started, I found that the initial prototype was so strong that I could iterate that project into what became the master branch.

During the initial stages of development I learnt a lot about mobile UX and its stark differences and requirements vs. desktop. From ensuring every user interaction has meaningful visual feedback, to refining the user journeys continuously as we alpha tested and found patterns and journeys users had that were not quite what we expected. This real user testing (along with real device testing) shaped the very nature and experience of the app.

On the technical side, it was great to be able to apply my React knowledge to a new and large project. I took some time to learn more about React app structure and made the mistake that I thought I wasn't going to make: implementing Redux. This was a particularly annoying mistake as I had read why I might not need Redux but stubbornly went ahead and used it. It did offer some very clean looking code, and gave us the option to use time travel debugging (something I never ended up using!), but in the end I found Redux blocking me effectively reusing large components that I'd built, as they ended up using the shared component state. It blocked me so much and my workarounds failed, so I decided to just rip out Redux. This actually really helped; new features didn't require touching 3 files and it forced me to localise and refine my component state trees.

Finally a great thing about React is that its component based nature creates a fantastic community of component developers, of which I am now a part, and this huge array of components allowed me to quickly develop features without re-inventing the wheel for some of the basics such as collapsible components or navigation.

What's next

I'm now squirreling away at a lot of really cool features that I hope users are going to love. However I'm not out of the water yet; I still have some big challenges ahead such as preparing the app for production, shipping betas, adding continuous integration and then actually shipping to production.

Rob is a web engineer working in London, who focusses on performance, simple code and accessible design.