And now for something completely different

Druid is known for being a Drupal-house. And we are. Most of the projects for us are still in the category of Drupal where a CMS is needed. But Drupal is not always the right tool for the job. Like Dries Buytaert stated in DrupalCon Vienna, “Drupal is no longer for simple sites”, and generally not for all use cases. That said, Drupal is still a very good choice for the right jobs. 

We have recently had some non-Drupal projects, and now I’m going to tell about one of those. Non-Drupal meaning, however, that the tech stack wasn’t completely new to us, as we are already very familiar with the programming languages themselves (PHP and JavaScript).

The need – say no more, say no more

Our customer had a need which was not totally structured at the moment as they targeted a market which is under a major disruption. The digital landscape for this particular market is evolving, and as is often the case with evolution, you need to adapt or perish. What we already knew from the start was that the application needed to be mobile-friendly and its main function should be to facilitate communication between users. Create a backlog from that!

Mobile? So we thought PWA is the way to go. At Druid we have been fans of PWA for a while, and we have written about this exciting concept before. Progressive Web Applications are the future and show much promise. PWA is also a very good choice when you want to distribute your apps without App Store or Play Store. For example, some internal tools could be delivered from intranets. I’ll tell more about PWA later. Anyway, we thought that PWA would suit the need very well.

Communication? Wink wink nudge nudge. Say no more, say no more. This raised ideas for data structuring and for the UI.

Tech stack – And Now for Something Completely Different

We decided to go bold and try totally new components for this project: frontend, backend, database and infrastructure. Of course, there was knowledge and learning behind these things with some PoCs and such. And like I said, we were familiar with the tech. Or at least someone on the team was.

If we start from the bottom, we chose Docker for being the glue between components and between environments. We quickly drafted an open source version of this Docker thingie and released it as a separate thing. Stonehenge is a multi-project local development environment and toolset on Docker. Now the project uses Stonehenge as a developer’s tool to run it. As the local development environment is quite a common problem for developers, we thought this could be beneficial for others too. So that’s why we extracted this functionality from the project and released it as a separate tool.

Basically, Stonehenge provides us with local URLs and a proxy to handle the traffic to our projects. Proxy is made with Traefik which is just a breeze of fresh air compared to any previous tech used for the same purpose. I can say it works and performs very well on production too!

The project itself defines the services for our application. The basic stuff like Nginx, PHP, database and CLI and their relationships. We use Docker Compose for this.

For the application itself, we chose Symfony 4 for the backend and React for the frontend. Basically, Symfony creates a standard JSON API which the React application then uses. One reason we chose Symfony was the support for our database (what could it be?) via Doctrine. When evaluating different backend (PHP) frameworks, we studied the experiences of other developers, and there seemed to be nothing but praise for Symfony 4. And it really was a pleasure I can say. Some of us already had experience with Symfony as Drupal 8 is built on top of Symfony 3. Still, there were many new things for us to learn.

The database. MySQL, MariaDB, PostgreSQL or something else? We ended up choosing MongoDB to complete our jump into the unknown. MongoDB is a so-called NoSQL database where data is stored as objects instead of rows. This is very useful with data that can be very different by structure (read: document might have data which the other documents of the same type do not have). Also, the schema does not need to be defined beforehand (and updated) but it just lives by how you use your document entities.

React is something which I personally cannot write very much about, however my colleague Kristian has written a small recap of its use in our project below. Beware though: the Dependency Hell in Javascript world and the vast amount of same-but-different kind of tools available might sometimes make a developer’s life not-so-easy.

Quote from Kristian:

“It was pretty great to work with React on a large-scale project. In general, it was surprisingly easy. We did make some mistakes early on, which ended up forcing us to refactor. The original plan was to render the majority of the application with Twig, and only the communication aspect would be controlled by React. Eventually, the majority of the application was ported to our React app.

This means that we initially didn’t implement any sort of routing system and we didn’t think enough about the architecture of our store. Luckily we were able to refactor with relative ease once these problems presented themselves. 

