staging-devopsy.kinsta.cloud

Tag: query language

  • Honeycomb Taps ChatGPT to Simplify Observability

    Honeycomb Taps ChatGPT to Simplify Observability

    Honeycomb today added a Query Assistant to its observability platform that uses OpenAI’s ChatGPT generative artificial intelligence (AI) platform to launch queries via a natural language interface rather than having to master a query language.

    That capability complements an existing tool based on machine learning algorithms, dubbed BubbleUP, that DevOps teams already use to debug code.

    Honeycomb CTO Charity Majors said both tools make the Honeycomb observability platform more accessible to IT teams that are tasked with managing complex application environments. Those teams are not going to be able to accomplish that goal without relying more heavily on AI to determine the root causes of an issue.

    Generative AI augments DevOps teams by making it possible to build a relevant, modifiable query that they can continuously iterate as IT staff investigate an issue. This approach means teams don’t necessarily need a deep understanding of code behavior and the underlying infrastructure it depends on, noted Majors.

    That’s critical, because not every IT professional immediately knows what query to launch. One of the challenges with adopting any observability platform is they require a a DevOps team member to frame a query to generate a result. If multiple queries are required, coding them in a query language becomes a cumbersome task.

    As AI continues to improve, algorithms should be able to automatically surface more issues. But given all the dependencies that exist in modern application environments, there will still be a need for a DevOps specialist to ensure application availability and optimize performance, at least for the foreseeable future.

    In general, generative AI represents a significant leap forward compared to AI for IT operations (AIOps) platforms that, in comparison, are not nearly as useful, noted Majors.

    It’s still early days as far as measuring the impact AI will have on DevOps workflows. But the AI genie is already out of the proverbial bottle. Many of the low-level tasks that tend to make DevOps jobs tedious will soon be automated. As a result, job roles within DevOps teams will need to evolve.

    Less clear is what impact the rise of generative AI might have on the adoption of observability platforms. While there is no shortage of observability platforms, adoption has been limited by the number of DevOps professionals that could master a specific query language created for that observability platform. The ability to rely on a natural language interface instead reduces the need to use a proprietary query tool.

    In the longer term, the simpler it becomes to use DevOps best practices, the more widely they will be adopted. AI platforms should enable more organizations to embrace DevOps in a way that reduces the level of cognitive load currently required.

    In the meantime, there’s no doubt that current DevOps professionals are cautiously watching the rise of generative AI, much like everyone else. The difference is that most DevOps professionals are not going to want to work for organizations that don’t provide access to AI-infused tools and platforms that make their jobs easier.

  • Why GraphQL Will Reign King

    Why GraphQL Will Reign King

    After years of development, GraphQL is set to reign as the go-to API for data fetching. But what is GraphQL? Simply put, it’s a query language that allows you to fetch data from any server, and it’s a noteworthy alternative to the likes of other web service development styles like representational state transfer (REST) and simple object access protocol (SOAP). There are a few reasons why GraphQL will dominate the DevOps world, including its overall efficiency, ability to work with any server and overall ease of use.

    Understanding GraphQL

    GraphQL is a query language for APIs and a runtime for fulfilling queries with existing data. GraphQL provides a complete and digestible description of the data in an API, gives clients the power to ask for exactly what they need, makes it easier to evolve APIs over time and enables powerful developer tools.

    Top Benefits of GraphQL

    GraphQL addresses many pain points that often slow down developers, who prioritize adaptability and working quickly and efficiently when building applications.

    For one, it is much more flexible than other data query languages, allowing users to specify exactly what data they want and in which format. Other data query languages require users to retrieve all data in a specific format, regardless of whether they actually need the data. That excess, unnecessary intake can cause delays and confusion.

    GraphQL’s ease of use is also invaluable, thanks to its simple and intuitive syntax. The language is strongly typed, which means developers can catch errors early on in the development process before code goes into production. This can save much-needed time and money in the long run.

    Another benefit is that it can be used to fetch data from multiple sources because it uses a schema that defines the different types of data available. This means if a developer has a field in a schema that could potentially return data from multiple sources, they can specify which source to fetch the data from. Developers don’t get this benefit from other data query languages, which often allow data fetching from only a single source.

    Advantages for DevOps Teams Over Other Data Query Languages

    As the world of software development continues maturing, so do the tools and technologies DevOps teams use to build and operate their applications.

    REST and SOAP are popular web service technologies, but they come with some major drawbacks. Notably, both REST and SOAP rely heavily on URL structures and verbose XML payloads, which makes it difficult to evolve the API without breaking existing clients. And because each endpoint is a unique URL, providing a consistent experience across different parts of the API can be challenging. REST and SOAP are also quite chatty and can make it hard to optimize performance.

    In contrast to REST, GraphQL provides a single endpoint for all data requests and is much faster than making many HTTP requests. GraphQL’s declarative query language specifies precisely the data needed – no more, no less – increasing bandwidth and improving performance. Applications can run faster and use fewer resources, which is especially important for mobile apps that need to be lightweight and fast.

    Understanding the data is crucial for DevOps teams, and GraphQL allows developers to visualize data in a graph. Teams can see the relationships between different points more easily, leading to better-informed decisions about the best ways to manipulate the data.

    The increased efficiency when conducting API calls is also a plus with GraphQL, which helps teams retrieve all information they need with a single API call. Traditional REST APIs often require multiple API calls, mainly because each resource in a REST API is represented by its own unique URL, along with its own set of permissions and data that needs to be retrieved. GraphQL can eliminate this bottleneck.

    Overall, dealing with complexity is significantly reduced when developers use GraphQL. When using traditional REST APIs, writing a lot of code to handle different edge cases and error conditions is the norm. But GraphQL streamlines this – much of the complexity can be handled by the server itself, making way for simpler and more maintainable codebases. DevOps teams are also able to decouple their front-end and back-end development efforts by using a schema-based approach. GraphQL enables frontend and backend components to be developed separately without worrying about breaking changes, which means faster development cycles and fewer errors.

    The amount of data that organizations need to understand, organize and query will only increase in the coming years. DevOps teams can get ahead of the ongoing data and information onslaught by taking advantage of GraphQL and its unmatched ability to provide an efficient, powerful and flexible API for data fetching and manipulation.

  • 5 GraphQL Trends to Watch in 2023

    5 GraphQL Trends to Watch in 2023

    The GraphQL query language had a big year in 2022. We witnessed its increase in production use cases, solving overfetching and underfetching concerns that plagued traditional API integrations. GraphQL can significantly improve usability, aggregate multiple services and optimize how data is ported from system to system.

    Yet, GraphQL is also prone to new security concerns. And as attacks on APIs continue to increase and grow in sophistication, an increased security focus will undoubtedly be required to avoid vulnerabilities. The coming year will likely also see architects grappling with their GraphQL maturity as they consider how best to scale its use across an organization and its various stakeholders.

    Below, we’ll consider where the tides are flowing for GraphQL in 2023. These forecasts are informed by my coverage in 2022 and reports from within the web development community.

    1. Increased Production Use

    A full 62.6% of developers reported relying on APIs more in 2022 than they did in 2021, according to RapidAPI’s State of APIs report. As the number of APIs in use expands, we will undoubtedly see more GraphQL examples. GraphQL is popular due to its usability and flexibility which outweighs traditional integration points. Studies showed it is primarily used for exposing internal data, although partner and public use cases are not uncommon.

    Representational state transfer (REST) remains a dominant style for modern APIs. According to Postman’s 2022 State of the API report, 89% of developers use REST. GraphQL is in fourth place at 38%, superseded by webhooks (35%) and SOAP (34%). Although usage remains small in comparison, it’s steadily gaining traction and will continue to expand.

    2. Unifying Disparate APIs

    GraphQL helps expose fields in an easily consumable manner. But it’s also good for aggregating disparate microservices into a unified schema. As such, it is often used as a meta layer that combines multiple REST services, databases and even GraphQL schemas. For the time being, it appears that REST has staying power. And it’s unnecessary to migrate all REST services to GraphQL. Looking to the future, it is more likely to be adopted as a layer on top of existing REST APIs.

    Combining multiple backend services under the hood and exposing them in a unified schema creates a more usable, localized interface that frontend developers can work from. In the future, GraphQL might become a meta layer for more organizations, increasing the discovery of internal services and helping teams reuse internal microservices.

    3. Supergraphs and Subgraphs

    As mentioned above, GraphQL is used not only to combine legacy REST services but also to combine multiple GraphQL schemas. Some call this a graph of graphs—or a supergraph. A supergraph that combines multiple GraphQL schemas would offer unparalleled developer experience in that engineers can access many services from the same endpoint.

    However, there’s a downside to centralizing with a unified graph. Different internal teams or partners might only need access to a particular set of functions. Giving the entire schema to every person who walks through the door would be TMI, not to mention a potential security risk that breaks the rule of least privilege. So, the idea of a subgraph has gained traction. A subgraph is an Apollo concept, but the theory could certainly be applied in other implementations. In the future, we’ll likely witness more use cases that use subgraphs to help federate a supergraph across an organization, helping segment a graph to specific stakeholders’ needs.

    4. Turning on GraphQL Security Controls

    As of 2022, less than half (43.2%) of GraphQL implementations have disabled query introspection. Disabling field suggestions and introspection are means to reduce the risks of public GraphQL exposures. As GraphQL security best practices become more apparent, these numbers will likely become more commonplace. Other security controls, such as implementing query timeouts, query rate limiting and query cost analysis, can also help curb potential malicious behaviors.

    As we’ve covered before, security by obscurity is not enough to protect GraphQL. Yet, many native GraphQL security and performance directives go unused. Besides turning on these advanced features, new tooling is coming to market that could harden GraphQL. Security vendors continue to add support for GraphQL, making its protection more accessible for non-security engineers.

    5. Managing GraphQL at Scale

    GraphQL has arisen in some large production use cases in recent years, helping developer usability at GitHub, boosting productivity at Netflix and aiding Shopify’s API strategy. These case studies proved its usefulness in large enterprises. But how do we effectively scale GraphQL across a massive organization?

    The concepts of supergraphs and subgraphs are ways to help scale it across a company. But retaining high performance will also be vital to maintaining an effective, scalable footprint. As such, we will likely continue to see companies optimize how GraphQL is used as it matures. This includes optimizing queries and query depth and applying filtering and rate limiting to fit application demands. Taking measurements of GraphQL response times will be necessary to establish benchmarks to improve over time.

    We’re Just Querying the Surface

    Above, we’ve only scratched—or queried—the surface of the exciting developments on the horizon for GraphQL in the coming months. There is much more to be said regarding updates to the query language and improvements within the surrounding tooling landscape. Where do you think GraphQL will go in 2023? Let us know in the comments below!

  • Key Findings From the 2022 State of GraphQL Report

    Key Findings From the 2022 State of GraphQL Report

    GraphQL, the open source query language, has been steadily growing in popularity over the past few years. The language is excellent for frontend development, as it creates a usable interface to fetch precisely the data required for the specific client at hand. You can also use it to aggregate multiple backend services and data sources.

    Studies show that the ecosystem around GraphQL is maturing—it has a very global user base and a growing number of tools exist to aid in its adoption. The 2022 State of GraphQL Report found that 61.8% of developers are happy with the overall state of the ecosystem. Yet many native GraphQL features go unused by developers, which suggests there is a wide range of experience levels, from novice to advanced users, working with the technology. This indicates there is plenty of room for growth and knowledge sharing.

    Below, I’ll review the key takeaways from the 2022 State of GraphQL Report, considering overall usage data and focusing on the popularity of specific features. We’ll also highlight the state of standard tools used in conjunction with GraphQL to get the job done.

    Analyzing Overall Usage Statistics

    First off, there is a wide variance in the types of GraphQL APIs in production today, ranging from private to public endpoints. The report found 47.9% of developers use GraphQL for exposing an API intended for a personal website or app, 40.4% use it for private unexposed APIs for internal usage and 19.5% use GraphQL for publicly available APIs intended for third-party developer consumption. This demonstrates its flexibility to cater to multiple scenarios. And while the majority of clients that connect to GraphQL APIs include browsers (62.3%), it’s commonly consumed by other client types such as native mobile apps, other servers and desktop apps.

    Previously, we discussed using GraphQL as a composition layer to combine underlying APIs and services. And the report backs up this idea that developers commonly use it to aggregate various data sources: 55.4% of GraphQL APIs hit databases, while 35% consume REST APIs and 14.6% eat other GraphQL endpoints.

    In terms of benefits, one strong point is the ability to enforce and validate types for every object in the API. Users find other top benefits to be avoiding overfetching and aggregating requests. Yet, some hurdles still present themselves. These top drawbacks include error handling, performance issues, client-side caching and security woes.

    Regarding user base statistics, most users have been working with GraphQL for less than five years. If we look at the type of sector utilizing GraphQL, we see it primarily leveraged in the programming and technology sector. This is followed by e-commerce and retail (16.4%), finance (8.9%) and news, media and blogging (7.2%).

    Many Advanced Features Go Unused

    Many of the more advanced GraphQL features still go unnoticed by the majority of users. For example, live queries is a feature that helps obtain live data from a GraphQL server, yet only 25% who know about it have used it. Over half of respondents had never heard of @skip, a directive that skips a field based on a value passed to it. Similarly, other directives like @specifiedBy, @defer and @stream also share little-to-no awareness or use.

    Analyzing feature usage becomes a bit more serious if we consider the unadopted security and performance features. For example, only 43.2% of respondents have disabled query introspection. Disabling query introspection is a suggested security best practice to limit a hacker’s ability to perform surveillance. But as we’ve previously covered, security by obscurity isn’t enough to protect GraphQL, and an additional security emphasis is often needed.

    As most GraphQL APIs are intended for personal or private scenarios, you would think that more security features would be leveraged to limit the threat of introspection and denial-of-service attacks. Yet, the report discovered low usage and awareness of security and performance features like query timeouts, query rate limiting and query cost analysis, all of which could be turned on to curb malicious behaviors.

    Tools Used In Conjunction With GraphQL

    Developers often seek to combine, aggregate or merge GraphQL schemas from different APIs. To do so, Apollo Federation is the most common solution, used by 22.5% of respondents. This is followed by Schema Stitching (16.9%), GraphQL Modules (4.4%), and GraphQL Mesh (2.9%).

    Looking at other technologies used in connection, Next.js is the most popular framework and PostgreSQL is the most common database used. TypeScript and JavaScript comprise the most common languages used to write a GraphQL backend. Developers also use a balanced mix of IDEs to query and test endpoints, including GraphiQL, GraphQL Playground, Postman, Apollo Studio, and Insomnia.

    The report also found relatively high usage and retention for tools like the GraphQL Code Generator schema builder, Apollo Client and Apollo Server. The data shows a crowded solution market with Apollo as an industry-leading outlier—many other clients, servers, API generators and schema builders have medium-to-high retention rates yet experience far less use.

    Final Thoughts

    The 2022 State of GraphQL Report sheds some interesting light on the state of GraphQL, validating a lot of the interest and trends we’ve covered lately on the blog. Of course, there is more to be said about many areas, such as smoothing the transition to GraphQL.

    One key finding is the low number of security features being leveraged by developers. A greater emphasis on API security is required to avoid incidents and retain a zero-trust approach. This emphasis is part and parcel of responding to ongoing software supply chain threats and will require more awareness and thought leadership around GraphQL security best practices.

    The 2022 State of GraphQL survey ran from June 15, 2022, to July 15, 2022, and collected 3,094 responses. The above analysis only scratched the surface and there are many other insights. For more findings, you can read the full results here.