devopsy.kinsta.cloud

Tag: GraphQL

  • Hasura SDK Integrates GraphQL Platform With More Data Sources

    Hasura SDK Integrates GraphQL Platform With More Data Sources

    At its HasuraCon ’22 conference, Hasura today announced the early release of a software development kit (SDK) that extends the reach of its GraphQL platform to additional data sources.

    In addition, Hasura is making generally available integrations with the GitHub repository, support for OpenTelemetry Traces within the Hasura Cloud Platform and Microsoft SQL event triggers.

    Finally, Hasura Cloud can now be deployed on the Google Cloud Platform while the Hasura Cloud Enterprise edition is now available on the Amazon Web Services (AWS) marketplace.

    Hasura CEO Tanmai Gopal said that while the company already provides support for widely used data sources such as the Postgres database, there are many data sources that organizations also want to be able to query via GraphQL application programming interfaces (APIs). Organizations want to be able to join data using GraphQL regardless of what repository it resides in, he added.

    The open source Hasura engine at the core of the company’s offerings automatically generate a GraphQL schema from a data source. That can then be used to accelerate the development of APIs to make it easier for a wider range of developers to build applications that aggregate data across multiple sources.

    That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs for internal IT teams to support, noted Gopal.

    GraphQL was originally created by Facebook, but it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited.

    It’s not likely IT teams will replace REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a wider variety of types of APIs.

    The challenge is that it’s not always clear who within IT organizations will manage those APIs. They are often created by developers and are left to IT operations teams to maintain. It’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands of APIs.

    In addition, many of those organizations are now consuming data via APIs exposed by other organizations. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex to manage.

    In the meantime, DevOps teams will need to extend existing DevOps workflows to both support and secure GraphQL-based APIs. The amount of sensitive data being accessed via those APIs is likely to accelerate the rate at which organizations are adopting DevSecOps best practices. Let’s hope this happens before they wake up to discover GraphQL APIs have already proliferated across the enterprise.

  • Supergraph: One GraphQL Schema to Rule Them All

    Supergraph: One GraphQL Schema to Rule Them All

    GraphQL has been garnering much interest as a way to seamlessly interact with backend services. The query language is a boon for frontend developers, too, as it conveniently allows you to fetch the specific fields you require, thus eliminating the potential overfetching or underfetching concerns of REST APIs. And as GraphQL adoption matures within organizations, there is increasing interest (and investment) in how enterprises can use GraphQL to securely unify their growing catalog of disparate microservices and APIs.

    Using GraphQL as a meta layer could help unite many disparate systems under a single unified schema. This would enable the age-old promise of composability, in which software building blocks are seamlessly pulled together to assemble applications and unique experiences for different client types. However, managing GraphQL at scale can become tricky. And when a schema gets really large, it then may require a schema of its own! This is where the concept of the supergraph comes in.

    I recently met with Geoff Schmidt, Apollo GraphQL CEO, to discover what a supergraph is and how it may help platforms aggregate their backend microservices. According to Schmidt, “Developers want this composition layer for one abstract view of all their services.” Below, we’ll explore the concept of the supergraph and look at some new open source components that may help you enable GraphQL-based composability in your organization.

    Microservices Enable Composability

    First off, what do we mean by composability? Well, composable architecture is intrinsically linked with microservices. You can think of each microservice as a single lego piece that makes up one aspect of an application. For example, Uber uses 4,000 microservices to power its backend. These services span from maps, currency conversions, driver reviews, payments and other components. When combined, they ultimately create the convenience and the sleek user experience that is Uber.

    Historically, software developers were overseeing larger monolithic applications in which a single client was interconnected to a web server, Schmidt explained. On the other hand, microservices tend to be more domain-specific and used in tandem with other microservices. They’re also typically easier to iterate on and faster to ship when compared to monolithic codebases.

    The Need for Aggregation

    As a result of the microservices age, applications typically pull in far more data from various sources. For example, a banking application might loop in a mortgage service, investment service and other data sources to display a combined net worth on a screen. This explosion in microservices has created a “polygon environment” spanning databases and APIs, increasing service complexity, said Schmidt.

    Nowadays, many third-party components must be combined to render an experience. However, supporting this composability can be challenging for developers and backend API teams—not to mention that handwriting a backend-for-frontend could be burdensome. “App developers are slowed down by the need to integrate or compose these backend services,” said Schmidt. “Developers need a way to put all those pieces back together.”

    What is Supergraph?

    Supergraph can be thought of as a graph of graphs. The vision is to have one GraphQL schema and one ingress port to oversee many services. Creating a supergraph is becoming more accessible, too, as more open source projects emerge to enable this paradigm. For example, Apollo recently open sourced some components that can help to build and operate a supergraph. These include Federation, which helps to create a data graph across multiple services, and the Apollo Router, a tool written in Rust that decides how to route queries. Apollo has also open sourced a supergraph demo along with other resources.

    A supergraph architecture is already powering Expedia, Walmart, Netflix, Paypal, the New York Times and other large environments, said Schmidt. For example, Expedia has used a supergraph to combine flights, rental cars and other microservices to create integrated experiences. Hivee, an upstart modern supermarket chain, also uses a supergraph to unite its investment into APIs.

    According to Schmidt, the fundamental benefit is that less time is spent writing integration code which means faster development speed and the ability to quickly pivot your business. “It allows you to change business quickly to meet the needs of your customers.” A supergraph could also enable greater visibility into your API estate, making auditing easier.

    A key benefit of the above components is that they already have a proven track record running at a commercial scale. But outside of the Apollo projects, other groups are attempting to codify a similar GraphQL schema aggregation concept, as well. For example, WunderGraph utilizes GraphQL within a “virtual graph” that acts as a common language to call various underlying APIs.

    Repercussions of ‘One Graph to Rule Them All’

    Schmidt said the hope is that, at the end of the day, this abstraction can contribute to “making the world a little more human-centric.” This is because GraphQL can enable less rigid apps that conform to unique user tastes. But a robust composition layer will be necessary to allow such reconfigurations.

    Of course, as I’ve covered previously, there are significant security hurdles to address when supplying so much power to a single entryway. Increased GraphQL reliance will require forethought into new potential security risks, such as schema introspection and object-level authorization control.

    According to Schmidt, a GraphQL composition layer presents an opportunity to enforce security controls. He defines these as contracts that create access rules for a particular set of users. By declaratively managing GraphQL security, a development team, in essence, could expose a subgraph of the supergraph for a partner to consume. The graph could even be segmented for internal teams.

    A central point of ingress will require authorization rules to protect user privacy and avoid breaking the rule of least privilege. Schmidt also advocates for backend schemas to be built for app developers who understand their needs, instead of precisely mapping logic to business models.

    Supergraph: A Graph of Graphs

    Software is becoming more modular, which has resulted in an explosion of unique microservices and APIs. And we’re now at another tipping point in how software architecture is divided and combined, said Schmidt. He now sees GraphQL as a prime opportunity to create software architectures that call multiple backend services with a single GraphQL query.

    “GraphQL is the composition layer you need to build modern applications,” said Schmidt. “We’re super excited about this. Users have shown that GraphQL is the future. Supergraph is such a powerful technology, and we’re excited to bring this to everybody.”

  • Does GraphQL Introduce New Security Risks?

    Does GraphQL Introduce New Security Risks?

    The GraphQL query language is an excellent tool for increasing the ease of data sharing. The premise is that you request the fields you need in a single bundled request, avoiding multiple network calls. Due to its usability, GraphQL is a growing area of development. Yet, as with any new technology, it comes with caveats.

    REST APIs function as a request-and-response paradigm in which the receiver accesses one resource at a time. On the other hand, GraphQL exposes many fields at once, requiring additional rate-limiting and time-outs to avoid nefarious queries. Additionally, the ability to traverse the entire schema could be abused by attackers to expose intricate data linkages. There are also some usability features with GraphQL that could be abused if misconfigured.

    GraphQL is a friendly alternative to REST. But how do we handle the security implications of GraphQL? I recently chatted with Mike Benjamin, vice president of security research, Fastly, to dive deeper into the security repercussions of adopting GraphQL. Below, we’ll consider the unique insecurities associated with GraphQL and suggest specific steps to limit the impact of these risks.

    Four GraphQL Security Vulnerabilities

    1. Introspection

    GraphQL provides built-in documentation that tells developers what the fields are, providing a schema of everything you can query. You’ve essentially given the entire dataset schema to a developer, meaning they can perform introspection to capture attack surface information. Hackers will most commonly look for injection or mutation capabilities that they can exploit, explained Benjamin. Or, they might seek to leverage the interlinkages between data to map a way through to classified information.

    To mitigate this problem, Benjamin cautioned against over-exposing all documentation publicly. Instead, he suggested using a restrictive security model for external viewers. “Provide appropriate user documentation in a different method,” he says. This may end up looking more like the standard REST API view of documentation.

    2. Field Suggestions

    Another usability benefit in GraphQL could also be a potential security concern—field suggestions. Field suggestions occur when you don’t enter the correct field name or enter a partial input and the system returns a hint. You might type in 0 or user, and the system makes a suggestion to fill out the rest of the field.

    This user interaction improves the developer experience, but, unfortunately, it could be abused by a hacker, said Benjamin. Thus, he recommended disabling hints after initial development. Or, if you decide to keep it in, he recommended placing a limit on its use. For example, if you try this more than five times in a second, the system could flag it as a bot.

    Right now, this attack vector is pretty limited, but Benjamin anticipated that, over time, hackers could automate this introspection with mass scanners to divulge more information.

    3. Denial-of-Service-Oriented Attacks

    Without the proper guardrails, all web APIs are prone to denial-of-service (DoS) attacks. Such an attack may pummel a service with a million queries per second to shut it off completely. In the case of GraphQL, these queries can dive very deep in a nested data relationship. A social network, for example, might expose friends of users, friends of users’ friends and so on.

    Or, hackers might utilize GraphQL’s bulk query ability to perform reconnaissance, brute-forcing the enumeration of data to query hundreds of user IDs to see which are valid. If you’re allowing unlimited data retrieval bundled within a single request, you could be inviting hundreds of bundled queries that could expose large swaths of the underlying database in one fell swoop.

    To counter these actions, Benjamin recommended limiting the testing depth. This could involve placing limits on how long a query can run, which would cause a time-out for requests that require suspiciously high degrees of processing. Another option is to limit how deep the bundling can get, said Benjamin. For example, perhaps the system restricts going three levels deep into a graph database, as that could expose millions of interconnected endpoints.

    4. Lack of Object-Level Authorization

    Another vulnerability that GraphQL endpoints may be prone to is a lack of object-level authorization, which hackers could leverage to get at a datapoint through its edges, said Benjamin. Since the idea is that you can access any data from one all-encompassing endpoint, authorization rules are often too abstracted away from the actual data. Queries may be able to access nested data or query relationships between data, too, which may unintentionally divulge information.

    Benjamin recommended placing authorization closer to your objects or data to rectify this issue. Use authorization-level controls that align permissions structure and roles with users. “Everyone needs a common authorization model,” said Benjamin.

    Future Evolution: GraphQL Security Matures

    As I’ve written before, the greatest strength of GraphQL is also its greatest weakness. Using GraphQL with default settings is a security trade-off in favor of usability. But according to Benjamin, we’re seeing more GraphQL servers disabling some introspection features, which he sees as a very positive move and a sign of maturity of the base configuration.

    GraphQL might suffer from similar threats that all APIs are vulnerable to, such as XSS, injection, DDoS attacks and broken authorization. However, Benjamin stressed that the added complexity of GraphQL makes it a unique case. “The most important thing for folks to consider is that GraphQL is more complicated than a REST endpoint—much more complicated,” said Benjamin. “GraphQL is unique in that it has linkages of data which contributes to complexity. It takes a little more time to think about how that’s confirmed, how it’s presented and how it would be attacked.”

    In other words, with great power comes great responsibility.

    Although exploits in public GraphQL APIs are still rare, we should stay vigilant. Benjamin encouraged developers to continue reading about, understanding and thinking about these attack vectors when designing their interfaces, as these risks will become more prominent as GraphQL usage grows and hackers become more familiar with these specific frailties.

  • Smoothing the Transition From REST to GraphQL

    Smoothing the Transition From REST to GraphQL

    Since its open source release in 2015, GraphQL has taken the development world by storm. GraphQL, the query language originally developed by Facebook, is a big boon for frontend developers, as it enables you to grab the exact data you need with a single request. This solves the problems of over-fetching and under-fetching, which classical REST APIs are prone to. GraphQL also offers a nice developer experience with a consistent schema and documentation. Some are even treating GraphQL as a convenient meta layer to aggregate multiple underlying services and abstract their interfaces with simple commands.

    For these reasons and more, many development teams are considering switching from REST to GraphQL. Even enterprises are beginning to use GraphQL in large production environments. But, how can these teams make the switch without breaking existing integrations? How can we ensure that things like developer experience, security, and access control all remain stable?

    I recently met with Anant Jhingran, the co-founder of StepZen, to discover tips for transitioning from REST to GraphQL. According to Jhingran, most organizations see the benefit in adopting GraphQL but are hesitant to forgo years of investment into RESTful architectures. But according to Jhingran, it’s rarely a case of “either/or”—more often, he sees projects running both styles simultaneously or layering one on top of the other. Below, we’ll explore some things to keep in mind as you invest in GraphQL.

    The Decade of Developers

    We’ve reached ubiquity of web APIs among companies big and small. “APIs have turned out to be phenomenal for software supply chains,” said Jhingran, the former CTO of Apigee. They help share data between partners and can enable platform ecosystems to thrive. Jhingran describes how within the last decade, APIs and API management have peaked to near-ubiquity in terms of adoption.

    But not all APIs behave the same way. Although representational state transfer (REST) is the most popular style, it’s still quite a general architectural guideline for web APIs—how the data comes out of each service is still highly nuanced. The structure of requests and responses are different from service to service, causing developer experience hangups at scale.

    GraphQL, on the other hand, “is a fantastic way of structuring data,” said Jhingran. With a single call, you can return the explicit information that the client requires in an expected format. For an e-commerce application, for example, this might be customer information, order numbers and delivery status. Displaying this all with one call is an awesome experience for frontend developers. And, GraphQL APIs are easy to explore and navigate since the schema is baked in. This improves upon REST APIs, where documentation may not always match the actual production implementation.

    “This decade is the decade of developers,” said Jhingran. Satisfying developer experience has become more mission-critical as enterprises work to increase their footprint in the cloud marketplace and GraphQL is part of this movement. “For people who build apps, it’s just better,” said Jhingran.

    But just because frontend teams clamor for the ease of use of GraphQL doesn’t mean backend teams can easily restructure their entire framework around it. Doing it right requires many skills, and the journey can be arduous, explained Jhingran.

    It’s Rarely REST Vs. GraphQL

    REST and GraphQL are often pitted against one another to the point that they seem like polar opposites. But in practice, teams often use GraphQL to build on top of APIs already in place. Jhingran describes the most common pattern as “GraphQL comes in as a layer that connects the dots between various REST APIs.” Either GraphQL is consumed directly or as a REST layer above GraphQL. “It could go either way,” he said.

    GraphQL is a fantastic data infrastructure tier as it can mix and match database backends. It could, in essence, become the new plumbing upon which applications are constructed. But while GraphQL may be excellent for internal construction, the name of the game is stability when externalizing services to the outside world. With REST, the big goal is to decrease broken clients and ensure high-grade security for each resource. Therefore, Jhingran foresees certain use cases where using a REST wrapper around GraphQL services to deliver fixed JSON responses would be preferred.

    Another point is that GraphQL is not only relegated to appeasing frontend developers—it has some backend potential, too. “GraphQL is an opportunity to reimagine frontend and GraphQL is an opportunity to reimagine backend infrastructure,” said Jhingran. This concept has weight nowadays, as Netflix engineers, for example, use GraphQL as a backend for microservices architecture.

    Making the Transition From REST to GraphQL

    Not all apps are going to be transformed on day one. Teams may encounter cultural resistance to new technologies. Interface redesigns, especially for those external apps which are exposed to third parties, must also require extra precaution to maintain app compatibility to avoid breaking change.

    Thus, it may take time to transition effectively. “Getting it started versus getting it right are not the same thing,” said Jhingran. He said people who get started with GraphQL may struggle for months due to competing best practices and tools. For example, Jhingran identified two main perspectives when approaching GraphQL: Programming and declarative.

    • Programming: Teams use GraphQL libraries such as Apollo to program their way out of your GraphQL endpoint. In this approach, you just start writing. It’s quick to get started, said Jhingran, but you end up describing everything you do and encountering many contingencies along the way.
    • Declarative: The other option is a more declarative approach—instead of telling the system how, you tell it what to do. For example, this subsystem should do X, this subsystem should do Y and so on. According to Jhingran, adopting tooling with declarative snippets to create GraphQL endpoints is “better in the short and long run.”

    GraphQL Security

    A March 2022 report from Salt Labs found a shocking 681% increase in API-based cyberattacks over the previous 12 months. There are many concerns surrounding API security right now—these valuable endpoints are prone to broken access control, data overexposure and over-permissive states.

    As I’ve covered previously, GraphQL security is a bit nuanced compared to REST. Within the REST paradigm, you can easily assign permissions and rate limit calls per resource. But with GraphQL, it’s not that simple. Since you can batch multiple queries, callers have much more power at their fingertips, and hackers might abuse such power if the proper authorization isn’t in place.

    Companies may rightly worry about opening another can of worms with GraphQL. But according to Jhingran, these worries are all solvable. A comprehensive GraphQL endpoint will likely require another layer to uniquely segment authorization to retain a least-privilege model for all resources and backend endpoints.

    Future of GraphQL

    To date, GraphQL has gained modest prominence. But, Jhingran foresees an incoming inflection point in the next two to three years. “The dominoes are beginning to fall,” he said.

    Now that the market is saturated with APIs, characteristics outside of functionality will be what sets a service apart and gives it a competitive edge. This includes things like performance, security and developer experience, the latter of which makes GraphQL an attractive proposition. This, paired with the explosion in GraphQL tools, will undoubtedly help developers perform their jobs better.

    Looking to the future, Jhingran predicts increased usability and abstraction in how developers work with GraphQL. He compared it to how disjointed pages on the web became interconnected and searchable with links. We see similar thinking happening in the world of APIs, he explained, in which the disjointed APIs require a better connection. Similar to how Google simplified search, he foresees GraphQL and the tools that work with it helping to decrease cognitive load by abstracting complexity with declarative commands.

  • Hasura Adds Join Capability to GraphQL Engine

    Hasura Adds Join Capability to GraphQL Engine

    Hasura today announced it has extended its GraphQL engine to make it possible to join data generated by multiple sources.

    Hasura CEO Tanmai Gopal said GraphQL Joins makes it possible to join data from across different GraphQL services that can then be accessed via a single GraphQL application programming interface (API). The extension of the federation capabilities enabled by the Hasura GraphQL engine eliminates the need for custom code that would otherwise be required to join that data, he added.

    The Hasura engine automatically generates a GraphQL schema from a data source that can then be used to accelerate the development of APIs. GraphQL Joins extends that federation capability to now include multiple GraphQL and, eventually, other data sources accessed via, for example, legacy REST APIs, said Gopal. That capability will make it easier for a wider range of developers to build applications that aggregate data across multiple sources, he added.

    The core Hasura Engine is based on open source software that the company claims has now been downloaded more than 500 million times. Hasura makes available a cloud service based on that core engine. That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs that internal IT teams need to support, noted Gopal.

    GraphQL was originally created by Facebook, and it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited. Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. DevOps teams looking for easier ways to provide developers with access to backend services via a GraphQL API can employ the Hasura Engine to automate that process.

    Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a range of types of APIs to support multiple digital business transformation initiatives that an organization may have simultaneously launched. In addition to building APIs, many of those organizations are now consuming data via APIs exposed by another organization. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex. The good news is that APIs make it easier to upgrade—and even replace—backend services without disrupting application services.

    It’s not always clear, though, who within IT organizations will manage those APIs. They are often created by developers that then look to IT operations teams to maintain them. Before too long, it’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands, of REST and web services APIs—and soon, that may include many built using GraphQL.

  • Netlify Leverages GraphQL to Simplify Access to Backend Services

    Netlify Leverages GraphQL to Simplify Access to Backend Services

    Netlify this week added a Netlify Graph tool to its portfolio that makes backend services available to developers via a single click. The tool aims to simplify DevOps teams’ access to those services when building their applications.

    Netlify Graph is based on the GraphQL query language for application programming interfaces (APIs) and enables developers to integrate services such as GitHub, Salesforce and Stripe within frontend and web application development tools without any direct intervention required from a DevOps team.

    Netlify provides an application development framework based on JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as a JAMstack, to isolate frontend and backend components of an application.

    Netlify CEO Matt Biilmann said Netlify Graph is based on the GraphQL technology the company gained when it acquired OneGraph. The overall goal is to make it simple for frontend developers to invoke backend services accessed via either GraphQL or REST APIs, he said. Services based on GraphQL can be especially complex for developers to invoke as they navigate the management of tokens and application secrets, Biilmann added.

    It’s not clear to what degree GraphQL APIs will supplant REST APIs. However, developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited. As GraphQL becomes more widely adopted, the level of effort DevOps teams now need to expend to expose backend services should decline as tools such as Netlify Graph are employed by frontend developers.

    As a result, at least theoretically, the rate at which new applications are built and deployed to drive digital business transformation initiatives should increase. Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. DevOps teams looking for easier ways to provide developers with simpler access to backend services now have an incentive to embrace GraphQL.

    Ultimately, Biilmann said, the goal is to enable developers to build applications without having to directly engage anyone on the IT team. Each backend service can be managed in isolation from the frontend of any application. It’s not clear how long it might take to achieve that goal, but as responsibility for the end-to-end management of the application experience continues to shift left toward developers, the need to surface backend systems-as-a-service becomes more pronounced. In fact, given the current focus on improving developer productivity, IT organizations might soon face a mandate to embrace GraphQL more broadly. After all, every minute that a developer spends on plumbing is time they’re not spending writing actual business logic.

    Naturally, it may take time for enterprise IT to be truly transformed into a set of services that developers can easily consume. But as progress continues to be made, that dream may finally be realized.

  • Graph CDN for GraphQL APIs

    Graph CDN for GraphQL APIs

    Alan Shimel talks with Max Stoiber from GraphCDN, the CDN for GraphQL APIs. GraphCDN is now available to everyone with edge caching, query analytics, error tracking and protection from malicious queries for your GraphQL APIs. A video is below followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Thanks for joining us on another Tech Strong TV segment. My guest for this segment is Max Stoiber—and if I mispronounced that, Max, I apologize. I did my best, but why don’t you say it correctly?

    Max Stoiber: Stoiber, but it doesn’t really matter. I’m really excited to be here—thank you for having me.

    Shimel: Oh, it’s our pleasure to have you on. But you know what, it does matter—names matter, right? My mom taught me that and somewhere, your mom or dad or both, their name and—they deserve to have it pronounced right, as well.

    But anyway, Max, thanks for joining us. Maybe more important than your name is the name of your company, so why don’t you start off with sharing that with our audience?

    Stoiber: Absolutely. So, I am the Co-founder of GraphCDN, which we just recently announced is now publicly available for everybody. And so, that’s sort of the reason I’m here is to tell you a little bit about that journey and how we got here.

    Shimel: Absolutely. So, GraphCDN—I mean, we’ve seen so much news coming out of kinda graph databases and graph data, and it really gives us a new way of looking at, I guess it’s part of nature, right? Things get more complex and bigger as we go on, and so you need new technologies to help you get your arms wrapped around it. And certainly, graph technology is a real up and comer, if you will, in terms of helping us wrap our heads around stuff like this.

    So, you know, why don’t we start with a little bit of background? Like, what does the company do, what’s the problem you’re solving—that kind of thing.

    Stoiber: Absolutely. So, GraphCDN is a GraphQL CDN. And GraphQL is a technology, in case you’re not familiar with it, that was invented by Facebook back in, I want to say 2014, maybe ’15. It’s been a while. And they use it—it’s basically like an API framework that lets people build very strongly typed APIs to communicate between their servers and their clients. And Facebook invented that, and open sourced it. And a lot of other companies started adopting it, because it feels very nice to use for developers.

    And so, we provide, similar to how other CDNs provide features for websites to make them faster, more secure, think, like, Fastly cloud there, we do the same thing for GraphQL APIs. And we do that for everybody, not just Facebook who has technology like this internally, of course, we do it for all the other companies that aren’t Facebook and don’t really have the time to build all this technology themselves.

    And we came to that whole thing because when we built our last status, me and my Co-founder Tim, we were using GraphQL and we had huge scaling problems. We were growing like mad, but we couldn’t just cache our GraphQL API, for example, because none of the existing CDNs support GraphQL. They can’t cache any of the data that goes through it.

    And so, we struggled with this and we built terrible solutions internally at our past companies, trying to solve this as best as we can. And then now, we got together and we said, “Hey, we just gotta solve this,” right? It’s almost, excuse my language, stupid that nobody’s done this, because it’s such a clear need.

    And so, we sat down, and it turns out it’s quite hard to solve, which is why it took us a while, but we finally got there and now we’ve got GraphCDN, and it does a lot of things for people that have GraphQL APIs. That’s sort of the broad strokes overview, I would say.

    Shimel: Absolutely. Max, you know what, you mentioned a little bit here and there, but let’s talk about your background and your history.

    Stoiber: Absolutely. So, I am, I would say, most widely known in the engineering community for having invented a bunch of open source projects, particularly in the front-end web development space. About 1 to 1.5 percent of all websites on the planet are powered by technologies that I invented, mainly by styled-components, which is one of the biggest ones.

    And so, I’ve sort of amassed a large following of engineers and designers and other tech people following me for my open source work. And then, I’ve previously co-founded a startup with two friends from California where we were building sort of a modern forum, in a way, sort of a mixture between WhatsApp and traditional, you know, the forums of the past where we used to hang out and have friends.

    That was then acquired by GitHub, and turned into GitHub Discussions so that the engineers on GitHub can then sort of hang out. And then I had a stint at GatsbyJS, another startup, that was building a JavaScript framework, or is still building a JavaScript framework, and I left that at the beginning of this year to focus on GraphCDN and really build that out with Tim. And sort of, that’s my background.

    Shimel: Very cool, and congratulations. Very, very impressive.

    Stoiber: Thank you.

    Shimel: Thank you. You know, look, I’ve worked with enough engineers and software developers to know that nothing is ever truly done, right? There’s always more we could do, right? Why GA now, why kind of emerge from Stealth, if you will—you know, why now?

    Stoiber: That’s a great question. It’s funny, because we debated this for a long time internally, because we felt like we were GA ready two or three months ago, right? We sort of had the basic set of features where we thought we could cover common needs, almost all of the common needs that we wanted to cover. We were ready or people, but also, GraphCDN, because it is a CDN, is critical infrastructure. If we’re down, our customers are down. And we take that responsibility incredibly seriously.

    Now, we’re based on Fastly’s edge computing technology. So, the infrastructure underlying GraphCDN is actually very solid. But we wanted to make sure that our part of that infrastructure was as solid as it could be. And so, we gradually on boarded early access customers, including the biggest rugby site in Australia and a bunch of others, to make sure that our infrastructure could really handle the load. And after we proved that out for the last two, three months, we said, “Okay, we are confident in our systems, we’ve found all the bugs we’ll find before with GA.” Of course, you can never find all of them. That would be—I think any engineer that says that is lying. But we found most of them, the ones that really mattered, and then we said, “Okay, it’s good enough, let’s have people sign up and really get this into people’s hands.”

    Shimel: Excellent. And let’s talk about the model for the company. I mean, with your open source background, I’m gonna assume, is there an open source graph?

    Stoiber: There actually isn’t.

    Shimel: No?

    Stoiber: The open source part of it is the GraphQL part, the framework that Facebook open sourced. But our infrastructure is fully proprietary. There’s actually—there’s sort of two schools of thought, right? You have companies like Sentry doing all of their core work in the open source and then providing hosting or other services on top. And I think that model can work quite well, but for us, because we’re critical infrastructure, we knew that we needed to be in people’s critical path and we knew we needed to be reliable, and that just takes a team, right? There’s no way that you can just run this on the side, you know, have it running in the background and not worry about it. It needs to be maintained. Somebody needs to sit there 24/7 on call and pay attention that this thing keeps running, just to make sure nothing goes wrong.

    And so, open source just didn’t feel like the right fit for that, because honestly, we’re gonna sit there 24/7 and make sure that our infrastructure stays up and doesn’t have any down time. And so, we did not go open source and instead have—we have a very generous fee plan, but beyond that, believe it or not, people pay us for the thing we provide. Which, of course, sounds ridiculous, because that’s what businesses do, but as an open source developer, that’s actually less natural to me than you might think. But it feels very nice, I have to say. We’re very appreciative of our customers for helping them scale and secure their GraphQL APIs. And so far, over the past months that we’ve had customers, everybody has been very happy that they have us and that’s very gratifying to see from our side, of course.

    Shimel: Agreed, agreed. When you say GA, I’m assuming GA, people can go buy and use this right now.

    Stoiber: Correct. Absolutely.

    Shimel: But is there a free trial, is there—

    Stoiber: Yes.

    Shimel: You know, because you know how software is consumed today, right? You gotta get it in people’s hands and deliver delight, right?

    Stoiber: Absolutely.

    Shimel: And if it’s good and they like it, they buy it.

    Stoiber: Absolutely. That’s the exact model we follow. We have a very, I would say, generous free plan. You can use us for free for up to, I think, 5,000,000 requests per month, which covers a lot of early stage startups, we’ve realized, maybe even more than we would’ve liked. It’s definitely a very generous free plan, is what we’ve learned, which is a good thing, because we wanna provide that value, particularly to those growing companies. And then eventually, when they hit the scale where they have more than 5,000,000 requests, it starts costing $10.00 per 1,000,000 requests. And so, it’s sort of, the pricing scales with your usage.

    In theory, you can throw as many requests as you want at us, since we’re based on Fastly and they handle a lot of traffic, I’m not very worried about not being able to handle scale. And we have—it was actually funny, after we GA’d and we announced that this is now available to everybody, of course, people signed up and then suddenly started deploying this thing to production and our traffic just 10X’d overnight, and we didn’t even notice. Like, we just looked at our graph, like, we woke up the next morning, we looked at our graphs, at our internal dashboards and we realized, “Hey, a site just enabled us overnight and 10X’d our traffic, and we didn’t even realize,” right? And they’re just—they were just like, “Yeah, this works, we’ll use it—perfectly fine.” And that just kind of keeps happening and it’s very, very interesting to see. I love it, I have to say.

    Shimel: You know, that’s one of the—so, I’ve been in the Internet business since ’96, ’95, and that truly is one of the remarkable things about the Internet is yeah, people, you know, if you put your shop out there, you put yourself out there, people come by. And they could be from anywhere, whether they’re from Australia, Japan, Korea, you know, Amsterdam, London, or next door, it makes no difference, they’re on the Internet. And all of a sudden—boom, you know, it lights up and it’s like, “My goodness, you know? We were hoping for this, but who”—you know, you never know. That’s fantastic.

    So, what are plans going forward? Have you guys announced fundraising, is that in the works, or—you know, where’s the continuing journey, here?

    Stoiber: We raised a round of funding a couple months ago from some well-known industry people, mostly friends of ours, like Guillaume ________, the CEO of Versel; Tom Preston-Warner, one of the Founders of GitHub; Jason Warner, the current CTO of GitHub. A bunch of friends that we knew from the industry that we also knew loved GraphQL and that they knew what it was about and they immediately got what we were working on.

    And so, we raised enough funding to sustain us for a couple years, and now we’re gonna use that funding to build a small team to help us maintain this, because right now, it’s just me and Tim—or has been just me and Tim for the past months, and now we’re starting to hire and on board the first people to help us really take this to the next level. Because it’s a lot of work, it turns out. [Laughter]

    Shimel: Yeah, I know, yeah.

    Stoiber: Building a great product is a lot of work.

    Shimel: Well, you know what they say, Max, if it was easy, everyone would do it.

    Stoiber: Exactly right. [Laughter] Absolutely.

    Shimel: But it’s fun work, right? There are people who really work for a living versus people who love what they do.

    Stoiber: Yeah, absolutely.

    Shimel: You know what we didn’t do, though, Max, we never gave anyone, like, the URL, where could they get more information, where can they download it? Where can they go?

    Stoiber: The URL and the home page is at GraphCDN.io, and it just has—as any website, it has a massive sign up button that you can click, and then you’ll be redirected to GitHub and you can sign up and just try it out. You don’t even need a GraphQL API, we have this sort of flow where we’ll give you a demographical API, just so you can get a feel for what it does and how it works. So, yeah, go to GraphCDN.io and try it out.

    Shimel: That sounds like a plan. Hey, man, you gotta come back and keep us posted of progress here, okay?

    Stoiber: I will absolutely do that. Thank you so much for having me.

    Shimel: Oh, it’s our pleasure. Max Stoiber, Co-founder, GraphCDN, it’s at GraphCDN.io—right, Max?

    Stoiber: That’s it. That’s the one.

    Shimel: Yeah. Go check it out. Seems pretty cool. This is Alan Shimel for Tech Strong TV, we’re gonna take a break and we’ll be right back with our next guest.

    [End of Audio]

  • 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.

  • Hasura Adds Engine to Transform REST APIs to GraphQL

    Hasura Adds Engine to Transform REST APIs to GraphQL

    Hasura today unveiled a Data Hub repository for integrating application programming interfaces (APIs). The repository includes a connector that makes it easier for IT organizations to convert REST APIs into ones based on the GraphQL specification.

    Tanmai Gopal, Hasura CEO, said the connector eliminates the need to write custom code to connect existing REST endpoints to a GraphQL API using an update to the transformation engine developed by Hasura. Instead, the model for the GraphQL API is automatically overlayed on top of the REST API endpoint, explained Gopal.

    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 provides 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. 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.

    Hasura claims its engine has been downloaded more than 400 million times since its introduction in 2018. It automates the repetitive work involved in mapping models to APIs by providing common access patterns for pagination, filtering, joining, setting up authorization rules and optimizing performance. Hasura also provides APIs that are able to connect to multiple services and data sources, embed domain-specific authorization logic and provide additional layers of security.

    Hasura is now also adding a way to create identity-specific authorization policies for any GraphQL service or data source, enforcing security by limiting the models and fields of the GraphQL APIs in a way that eliminates the need for IT teams to cobble together disparate libraries and frameworks, said Gopal.

    In addition, Hasura is adding support for Google Cloud to Hasura Cloud in beta, a managed API integration service the company already provides via the Amazon Web Services (AWS) cloud. Support for the Microsoft Azure cloud will be forthcoming in 2022, added Gopal.

    It’s not clear the degree to which organizations are looking to replace existing REST APIs with ones based on GraphQL. However, Gopal noted there are plenty of instances where organizations need to overlay a GraphQL API on top of a REST API that they may not own. For example, a software-as-a-service (SaaS) platform that currently exposes a REST API may not have any plans to support GraphQL, he said.

    There’s no doubt the number of GraphQL APIs being employed in the enterprise is about to dramatically increase. The challenge now is finding a way to manage them alongside the previous generations of APIs that remain. The trouble is that many of those APIs were created by developers that may not have documented the APIs they created or, in some cases, never informed DevOps teams that they existed in the first place.

  • The Graph Donates $48M to Advance GraphQL Platforms

    The Graph Donates $48M to Advance GraphQL Platforms

    The Graph, a provider of indexing and query tools based on the GraphQL language designed for blockchain platforms, today announced it has given $48 million to The Guild, a group of developers advancing an open source application programming interface (API) platform to further development of GraphQL-based technologies.

    Administered via The Graph Foundation, a nonprofit consortium that oversees the development of an open source graph database dubbed ONgDB, the agreement also calls for members of The Guild to contribute to the development of indexing and query tools being advanced by The Graph over the next four years.

    Eva Beylin, director of The Graph Foundation, said the goal is to fund the development of projects that leverage GraphQL, an open source data query and manipulation language for application programming interfaces (APIs) originally developed by Facebook, to create subgraphs used on blockchain platforms like Ethereum to index data in a way that is more accessible to developers.

    The open source community that is starting to evolve around blockchain platforms, also known as Web3, is now a major contributor to a range of GraphQL projects, noted Beylin. Those blockchain platforms are now being used to drive decentralized finance (DeFi) applications that do not rely on any single platform to process transactions. Those platforms are being employed by both startup and incumbent providers for financial services around the globe.

    It remains to be seen, however, how the GraphQL community will address security concerns. GraphQL APIs can easily suffer from broken object-level authentication issues just like any other API. The issue is 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 become a major vulnerability.

    Cybercriminals also tend to launch brute-force attacks against APIs. With REST APIs, that malicious behavior is easier to catch with standard web application firewalls (WAFs) because it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a brute-force attack is harder to detect. It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks one at a time.

    It’s not likely GraphQL APIs will replace REST APIs overnight. However, as the backend platforms for managing GraphQL APIs become more robust, the number of these APIs being used in a production environment by DevOps teams will dramatically increase—assuming there are no objections from cybersecurity teams.

    In the meantime, the open source community is clearly starting to rally around GraphQL, which should result in innovations applicable across a wide range of use cases. The challenge now is not only determining which type of API to employ and when, but also deciding whether any existing legacy APIs need to be replaced. One way or the other, however, the managing and securing of APIs—like it or not—is only going to become that much more challenging in 2022.