Probably the most fun thing during this application for me was working with MobX. This is something I’ve wanted to do for a long time, and I’m glad I got a chance to finally use it in a commercial application. Essentially MobX is a state management tool built on the observer pattern. All observers who are watching an observable variable will magically update whenever the observable value changes. If there is one thing I’d do differently next time, I’d probably use MobX State Tree, which is a more opinionated version of MobX with some Redux-like behavior, without the overhead of Redux.”

Well, there you have it.

As we jumped on the PWA bandwagon, React helped us there to basically create a single page app which helps on some aspects on PWA. What does a PWA do, one might ask? You can think of it as an app which is basically a webpage. That means no App Store or Play Store for distribution. The app is updated when the web application is updated. There are a few distinct features to make it an “app like” experience: caching of assets for speed, standalone mode (to make your own UI without browser components), access to some mobile APIs and offline capabilities. There are also push notifications which currently work only on Android. Check the 2018 State of Progressive Web Apps for more info.

Progressive Web Applications is funny enough something Apple envisioned already in 2007 when they announced/released the original iPhone. Currently they are very strongly driven by Google. So this means basically that PWA works better on Android phones at the moment.

Fortune favors the bold, and I strongly believe the PWA is the future of apps and especially useful when creating tools for organizations and business.

Well, that was quite a long rant about technical stuff. Let’s take a breath for a moment.

“And now a film about a man with a tape recorder up his brother’s nose”

GDPR aspect

Yeah, the infamous GDPR. At this point we don’t have actual user data, so we’re nicely covered. But we designed the whole development on dummy data which started to be very fruitful during the project. We programmatically added data fixtures, which filled our database with dummy data. So in that sense, we’re totally GDPR-compliant when we do development. We don’t need production data.

This gave us some unexpected benefits too. In testing for example, we quickly noticed that we can use this generated data within our tests. How cool is that! Well, it is quite cool I can say.

“In this picture, there are 47 people. None of them can be seen.”

Next steps

The project is now in MVP state and moves to “field-testing” phase. Hopefully, end-users will like what we have done. The testing will be done with small groups and in a controlled way. This means we use a certain set of generated data suited for that test group. Also, we control the PWA aspect of the MVP. At the moment it works best on Android, so that will be the platform used in testing in testing.

“Now, what’s to be done? Tell me sir, have you confused your cat recently?”

About the coconut

We have learned a lot! This means that our learnings are already influencing our new projects and somewhat of how we handle older projects. We’re about to copy the backend stuff for a new API-only project and the Docker stuff has evolved into a very usable state. And releasing an open source project (Stonehenge) was a definite plus!

The most exciting part at least for me has been to share all this with more and more people inside Druid so that all the learnings can be put into practice on a wider scale.

“Wait a minute — supposing two swallows carried it together?”

Marko Korhonen
CTO, The Ministry of Silly Walks

Working with Progressive Web Apps

At Druid we are always keeping our eyes open for new technologies, which can benefit both us and our clients. Recently we have been experimenting with Progressive Web Apps. 

TL;DR

• Progressive Web Apps provide handy app-like functionality for web applications
• The two major requirements are the manifest.json and a service worker
• PWAs can be the answer to user’s unwillingness to install apps on their phone

So without further ado, let’s delve into the world of manifests and service workers…

What are Progressive Web Apps?

PWA is a term for web apps that share certain features with mobile applications (i. e. phone apps).  Essentially a PWA is a web app with several modern web capabilities designed to give users a browsing experience similar to using a mobile app.

Before we get started, it should be mentioned that some of these features will not work on all phones. As of writing this blog post, iOS does not yet fully support PWAs.

The requirements

In order to be considered by browsers to be a Progressive Web App, your app must meet a list of requirements.

The most important points are these: 

• Site is served over HTTPS
• Pages are responsive and mobile-friendly
• Site must work offline
• A manifest must be provided
• A service worker must be registered
• Site must load fast enough for 3G

Now, most of these features that you would include anyway if you were building a web app. However, there are two important aspects, which make PWAs different than normal web apps, which I will give a brief introduction to here:

The Manifest

A manifest is a simple file which essentially tells browsers that this is a PWA. The specification can be read in details here: https://w3c.github.io/manifest/

