With modern applications increasingly relying on data from multiple APIs, databases, and other data sources, the ability to perform data integration and aggregation has become more complex. Thanks to GraphQL, the ability to query data spread across scattered data sources has now been made much easier because you can use one unified query language to access an entire API.
By Joydip Kanjilal
This article will examine modern API strategies on IBM i, including REST and GraphQL.
Why expose existing RPG apps using REST and GraphQL APIs?
For decades, many banks, manufacturers, distributors, insurance companies, and retailers have used IBM i to power their core business functions. Business rules deeply embedded in RPG on those platforms make it difficult to replicate them in a new system.
The way organizations deploy enterprise applications has changed from traditional to a mobile and IoT-oriented approach over the last few years. Applications run on desktop or mobile devices and use machine-learning-like techniques and consumption models via SaaS, consuming data and executing business logic through a standardized API implementation across multiple platforms.
It can be difficult to determine whether to use REST or GraphQL when exposing business logic from an application type through public interface layers (i.e., APIs). Please research REST/GraphQL and how each will work for various use cases to understand better which will work best for your application.
From REST to GraphQL: What GraphQL Brings to the Table
While REST has existed for a long time and is recognized by many developers as an industry standard, it has shortcomings when it comes to implementing APIs. The two primary obstacles associated with a REST based API are:
- Over-fetching - This is when a client asks a server for data, and the server responds with too much data.
- Under-fetching - This is when a client has to make multiple requests for data, sometimes using different APIs, to get the data they need.
You can address these shortcomings, but it would require time and effort, and you would also need to perform a thorough round of testing. Enter GraphQL.
GraphQL is an API query language designed by Facebook to solve these two problems. By using GraphQL, you only need one endpoint to fetch data for a specific use case. A GraphQL client can create a structured query that describes the exact data it wants from the server, and the server will return just that data.
Comparing GraphQL and REST approaches
To see how GraphQL can solve a problem, consider this example of developing a sales dashboard. Consider that you want to show the customer’s name, the last five order data, and the line items for those orders. When using a REST-based approach, you would need to make three individual calls to the three different endpoints to retrieve a single data set for your dashboard.
With GraphQL, you can get all the data you need with a single call, as shown in the code snippet given below:
query GetSalesDashboard($customerId: ID!) {
customer(id: $customerId) {
customerId
customerName
accountBalance
lastOrders(limit: 5) {
orderId
orderDate
totalAmount
lineItems {
lineItemId
partNumber
description
quantity
unitPrice
lineTotal
}
}
}
}
With REST, you first have to wait for the call to retrieve the customer data before making the next call to retrieve the order data, and then you wait for that order data call to finish before you can make the last call to retrieve the line-item data for that order. When you’re using GraphQL, you can get everything you need to display your dashboard in one query.
Figure 1: Execution Flow of REST vs GraphQL
When using the REST approach, the entire customer object would be sent to the dashboard, including all its fields, even if the dashboard does not use them.
Hence, the payload is much larger with a REST-based call, resulting in higher bandwidth usage than when sending only the required fields. On the contrary, when using a GraphQL query, you specify exactly what fields the dashboard requires to display all of the information related to the dashboard.
With a REST-based approach, you will be making three requests to your server. You make just one request when using a GraphQL-based approach. GraphQL results in one round-trip to your server, no over-fetching or under-fetching of data, and has a self-documenting schema that clearly defines data relationships.
While REST, GraphQL, and event-driven messaging are complementary, they are distinctly different technologies with their own benefits and downsides. REST is best for transactional workloads because it provides a predictable interface, is relatively easy to integrate into existing or legacy systems, and is stable from an operational standpoint.
When you want flexibility for your clients when retrieving data, GraphQL is a great choice because it offers additional benefits over REST by aggregating the data you need, thereby minimizing the number of server calls required to retrieve it.
Message queue-based technologies such as Kafka and RabbitMQ are excellent tools for integrating different enterprise applications and implementing truly asynchronous systems with real-time capabilities.
Organizations should weigh the benefits and downsides of using GraphQL. While REST APIs typically have a set of well-defined endpoints, the complexity and size of a GraphQL query may make it difficult to manage. Hence, such queries may require more bandwidth, thereby increasing pressure on the backend systems, especially if they are not properly managed and controlled.
A Real-Life IBM i Modernization Scenario
Consider a distributor that uses an IBM i platform and an order-processing system running on it. Assume that the distributor wants to develop a portal for its customers and a mobile application without rebuilding the legacy RPG application code. Let us now understand where REST and GraphQL can fit in this scenario.
By exposing order and inventory data using REST-based services exposed via either an existing IBM Integration Workflow Service (IWS) layer or new middleware, and using a layer for security, it should be possible to take advantage of Node.js or Python running on an IBM i for orchestration and format the structure of returned JSON data as needed.
And you can use GraphQL to fetch aggregated data and display it in a dashboard. You can also use Kafka when you need to stream event data to external systems. The business value of this approach is awesome: you can have a faster partner integration, more secure, reusable business services, and reduced modernization risks.
Security Considerations
Since your APIs expose your application's business logic to the outside world, you should secure them in accordance with recommended standards such as OAuth 2.0 and OpenID Connect. It should be noted that IBM API Connect supports both OAuth 2.0 and OpenID Connect as part of its API security model.
You should also implement an API Gateway to centralize authentication, apply rate limiting and throttling, and monitor your traffic. You should know that these are the fundamental security safeguards and preventive strategies you should adopt to secure your APIs developed on the IBM i platform.
Additionally, you should implement observability to understand the real-time behavior of the application using logs, metrics, and traces, and take necessary measures proactively to fix issues in the event of an outage.
IBM API Connect for GraphQL
If you need flexibility in your access to IBM i-based data and you are having issues with REST APIs, either returning too much data or requiring multiple API calls to access related data, then GraphQL is definitely an option to consider. IBM API Connect for GraphQL provides a GraphQL server and a command-line interface that allows you to create, test, and deploy GraphQL APIs that connect and provide a single point of access to backend data sources, such as REST, SOAP, SQL, NoSQL, and even GraphQL backend data sources, while optimizing the queries automatically.
A Hybrid Approach
REST and GraphQL, and event-based messaging can work together to provide an architectural foundation where REST gives you a dependable transactional service for transactions, GraphQL provides you a simple way to retrieve and represent data, and having Kafka or MQ gives you the ability to create an event-driven, real-time integration solution. If you are using an IBM i-based environment, this combined approach will give you a solid path to migrate from tightly coupled legacy interfaces to more loosely coupled, API-based system interfaces.
IBM i integration tooling and deployment options
The IBM i HTTP Server is the primary source for accessing IBM i API implementations. While IBM IWS will provide service routing and handle much of the service plumbing needed for REST and SOAP services, you can take advantage of IBM API Connect to manage service lifecycles, provide gateway rules, enforce security, and also provide production-grade API governance.
There are several options for deployment outside of IBM's current stack of software tools, as discussed below:
- IBM Integrated Web Services (IWS): These are useful for rapidly creating REST and SOAP API-enabled services.
- IBM API Connect: You can take advantage of IBM API Connect to manage REST/SOAP API lifecycles and enforce gateway security policies using modern security protocols.
- Profound Logic: This can be used to expose your RPG and COBOL business logic through APIs.
- Eradani: This allows teams with an alternative integration approach that uses modern API contracts and middleware around IBM i business functions.
An IBM i Modernization Context Perspective
GraphQL is incredibly useful for exposing RPG business logic as REST APIs for the following reasons:
- Reduced Bandwidth: Reducing the number of network calls that have to cross the boundary between your modern user interface and legacy systems is critical to performance for the geographically distributed IBM i sites.
- Data Aggregation: A GraphQL layer can aggregate multiple legacy endpoints into a single, unified endpoint without having to do any refactoring of the core RPG business logic.
- Flexibility: With GraphQL, it is quite easy to write a query to fetch data without having to interact with the backend teams to make changes to the endpoint, thereby reducing the friction between the legacy and newer code bases.
Key Takeaways
- You can leverage IBM i as your business intelligence/data processing engine of choice.
- IBM i can continue to grow through augmenting its capabilities and APIs.
- Use API-driven integration from IBM i systems to access data sources that utilize REST or GraphQL
- AI integrates with IBM i by using REST for operational integrations, GraphQL for flexible data query, and IBM i as the authoritative source of truth.
- The IBM i architecture can evolve not by abandoning the past, but through intelligent exposure of its capabilities.
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online