Exploring GraphQL and REST for SAP Developers

Marwah_Shwaiki

I came across GraphQL while working on a side project and as a SAP Developer who worked a lot with REST APIs, I was wondering what advantages GraphQL could offer me, and how to apply it for different use cases. So, I decided to explore both APIs and how to use them in the SAP context. Here is a brief overview of my thoughts about both APIs.

Introduction

let's start with a brief definition of the APIs concept, APIs are the lifeblood of modern software development, bridging the gap between different systems. They define rules for accessing functionality and data remotely. Let's delve into API concepts and see how GraphQL and REST fit into the SAP world.

Over the past decade, REST has been the go-to for web APIs, but it's not without its flaws. Enter GraphQL, developed to tackle the shortcomings of REST and provide more flexibility and efficiency for developers.

Understanding APIs: APIs act as intermediaries facilitating communication between software applications. They come in two main flavors: SOAP, known for its strict standards, and REST, favored for its simplicity and scalability.

GraphQL: GraphQL, developed by Facebook, offers a more powerful alternative to REST. It allows clients to request specific data, reducing over-fetching issues common in REST APIs.

REST: REST, an architectural style for building networked applications, relies on stateless, client-server communication via HTTP.

Key Differences

Data Fetching: GraphQL enables precise data fetching with a single request, unlike REST which may lead to over-fetching or under-fetching.
Endpoint Complexity: REST APIs often require multiple endpoints, while GraphQL offers a single endpoint handling various data requests.
Versioning: REST commonly relies on versioning, unlike GraphQL which allows backward-compatible changes without versioning.
Caching: REST APIs leverage HTTP caching mechanisms, while GraphQL responses typically require additional configuration for caching.

Similarities

Both GraphQL and REST facilitate data exchange between services or applications, following a client-server model.

Architecture

Both are stateless and use a client-server model based on HTTP.

Resource-based Design

Both REST and GraphQL design data interchange around resources, each with its unique identifier and set of operations.

Data Exchange

Both support JSON as the primary data exchange format and caching for improved performance.

When to Use What?

Use REST When:

You need a straightforward and widely adopted solution.
Your data requirements are consistent and well-defined.
Caching is crucial for your application's performance.
You're working with legacy systems that are compatible with REST.

Use GraphQL When:

Your data requirements are dynamic and vary across different clients.
Over-fetching or under-fetching of data is a concern.
You want to reduce the number of API calls and improve efficiency.
You're developing a new application or service and want flexibility in data retrieval.

Conclusion

GraphQL and REST are vital for integration and data exchange in the SAP ecosystem. While REST is popular for its simplicity, GraphQL's flexibility is gaining traction. Understanding their nuances empowers SAP developers to design effective APIs for their solutions.

RalfHandl

Actually OData has all of the cited benefits of GraphQL, for example

avoid overfetching with $select, $filter, $top, and $skip
avoid underfetching with $expand and retrieve related resources with one request
flexibility of data retrieval with the above mentioned query options

Plus it has really nice tool support with CAP for Java and JavaScript/Typescript and RAP for ABAP, and it plays really well with UI5 and Fiori Elements.

For SAP developers OData is the optimal choice. And yes, I am biased 🙂

Marwah_Shwaiki

I agree that OData Service is offering indeed many advantages but it's also worth considering the role of GraphQL in SAP development. from my perspective and for specific scenarios, GraphQL can offer more flexibility and efficiency in fetching data, especially in scenarios where clients require specific data sets tailored to their needs. For example, consider a scenario where a Fiori application needs to retrieve information about customers and their orders from an SAP backend. OData may require multiple requests for data, which can cause over or under-fetching. GraphQL streamlines data retrieval with a single query, reducing unnecessary data transfer.

query {
  customer(id: "123") {
    id
    name
    email
    orders {
      id
      date
      totalAmount
      status
    }
  }
}

In this example, the GraphQL query explicitly requests customer details (id, name, email) and their orders (id, date, totalAmount, status) in a single request. This reduces network overhead and improves the efficiency of data retrieval, especially in scenarios where only specific subsets of data are required.

RalfHandl

consider a scenario where a Fiori application needs to retrieve information about customers and their orders from an SAP backend

There are several variations on this scenario:

1. SAP already offers an OData API that contains both Customer and Order entities. In this case the client simply sends (without the line break for readability)

GET /customer/123?$select=id,name,email
                 &$expand=orders(
                   $select=id,date,totalAmount,status
                  )

You may notice the structural similarity between the GraphQL query and the OData request - same basic idea, different syntax. And you get exactly the same data back, with only minor variations in the "JSON packaging".

2. SAP offers two separate OData APIs, one for Customer, one for Order.

This variant has several sub-variants:

2a: both Customer and Order reside in S/4HANA: simply build a custom OData service with RAP or key-user tools containing both business objects, and you are back to 1.

2b: Customer and Order reside in different SAP systems: use SAP Graph and build an OData service combining the two entities in a single OData API, and send the same request as in 1. to SAP Graph. Graph will then combine the data from the two SAP systems and make them look as one to the client application, same as what you would do with an off-the-shelf GraphQL proxy.

Building such a combined API with SAP Graph is mostly a point-and-click experience, and we are continuously working on making the configuration experience more smoothly.

What do you get from using SAP Graph? It's an OData API, and the scenario is to build a Fiori app, which is really easy with SAP tools on top of an OData API.

If you prefer to take the rougher road and build a Fiori app on top of a GraphQL API, you still can use SAP Graph as your federation layer because each API is by default served as OData and as GraphQL. After all the two protocols are quite similar to each other, mostly because they solve the same set of problems.

Marwah_Shwaiki

for Ui5 development, REST API might be a better option than GraphQL, however, if we can consider using GraphQL for real-time data aggregation for SAP HANA Extended Application Services (XS), SAP Cloud Platform, or even SAP Business Technology Platform (BTP) GraphQL might be a good alternative my main goal is to highlight the possibilities and advantages to using different APIs with SAP solutions 🤗

RalfHandl

my main goal is to highlight the possibilities and advantages to using different APIs with SAP solutions

Got it, and I like your blog 🙂

My point is that despite GraphQL's appeal, adding it to your stack isn't for free. You need a "middleware" that provides the GraphQL endpoint and delegates calls to the underlying REST/OData/... APIs, which you need to configure, deploy, and operate, adding to your TCD and TCO.