It’s possible to define a lot of functionality in the manifest, such as a visual theme, orientation (landscape or portrait), basic configuring of colours, etc. The only mandatory fields of your manifest are name and short_name. These describe the name of your app. 

The manifest must be referred from your HTML head, like so

<link rel=“manifest” href=“/manifest.json”>

Service Worker

This is kind of the body of your PWA. It is able to process all requests to and from your site from the client’s browser. Every time the user makes a request to your site, the ‘fetch’ event is triggered and you can handle that request however you wish. 

A service worker runs in your browser (it does not have access to the DOM). The service worker is a “special” JavaScript file, which runs in a different scope than regular frontend JS. The browser can execute this script without the page being open. It can even be executed while the browser is closed. This is extremely handy for several app-like features, such as push notifications. In this article we will only scratch the basics, so we will not really be using much of this advanced functionality. 

Unlike frontend JavaScript, the service worker needs to be registered to the browser navigator.

I’ve included the script app.js in my HTML and from there the following code is executed:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker
    .register('/sw.js')
    .then((registration) => {
      console.log('Service worker registered', registration);
    })
    .catch((error) => {
      console.error('Something went wrong with registering service worker', error);
    });
}

Then, in the ServiceWorker, you can add eventListeners.The most important events are install and fetch. 

install

This event runs the first time the user visits your site. Since it will only run once, it is expected that page load might take slightly longer than normal during this request.

const CACHE_NAME = 'static_cache';

const urlsToCache = [
  '.',
  '/js/script.js',
  '/css/style.css',
  '/images/myCat.png',
  '/images/myDog.png'
];

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(urlsToCache))
  );
});

The previous code defined the name of the cache we will be using and an array of URLs that should be cached immediately. Your cache will be created if it does not exist. You can add any internal URL here. Just keep in mind that the ServiceWorker has a certain scope. The scope is equivalent to its URL. So for example in the previous code, the service worker is located at /sw.js, which means that its scope spans the entire site. If the ServiceWorker was located at /swdir/sw.js, It would only be able to handle requests within the /swdir/ url.

fetch

Now comes the exciting part – fetch. As I mentioned earlier, this event is triggered every time (except the first) a user makes a request to your site. 

self.addEventListener('fetch', (event) => {
  console.log('Fetching data for', event.request.url);
  event.respondWith(
    caches.match(event.request).then((response) => {
      if (response) {
        console.log('Returning ' + event.request.url + ' from cache');
        return response;
      } else {
        console.log('Fetching ' + event.request.url + ' from network');
        return fetch(event.request);
        // TODO Add fetched file to cache
      }
    }).catch((error) => {
      // TODO Handle error
    });
  );
});

Remember, fetch is triggered every time a request is made for an individual file on your server. So for example, if the user visits index.html, it’s possible that a fetch event will be triggered individually for the urls index.html, /js/script.js, /css/style.css and /images/myCat.png. So in that case it will run 4 times. 

The previous code is a simple way of serving offline content. For each request, the ServiceWorker checks if the file already exists in cache. If it does, it is served to the user. Otherwise, the file is fetched from the server.

With this simple code, it is possible to have an offline PWA up and running. 

Some advice

While the concept of PWA isn’t extremely daunting or anything, there are definitely certain aspects that can be confusing and frustrating. Listed below are some of the more useful tools I used when learning the basics of PWA:

Lighthouse

Lighthouse is a built-in tool for Google Chrome designed specifically for testing Progressive Web Apps. Just go to your page, open Chrome DevTools and press the tab “Audits”. Lastly, press the blue button called “Perform an audit…”. Chrome will then run all the tests and give you the results in an easy-to-digest list. In case of failed audits, the reason for failure should be pretty self-explanatory. If you’re like me and like the shotgun approach, just keep modifying your code and re-run Lighthouse until it’s all green. Do keep in mind that your site needs to be served in HTTPS, so in case you’re testing on localhost, this audit will invariably fail. 

Google Developers

Google has some very good and up-to-date resources on PWA. One nice thing about their docs is that it will automatically warn you if the article is old and therefore more likely to be deprecated. 

Conclusion

