Editorial Calendar for February 2016
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: ChatGPT darling OpenAI wants people to write code in English, and the unintended consequences of blocking shared accounts. (more…)
The onset of COVID-19 accelerated digital transformation-related initiatives like cloud migration, microservices, observability and CI/CD, giving long-delayed projects the budget and staffing they needed to build momentum. After almost three years of increased investment and accelerating progress, CTOs and software development teams are navigating how to enable the improvements in time-to-market and customer experience that they set out to achieve. In 2023, we’ll see enterprise DevOps mature and expand its business impact by placing a central focus on quality, delivering improved time-to-market, customer satisfaction and productivity.
The past three years have seen massive growth in cloud computing, observability and pipeline automation as enterprises raced to deliver new, high-quality digital experiences to consumers. Cloud spending alone increased from $270 billion in 2020 to 397.5 billion in 2022, according to Gartner. With new technologies in place, the focus shifts to processes that deliver business agility and efficiency.
Under increased pressure to deliver faster, businesses need to revisit, evolve—and, in some cases, undo—decades of risk and change management practices built around brick-and-mortar experiences and long software release cycles.
As digital engagement increases, so will expectations for software quality and scalability. We’ll need to invest in new tools and practices—from testing to observability and beyond—to ensure that we’re meeting or exceeding those expectations.
The economic uncertainty will compel us to look for ways to improve productivity and decrease waste. Quality practices are central to both. We’ll continue to look for ways to shift left and catch defects early in our pipeline when they are the least expensive to fix. We’ll want to optimize our build, integration, testing and deployment processes to identify bottlenecks and causes of rework that drain the productivity of so many teams daily.
DevOps, with its emphasis on automation and collaboration, will connect the dots between operational goals, technological investments and improved software. Established frameworks like DORA give software development organizations concrete ways to measure the efficiency and effectiveness of delivery pipelines. The key metrics outlined by DORA—deployment frequency, lead time for changes, change failure rate and time to restore service—enable teams to align on where they can improve development practices and quality practices.
The value of digital transformation and DevOps will also extend even further across the enterprise as CTOs evaluate DevOps practices with structured assessments such as DORA. With several years of accelerated digital transformation under our belts, the software development industry can build out a broader definition of DevOps performance over time. The DORA framework sets the stage for understanding how engineering practices impact the customer experience and, in turn, company growth. In one example, Liberty Mutual, a company prides itself on exemplary customer service, is already seeing how DevOps performance connects to business success.
Architect Justin Robinson notes in their roundtable on data-driven decision-making and DORA metrics: “For organizations, this is improved organizational performance. If we want to keep investing in great tech and serving our customers as best as possible, [we need] behaviors and practices that we can adopt to continuously get better and hit on every front here. Happier engineers, a better culture and a better bottom line for our company.”
In 2023, more enterprises will harness DORA to measure DevOps performance and its impact on company growth.
We’re already seeing how metrics like deployment frequency can support an organization’s ability to attract and retain users. According to the 2022 Testing in DevOps Report, teams that increased deployments by 50%-100% were two-and-a-half times more likely to report high user satisfaction. The ability to innovate—without introducing defects to users—is the next frontier in DevOps success. Quality engineering will serve as a safeguard for DevOps teams so they can deliver new features faster and with confidence.
The Testing in DevOps Report also illustrated the growing connection between digital transformation, DevOps and quality engineering. A full 88% of teams with highly automated pipelines and mature DevOps practices reported high test coverage, which in turn is connected to high customer satisfaction. Test coverage, a core metric for quality assurance teams, is becoming the connection between code and customers throughout development. Quality teams will expand their testing strategies to cover more aspects of the customer experience, including non-functional attributes like performance and accessibility. Automation, particularly automated testing embedded in CI/CD pipelines, will allow teams to adopt these additional quality factors without slowing deployments.
2023 is shaping up to be an unpredictable year in technology. But with the momentum propelling digital transformation to an enterprise-level priority, engineering leaders have the data and the tools to shift focus from DevOps processes to transformative outcomes. DevOps maturity, measured and improved with DORA, will help organizations extract more value from their digital transformations by supporting greater innovation and better customer experiences. Quality engineering, augmented with new testing strategies that measure more of the customer experience, will play a critical role in this evolution by enabling development teams to move faster with confidence.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (more…)
OpenAI’s generative pre-trained transformers (GPTs) bring powerful AI language models to every IT community. Within the past few months, ChatGPT has become an incredibly popular derivative of GPT. GPT also has the potential to shake up the DevOps and DevSecOps communities. This article will provide an overview of GPT, its history, current status and future effects on IT, especially DevOps.
Understanding the difference between supervised and unsupervised learning is essential before understanding GPT. Machine learning and artificial intelligence (AI) use unsupervised and supervised learning approaches. A supervised model uses labeled data to predict outcomes, while an unsupervised model does not. In general, supervised models have some limitations. They need a large amount of annotated data to learn a particular task, which is often unavailable, and they also need to generalize beyond the task for which they were trained.
A generative language model is a class of statistical models that differ from discriminative models. You can, for example, generate photos of animals that look like real ones using a generative model. Whereas with a discriminative model, you can determine whether an animal is a dog or a cat. Generative models can assign probabilities to a series of words, such as those that predict the next word or sentence. A generative pre-trained transformer is unique because it uses both unsupervised and supervised learning from unsupervised unlabeled text and follows up with discriminative supervised fine-tuning.
GPT-based models—ChatGPT, for example—always return the text “I am” when asked, “I think, therefore …” On the other hand, if you ask ChatGPT, “Why did the rabbit cross the road?” it may respond thusly:
“The age-old riddle still awaits an answer: Why did the rabbit cross the road? It’s a mystery that has stumped people for centuries and will likely remain an enigma for years to come.”
In this way, we can better understand how GPT-3 works. When asked, “Why did the rabbit cross the road?” most humans will answer, “To get to the other side.” A Google search for “Why did the rabbit cross the road?” mainly yields joke punchlines on the first page of the results. GPT doesn’t differentiate between humorous or cynical answers or specific matter-of-fact answers. The model makes only guesses based on the data. Since, in this example, most of the highest-ranked answers are jokes, GPT’s answer is enigmatic at best. GPT is not pixie dust; it doesn’t have a sense of humor, is not sentient, doesn’t understand juxtapositions and, most importantly, doesn’t evaluate context. As another example, I asked a GPT-3 tool to provide biographical information about two individuals. Abraham Lincon was the first. Approximately ten paragraphs of accurate facts were generated by the GPT-3 tool. Second, I used Gene Kim, the author of The Phoenix Project and The DevOps Handbook. GPT-3 began inventing facts about the companies he worked for by the second paragraph. Additionally, it suggested that he had spoken at TEDx. While a Dr. Gene Kim has spoken at TEDx, that Dr. Kim is an opthamologist.
GPT was released for the first time on June 11, 2018. Sometimes it is referred to as the GPT-1 model. A large dataset of online books was used to train it. A database called BookCorpus also was used for training. There were 7,000 unpublished books in the original BookCorpus dataset at the time of training.
OpenAI’s GPT-2 model was created in 2019 as a direct scale-up of the original GPT model. There were ten times as many parameters and ten times as much data in that training set. The GPT-2 dataset was based on an internal OpenAI dataset called WebText. A focus was placed on the quality of the documents when scraping web pages for this tool. The authors scraped all Reddit outbound links receiving at least three upvotes. GPT-2 used about 40GB of Internet text, 8 million web pages, and 1.5 billion parameters. In neural networks, parameters are often used as synonyms for weights (found more often in statistics literature). Parameters in GPT are the weights and biases of the dataset and generally indicate the power.
As the third-generation language model, GPT-3 was introduced in May 2020. It has 175 billion parameters, making it more accurate than its predecessors—an increase of tenfold in capacity over the next largest NLP model available. Sixty percent of GPT-3’s weighted pre-training dataset is filtered Common Crawl. Common Crawl is a nonprofit organization that crawls the web and makes its archives and datasets freely available. Since 2011, Common Crawl has collected petabytes of data. About 37% of the GPT-3 sources were WebText2 and other sources, while about 3% came from Wikipedia. OpenAI Codex was also included with GPT-3, which generated code and served as the basis for GitHub’s Copilot.
As part of its training, GPT-3 used data available until November 2019. Thus, GPT-3 was unaware of events beyond January 2020. COVID-19, for instance, was unknown to it. Even so, it did have extensive knowledge of coronaviruses, pandemics, Wuhan and SARS. As of September 22, 2020, Microsoft, through a considerable investment, received exclusive permission to use GPT-3; others can still access GPT-3’s public API, but Microsoft is the only one with access to the underlying model. OpenAI developed DALL-E in January 2021, which generated images using GPT-3. OpenAI introduced models in the “GPT-3.5” series on November 30, 2022, including the now-famous ChatGPT, derived from a model from the GPT-3.5 series. Unlike GPT-3, GPT-3.5 includes data up until November 2022.
I have used several AI language model tools in the past few years based on GPT-3. It is used by Grammarly and by some useful writing tools like Jasper.ai and Wordtune. I also have had great success with GPT-3 research tools like Frase.io and Genei.io. One of my more recent go-to tools is called QuillBot. In my experience, these tools are aids, not replacements for writing. When I first started using these tools, I was writing a book about Dr. W. Edwards Deming. I would get inaccurate information about Dr. Deming’s childhood from a GPT-3-based tool. One time, it said he had six siblings. In fact-checking, GPT-3 confused Dr. Edwards Deming with Dr. Richard Deming. With surgically precise input, the results could be more accurate. One of my findings was that if I used a GPT-3 on a well-known subject, the information was primarily precise; however, lesser-known topics produce fewer facts. Furthermore, I learned from the documentation that when people talk about training GPT-3 models, what they really mean is that you can input a maximum of 2,048 linguistic tokens, which is about 1,500 words. In GPT-3, content is predicted by analyzing past context, one word at a time. The content you input to GPT-3 significantly impacts its output. As a result, it pulls words from a shortlist and calculates their probability of being used. A great set of tutorials on using GPT-3 can be found on Jasper.ai. This figure shows how Jasper (which is based on GPT-3) word prediction works.
People have accomplished some remarkable things by using the 2,048 tokens creatively, but complex training still needs to be improved. Due to the Microsoft deal, the original GPT models were close sourced, and robust training of GPT-3 models is unlikely to happen any time soon.
Where does all the hype come from? Despite its limitations, GPT-3 has created some unique industry artifacts. DALL-E and Copilot by Github are excellent tools. On September 8, 2020, the Guardian published an article titled, “A robot wrote this entire article. Are you scared yet, human?” This article was written by GPT-3. Using GPT-3, some full-blown novels have also been written; they’re not horrible, but they could have been better. According to a study conducted by Drexel University in 2022, systems based on GPT-3 could be used to screen for Alzheimer’s disease at an early stage. Just five days after its launch, ChatGPT surpassed one million users. It took 41 months for Netflix to reach one million users and 10 months for Facebook to reach one million users. By the end of the first quarter of 2023, ChatGPT will have over one billion users. Based on GPT-3.5, ChatGPT is more robust and up-to-date.
How smart is ChatGPT? Using a verbal-linguistic IQ test and Raven’s ability test, ChatGPT has an IQ of 147. GPT-3.5 has passed the United States bar exam, CPA exam and U.S. medical licensing exam. People often ask if it is plagiarism to use GPT-3. Technically, the answer is no. The GPT datasets are estimated to represent 300 years of pre-training with a connection of trillions of words. However, using these tools for rewriting other people’s work is, from an ethical viewpoint, plain and straightforward plagiarism. A recent set of tweets by Greg Brockman, president and co-founder of OpenAI and Sam Altman, CEO of OpenAI, sums up the current status of ChatGPT.
AI learning models based on GPT-3 are here to stay. From grammar correction to proposal writing to code generation, GPT-3 has revolutionized everything. In my opinion, GPT-3 still needs to solve some challenges before it is of actual value to DevOps and DevSecOps patterns and practices. For example, a great use case for GPT-3 is training it to deal with organizational incidents. If a GPT model could be trained this way, it would become an excellent tool for providing adaptive diagnostics. Based on the current GPT implementation, this is very difficult or impossible. Another example would be to train the model with the organization’s IT risk policies and enable predictive solutions. The opportunities are endless.
An alternative to GPT-3 is InstructGPT, which OpenAI describes as more truthful and less toxic. It has also been noted that GPT-3 can generate untruthful outputs. GPT models aren’t generally aligned with their users. InstructGPT models follow instructions much better than GPT-3. Furthermore, InstructGPT produces more truthful and less toxic outputs. Therefore, they generate fewer harmful outputs and more facts. The InstructGPT models use human feedback as part of the training model. Some of the real power behind ChatGPT is that it uses InstructGPT along with GPT-3.5. Some of my upcoming research will focus on prototyping some of the complex opportunities DevOps and DevSecOps practitioners currently face using InstructGPT.
Node.js is an open source development platform for running JavaScript code on the server side. Node is useful for developing applications that require a persistent browser-server connection and is often used for real-time applications such as chat, social applications, or news feeds.
DevSecOps is a way for development, security, and operations teams to work together throughout the project life cycle. It is often implemented by adding security to existing DevOps teams and agile processes.
The idea behind this collaboration is to incorporate security early in the development process. This is called shifting security left. As security moves to the “left” of the development process, application vulnerabilities and bugs are discovered and addressed faster. This leads to more secure product releases with a reduced need to apply patches and troubleshoot in production. Applying DevSecOps to Node.js development can improve both the efficiency and security of Node.js projects.
Here are a few cyber threats that affect many Node.js applications.
XSS attacks inject manipulated client-side JavaScript code. Web apps are vulnerable to XSS if they don’t validate inputted hostnames from the DNS. Attackers can use forms to enter malicious scripts and hack into the system. In some cases, entering code into the filename can trigger cross-site scripting in the target browser.
A hacker can use your file upload form to hack into your system. There are many ways for this vulnerability to lead to a system compromise. Though usually mitigated by modern front-end frameworks, in some cases it may happen that putting javascript into the filename will trigger XSS in a user’s browser, allowing the theft of session IDs. In other cases, an attacker might get sensitive server information by uploading a file to the Node.js server and running it by exploiting a path traversal vulnerability.
Developers are responsible for writing secure application code, but it’s impossible to fully guarantee the code’s security when using open source components. A code injection attack involves injecting malicious code into the target system and forcing the application to execute it, allowing attackers to access the codebase. Inadequate data validation often results in code injection vulnerabilities.
Cookies help web apps identify specific users by storing user actions in the underlying infrastructure (e.g., an eCommerce shopping cart that remembers the items a customer selects).
Developers should use custom names for cookies (rather than defaults) to prevent attackers from identifying and targeting cookies and extracting data.
Brute force attacks often affect Node.js applications. An attacker randomly generates millions of passwords to find one that works, logging in to the application. You can prevent brute force attacks by strengthening the authentication mechanisms, limiting the number of permitted login attempts from a single IP, and encrypting stored passwords (using bcrypt.js).
This type of session hijacking forces an authenticated user to execute malicious actions on the target web application. The attacker hijacks a legitimate user’s session to bypass security controls and change the application’s state. CSRF can force users to transfer funds or change their account details, potentially compromising the web application’s security.
A compromised, weak, or incomplete authentication mechanism is a common vulnerability. Many developers think of authentication as something that “just works”. However, authentication can easily be bypassed by attackers if not implemented correctly.
In Node.js, you have the option of using the default Node.js authentication solution. There are a few things to keep in mind:
Alternatively, use one of many third-party solutions available for application authentication, which may be superior to built-in Node.js functionality.
There are many things to consider when building error handling functionality:
Code linters help identify various issues in code before compiling. They let you detect the most common issues and ensure you follow best practices.
Code linters have their own rules, which you can customize according to your requirements. Before using a linter, make sure you enable rules related to security vulnerability detection in the linter configuration.
A good logging library provides developers with powerful troubleshooting and monitoring capabilities. On the other hand, unnecessary or excessive logging affects application performance and consumes more resources. Therefore, you should only use reasonable log levels when deploying applications to production environments.
When constructing log messages, they must be in a format that can be read and understood by humans and machines. Logging ambiguous messages can lead to misunderstandings among developers. An error message must not only describe the problem but also advise what the user can or should do to fix it.
It is also important to ensure that your logging mechanism captures all relevant information such as IP addresses, usernames, and actions taken.
Never retrieve or store sensitive information in application logs. This violates compliance standards such as PCI and GDPR. However, there are times when you need to record this information for troubleshooting – in this case, it is recommended to mask or anonymize sensitive information before writing it to the log.
Node.js security best practices are well known and security awareness is growing among Node.js developers. However, many organizations don’t have a clear organizational structure for implementing development best practices. Here are a few steps your organization can take to transition a Node.js development team to a full DevOps model:
For example, adding static application security testing (SAST) within the IDE and on every commit. Linters should be deployed centrally with a consistent configuration for all developers in the team.
During the CI/CD process, when a Node.js application is deployed to a staging environment, there should be automated tests that can identify security misconfigurations and integration-related vulnerabilities. Dynamic application security testing (DAST) tools are ideal for this purpose.
No DevSecOps process is complete without a safety net to identify security issues in production. This requires the use of tools like web application firewalls (WAFs), which can detect and block malicious traffic, and runtime application self-protection (RASP), which can proactively respond to attacks. Both these tools provide feedback to DevOps teams to help them identify and remediate vulnerabilities in the underlying application.
By implementing these three stages, you can be sure that Node.js security is not just an ad-hoc practice but a formalized, coordinated process involving developers, operations teams and security experts.
In this article, I explained the basics of DevSecOps and how to secure Node.js:
I hope this will be useful as you implement Node.js security in your DevSecOps organization.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: New ideas bring low-power ML inference, and more big-tech jobs are going. (more…)
2022 was a banner year for innovation, but not only in the traditional “churning out new features” way. Many organizations started thinking about their processes and how to amplify them to maximize efficiency and employee retention. And when they started digging, companies realized that the developer experience was a major pain point that could be rectified–and a ripple effect of positive gains would result.
Companies started looking more closely at how the tools and processes developers use support and enhance their work. Great tools and thoughtful processes boost developer happiness and satisfaction. And when those levels rise, guess what else increased? Productivity, efficiency and employee retention rates.
We saw this trend of developer support take hold last year, but with more work to be done across many companies, we’ll see it continue in 2023 and beyond, impacting just about every facet of tech in new ways. Many companies have realized what does work by trying what doesn’t work and are making big changes from there.
A major player in the changing developer experience has been the shift left approach that’s taken hold in recent years. About 80% of organizations have said they are adopting this idea of moving more of the responsibility for security and compliance to the front of the pipeline to avoid a compliance scramble at the point of delivery. The result, however, is a compliance process that ends up being more complex and less efficient, putting additional burdens on developers.
Involving more people creates more opportunities for security breaches and slows down the entire software delivery life cycle. It also shifts security responsibilities to developers and requires them to do significantly more than is listed in their job description. In fact, 60% of those shifting left said their development team is bearing the burden of the change. Rather than focusing on writing code, developers have been called on to understand regulatory policies, build regulatory controls into their applications or pipelines, inspect massive log files generated by more and more diagnostic tools for security info and spend more time in meetings to discuss audits. That’s not a recipe for fulfilled developers; it’s the path to a loss of innovation.
When developers–or anyone on your team–are tied up in compliance tasks, they aren’t spending that time in profit-earning efforts. This “compliance tax” costs companies an estimated 15% each year–that’s 15% of their time spent managing compliance instead of innovating or providing services that add value. That’s not to say that compliance isn’t important–it’s essential, in fact–but limiting the burden of compliance improves the overall experience of developers.
When developers aren’t innovating, they’re not happy. They want to be writing great code, not translating regulatory governance policies. In today’s culture of quiet quitting, companies simply can’t afford to turn over compliance tasks to developers. It’s a waste of their talent and a surefire way to lose great developers and the chance to attract new ones.
The good news is the compliance tax is largely avoidable. Instead of shifting responsibilities left, shift compliance everywhere. No one person or group, including developers, should be in charge of these tasks–that approach just isn’t comprehensive enough to ensure security and compliance throughout the software delivery life cycle.
Instead, security and compliance should be moved away from a point-in-time part of the cycle to a continuous process built into every step of the life cycle. CI/CD reduces the burden on any one person or group and is proven to be more efficient at catching anything that is non-compliant. When the tools are doing the heavy lifting, the people aren’t making as many mistakes and non-compliant code isn’t slipping through.
Baking in compliance allows developers to spend more time doing what they do best: Creating amazing features. This, more than anything, will boost the developer experience. Developers want to create and, when they experience the right environment and the right resources, innovation tends to happen.
Focusing on the developer experience pays off in more ways than just creating happy employees (though that alone is reason enough to make a change). Innovative developers are the backbone of leading tech companies. When they’re churning out new features that are getting public recognition and are touting a culture with a positive developer experience, companies attract more talented developers and the innovation loop continues.
So, if you’re looking for more innovation in 2023, start where you’ve always started: Your developers. Set them up for success by automating what can be automated and baking in the mundane – yet essential – tasks to truly optimize the developer experience. Then sit back and watch what incredible capabilities your developers can generate.
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: The FAA’s NOTAM database gets corrupted, and Threema shows why DIY cryptography is bad. (more…)
It’s that time of year again—the New Year’s ritual: Time to predict the big trends in your world for the new year. By now you have probably seen dozens of headlines, articles, videos and interviews telling you what big trends will shape the coming year. Here at Techstrong Group, our Predict virtual event is built around this New Year’s ritual. This year, Predict is January 12, 2023 and, not to blow our own horn, but I think it is our best Predict event yet.
What sets this event apart? Well, we have a real Techstrong Research team now headed up by Mike Rothman and Mitchell Ashley who are leading this year’s Predict event. We will have four tracks: DevOps, cybersecurity, cloud-native and digital transformation. Each track will kick off with either Mitchell or Mike presenting a Techstrong Research trends report for that market.
After the trends report, there will be a keynote panel featuring some of the top thought leaders in each of these fields. This will be followed by other sessions that explore what this upcoming year has in store. Many of these sessions will be streamed live on January 12, 2023 and allow for audience questions and input.
But wait—there’s more! One session I am really looking forward to features John Willis and Damon Edwards live at Techstrong Group Studios giving us their personal predictions for 2023. John and Damon need no introduction to the DevOps community. This should be a great session, so don’t miss it. I am also moderating two great panels; one is with C-level executives from CloudBees, JFrog and GitLab and Kohsuke Kawaguchi (KK), the creator of Jenkins and co-CEO of Launchable. The other panel features my friend Emmet Keefe of Insight Ignite who has his finger on the pulse of the digital transformation market.
The best part? We’ll have a live chat available so you can interact with the speakers and network with your fellow attendees. And you can register and attend Predict 2023 for free. That’s right—this analyst-led, daylong virtual interactive event is free. Don’t wait! Head over right now and register here.
Another highlight will be the announcement of our DevOps Dozen winners at the event. This year, the DevOps Dozen broke all of our previous records for both nominations and community votes. It has been quite a tough job selecting the winners from such incredible submissions and nominations.
I haven’t even mentioned the amazing cybersecurity sessions hosted by Mike Rothman or the sessions covering the cloud-native vision with Mitchell Ashley and digital transformation with Mike Vizard. There is just so much great insight you won’t want to miss.
A big thank you to all of the sponsors, panelists and speakers who help us make this event a true standout. If you want to get a head start on learning about big trends for 2023 and how they’ll impact cloud-native, cybersecurity, DevOps and digital transformation, check out these articles and register for Predict 2023 on January 12, 2023. We hope to see you there!
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.
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.
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.
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.
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.
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.
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!