Cómo el protocolo del servidor de idiomas afecta el futuro de los IDE

El lanzamiento de Visual Studio Code afectó por sí solo al ecosistema de desarrolladores de tal manera que no hay vuelta atrás ahora. Es de código abierto, gratuito y, lo que es más importante, una herramienta superpoderosa.

Pero con VSCode, Microsoft dio vida a otra cosa súper importante en 2016, que es menos conocida. Se llama Protocolo de servidor de idiomas.

¿Qué es el protocolo de servidor de idiomas?

Language Server Protocol (LSP) es un protocolo o una forma de hablar con servidores de idiomas (como HTTP o FTP).

Los servidores de idiomas son programas especiales que se ejecutan en servidores normales. Toman el metaestado del editor en el que está codificando (por ejemplo, dónde se encuentra el cursor actualmente dentro del editor, sobre qué token está pasando el cursor en este momento) y devuelven un conjunto de acciones / instrucciones: qué token debería aparecerá a continuación, qué debería suceder cuando CMD / Ctrl-clic en ese token, y así sucesivamente.

Esta comunicación ocurre usando un conjunto de reglas definidas por el protocolo. El protocolo del servidor de idiomas se puede considerar como una versión reducida de HTTP y se comunica solo en JSON-RPC.

¿Por qué se requiere LSP?

¿Ves esos elegantes mensajes de error y autosugestión apareciendo en VSCode todo el tiempo? ¿Y cómo, con solo agregar una extensión simple del mercado de VSCode, obtiene toda la potencia de IntelliSense para un lenguaje completamente diferente como C, Python, Java, etc.? Eso viene de LSP.

El soporte para autocompletar e IntelliSense para HTML / CSS / JavaScript viene integrado en VSCode (al igual que PyCharm viene integrado con soporte Python). Sin embargo, se puede implementar el mismo soporte para otros idiomas utilizando el Protocolo de servidor de idiomas para esos idiomas.

LSP en editor de Mónaco

¿Qué es JSON-RPC?

JSON-RPC son las siglas de JSON Remote Procedure Call. Es una arquitectura (similar a cómo REST es una arquitectura) pero con la unidad fundamental siendo una llamada a procedimiento en lugar de un punto final de API en el caso de REST.

Aquí hay una carga útil simple para JSON-RPC:

// Request curl -X POST —data '{ "jsonrpc": "2.0", "method": "runThisFunction", "params": [ "some-param", 2 ], "id": 1 }' // Response { "jsonrpc": "2.0", "result": "codedamn", "id": 1 } 

En este ejemplo, enviamos una carga útil codificada en JSON siguiendo la especificación de RPC. Si el servidor está configurado para manejar JSON-RPC correctamente, ejecutará el método runThisFunctioncon los parámetros pasados ​​y devolverá el resultado en el formulario que se muestra.

LSP + JSON-RPC

LSP usa JSON-RPC para comunicarse con el servidor remoto. Sigue esto:

Content-Length: \r\n\r\n 

Para escribir un ejemplo, será así:

Content-Length: 78 {"jsonrpc":"2.0","method":"runThisFunction","params":["some-param",2],"id":1} 

El LSP requiere que pase el Content-Lengthencabezado seguido de 2 CRLFtokens \r\n. Cuando los servidores de idiomas en ejecución cclsreciban esto, responderán con un mensaje apropiado:

servidor ccls

Por supuesto, en el ejemplo anterior, puede ver que cclsdice que no hay ningún método llamado runThisFunction. Pero puede ver que el servidor remoto también responde con un Content-Lengthencabezado con una especificación JSON-RPC.

¿Por qué todo esto importa?

Con la introducción de un protocolo LSP formal, Microsoft redujo el famoso M x Nproblema a un M + Nproblema.

M = Diferentes lenguajes (C, C ++, PHP, Python, Node, Swift, Go, etc.)

N = diferentes editores (VSCode, Eclipse, Notepad ++, Sublime Text, etc.)

Anteriormente, para que los editores M admitan N idiomas, necesita soluciones M * N. Es decir, cada editor tuvo que implementar el soporte nativo para cada idioma de manera diferente.

Con la introducción de LSP, el editor solo necesitaba implementar el soporte para el Protocolo de servidor de idiomas. Una vez que lo hizo, cualquiera que cree un servidor de idiomas (siguiendo los estándares de LSP) puede integrarse sin problemas con el editor, ¡sin que el editor "sepa" inteligentemente en qué idioma está trabajando!

El futuro de los IDE

A medida que aparezcan más y más idiomas con sus servidores de idiomas, las personas tendrán más capacidad para elegir el editor que más les guste.

Ya no tendrá que ceñirse solo a XCode para el desarrollo de Swift o PyCharm para Python. No solo esto, sino que los LSP también se pueden implementar directamente en JavaScript para admitir IntelliSense en el navegador, como lo hago en codedamn, ¡una plataforma para que los desarrolladores aprendan y crezcan! ¡Es un momento emocionante para estar vivo!

Paz,

Mehul