Apollo GraphQL Announces Tighter Integration for Language Server Protocol

On day 1 of the GraphQL Summit James Baxley, Engineering Manager of the Open-Source and Solutions Architecture Team at Apollo GraphQL announced new initiatives for CLI and Editor Tooling during an exclusive interview with ProgrammableWeb. 

Baxley shared during the course of the interview that Apollo GraphQL is engaged in improving its tooling assets based on ongoing end-user feedback. “We're doing a new commitment towards tooling and making it easier for people to understand what they're building and how what they're building will impact what they're trying to accomplish. So, we're spinning up a new tooling team to help to build things like our CLI, our editor integration and just general improvements to how you actually build to GraphQL apps.”, said Baxley.

A key new improvement that Apollo GraphQL is working on is tighter integration with its Graph Manager product and Language Server Protocol (LSP). LSP is a method of communication that allows usage metrics about a GraphQL API that’s registered with Data Manager to be consumed and reported by an Integrated Developer Environment (IDE) such as Visual Studio Code. The end result is that a developer can make programming decisions based on real-time usage behavior. For example, an LSP enabled IDE such a Visual Studio Code with the Apollo VS Code extension installed, can report broken API endpoints right within the programming environment. A developer will see this issue in real-time and can address it immediately and then release a fix directly into the enterprise’s automated Continous Integration/Continous Deployment (CI/CD) process.

Baxley explained the benefit of tighter LSP integration with an IDE, “The sophistication of continuous integration, continuous delivery continues to be a thing that pays off for teams over and over and over again. And what we've done now is connected your graph and brought graph intelligence to your editor and to your continuous integration pipeline so that as the developer, you're still just thinking about the feature you're building and you're focusing more on the user experience and less on the complexities and the risk of making these kinds of changes.”

When asked about the possibility that provided real-time use metrics directly to the programmer would increase rates of change and endpoint deprecation in the API that would result in a condition informally called, Deprecation Hell, Baxley responded, “The risks that runs with Deprecation Hell is that you're doing it so often that teams feel like they're kind of constantly having to keep up and constantly have to keep on the bus. What we want to do is to allow teams to find the right rhythm. We want teams to be able to find their own cadence and to inform the team that, hey, this is deprecated, but that fundamentally it’s a contract saying we're not going to remove it. It's a deprecation. We want you to stop using it. Some companies without these tools choose to keep those fields around forever. And even though they have thousands and thousands of deprecations, their graph itself still is huge.”

Presently the Apollo GraphQL CLI and Apollo VS Code extension support LSP integration. For more information, go here.

Be sure to read the next GraphQL article: Knotel Experiences Success and Challenges Implementing Microservices using Apollo Federation

 

Comments (0)