Tag: REST

  • Why GraphQL is a Better Choice for Building Microservices

    Why GraphQL is a Better Choice for Building Microservices

    There’s been a long debate about whether it’s better to use REST or GraphQL for building microservices. Both technologies have their proponents and critics, but when it comes to the specific needs of microservices architectures, GraphQL emerges as the clear front-runner. Here’s why.

    Understanding the RESTful Concerns

    While REST has been the go-to API style for many years, lauded for its simplicity and general applicability, its limitations become glaringly apparent in the context of microservices. These limitations include:

    • Over-fetching of data
    • Multiple HTTP requests for related data
    • Complex versioning strategies

    Such issues can impede microservices architectures’ performance and scalability.

    Over-fetching of data: REST APIs are designed to return a fixed set of data, which often results in over-fetching. This redundancy is particularly problematic in mobile networks, where every extra byte of data can lead to slower applications and degraded user experiences.

    For example, imagine we have a REST API endpoint /api/user/{userId}, which returns the following data for a user:


    In scenarios where mobile apps only require specific user details like name and email for a profile overview, fetching comprehensive user data means over-fetching.

    This excess data usage can be costly for users with limited data plans and result in slower app performance and degradation of user experience.

    Latency and the N+1 problem: Microservices often require data spread across multiple services.

    Suppose you have an ecommerce application where the order domain handles product, customer, order and return entities, and the stock domain manages product, stock, warehouse and delivery entities. A common operation might be to display order details along with the current stock status for each product.

    Let’s say we have an order microservice and a stock microservice to handle orders and stocks.

    In our scenario, a customer places three orders (N=3) and each order contains four different products. To display the order details with the stock status for each product, the application initially makes one request to fetch the orders. Then, for each product in each order, it makes additional requests to the stock microservice to retrieve stock information. This results in one initial request, plus 12 subsequent requests (three orders times four products per order), summing up to 13 API calls. This multiplicative increase in requests leads to higher latency due to multiple round-trip times (RTT) and increased load on the network and servers, embodying the N+1 problem.

    Versioning challenges: Maintaining REST APIs over time involves complex versioning strategies, such as introducing new endpoints or embedding version numbers in the API path. This can lead to bloat and confusion, complicating API development and consumption.

    The GraphQL Advantage

    GraphQL addresses many REST weaknesses.

    Domain-Driven Design: Microservices thrive on a domain-driven design, where each service is built around a specific business capability. GraphQL’s schema-centric approach aligns perfectly with this, enabling a more organized and coherent structure for microservices.

    Unified schema: In a microservices architecture, each service may have its schema, representing a portion of the business domain. GraphQL stands out by allowing these schemas to be combined or stitched together, presenting a unified interface to clients. This means that clients can query data from multiple services in a single request, drastically reducing the complexity and number of network calls.

    Solving the N+1 problem: GraphQL’s ability to fetch data with a single request, regardless of how many underlying services need to be called, directly addresses the N+1 problem inherent in REST architectures. This not only improves performance but also simplifies client-side data fetching logic.

    For the N + 1 problem described earlier, if the services support GraphQL, it can be used to fetch nested data in a single query, effectively solving the N+1 problem.

    Efficiency and performance: By allowing clients to specify exactly what data they need, GraphQL eliminates over-fetching and under-fetching issues common in REST APIs. This leads to more efficient data retrieval, reduced bandwidth usage, and faster applications, particularly noticeable in mobile environments.

    In the earlier scenario where mobile apps only require specific user details like name and email for a profile overview, clients can request name and email alone.

    Simplified versioning: Unlike REST, GraphQL reduces the need for versioning by allowing new fields and types to be added to the schema without impacting existing queries. This forward compatibility means that clients and servers can evolve more smoothly over time. GraphQL stands today as a mature technology that addresses specific needs in modern web development that are not fully met by traditional REST APIs. Its design promotes efficiency, flexibility, and developer productivity.

    Looking ahead, the future of GraphQL is bright, with community-driven efforts focused on addressing its current limitations, particularly around security, performance and standardization. As these efforts bear fruit, GraphQL’s adoption is expected to widen, consolidating its position as a key technology in the API landscape.

  • The API Economy: Increasing Potential to Monetize Public APIs

    The API Economy: Increasing Potential to Monetize Public APIs

    API-first strategies are becoming more commonplace throughout today’s digital strata. APIs connect microservices architectures, power new digital transformations and help development teams avoid reinventing the wheel for common functions. And although most are built to connect internal components, studies indicate a movement toward more externalization and monetization of public APIs.

    Over three-fourths of developers now view participating in the API economy as a priority for their organization or plan to prioritize it soon, found Rapid’s newly released 2022 State of APIs report. The survey, which surveyed hundreds of professional developers, also uncovered a modest increase in companies seeking to generate direct revenue from APIs.

    Below, we’ll review some intriguing statistics from the Rapid report and consider the major takeaways technology professionals should consider in the year ahead.

    API Reliance Increases

    Reliance on APIs is rising across the board. Over 62.6% of developers reported relying on them more in 2022 than in 2021. Internal APIs help avoid development duplication and third-party APIs can quickly integrate standard functionality related to payments, messaging, geolocation, data sharing and many more areas. For example, ChatGPT has demonstrated the power of standard APIs to deliver advanced AI/ML to the masses in a programmatic way.

    As a result of this interest, the majority of organizations now consider participating in the API economy as a top priority. And as an organization grows larger, its reliance on APIs is likely to increase. A full 40% of the largest companies surveyed reported having more than 250 internal APIs. Nowhere is this more prevalent than in financial services. This finding makes sense, given how APIs can automate payments and underpin the open banking movement.

    In terms of who is using APIs, it’s most commonly full-stack or backend developers, the report found. One intriguing factoid is just how much of this work is now dominating developers’ time. Impressively, 65.5% of developers reported spending ten hours or more working with APIs in their job; 14.5% of them said that work takes up all of their time.

    In terms of design styles, various standards are used throughout the web development sphere. Yet REST is still king—69.3% of engineers used REST in production. REST is followed by webhooks, WebSockets, AsyncAPI, serverless and FaaS, SOAP, GraphQL, Kafka and gRPC, in descending order of popularity. Across the board, these statistics showed a steady increase from last year.

    Of note is that most APIs are built for internal purposes. These often wrap a database or provide open access to an internal microservice. Private use cases are by far the most common approach; according to the report, 75.1% of respondents worked on internal APIs. These findings aligned with other industry reports, such as the Postman State of the API Report, which found that, in 2022, 58% of API initiatives were private.

    Third-party APIs (53.9%) and partner-facing services (48.9%) trailed behind internal APIs in popularity. Interestingly, while internal use cases have remained steady, both partner and public-facing strategies have increased since last year. While the growth was a modest 5% for most sectors, partner-facing APIs in some industries grew by nearly 10%.

    Spotlight on Monetization

    Many still view APIs as operational glue for internal data or connecting partner services. Yet, the possibility of monetization through self-service developer portals shouldn’t be overlooked—countless API-first startups are actively gaining traction and funding. And monetizing this power is seen as a holy grail to some unicorn-chasing VC funds.

    Most APIs are purely for in-house internal integrations and are typically not externalized to the outside world for profit. However, this is slowly changing. In fact, 42.6% of organizations are now monetizing APIs, representing an increase of about 5% from 2021.

    As one may have guessed, financial services are leaders in monetizing their external APIs. The telecommunications industry is also noticeably active in monetization, too. Furthermore, with size comes increased monetization potential—about half of the companies with a large footprint of ten or more internal or external APIs also monetized them.

    API Economy in 2023

    Looking to the future, most anticipate more reliance on APIs across sectors — 69.2% expect to rely on APIs even more in 2023. Yet, organizations will have to grapple with particular hurdles in this newfound landscape. For example, a cloud skills gap might bar some groups from realizing the benefits of an API strategy. Other concerns include ungoverned sprawl, authorization concerns, shadow APIs and escalating attacks on public-facing endpoints. Also, some organizations are still determining how to best secure and scale their use of new styles, like GraphQL.

    A standards-based approach that applies platform-wide governance will likely be necessary to maintain an efficient yet stable API footprint. To meet these high quality standards, testing is nearly universally applied—92.7% of those surveyed test their APIs or plan to do so. The most common tests ranged from functional testing to integration testing, acceptance testing and performance testing.

    The Rapid 2022 State of APIs report received 850 responses from over 100 countries. For more insights, readers can view the complete results here.

  • Best of 2021 – The Torture Never Stops

    Best of 2021 – The Torture Never Stops

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the nineteenth in our series of the Best of 2021.

  • OpenLegacy Partners With Compuware to Advance DevOps on Mainframes

    OpenLegacy Partners With Compuware to Advance DevOps on Mainframes

    OpenLegacy has allied with Compuware to make it easier to build and debug microservices-based applications employing REST application programming interfaces (APIs) to access data residing on mainframes.

    Zeev Avidan, chief product officer for OpenLegacy, said the company’s namesake platform analyzes mainframe environments to create microservices-based APIs written in Java without requiring any changes to the legacy environment. That approach not only minimizes disruption to the mainframe environment, but it also eliminates the need to rely on enterprise service bus (ESB) platforms and legacy web services interfaces to access mainframe data, he said.

    The alliance with Compuware now makes it easier access the OpenLegacy platform from within Topaz Workbench, a set of tools from Compuware that are used to apply DevOps practices to applications that either run on a mainframe or need to access data residing on a mainframe.

    Avidan said it is becoming increasingly common for organizations to want to build and deploy applications that need to access mainframe data as part of various digital business transformation initiatives. The challenge they face is that most legacy monolithic applications running on a mainframe don’t have an API to invoke. OpenLegacy provides a framework for generating those APIs, which in turn makes it easier to incorporate mainframes within the context of a larger DevOps process. The alliance with Compuware furthers an ongoing effort by the two companies to foster the adoption of best DevOps processes in mainframe environments, he said.

    Legacy waterfall-based application development processes are still relevant in mainframe environments, he added, but it’s also clear organizations want to apply DevOps processes to applications spanning hybrid environments that include mainframes. The majority of data in many enterprise IT environments is created on a mainframe. Rather than being forced to copy that data, API platforms such as OpenLegacy make that data more accessible where it resides. Once the APIs are in place, it becomes practical for DevOps teams to create software development kits (SDKs) to access various applications running on mainframes, Avidan said.

    Organizations that have invested in mainframes generally are interested in agile development methodologies that enable them to derive more value from those investments. The challenge they face is finding a way to make that data available in a way that doesn’t disrupt the mission-critical applications running on the mainframe, he said. Over time, IT organizations running mainframes will adapt their processes to incorporate best DevOps practices, but the level of disruption they can embrace in pursuit of that goal has to be minimized, Avidan noted, adding it would be unreasonable to expect that level of cultural change to occur overnight.

    Despite ongoing predictions about the eventual demise of the mainframe, the number of workloads running on the venerable platform continues to increase, thanks in part to the ability to run Linux on a mainframe. What many organizations that opt to run Linux on a mainframe don’t always initially appreciate is the degree to which that decision also opens the door to transforming their internal IT culture, regardless of whether they are ready.

    — Mike Vizard