Inside SCL: API Decision-making

By November 3, 2016Uncategorized

Fred Smith, our Head of Development, spent a large part of  last year designing and creating the server-side framework to support our new API. Below, he discusses the decision-making process behind it.

UltraPoS, like most software, consists of various components communicating with each other. There are different types of component – plug-ins to extend basic UltraPoS features, gateways to card processors and, for some of our clients, links to their MI and GL systems. All these different components communicate using APIs, Application Programming Interfaces.

It may not be obvious, but the screens you interact with when using UltraPoS are part of another component, an application that runs in your web browser and communicates with the core of UltraPoS to record transactions, run reports, manage stock and so on. The browser application uses an API to communicate with UltraPoS. This same API is also used directly by some of our clients from their own applications, and by SCL’s public-facing Money4Travel offering.

UltraPoS was born 15 years ago, and the API was built around what browsers and web servers could do at the time. Essentially this was to have the core services provide the raw data for each page, and for the application to re-interpret it into the familiar form you see today. SCL developed some advanced techniques to allow this to work – caching mechanisms to avoid having to look up the same thing twice, load balanced application servers to support large numbers of users, and so on.

As browsers and network software have evolved, so has the API, but based on the same mechanisms. This has allowed SCL to continually improve UltraPoS to fit in with our client’s needs while building on an established base, but has inevitably led to an overhead in maintaining forwards and backwards compatibility. 15 years of code does not come without a cost.

So one of the things we’ve been looking at is how we can use all the new facilities available in modern web browsers and frameworks to take UltraPoS forward so that it is more responsive to use, more secure and easier to maintain. The model we’ve chosen is based on a RESTful architecture. I’m going to skip over the technical details of this, but as far as UltraPoS is concerned it means we only transfer the data that has changed to and from the servers in our data centre, rather than reflect the complete state of a page or order back to the browser each time. This will significantly reduce the traffic, and thus loads on the servers and networks, making UltraPoS more responsive and the servers able to handle more requests with the same hardware.

This style of API allows us to split the software into much smaller components, making it easier to maintain and quicker to add new features. On the server side it also lets us deploy an appropriate number of instances of each component – more components supporting order taking than those for stock management, for example.

The new API has been designed to work consistently for all requests, so there is no special effort to package and interpret data for different operations. All requests are built and used in the same way, the differences being in the data being changed or requested. The prime format is JSON, a standard in this area, although XML is supported as well for those who wish their applications to communicate directly with UltraPoS. We also have the option to add further formats should the need arise.

Developing the foundations for this new style of API has taken us plenty of time and effort in research and experimentation. At the server side we did not want to replace the solid and well-engineered core software that handles saving orders to the database, managing complex rate lookups, etc. and so we were not in a position to use an existing framework. Instead we have produced our own, neatly fitting between the core software and the web server, removing two layers of software in the process. Simple new features are quick to implement, mainly being descriptions of what is needed and the generation of suitable tests. More complex features will need more work, but will still fit into the same structure and use the same support for packaging and validating data.

The browser side application had more scope for using standard frameworks. We spent some time exploring these, ultimately choosing Angular. This has been produced principally by, and is extensively used within, Google, who have invested uncountable resource-hours to produce a programming framework that is efficient for our developers and easy to use for our clients.

We will soon start to realise the fruits of this effort. New pages allowing parts of UltraPoS to be configured will use the technology first. Some of you may see these in our new promotions feature which will make its first appearance in version 2.7. Other uses will be less visible, such as the service controlling access to IDs scanned by UltraPoS, another new feature coming soon. Initial looks at these new pages are promising, with responses being very fast.

Ultimately the pages you use most often will be moving to this technology, the ones concerned with taking orders and managing stock. This will take us some time as there is a lot going on behind these outwardly simple pages. Initially you may not see much outward change, but this technology, alongside our look and feel refresh, is going to make UltraPoS even easier to use in the future.

Leave a Reply