devopsy.kinsta.cloud

Tag: GraphQL

  • GraphQL as a Meta Layer

    GraphQL as a Meta Layer

    There’s a lot of interest in GraphQL lately. The query language is excellent for data retrieval, and it could act as a more usable mechanism to evolve the traditional REST API integration approach. But as adoption grows steadily, architects are now considering the implications of managing GraphQL at scale.

    Certain issues may hinder GraphQL in practice. To review, security concerns require a nuanced approach to authorization. This is because it wraps multiple data retrieval points into a single request. Without native caching, performance could also suffer. Changeability is also required to continually update the graph, which may ruffle feathers with those seasoned in the world of REST where a guiding tenet is to build for longevity using web-compliant methods.

    According to Jens Neuse, CTO, WunderGraph, there is a simple way to mitigate most of these issues and harmoniously work with various API styles. To Neuse, the core problem is that GraphQL is not meant to be exposed over the internet. Instead, he advocates for interacting through a gateway. Such an intermediary would enable more implicit calls and proper authentication and authorization for specific underlying functions and resources. Using GraphQL as an internal integration layer could also help combine disparate APIs into a similar language, exposing GraphQL-like usability for frontend developers while allowing them to hit any API style on the backend.

    Below, we’ll consider the drawbacks of exposing GraphQL directly and see how an intermediary layer could benefit development. We’ll also uncover what open source software is on the horizon that could power this setup.

    Why GraphQL Shouldn’t be Exposed Publicly

    Facebook, the creator of GraphQL, uses an internal GraphQL API to power all of its apps across Android, iOS and web browsers. (This is not to be confused with their public Graph API). Interestingly, if we look at Facebook’s use of GraphQL, we see these endpoints are not exposed to the public web at all.

    It’s true. Open up Developer Tools in Chrome, and you’ll see there is not a single mention of a root HTTP endpoint like https://api.graphql/. Functions name GraphQL, sure, but they call it more implicitly. Other companies, like Twitter and Airbnb, use a similar abstracted approach to interact with a private GraphQL.

    In fact, most GraphQL APIs are not public. APIs.guru only charts 35 public GraphQL APIs—notable services include GitHub’s GraphQL API, Shopify Storefront and GitLab. This number is minuscule compared to the total number of public APIs, at over 24,000 according to ProgrammableWeb.

    A Layer In Between

    If we treat it as Facebook intended (and how they use it in production today), it could reverse the issues above, said Neuse. “These problems come down to our core belief that GraphQL is not supposed to be exposed over the internet,” he said.

    But if clients do not access a GraphQL endpoint, what are they interacting with? According to Neuse, the ideal architecture involves a layer between the client and the server. Such a layer would validate queries and represent verbose calls with simple functions. The process would involve a handshake as follows:

    1. Take query, store it on a server.
    2. Validate it; make sure it’s not malicious.
    3. Send back a handle to the client.
    4. Then, execute the query.

    Such a process could also enact universal policies on a per-function basis, thus solving potential authorization issues when fetching data from multiple backend services with a single query.

    “The issue is that using the query language comes with a cost,” Neuse said. “Not exposing GraphQL directly but ‘compiling’ it to a JSON-RPC API when deploying solves these problems.”

    Thus, the scalability issue isn’t so much an issue of size but of access. “GraphQL can be very valuable, even in small environments,” said Neuse.

    The Next Evolution of a Virtual Graph

    Another potential benefit of using GraphQL as an intermediary is combining APIs; a “virtual graph,” as Neuse calls it. This virtual graph offers a common integration language to interact with various API styles, whether REST, GraphQL, gRPC or webhook, in a GraphQL-like manner.

    Consider the ease with which package managers like npm enable developers to instantly install dependencies. For example, installing a package like React.js is as simple as initiating the command npm install react within Terminal.

    On the other hand, the API integration is very cumbersome. Users must read through documentation, create an account on a third-party site and download an SDK to call the service in their preferred language. So, why isn’t looping in dependencies like APIs and cloud services as simple as other common dependencies?

    According to Neuse, one reason is that the REST paradigm is obsessed with the resource constraint—aside from HATEOAS, it lacks a concept of relationships between data and fields. A virtual graph could enable a straightforward process similar to package managers, said Neuse. Interestingly, the WunderGraph team plans to open source a project that allows just that ability.

    GraphQL as a Meta Layer

    Many folks assume that GraphQL and REST are mutually exclusive. However, as we’ve seen, there are ways to use them in combination. Plus, with an abstraction layer, the REST versus GraphQL comparison becomes just an underlying technical nuance.

    “If you compare GraphQL to other specifications, like OpenAPI spec, you see GraphQL has the fastest-growing community,” said Neuse. As of 2021, JSON Schema is the most popular, used by 75% of developers, followed by Swagger 2.0 (54%), OpenAPI 3.0 (40%) and GraphQL (31%) according to the Postman State of API Report. While this number may be small now, 35% of respondents also said they plan to use GraphQL in the coming year.

    “It’s a very, very interesting movement,” said Neuse. What began at Facebook as a framework for data fetching for React apps has now expanded into something much bigger. Within this second new movement, largely driven by companies like Apollo and Hasura, GraphQL becomes the new data layer, he said.

    “Still, everybody is looking at GraphQL thinking they must migrate from REST—this is the wrong direction,” said Neuse. Instead of migrating all existing REST APIs to GraphQL, he predicts the industry will coalesce on using GraphQL as the integration language for querying REST APIs. A meta layer, if you will.

    Of course, meta has been a bit co-opted lately with Facebook’s rebranding …

  • Netlify Acquires OneGraph to Integrate GraphQL APIs

    Netlify Acquires OneGraph to Integrate GraphQL APIs

    Netlify this week announced it has acquired OneGraph, a provider of a platform that simplifies the integration and management of application programming interfaces (APIs) based on the GraphQL query language.

    At the same time, the company is committing $1 million to sponsor open source projects and setting aside $10 million for a Netlify Jamstack Innovation Fund that will help drive the development of emerging technologies. Those technologies will be consumed via the platform the company created based on Javascript, APIs and a markup language (referred to as Jamstack) to accelerate web application and website development. Rather than becoming investors in those companies, Netlify intends to make those funds available to advance the development of technologies that benefit the overall community.

    Fresh from raising an additional $105 million in funding, Netlify CEO Matt Biilmann said Netlify is committed to an ecosystem through which developers will be able to consume a wider range of services via both REST and GraphQL-based APIs. OneGraph will provide the core foundation for adding support for GraphQL to the Netlify platform, he noted.

    Overall, Netlify is trying to reduce the friction that developers encounter building web applications and the sites they run on, added Biilmann. That’s becoming especially critical as developers increasingly build microservices-based applications that invoke APIs to consume backend services that are made available via the Netlify platform, he added.

    Earlier this year, the company made available Netlify Build Plugins that provide DevOps teams with a set of continuous integration/continuous delivery (CI/CD) workflows for building websites and web applications. Designed to be launched from within a Netlify platform, those plugin makes it possible to build a web application or website that can be launched directly from within a Git repository.

    The overall Jamstack philosophy enables DevOps teams to separate the development of frontends and backends of websites and applications. That approach is agnostic as far as any specific JavaScript framework is concerned, but it does define a way to automate the build process for a web application or website.

    A recent survey of more than 3,000 Jamstack developers published by Netlify finds one-third of survey respondents have worked on sites serving millions of users over the last year. Nearly two-thirds of survey respondents (62%) work outside the tech industry, including in advertising and marketing (21%), media and publishing (14%), education (14%), financial services (13%) and business support and logistics (13%). Well over a third (38%) work for a technology company. About a quarter (26%) have more than 10 years of experience. Top Jamstack benefits cited by all types of developers are performance, uptime, speed of development, security, compliance and avoiding vendor lock-in, the survey found.

    Jamstack is, of course, not the only framework for building web applications and the sites they run on. DevOps teams are increasingly being tasked with building a much wider range of external applications to drive digital transformation initiatives that are typically built using some type of JavaScript framework. The next big DevOps challenge, of course, is that as the number of applications being built continues to increase, so does the number of applications that need to be maintained and continuously updated.

  • Managing GraphQL at Scale

    Managing GraphQL at Scale

    GraphQL, the query language invented by Facebook, has attracted a lot of interest as a means to conveniently access data programmatically. GraphQL structures internal services with a unified schema for data, empowering product engineers to easily grab what they want from many microservices to populate the user interfaces (UIs) they’re creating. By unifying company data into a single graph, GraphQL combines the benefits of SQL with the ubiquity of API access.

    However, GraphQL does introduce some challenges when you’re trying to scale it across a large enterprise and partner ecosystem. For example, since GraphQL channels all requests through a single endpoint, security must carefully segment access to all the underlying infrastructure to avoid data overexposure. Matt DeBergalis, Apollo’s co-founder and CTO, also identified potential issues around changeability and performance when adopting a graph at scale.

    As the use of GraphQL within large organizations grows, development teams will have to overcome these obstacles—especially if companies intend to productize public APIs and reuse the same single graph company-wide. I recently met with DeBergalis for an update on managing GraphQL at scale. According to DeBergalis, we’re still in the early days of the graph revolution. And, future GraphQL maturity will require more rules-based declarative architecture, efficiency improvements and the adaptability to enact agile iteration of graph schemas.

    State of GraphQL Adoption

    So, what is driving the rise of GraphQL? Well, DeBergalis noted three key contributing factors:

    1. Many many microservices. In recent years, there has been an explosion of microservices. These modular services can be challenging to wrangle and are often exposed inconsistently throughout a software ecosystem.
    2. The rise of omnichannel platforms. Product engineers must now port the same data across disparate devices, whether streaming in a browser or on a Peloton screen.
    3. Users expect a hefty, data-rich experience. Expectations are at an all-time high. It’s now expected that an e-commerce shop, for example, will include product recommendations, auto-fill keyword search, pricing by geography and many more advanced features.

    Juggling all these factors creates a “complexity bottleneck,” DeBergalis explained.

    GraphQL responds to such complexity, helping unify the backend to enable product developers to fetch precisely what their client applications require. And, GraphQL adoption took off pretty quickly, particularly among product engineering teams, DeBergalis added. GaphQL plays nicely with familiar languages and frameworks like JavaScript, React and Relay. It’s also a bit different than previous trends, with demand being driven more by the database folks; “query people are really leading the charge,” he said.

    With the right technology stack, developers can add a graph layer between the underlying core APIs and the UI they are building, creating a universal API with a self-documenting schema. “For the developer, the amazing thing about GraphQL is throwing away all this boiler code,” DeBargalis said. GraphQL acts as “a foundation for tomorrow” to help deliver future business requirements, he said.

    With regard to architectural styles for APIs, 94% still use REST and 31% use GraphQL, according to the 2021 State of API Report from Postman. Though this percentage may seem small now, GraphQL adoption is steadily growing among large companies, such as PayPal, Netflix, Shopify, GitHub and Airbnb.

    Three Issues When Scaling GraphQL

    Using GraphQL is like using a mobile phone. You wouldn’t want to use a different phone every time you called a different number, would you? You would rather have all your contacts accessible from the same device. Similarly, GraphQL excels the more functionality is added.

    “Due to the network effect, a graph becomes more interesting as we publish more into it,” said DeBergalis. “What we have found is that GraphQL is most interesting and valuable at scale.” So, what are some inevitable consequences of GraphQL at scale? DeBergalis outlines three main architectural issues.

    Performance

    Performance downsides are one disadvantage that developers often cite when considering GraphQL. GraphQL has no built-in caching features, and the payload query could introduce additional latencies. Mitigating lower-level issues around throughput and reliability will likely require additional tooling from the community, DeBargalis said. This is partially why the Apollo team has begun to embrace Rust in new attempts to make infrastructure for GraphQL routing hyperefficient.

    Changeability

    A second problem enterprises may encounter when scaling GraphQL is embracing agility for such an all-encompassing fabric. “The companies that do GraphQL really well change it all the time—they treat it like a product,” said DeBergalis. This agility is at odds with the traditional REST API approach of building for longevity, which makes that approach extremely averse to breaking change.

    The reality is that when a company embraces a single graph, it may be pushing hundreds of schema changes every day. Different internal teams may maintain their own slice of the graph, defining it differently. Plus, maintenance roles may shift from team to team over time, noted DeBergalis. “If you try to waterfall what your inventory model should look like, you won’t get anywhere,” he said.

    Balancing change and stability will likely require a two-pronged approach to GraphQL. You want to continually iterate the graph with experimental features but also depend on certain functionality to preserve backward compatibility for client integrations. Satisfying both sides will likely require a change management strategy for iterating quickly, as well as enterprise-grade service level agreements (SLAs) to retain a firm bedrock on which to build more permanent data models.

    DeBergalis also described how observability is important for obtaining a clear picture of graph environments. This is one area where GraphQL shines—since clients request precisely what they need, you are never left wondering which methods are fetched but not implemented in production, as could happen with REST API management. According to DeBargalis, tracking fine-grained GraphQL usage with KPIs can help direct how the data model should evolve over time.

    Authorization

    Finally, perhaps the most significant concern surrounding GraphQL at scale is apportioning the appropriate access to users and devices. As a single unified endpoint can connect to a vast array of data behind the scenes, large GraphQL implementations will require a strategy for how that one unified graph can be implemented in parts.

    Without the proper access control, GraphQL could improperly expose personally identifiable information (PII). For example, a FinTech company may have a rule that requires a customer service representative to only have visibility into a customer’s transaction history if the customer has filed a support ticket in the last few days. Or consider data custody—a business working in the EU must comply with regulations on where data can and can’t live.

    Safeguarding GraphQL will require a declarative setting that integrates authorization control and context into GraphQL queries. To implement this, DeBergalis advocated for a command-and-control style. First, you build the schema around the data and problem statement. Next, you integrate rules field-by-field, marking sensitive touchpoints as PII.

    With rules baked into the query, you can have a more solid understanding of the surrounding context. “Authorization is actually a lot better at graph level,” said DeBergalis. “It’s the layer that has semantic understanding.”

    Future of GraphQL Scalability

    “Once you have a graph, you want to use it for everything,” said DeBergalis. The heritage of GraphQL is JavaScript, the language of the product world. And, the graph approach delivers an excellent experience for product engineers. The sheer usability and productivity benefits of GraphQL indicate incredible potential for projected use in the years to come.

    As we’ve discussed, scaling GraphQL across an enterprise will likely require performance improvements, a path for schema adaptability, policies to handle authorization for queries and greater accountability for business metrics. While GraphQL certainly has existing momentum among a subgroup of engineers, there are plenty of opportunities to introduce more training and educational curriculum to spread greater awareness.

    Furthermore, for those coming from a traditional REST API mindset, GraphQL is a bit of a new paradigm that will require some massaging to expose graph endpoints as a productized API. Doing so will likely involve marking select parts of the larger graph to expose to partners. “Starting with an internal GraphQL use case works really well, but productization around GraphQL is coming,” said DeBergalis.

    The value of a unified graph is so strong, and the bottom-up hunger for a graph environment is so intense that increased GraphQL adoption feels like a given. “At this stage, the focus is on expansion,” said DeBergalis. “How do we roll this out to more teams?”

    “We know there’s going to be a graph in every company—not a lot of little ones,” said DeBergalis. “Every company’s going to need a graph.” When that day comes, the architectural challenge will be breaking apart the graph into pieces. “That’s the next big frontier.”

  • GraphQL’s Greatest Strength is Also its Greatest Weakness

    GraphQL’s Greatest Strength is Also its Greatest Weakness

    Michael Scott: Why don’t I tell you what my greatest weaknesses are? I work too hard, I care too much and sometimes I can be too invested in my job.
    David Wallace: Okay. And your strengths?
    Michael Scott: Well, my weaknesses are actually strengths.
    David Wallace: Oh. Yes. Very good.

    GraphQL is a new query language that offers a simple way to interact with structured data. The best thing about GraphQL’s design is its convenient data fetching process which enables the requesting party to collect limitless data and perform multiple actions, all with a single API call. This interaction method makes it super useful and very easy to use. However, from a security perspective, its greatest strength could also be its greatest weakness.

    I recently met with Elad Koren, chief product officer, Salt Security, to understand the nuances of GraphQL security. According to Koren, GraphQL affords better usability than REST APIs, yet its bundled request model may compromise systems that don’t employ proper object-level authorization checks. Also, since developers interact with GraphQL services differently than typical web APIs, hackers could avoid detection by typical firewalls, requiring a new approach to security.

    These concerns aren’t dealbreakers for adoption; rather they are a reality check for those using GraphQL in production. Below, we’ll explore some potential weaknesses and look at some general mitigations that providers can take to improve the confidentiality of their GraphQL endpoints.

    What is GraphQL?

    GraphQL was initially developed by Facebook and open sourced in 2015. It’s a query language that makes data retrieval and manipulation with external sources very easy. Instead of programming and linking together complex calls with traditional HTTP API requests, GraphQL enables a client to bundle queries into a single request. This design pattern reduces the under- and over-fetching pattern that REST APIs typically suffer from.

    “You get exactly what you need, not more or less,” described Koren. This makes GraphQL a popular choice for modern database mechanics over REST, as it’s similar to SQL querying.

    Adoption of GraphQL is steadily growing; a 2020 RapidAPI survey found GraphQL usage had quadrupled. GraphQL is now used by 22.5% of API developers. But when it comes to overall API design patterns, REST is still the dominant architectural style used by 93.4% of APIs, found Postman’s 2020 State of API Report.

    GraphQL is promising and has a number of benefits, but remains in an early adoption phase. “It’s still a technology that early adopters are starting to look into—it’s not so widespread,” said Koren. Due to its age, GraphQL security practices are immature, exposing a few potential vulnerabilities for platforms that use GraphQL.

    Unique Security Concerns

    So, what are some unique security concerns in the GraphQL paradigm? Well, according to Koren, it begins with a lack of understanding. “Security is not necessarily top-of-mind most of the time,” he said. “When developers choose to implement GraphQL, they assume that they’re not using APIs anymore and that traditional REST API vulnerabilities do not apply.”

    In fact, the opposite may be true. GraphQL APIs can easily suffer from broken object-level authorization, OWASP’s number-one API vulnerability, just as REST APIs do. But, with greater ease of access to many underlying systems, a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could suffer from data overexposure.

    Another issue concerns spotting malicious behavior. Typically, when hackers perform reconnaissance on an API, they brute-force it with many requests; trying different namespaces and changing user agents in the process. With REST APIs, this sort of malicious behavior is easier to catch with standard web application firewalls (WAFs) since it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a hacker conducting query batching could completely fly under the radar of typical thresholds.

    This could easily lead to an account takeover, said Koren, who has seen this in production. He described a production payment service that used GraphQL; callers could perform mutations and capabilities they shouldn’t have been allowed to perform, such as pulling up other users’ account information and even initiating transactions.

    It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks once at a time. But, this playbook is thrown out the door in GraphQL. “When you’re using a single point to access the data, you may have some false sense of security,” said Koren. In practice, having a single access point requires hard work to retain its integrity. A usable GraphQL frontend may also often mask a convoluted backend made of disparate API styles, Koren explained, making it much harder to correlate user authorizations to specific resources and mutations across various microservices.

    Tips to Mitigate Weaknesses

    So, with these weaknesses in mind, how should GraphQL-based platforms respond? Koren provided the following advice to protect GraphQL APIs:

    • Adopt a security mindset in development: It’s vital to start with a security culture from the beginning. Usability shouldn’t compromise security; ideally, they should complement each other.
    • Ensure proper authorization checks are in place: Whenever an asset is provided to the user, you need to consider whether the user is authorized to access it—especially if they are hitting multiple resources at once.
    • Set a new baseline specific to GraphQL: GraphQL owners need to adapt their perimeter security systems to look for new queues. These validations should consider typical REST API security checks and nuanced thresholds that consider nested queries and batch queries.
    • Know your API inventory: Maintain a clear picture of the underlying architecture of what is beneath the GraphQL endpoint. Verify the data sources and ensure they correctly correspond to user privileges.
    • Increase visibility into API calls: If possible, increase your visibility into queries, mutations, attributes, variables and underlying specifications and how they interact with each other.

    Strengthening GraphQL Endpoints

    API attacks are rapidly increasing. Gartner estimates APIs will become a top threat vector in 2022, and Salt Labs data showcased a shocking 300% growth in malicious API traffic in mid-2021.

    “Like any other innovative tech that comes into the mainstream, it will rise in popularity, but it will not surpass REST in the foreseeable future,” says Koren. Perhaps in three to four years, GraphQL’s current 20% adoption rate will rise to 30% to 50%. While GraphQL is still a relatively niche tool, its use is growing, especially among API-first cloud-native tech companies. And with this adoption will come novel security concerns.

    According to Koren, query batching makes catching malicious attacks using ordinary firewalls tricky. Thus, training a new baseline to discover anomalies unique to GraphQL will be necessary to find and limit hackers while they are still in the reconnaissance phase. Thus, we’ll likely see future security investment go into spotting these atypical GraphQL interactions.

    In general, perhaps the best advice is to treat GraphQL with the same level of intensity you would with any other type of API—if not more. As a single doorway to many underlying systems, GraphQL requires added security forethought and careful application of user authorization.

    With that squared away, hopefully, GraphQL’s greatest strength will remain just that—a great strength.

  • Hasura Extends Scope of GraphQL API Platform

    Hasura Extends Scope of GraphQL API Platform

    During its online an HasuraCon ’21 conference, Hasura today announced that it has made it possible for developers to employ GraphQL application programming interface (APIs) to launch queries against data residing in multiple databases.

    At the same time, Hasura announced a preview of schema sharing capabilities along with support for workflows based on GitOps processes that it will make generally available later this year. The Hasura Cloud platform can now deploy local migrations from staging to production with a simple git push in addition to accessing previews of applications on every pull request to the git repository.

    The schema sharing capability added to the Hasura GraphQL Engine is intended to bridge the gap between beginner and power users by allowing them to share and install samples of permissions, relationships and metadata. In addition to improving collaboration, the goal is to make it easier to onboard software engineers as projects evolve and become more complex.

    Originally developed by Facebook, GraphQL has emerged as a popular alternative to REST APIs because it enables developers to retrieve data at a more granular level, which results in improved performance.

    Hasura is a provider of an instance of a GraphQL engine the company has developed around a project that is now hosted by the GraphQL Foundation, an arm of the Linux Foundation. The GraphQL Foundation counts among its members Airbnb, Amazon Web Services (AWS), Apollo, Coursera, Elementl, Facebook, GitHub, IBM, Intuit Hasura, Paypal, Prisma, Shopify and Twitter.

    GraphQL provides a complete description of the data made available via an API and is organized in terms of types and fields rather than traditional endpoints. In addition to clarifying what data is available via that API, developers can employ types to avoid writing manual parsing code.

    Since last summer, Hasura has been making available a pilot of a GraphQL implementation that is capable of supporting remote joins across disparate databases. That capability is critical because data sets that are related to a specific business process may wind up being stored in multiple databases.

    Hasura

    Tanmai Gopal, Hasura CEO, said the open source Hasura GraphQL Engine has already been downloaded more than 250 million times this year. Downloads in 2020 reached 100 million. The challenge is that while GraphQL offers a superior alternative to REST APIs, most of the API tooling that exists within organizations is still designed around REST APIs, noted Gopal.

    To accommodate that reality, Hasura has made a tool available that will convert a query designed using GraphQL into a set of calls that are compatible with REST APIs. Developers still gain the benefits of being able to launch more granular queries, noted Gopal.

    REST APIs, in general, are becoming more problematic as organizations embrace microservices-based applications. It often takes minutes to refresh a simple dashboard because of the amount of data that REST APIs are trying to pull from various data sources. As organizations embrace digital business transformation, they are also encountering application latency issues that can be traced back to the amount of data being called from multiple microservices.

    Hasura says in addition to providing a more efficient method to access data, Hasura is also working on adding caching capabilities to its core engine to further improve performance.

    It’s not clear at what rate GraphQL might replace REST APIs, but DevOps teams should assume organizations will wind up employing a mix of both for years to come. The challenge is going to be determining when to make the transition as organizations become more dependent on APIs.

  • Hasura Launches Beta of GraphQL-Based Remote Joins Tool

    Hasura Launches Beta of GraphQL-Based Remote Joins Tool

    Hasura today announced the public beta of Remote Joins, which makes use of an open source GraphQL query language for application programming interfaces (API) to join disparate data sources residing in different repositories.

    Company CEO Tanmai Gopal said Remote Joins extends a GraphQL engine the company has developed around a project that is now hosted by the GraphQL Foundation, an arm of the Linux Foundation. The GraphQL Foundation counts among its members Airbnb, Amazon Web Services (AWS), Apollo, Coursera, Elementl, Facebook, GitHub, IBM, Intuit Hasura, Paypal, Prisma, Shopify and Twitter.

    Originally developed by Facebook, GraphQL has emerged as the basis for a more streamlined alternative to REST APIs. GraphQL provides a complete description of the data made available via an API and is organized in terms of types and fields rather than traditional endpoints. In addition to making it more clear what data is available via that API, developers can employ types to avoid writing manual parsing code.

    Hasura is now taking that concept a step further by enabling IT organizations to join data residing in different databases and microservices to enable that data to be queried as if it were a single data source. The core Hasura engine automatically generates the GraphQL engine, which enables those remote joins to be created in a few minutes.

    Gopal said joining data across a complex portfolio of modern applications based on microservices and legacy monolithic applications is becoming increasingly difficult as the number of microservices in an IT environment continues to proliferate. The Hasura engine addresses that issue by providing data access and flow tool base on a GraphQL type system for managing APIs that can be applied to GraphQL APIs as well as REST APIs or other protocols, he said.

    The join, authorization logic and consistency checks are all managed by the Hasura engine. Hasura also provides data change management, observability, auditing, security and performance management capabilities. That approach makes it possible for data sources and APIs to evolve independently while still allowing organizations to query data flexibly, noted Gopal.

    As DevOps and DataOps processes continue to converge, IT organizations will need to find a way to advance application and API development in a way that doesn’t result in data access becoming a major bottleneck. Too many DevOps teams are rapidly building applications and APIs only to find themselves waiting to be given access to data. GraphQL could provide a foundation on which IT teams can manage DevOps and DataOps processes more collaboratively.

    It’s not likely IT teams will be replacing existing REST APIs wholesale overnight. However, it’s also apparent that REST APIs may not enable IT environments to scale as efficiently as GraphQL, which is the primary reason why Facebook developed it. Of course, it’s still early days as far adoption of GraphQL is concerned. However, with more IT teams under pressure to innovate faster, interest in a more streamlined approach to building and managing APIs is likely to gain additional momentum.

  • Serverless and GraphQL: Build and Launch at the Speed of Thought

    Serverless and GraphQL: Build and Launch at the Speed of Thought

    Websites and apps are now, often, one and the same. Traditional development methods for an online or downloadable app can take months, given the backend development aspects that need to be managed—infrastructure provisioning and management, security, scalability, consistency and more, particularly for companies that have users around the globe and potentially very high usage demands.

    In addition, once the app is built, it can take several days to launch and ensure global availability. Once launched, the app can require ongoing maintenance and supervision to ensure availability and performance, as well as constant fine-tuning of the balance between over- and under-provisioning to manage costs.

    Serverless computing, when combined with GraphQL APIs, is the Holy Grail of application development. These technologies make it possible for developers to build and launch apps lightning fast by removing server provisioning and management concerns. Developers need only worry about building a compelling app with usability features that optimize engagement. Additionally, with serverless and GraphQL, an app can essentially be launched to a global user base within hours or even minutes, rather than days, while avoiding the need to manage servers. Let’s take a look.

    What is GraphQL?

    GraphQL is an API standard for building modern, data-driven applications based on the widely known HTTP Protocol. First created by Facebook in 2012, GraphQL was key to the social media giant shifting its mobile app from HTML5 to a native mobile app. Based on its success, Facebook made GraphQL available to the public as an open-source project in 2015.

    With GraphQL, you define an agnostic Domain Specific Language (DSL) around your data structure in terms of:

    • The programming language you use. As an API standard, GraphQL is open for implementations in many languages, such as JavaScript, Java and C#. You can essentially use the standard with your language of choice.
    • The database engine you use. GraphQL is only concerned with having the data ready, rather than the source of the data and where it is coming from, so you have the freedom to implement a GraphQL API with almost all database engines.

    What’s All the Fuss About Serverless?

    Serverless represents a major paradigm shift in the way we create and run web services and apps. Serverless computing operates in the cloud, freeing developers from the burden of thinking about back-end tasks, such as managing infrastructure, scaling servers and provisioning capacity and resources.

    Below, I’ve listed some specific benefits that serverless provides, looking specifically at serverless databases—many of these advantages are part of other serverless offerings as well. The overall impact is that with serverless technologies, developers only pay for what they use, or what the app uses depending on user demand. Developers can scale up to virtually infinite disk space and compute loads in seconds when traffic spikes hit, and scale back down when users go offline. The NoOps aspect of serverless means maintenance costs and burdens are removed. Additionally, global availability zones allow for replication between different locations and allow you to keep data where it’s needed—close to the user to minimize latency. Built-in encryption means developers can secure their apps with only basic security know-how.

    • Consumption-based billing.
    • Auto-scaling.
    • No operations overhead.
    • Global low latency.
    • Secure by default.

    When these benefits are combined with the advantages of GraphQL, one will notice a perfect synergy between the two technologies. Not only does the process become more automatic, the standard facilitates communication between internal teams and makes it easier for clients to integrate with your software, through:

    • API discoverability and automatic documentation.
    • Consolidation of data.
    • Language and data source-agnostic.
    • Type safety.

    Serverless Plus GraphQL Equals Developer Nirvana

    There are numerous examples of companies that have managed to build faster and cut costs with serverless. One of the most impressive demonstrations is when students in Australia managed to rebuild the census application and handle loads that the official $9 million system could not handle, at a fraction of the cost using serverless technology. GraphQL takes these advantages a step further.

    Airbnb, a company already known for its serverless adoption, claims to be moving 10x faster thanks to GraphQL, while Coursera noticed that their frontend developers found it easier to discover and query new data as their API evolves. These benefits are not just limited to a developer’s own company. For example, GitHub clients can now fetch data more efficiently and more easily thanks to the GraphQL-based public-facing API. GraphQL is even competing with SQL—when databases such as FaunaDB offer a native GraphQL API, users move to GraphQL at a rapid rate.

    Given the advantages of serverless in removing server provisioning and maintenance, and the freedom GraphQL gives developers when it comes to using programming languages and database engines, developers are essentially able to build and launch apps on a global scale as quickly as they think of them. And in the end, don’t we all want our customers to have a better experience?

    — Brecht De Rooms

  • Instana Adds Deep Inspection of GraphQL Queries and Performance to Microservice APM Solution

    Company is first APM provider to deliver complete GraphQL system and query details for application performance monitoring

    October 8, 2019, San Jose, CA at API World – Instana, the leading provider of automated application performance management (APM) solutions for dynamic microservice applications, today announced the extension of monitoring and tracing capabilities for applications using GraphQL as part of their infrastructure, including deep inspection of GraphQL queries. This latest extension makes Instana the first APM provider to monitor GraphQL and the applications making use of the unique data query engine.

    “Since application and microservice platform technology continues to evolve, it’s critical for application management solutions to keep pace,” said Chris Engelbert, Developer Advocate at Instana. “By monitoring and tracing GraphQL performance in addition to the application, Instana provides the exact data needed to optimize performance of GraphQL queries.”

    Instana captures the GraphQL HTTP traffic and displays the executing query as plain text. Instana goes further, though, parsing the actual GraphQL queries – making Instana the only APM solution to provide complete comprehensive GraphQL monitoring as part of the automated solution.

    Instana’s automated Application Performance Monitoring (APM) solution discovers all application service components and application infrastructure, including GraphQL, Jenkins, Kubernetes and Docker. Instana automatically deploys monitoring sensors for each part of the application technology stack and traces all application requests – without requiring any human configuration or even application restarts. The solution detects changes in the application environment in real-time, adjusting its own models and visualizing the changes and impacts to performance in seconds.

    “Ultimately, application providers are driven to create the best possible user experience,” said Chris Farrell, Director of Marketing at Instana. “By providing monitoring and deep inspection of more components, Instana’s comprehensive and automated monitoring delivers the precise data application stakeholders need to optimize application performance, especially for platforms such as GraphQL.”

    Instana’s GraphQL monitoring and tracing is part of Instana’s larger dynamic application and infrastructure monitoring that includes support for everything from Java application code to specialty microservice querying platforms. The company will be showcasing their solution, including the new functionality, at API World in San Jose (Booth #207). Learn more at Instana.com

  • Query Your Network Like a Database

    Query Your Network Like a Database

    Network process automation is an often-overlooked component of DevOps. Incorporating DevOps philosophies toward networking, or DevNetOps, can lead to even greater process improvements and more flexible deployments. Fortunately, it’s becoming even easier to automate network tasks with evolving standards and open data models that are allowing more programmatic access and insight to the network infrastructure. The most dramatic shift, however, is now being able to write queries about your network devices and topology as though you were querying a database!

    When rapidly deploying application updates, network flexibility is key. Policy changes or configuration updates are often required. Network operators can best serve DevOps processes when they can programmatically check the status and/or repair key issues from these changes. Here are some example queries that are commonly useful across the entire network infrastructure:

    • Do all distribution layer access links in my network have redundant paths?
    • Are all Border Gateway Protocol (BGP) sessions currently established with configured peers?
    • What are the nearest neighbors of a down device?
    • Are any device interfaces intended to be operational currently down anywhere in my network?

    Note that we are moving away from looking at individual devices, one at a time, to querying about network issues and status across all devices in one simple query. The challenge has been to create a structured data model of network details that was normalized across all vendors and device types that single programmatic query could leverage. The goal is to be able to query about the status of an interface port on a Juniper switch as well as a Check Point firewall, for example. Converting the detailed text files that configure each device into such a normalized data model is becoming easier with established standards, such as OpenConfig. OpenConfig has defined a common syntax and schema for network-oriented applications across vendors and applications.

    Accessing such a network schema is now extremely efficient with the widespread adoption of the GraphQL query language. Network data models are going to be graphical data structures by design, and GraphQL is ideal for building flexible data queries in minutes to such schemas. GraphQL was developed by Facebook and made an open source project in 2015. It has now been adopted by hundreds of development-minded organizations as a more efficient API model, regardless of how the underlying schema is structured.

    GraphQL is already being used widely in DevOps organizations aside from network-oriented applications. GraphQL is extremely intuitive and queries look like a JSON object without the data included. Queries simply return a JSON object with the specifically requested data. From there, it is a small matter of a few lines of code to embed GraphQL queries into a scripting language (such as Python) to analyze, process or format the results. If you aren’t using GraphQL in your DevOps coding, you should be!

    The full process looks like the diagram below (Figure 1), where text files can be parsed and normalized into an open graphical database schema that represents the current network state. The GraphQL queries can be constructed, along with a Python script (Figure 2) to format results, as shown in the third column. The following example returns both the desired admin state of every interface port in the network, along with the current operational state (up or down). The Python script compares the two states and alerts on any discrepancies.

    Figure 1

    In the example query results from Figure 1, consider that the alerts are reported from both an F5 load balancer (atl-bl01) and a Juniper router (sjc-ce01). Writing code that could parse such disparate device types and text files—without a normalized database schema, based on something such as OpenConfig—would be extremely complex. However, a simple GraphQL query can apply across the entire network. The main portion of the Python code that was used to embed the above query, compare the results and display the table, is shown below:

    Figure 2

    Network operations are becoming an increasingly important part of DevOps processes. Automating network tasks is greatly simplified when you can view your network infrastructure as a database. Embedding queries that confirm network policies and health checks into Python scripts can be trivial when leveraging open data models and query languages such as GraphQL. This will enable a new convergence of agile development and network operations for the first time.

    — David Erickson