Progressive Web Apps are a new exciting technology and it is definitely worth it to invest some resources into learning this technology. In an age where users no longer want to install apps on their mobile devices, PWAs serve as a nice middleground between the modern web applications and more traditional mobile applications. 

Making super fast virtual machines with passthrough

Reader beware: this text is highly technical! It’s meant for fellow developers and tech enthusiasts. We’ll take a look at using virtualization as a no-compromise replacement for dual booting between operating systems, emphasis on the word no-compromise. Many tasks are quite feasible even with a basic VM, for example testing websites in a legacy browser not available on current operating systems. For more demanding tasks, booting to another natively running OS and then back just for one specific app or a gaming break is cumbersome. So what can be done?

Getting up to speed

Emulating a CPU, graphics and I/O has a heavy performance cost. We can get away with it when running old applications on modern hardware (think of DOSBox and video game console emulators). We need something faster than emulation for a snappy VM running new operating systems and apps. To do this, the virtual machine monitor has to bring the guest system closer to bare metal. Hardware assisted virtualization has been on server and consumer CPUs for years (as Intel VT-x and AMD-V). It allows executing guest instructions on the real CPU with far less overhead than in emulation. It is crucial for running x86 virtual machines at nearly native performance. It’s also widely supported nowadays.

On the I/O side of things, various paravirtualization methods have been used to boost performance compared to emulation. What this means is the virtual machine manager exposes special devices that allow somewhat direct access to actual host hardware through an API. This provides faster disk, networking and timing support in virtualized environments. Even limited hardware accelerated graphics support exists in various virtual machine managers, where OpenGL and Direct3D up to version 9 via an API translation similar to Wine are supported. Paravirtualized devices often need specific device drivers that have to be installed on the guest OS.

Another step further is to provide a guest system with dedicated, exclusive access to actual devices on the host machine. We call this method PCI passthrough. Since the guest has direct access to the device, it is controlled by the same device drivers and has the potential to provide the same performance and device specific functionality as on bare metal. For instance, TRIM commands can be sent directly to an SSD connected to a passed through disk controller. Dedicated storage and networking hardware can be useful for demanding server use cases where the best performance is needed without giving up the benefits of virtualization. On the desktop, an interesting use case is dedicating a graphics card (VGA passthrough) to a guest OS and running graphics-intensive applications with high performance.

The software side

Support for PCI passthrough exists in various virtualization software. However for VGA passthrough specifically the common and well documented approach is to run a VM using the Linux kernel’s KVM as its hypervisor, QEMU as the userspace emulator and OVMF as its UEFI component. Trying out QEMU is relatively straightforward. Virtual machines can be fired up from the command line and all the needed configuration options are given as arguments. Then, host devices can be given to a VM using a helper driver called vfio-pci.

If all goes well, you’ll have a VM with direct access to the piece of hardware, with minimal overhead. Pretty much any PCI-E device can be passed through, with caveats (we’ll get back to these in a moment). Many motherboards have their SATA and USB ports spread out on more than one controller. Then, one of them could be dedicated to a VM. My own VM setup has its own graphics card, USB controller (mouse and keyboard can be switched between the host and guest with a switch), an add-on SATA controller and the onboard audio passed through. After some tinkering, optimization and figuring out what works best, I’ve given up on dual booting because the VM is simply free of compromises.

The fine print

Let’s look at the caveats, then. Doing this needs obviously appropriate hardware. Most importantly both the CPU and the motherboard need IOMMU virtualization support (Intel VT-d and AMD-Vi). Luckily, they have been available in many if not most consumer platforms for years. However, a working implementation on a motherboard is not a given even if VT-d or AMD-Vi support is advertised. Though in many cases fixes have been provided via BIOS/UEFI updates, virtualization features are hardly a priority on mainstream consumer hardware.

Another common issue is something known is IOMMU grouping which deals with the separation between devices. To put it simply, devices cannot be passed through if other devices belong to the same group, unless you pass all of them. Otherwise they could interfere with each other and nasty things could happen. How your onboard devices and add-on card slots are grouped depends on the motherboard and the chipset it’s based on.

