As a developer myself, whenever I read a set of patch notes or a feature blog post, I'm always interested in the details behind the note. We try to make our notes a little more specific than the infamous "Various bug fixes and improvements" when we can, but there's always a deeper story behind that one line of text. For this Dispatch beta period, we're going to release a series of developer-centric blog posts to provide some more context to those who are interested in the direction of Dispatch.
If you are light on time, our recently released patch notes will tell you about the new features we've made and the old ones we've retired. Our GpsGate blog posts will explain how our new features can help your business and fulfill your customers' needs.
These developer blog posts are designed to provide some extra insight on the creation of the plugin for those looking for more technical details or the intent behind the various features and are purely optional reading material.
In the coming weeks we will have some deep dives on the design and the implementation of our various key features touching on topics like our new native apps, our route management and optimisation, the analysis panel and our developer APIs.
This week we'll be looking at our motivations for redesigning both the server and the user interface of Dispatch.
Let's start at the very beginning.
The main motivation for this redesign of the Dispatch plugin was to address 3 key issues that we were having with Dispatch 4.
- The resistance involved in creating new features
- Usability of the UI at scale
Performance is one of the simplest concepts to understand in software for both users and developers. While using the features of the program, everything should work responsively and not stutter and stop when it's stressed. To get to this level of usability in modern software with its terabytes of data flying around between thousands of interlinked features, performance, for developers becomes a never-ending quest and a state of mind.
In a piece of software, the very slowest component immediately becomes your performance bottleneck. It's obvious when you think about it. Who cares if the server is flying at 88 miles per hour if your user interface is immediately choked by the data it's getting. If your data storage takes a long time to load your data, every subsequent component is waiting around idle.
To achieve good performance, every aspect of the system between the user's screen and the store with your data needs to be designed in a way that does not block anything else. Every time you implement a fix or feature, you need to consider how it will work when there is a lot of data and a lot of users. If you do this in every aspect of your system, then you can have good performance.
GpsGate Server is used by many different types of partner and solves so many business cases that we won't ever be able to add every feature that everyone would like. Despite this, we have a strong commitment to working with our partners and turning their feedback into features whenever we can. We typically have a much faster turnaround time on features and fixes than most software developers and we look for opportunities to design our systems in a way that can help us with this goal. It's important to us that Dispatch provides a platform that aids our ability to be responsive with updates and we saw an opportunity to make it better at this with Dispatch 5.
When a large system is working smoothly and there are no performance issues, the next thing to address is whether the data that you can serve to the user is useful. If your system can display 1 million items to the user, can they use that information in a meaningful way? There's a chance that you're just making a lot of noise that is hard to interpret. For the performance to be meaningful the system needs a way of displaying all the information that will help the user the most, while ideally having the rest of the data close at hand.
The concept of usability is a very complex one and is best addressed in discussions about specific features. We will leave this topic for the posts about our features in the coming week and instead concentrate on performance and adaptability.
These two concepts are unrelated at first glance but it turns out that a shift in design can help you in solving both at once.
Traditionally the best way of gaining performance has been by optimising code to do as little work as it can to achieve the goal that you want. The fewer operations that the processor must perform, the faster it will go. If your processor is faster, it can do more operations in a certain time and the faster your software will go. Both principles still hold true and are still valuable tools to improve performance but in a modern system there are a massive amount of operations taking place at once. Very quickly you will hit a point of optimisation and server capacity that can't really be tweaked all that much better.
With the increase in complexity of systems come more moving parts in the system. This is a blessing as well as a curse. A lot of the functionality of these smaller parts don't need to be very connected to each other aside from when they start and when they finish. With this in mind, it's almost always possible to break each small part of the system down into a self-contained little black box that only needs two things outside of their own world. When they start an operation, they will need to be given instructions and data to process, and when they finish they'll need to tell some other part what they managed to produce.
In Dispatch 5 we have rewritten the server back end to use a message-driven architecture. All the system has been split into smaller parts that do their own work and spring to life when they are sent a message telling them to do something. When they are finished, they send a message to the other parts that will want to know about the result, who in turn can act on this message.
Breaking the system down into very self-contained parts like this creates a small amount of extra work compared to extremely optimised code that directly links into parts of other systems to bypass a few redundant operations. In exchange for losing a few extreme optimisations you get many benefits:
- The code to deal with each part of the system is completely separated from other aspects of the system. This instantly solves a lot of our concerns about making sure that the system can be updated and fixed easily. You can change inside one feature without causing a lot of side effects.
- The code to run an operation of a certain type has nothing to do with other parts of the system. They communicate only by sending a message to each other when a message is ready. This means that we get access to â€œasynchronyâ€ when it makes sense; the ability to run the code at the same time as another operation without waiting for the other operation to finish. Asynchronous programming is not a new concept and GpsGate Server has taken advantage for it for years, but a message-driven architecture allows asynchrony without adding a lot of the complexity that comes with traditional asynchronous programming.
- As we just created some asynchrony we now also have scalability. Instead of trying to supercharge our processor even more, we can just throw more processor cores at the workload and benefit from them. An operation can run on any free resource and fall asleep when it's either waiting for a message that it needs, or has no work to do, freeing up the resources for another operation.
- As all our processes communicate with passing messages we don't need to stop at multiple cores. We can have the different parts, usually called micro-services, live on different servers that are tailored to what they're trying to achieve. A server with a lot of disk storage for the database and a lot of processor power for the route optimisation, for example. GpsGate 5 now has support for the track store running on a cluster of these servers and in the future Dispatch will also be able to be scaled to a cluster that you can tailor for your business case.
Things have subtly changed on the server now. In a message-driven architecture you should no longer start an operation and wait for a response. Waiting is a waste of time as the part of the system you are communicating with will send you a message when it's finished. If you would like, you can even ask it to stream messages to you as it finishes each part of an operation.
This concept is something that we want to exploit on the interface side. Using HTML5 server sent events we can split up our server communication logic to be two different systems. One system sends requests to the server when the user wants to do something or wants more data. One system processes any incoming data that is received from the server. This means that operations in the interface finish immediately and release control back to the user. It also means that the instant the server is finished processing some data, it can inform all the connected clients - web or app - that the new information is available. This messaging happens without leaving any processes sitting waiting for responses on the client side. As there are no processes waiting, it also means that on the server side you don't need to have an operation that is sitting and waiting for the response data for each request that is sent in. Now you don't have a server that is being choked by lots of longer running requests.
As well as the communication with the server being rewritten, our web interface refresh and new apps are designed to work with large amounts of data. A lot of effort has been put into making sure that with this increase in server responsiveness, the user interface can keep up.
We will share more details about the interface in the upcoming blogs.
What is next?
Throughout the beta period for our live Dispatch 5 release we will be concentrating on fixing bugs and tuning the performance even more based on our own testing and feedback from all our beta testers. We are proud of our new system but we're not ready to call it finished. There will be glitches and bugs and we'll be working to get them smoothed out.
Alongside bug fixing, the development team will be making sure that all the features listed in our Known Issues patch notes section are included in the plugin and working before we go live.
Our design team is working on constant improvements to both the user interface and the wider user experience for GpsGate Server and their efforts will be debuted in Dispatch 5 as soon as they are ready. Other plugins might take some time to be updated but Dispatch 5 will be at the front of the line.
While the beta period is ongoing we have some of the team working on our first major feature release. Our current plan is to have a beta build ready very soon after Dispatch 5 is released to the update channel. We will share more about our first feature patch nearer to the end of our beta, but it will introduce some very requested features such as the ability to add media to Dispatch custom fields and a more powerful search functionality in the Dispatch panel.
We will be releasing blog posts during the beta phase highlighting new and upcoming features for Dispatch 5, but we are also running a Dispatch 5 beta feedback group. Members of our beta feedback group will get emails with the developer deep dive posts, be assigned specific feature feedback assignments to communicate with the developers and be a part of shaping the development of Dispatch 5 for our first feature patch and beyond!
Our first round of specific feedback gathering will be targeted at our Mobile apps so sign up now if you haven't already!
Sign up to our beta feedback group here.
Andrew is a developer at GpsGate in Stockholm. He works mostly on designing systems for GpsGate 5 and in his spare time enjoys trail hiking to the fridge.