The Language Server Protocol - Building DBChat (Part 5)

Hi there! I'm Shrijith Venkatrama, the founder of Hexmos. Right now, I’m building LiveAPI, a super-convenient tool that simplifies engineering workflows by generating awesome API docs from your code in minutes.

In this tutorial series, I am on a journey to build for myself DBChat - a simple tool for using AI chat to explore and evolve databases.

See previous posts to get more context:

1. Building DBChat - Explore and Evolve Your DB with Simple Chat (Part 1)
2. DBChat: Getting a Toy REPL Going in Golang (Part 2)
3. DBChat Part 3 - Configure , Connect & Dump Databases
4. Chat With Your DB via DBChat & Gemini (Part 4)

What is LSP and How Does It Relate to DBChat?

With DBChat, the idea is to explore and evolve databases with simple chat.

The most natural place for the above to happen is in the code editors we use day to day: VSCode, Cursor, Jetbrains, etc

The problem here is that - there are many editors/IDEs, which means we may need to build many extensions/plugins to get the desired level of developer coverage.

So - the "obvious" solution is to take out the core and implement it as a separate component, and then let the core power the various "UI" within extensions/plugins in different editors.

Essentially LSP is just that - it is the "backend server" for "extension frontends".

This is my understanding of LSP. The official definition of LSP is as follows from Microsoft:

Implementing support for features like autocomplete, goto definition, or documentation on hover for a programming language is a significant effort. Traditionally this work must be repeated for each development tool, as each provides different APIs for implementing the same features.

The idea behind a Language Server is to provide the language-specific smarts inside a server that can communicate with development tooling over a protocol that enables inter-process communication.

The idea behind the Language Server Protocol (LSP) is to standardize the protocol for how tools and servers communicate, so a single Language Server can be re-used in multiple development tools, and tools can support languages with minimal effort.

LSP is a win for both language providers and tooling vendors!

LSP Events (from the Editor Extension)

The first part of LSP is editor events. Here are things a user may do:

1. Open document
2. Edit text
3. Execute "goto definition"
4. Close document

As these events happen, some processes must be initiated to make them work.

Fulfillment of Events (from the server side)

For each of these events, the server is supposed to use its internal representation to provide appropriate responses.

For example on receiving "Open Document" event, the server may load the file contents into memory.

And on closing the file, the server may clear the memory for other programs to use.

LSP Event Samples - Goto Definition

The following is the Goto Definition request from any LSP enabled editor:

{
    "jsonrpc": "2.0",
    "id" : 1,
    "method": "textDocument/definition",
    "params": {
        "textDocument": {
            "uri": "file:///p%3A/mseng/VSCode/Playgrounds/cpp/use.cpp"
        },
        "position": {
            "line": 3,
            "character": 12
        }
    }
}

Response from the LSP server:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "uri": "file:///p%3A/mseng/VSCode/Playgrounds/cpp/provide.cpp",
        "range": {
            "start": {
                "line": 0,
                "character": 4
            },
            "end": {
                "line": 0,
                "character": 11
            }
        }
    }
}

LSP Servers in The Wild

Python

• Python (pyright)
• Python (palantir)

Typescript

• TypeScript (theia-ide)

CSS

• CSS (vscode-css-languageservice)

More example servers can be found at awesome-lsp-servers

The Specification

You can find the specification for the LSP in Microsoft's doc pages

Overall, we see a large number of messages/events defined by the protocol in the following areas:

1. Lifecycle management: Initialize, Exit, etc
2. Doc Sync: Save, Update, etc
3. Language support: Goto, Find, etc
4. Workspace management: Create File, Delete File, etc
5. Window Features: Show Notification, Log Message, etc

With such a comprehensive set of events/messages, LSP enables us to build multi tool, multi-platform plugins and extensions for various languages

Next Steps

Nowthat we have an overview of LSP, in the upcoming posts we will try to get an LSP going for DBChat. And once we have a basic LSP, we will attempt to build a nice and friendly UI for VSCode/Cursor first, and hopefully for other IDEs as well in the future.