Recently we were approached by a partner who wanted to use some of AppScore’s features in their own client portal. We’ve had a public API on our roadmap for some time, so this request gave us a perfect opportunity to bring the feature forward.
In this blog I’ll cover how we created a public API in just two weeks. I describe how we combined AWS technologies with the relevant parts of our core codebase to rapidly build the API.
I’ve worked in the IT industry for nearly 30 years, and despite having focussed on cloud for the last 10 years I was still amazed by just how quickly and easily cloud technologies can be used to create something that traditionally would have taken months.
But before we go into that, it’s probably a good idea to understand what an API is.
An API (Application Programming Interface) is a service widely used by developers for connecting and exchanging information between or within applications. By using clearly documented procedures (known as API calls), they are ideal for interfacing between different applications or organisations without having to create a custom connection.
Every day you use APIs without realising it. For example, when you make a purchase online, the company you’re placing the order with will use an API to connect to a payment provider to process your credit card payment. They may also use an API to communicate with a courier company to ship your order. The payment provider or courier company creates a standardised API for use by all its customers rather than having to create bespoke interfaces for each customer.
What technology did we use, and why?
The AppScore application is constructed in such a way that it already has an internal API, however, this was not designed to be public facing and we knew would require significant development effort to use it in that way.
Therefore, we needed to build a new API that could be used publicly by approved partners. The API had to be able scalable - to process large volumes of transactions on-demand, secure- by providing authenticated access, resilient – to provide high levels of availability and enable us to do meter-based billing. All of this at a low operating cost.
As we make extensive use of AWS in our AppScore SaaS platform and our dev team is highly conversant with AWS technologies, this was a natural place to start investigating the solution. With AWS there will always be a solution to your problem, the challenge is how much you need to bend your solution to meet the services that AWS offer.
Research
Research into how to create an API for AppScore on AWS proved very simple. It involved reading AWS documentation as well as watching YouTube videos and other content. There were many examples available that showed how to create an API to do exactly what we needed.
We then built some test APIs to understand how the AWS services worked together to meet our goal. This is where the service consumption model of cloud is a great benefit; it was quick and simple to build some test APIs at a negligible cost and this took around a week’s work to research and create some test APIs.
How we did it
We used the AWS API Gateway, AWS Lambda, AWS DynamoDB, AWS Amplify and AWS s3 services
As AWS Lambda supports our core code base, development time was significantly reduced. This was the case for our 6Rs assessment feature as that has detailed decision logic built into it.
But for some of the simpler functions it was quicker to create new code that used our existing reference datasets, such as our cloud compatibly checker and operating system and database software support dates.
To test out the results from the API a simple front-end was built using AWS Amplify.
Metering
Calls against the API are logged in an AWS DynamoDB database which is used to record the user details and the volume of calls made. This data is used produce monthly bills for API usage for each partner.
Scaling and support
Using AWS API Gateway means we have no concerns around scaling to meet our partner’s demand, if needed we can also deploy a specific instance of the API into the same region as the partner’s solution to reduce latency and network charges.
As this is an AWS service, there’s very little infrastructure for us to support. Updates to our code in the API are managed by providing test and production instances for our partner’s dev team to develop and test against.
End user documentation was produced and made available in AWS s3, allowing partners to self-service development of the required calls.
The future
We now have a scalable, resilient, and secure platform and adding new features is a simple and repeatable exercise, we estimate 1-2 days per feature to add them into our API portfolio.
Do you have any other questions on how we created the AppScore API within two weeks? Or do you want to learn more about the AppScore platform? Get in touch, and one of our solution experts will be more than happy to help.