Finally, the PCI-E devices themselves can have firmware bugs that cause them to behave badly when passed to a VM. Some hardware vendors are also known to implement VM detection in their (consumer hardware) drivers and prevent them from working if they are running inside one. With server grade, and to some extent enthusiast consumer hardware you might avoid these issues. Still, it doesn’t hurt to do some research on your prospective components before building a setup like this.

All in all, we have just scratched the surface on this matter and this is only intended to provide an introduction. If you’re interested in this kind of thing, I recommend checking out the links below for more details. You might also ask, what’s the point? Considering the amount of time spent tinkering and possibly the cost of additional extension cards for VMs, one could just buy a whole extra machine and be done with it. But where’s the challenge and fun in that? 😉

Passthrough and virtualization in general will quite probably remain in the niche for regular desktop/laptop users but time will tell what happens in the business and server world.

https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF

https://vfio.blogspot.com/

A static content layout lifesaver: Paragraphs module

As Drupal website users, we all know how boring static basic pages and detail pages are. As Drupal developers, we all know how frustrating those boring basic pages and detail pages become, when someone (indeed, the content editor) tries to change the layout by messing with the source code of the WYSIWYG.

Frustrate no more. The Paragraphs module is here to save the day (and your content layout)!

What is it, this Paragraphs module?

Imagine you’re a content editor and you want to create an article with some text, a few images, maybe a caption underneath the image. You also would like to have a quote, which stands out with a full width background image. How would you do that with the WYSIWYG? You try to modify the HTML in the source code and hope it turns out exactly like you had in mind. 

Of course, that’s wishful thinking. But there is a solution. One that doesn’t require a big WYSIWYG field, but a solution that lets the content editor create every section of the article separately.

Curious how it works? Let’s dive right into it, shall we.

** For examples I am referring to a paragraph demo site I recently created for Druid. **

The Paragraphs module simply creates a new field type, Paragraph, which you can use in your content type. And for each type, you can add field types. Sounds familiar? Well… it kind of works the same way as a content type.

Now you’re probably thinking, “haha, what’s so life-saving about this” and you have a point. The field type is nothing life-saving at all, but the paragraph types behind it are.

Paragraph types

A paragraph type consists of fields, and these fields are the same types as those of a content type (you even get an extra reference option to another paragraph).

After you’ve created your paragraph types, you can add them to your content type – and this is the nice thing about it. Basically, you create a field with a reference to paragraph types. You can define no paragraph types, which will let you use them all, or you can define only those you would like to use in a specific content type. When you create a new node you can use as many paragraphs as desired, and you can mix them as much as you like. There’s also a handy little drag and drop so you can change the order of the paragraphs really quickly and easily.

Each paragraph type has a matching template file, where you can add the needed HTML markup. This allows you to theme per paragraph and that way, you don’t have to worry about the layout of your node. It doesn’t matter if you add a certain paragraph type to the top of the content or the bottom; if the theming has been done properly, it will look good.
 

Looking pretty good, right? Try that with one huge WYSIWYG body field. Yup, didn’t think so!

Why you should only use it for static content 

The purpose of this module is to create nicer and cleaner content. As in content created by the client. Overview pages, feeds, or any other item that needs dynamically generated content, should probably be handled by something that is able to do this automatically, like views.

If you want to give the content editor a bit more freedom layout-wise, but at the same time you don’t want to worry about your pretty layout getting messed up, the Paragraphs module is exactly what you need. Dying to try it out? You can find the module here. I truly hope you enjoy using it as much as I do!

How to visualize the status of a sprint in JIRA?

The chosen project model is often critical to the project’s success. That is why we at Druid prefer agile methods and Scrum. Scrum requires all the work of a project to be gathered to a single place so that it can be managed properly. Even though a hip method might just be to scribble notes on pieces of paper and stick them to a wall, we have settled on a more engineerish solution, and use the JIRA project management software. We might lose out on some hipster points, but what we gain are various different project views, comprehensive reporting and other useful features.

On default settings JIRA creates two views for a Scrum project; a backlog view and a view for the active sprint. In addition, the workflow is very simple; just ‘To Do’ → ‘In progress’ → ‘Done’. For many this is enough. Or is it? Let’s find out.

