> For the complete documentation index, see [llms.txt](https://medomicslab.gitbook.io/medomics-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://medomicslab.gitbook.io/medomics-docs/tutorials/remote-medomics/development.md).

# Development

This section describes where to find the different components for development of the remote version of the MEDomics Platform.

## New structure

In order to separate the local client component from the backend server component, so that we can run either independently and use the server without a GUI (like in a remote terminal, through SSH), we had to move files and features to a separate folder, labeled `backend` in the repository.

Express is now at the root of all backend operations, and you can find more details about its usage in the [Backend - Server](https://medomicslab.gitbook.io/medomics-docs/~/revisions/z0wFwbRqAmxlgbHR1M4e/tutorials/remote-medomics/development/backend-server) subpage or its own subpage, [Express Endpoints](/medomics-docs/tutorials/remote-medomics/development/backend-server/express-request-endpoints.md). 

Similarly, the parts of the client that have been altered or added to fit this new usage mode will be described in the [Frontend - Client](/medomics-docs/tutorials/remote-medomics/development/frontend-client.md) subpage.

## Enabling/disabling remote modules

A lot of the modules haven't been fully tested or refactored yet for remote use and therefore have been "locked" behind a blank screen like this:

<figure><img src="https://4288370141-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FUO0RN9PzFLqAgLEwwaSn%2Fuploads%2F7BpXVOy8zXx4ImlmKzj8%2Fimage.png?alt=media&amp;token=c461fcfc-f7f9-4ba3-94f9-73870ac680ca" alt=""><figcaption></figcaption></figure>

In order to reenable a module that has been adapted to the new architecture, find the `REMOTE_READY_COMPONENTS` and `REMOTE_BLOCKED_COMPONENTS` variables around line 35 of `renderer/components/layout/layoutContext.jsx`, as well as the `blockedInRemote` set at line 150 of `renderer/components/layout/layoutManager.jsx`. Those sets are what determines whether or not a module is displayed or shows the error page, and therefore can be used to allow access to modules once they are ready for online use.

## Packing and distributing

Using the new GitHub actions files (located under `.github/workflows`), the server and client can now be packed either together or independently:

* A `server-vX.Y.Z` tag will create a release for **only the standalone NodeJS server**, along with scripts to start and stop it.
  * Uses `serverRelease.yml` to start the workflow, which will use the `package.json` file in the backend folder to gather the correct versions, then `pack_server.js` to create ZIP folders with the necessary (GO files, Python files, start/stop scripts, etc.) to run the server on different platforms.
* A `client-vX.Y.Z` tag will create a release for **only the lightweight Electron client.**
  * Uses `clientRelease.yml` and `electron-builder.client.yml` (practically how it was before the client/server split but without any backend parts attached).
* A `vX.Y.Z` tag will package both together like it used to be in previous, local-only versions.
  * The legacy path, that packs both server and client together (through `automaticBuilding.yaml`)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://medomicslab.gitbook.io/medomics-docs/tutorials/remote-medomics/development.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.