What endpoints is the "backend" server hosting

#1

Is there documentation for on the endpoints the Theia backend server for my application will be serving up? (either swagger-esq, or otherwise)

I understand the actual modules that will be used are somewhat dynamic, based on some kind of dependency graph and depending on what I’ve got in my package.json… But the dependency injection and auto-magic make it kind of unclear at a glance (or I’m looking in the wrong place :laughing: ). What I’d really like to know is:

  • What endpoints the server for the IDE I’ve configured will be handling (and what is there API)
  • What in the frontend will be calling them.

Thanks :blush:

#2

Hey @jdoig,

as you’ve already guessed, HTTP endpoints can be added pretty dynamically by Theia extensions, and therefore there is no easy way to document all HTTP endpoints.

Generally, the framework has only a few actual HTTP endpoints, as almost everything else is getting handled via RPC over websocket. You can find all endpoints via GitHub search looking for usage of express.

As for the callers, most of that stuff is getting called by the browser itself, we only have very few fetch calls here.

#3

Thanks for that @msujew …and those RPC calls, can I find them documented somewhere. Sorry I’m just not very comfortable with having this largely unknown node server being generated dynamically. Thanks :blush:

#4

@jdoig Any service instance on the backend can be potentially exposed to the RPC backend and called from the frontend. If you want to learn more about that, you might be interested in this documentation page. You can find all known exposed backend services here.

Generally, Theia does not offer a clear HTTP/RPC API. Everything is very much based on services implementations that just call each other, independent of any frontend/backend boundaries (realised through the RPC system). This might make more sense if you take a closer look at Theia’s architecture.

#5

Thanks again, that example commit in the documentation really helps!
It looks like if I want to move from using electron and node with websockets, to using Tauri with events/invokes it’s mostly a matter of: changing the WebSocketConnection behaviour to call Tauri as required (and then the complex and tedious matter of getting all that functionality on the backend compiled as WASI for Tauri to proxy the RPC to :sweat_smile:… Though it seems worth it to be free of node and electron)