A smoother user experience with new technology
The Aava Medical Centre is one of our customers with very high expectations concerning user experience. In order for us to meet these expectations in a cost effective way, it's important for us to utilize the most modern tools when building their services. Luckily for us, for the whole duration of our cooperation, Aava has committed itself to adopting new technology. This way Aava has also avoided excessive expenses during updates.
At the end of 2016 we set a goal with Aava. We decided to combine the front end solutions for Aava's different services, all of which have been created using different back end systems. At present, all of the systems have their own user interfaces, which has led to maintenance being cumbersome and non-scalable after the systems have expanded. Despite the fact that we have utilized modern tools building the current systems, the work always has to start from scratch for each system. The development of the user experience is also hindered, since the systems look very different from each other.
We began with building Aava's "Terveytesi" (Your health) service. The goal of the project was to quickly create a new service from which customers would be able to easily find information on their health, for example diagnoses and appointment reservations.
Why did we end up using React?
Building the service required changes on the architecture already in place. For the development to be cost effective in the long run, we decided that all of the functionality available before the architecture overhaul would also have to be available after the overhaul. Because of this, we ended up focusing most of our effort on forming functional interfaces. For this project it was only natural to create a browser application, since the service would not require a lot of business logic outside of the interfaces.
Ember.js and React.js were both picked for consideration, since the team members had had positive experiences with them previously. Initially we tried to estimate which of the two systems would be easier to adopt into the current architecture, but we had to accept the fact that the comparison would be difficult, since neither seemed to fulfill the requirements we set at the start of the project. We therefore ended up comparing their community support and they way each of the systems had been implemented. In the end, we chose React, since we believed it would have more support in the long run.
How did the project run?
Because we wanted to expedite the start of the project, we took a lot of our cues from boilerplate solutions. This proved to be a mistake at a later stage, when we had to sort through bugs found in the copied parts. The sorting was a challenge since we weren't completely up to speed with all the choices and weaknesses in the code.
In the end, the project took about two months, approximately half of which was used to developing the previous infrastructure. We have now released the application for internal testing and it is soon going to be released for public.
Since PHP 5.6, which is still in wide use, is starting to fall short of Aava's high standards, we decided at this point to update the service to PHP version 7.1, so that we could benefit from the increase in speed and amount of features. Many PHP libraries have already ceased to support PHP 5 versions, which complicates developing new things on top of PHP 5 versions. Aava was our first client to adopt PHP 7.1 into an existing project. This raised a lot of interest also outside of Druid, which is why we have decided to write a separate blog post about it at a later date.
For the moment we are using Drupal 7 as a back end system for the application. The API we've designed works so that the front end application will be easy to move onto any platform. This way Aava's technical choices will not be restricted by the technical choices we've made. We came to this decision because there was a substantial amount of functions already built for Drupal, which would speed up the development of the software.
We used the Swagger tool for the API documentation. Swagger documentation has been compiled from JSON data. The same file was also used to generate the interfaces.
As a whole, the project proved to be very interesting. Particularly the constant utilization of new technology keeps the mind sharp and the team motivated. It also ensures good mileage for our customers' systems, and as low a cost as possible during the development phase.
The project team included Bart, Lauri E, Lauri A, Juho and Pete. Thanks to Lauri E for helping with this blog post!