Attending the API Days NZ Conference recently gave me the opportunity to learn the API journey of several successful companies, and how they came to be where they are today.
Ian Randall, a software engineer at Pushpay, presented ‘APIs at Pushpay – A Continuous Delivery Story.
Ian described the PushPay API store from the beginning to its current position. Starting from one API, they eventually split into two: public and mobile. The mobile API is for internal company use only, with the amount of data used always kept at a minimal level – the only data transferred is what a client needs.
Ian also spoke about Pushpay’s delivery approach. Changes are pushed to production at least six times per day. The development team and the test team are fully integrated, allowing for the efficient resolution of any issues raised during testing.
Barak Chamo, a London-based developer, introduced us to GraphOL, a new technology which is leading to a new language.
Originally developed by Facebook for its mobile applications, GraphOL became open source in 2015. It brought a paradigm shift in the way we approach data transfer, from the front to back-end of applications.
Instead of using predefined data and response structures, a developer can declare a graph form of a data model, and request data in its object form in a JSON-like syntax. GraphOL also makes things easier, without the need to maintain v1, v3, and v100 or APIs to ensure legacy versions are supported. GraphOL queries always return predictable results. Send a GraphOL query to your API and you get exactly what you need – nothing more and nothing less. If more than one object is required, GraphOL queries follow the references between the resources, retrieving multiple objects in a single request. This means applications which are GraphOL-based are fast, even on slow mobile network connections.
The only disadvantage is GraphOL is a brand new language API developers need to learn – or is that actually another advantage?
Abhishek Tiwari is a lead software engineer at Isentia, and spoke about legacy code API transformation journey.
Due to one-time, one-place processing and isolation of business rules, stored procedure has been used as a de facto standard for application to access and manipulate data. But if you have a legacy code with most of the business logic imbedded into it, you can still develop API against the stored procedures considering them as a variation of Functions as a service (FaaS).
A function in FaaS is a self-contained piece of reusable functionality, which makes them similar to stored procedures. This means stored procedures can be converted one by one into FaaS functions to be executed via API endpoints.
API days presented a wide and informative range of new technologies, together with approaches to using these new technologies. We were able to see ways to enhance the API build process and get new features into production quickly and safely. There were ideas on how businesses use APIs by mixing new and old technology to enable them expand the capabilities of legacy systems through APIs, without the need to reengineer or rearchitect much of what is already in place.
While API itself is not new, it has recently turned into a key tool. It could be compared with a door. For a developer, it is a door into the software program - APIs allow interactions without need to share the code. For a business, it is a door to the leading products market, which turns competitors into partners.