In the ‘Backlog’ view you create stories, give points, assemble a sprint and initiate it. The stories get (technical) subtasks added to them. So far so good. Let’s switch to the view for the active sprint. I undertake one of the stories. I can easily see what subtasks the story has, and the status of those subtasks. One by one, the subtasks are completed until all of them are done. The story is finished!

No, wait a minute… Of course the story has to be put through peer review to ensure the technical quality of the work. And naturally the product owner will want to use a separate testing environment to check that the story’s requirements are met before signing off. Hmm… Should separate subtasks be created for all this? For each story? That sounds like a lot of repetitive work.

The correct solution is to follow the golden rule of software architecture: model the desired structure with the features that the system offers, so that the system will ‘understand’ what you are doing. In this case, the goal is to model the whole process of the stories from the beginning to the end, so the first step is to expand the JIRA project’s workflow to cover all the phases of the sprint.

The necessary phases will vary between projects. Here is one example:

• Sprint Backlog
• In progress – Frontend
• In progress – Backend
• Development Done
• Peer Review & Deployment
• Acceptance testing
• Done

This too is best handled agilely. The first version is drawn up according to your best knowledge, and after that the phases are modified according to the experience gathered. (Pro tip: The project’s workflow should be labeled ‘Simplified Workflow’, so making changes is easier.)

When the workflow is all in order, we should work magic with the views. The view for the active sprint should work as before, so that the development work will run as smoothly as possible. That’s why you’ll only need the first four steps in the view (from ‘Sprint Backlog’ to ‘Development Done’).

In addition to that, a new view is created, called the ‘Review’. The purpose of the Review view is to offer a quick overview of the status of the sprint, and to allow processing the work on a story level, which is required on the final stretch of the sprint pipeline. In addition, we want to group the first four phases (‘Sprint Backlog’ through ‘Development Done’) into a single column titled ‘Develop’, because those phases have to do with the subtasks, and at this point we are interested in the stories themselves.

See a more in-depth installation guide on video:

The end result is that the stories’ workflow has been modelled into JIRA, and now you don’t have to guess or try to remember what phases the stories are on. In addition, it’s easy for everyone, even outside of the project, to check on the sprint’s progress.

Visualization also helps in finding bottlenecks; if, for example, stories keep cropping up in the peer review column, the development process should be modified to lean more towards peer review. There are exceptions, but continued congestion is a sign of a defective process. Luckily the retrospectives that are built in to Scrum can be used to bring the issue to light, and possible fixes can be tested easily. The views will show directly whether the fixes work.

A couple of known issues:

– At the end of a sprint the stories are in ‘Done’ status, but their subtasks are left in ‘Development Done’ status. Before closing the sprint, the subtasks have to be manually moved to the Done column. The move action can be performed on all the subtasks by searching them with the ‘Issue Navigator’ and changing their status with the ‘Bulk edit’ tool. The fix can also be implemented automatically with JIRA’s own script language, but we haven’t gone that far yet.

– In the ‘Review’ view, the ‘Only stories’ filter has to be manually activated. If you find excessive clicking annoying, a quick fix would be to add the view to your browsers bookmarks and to the bookmark toolbar. We developers use Grease Monkey scripts that add the proper links automatically to our browsers.

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 frontend solutions for Aava’s different services, all of which have been created using different backend 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?

Adopting new technology always creates challenges. On this project, the most prominent challenge was how modern technology would merge with the infrastructure and programs Aava already had in place, even though the whole in itself had already been modern, per se. Also, not all of the team members had previous experience with modern JavaScript (es2016+). But we’re all for challenges, so during the project we made sure that each team member would have the same level of readiness to take part in the development of the project.

The infrastructure in place for Aava has been kept up to date for the whole length of our cooperation, but despite that, at first the development seemed to advance slowly, because we had to concentrate largely on developing the previous architecture; groundwork takes time. The main reason for this was that Aava did not have similar JavaScript implementations in use. When we completed the first components, we begun to pick up the pace, and new functionality started cropping up very rapidly.

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.

Technical choices

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.

For the moment we are using Drupal 7 as a backend system for the application. The API we’ve designed works so that the frontend 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.

Summary

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.