Discuss desired subdomains for Neurobagel services hosted by us

[alyssadai]

• all n-APIs could become https://nodes.neurobagel.org/node-name
  • need a dedicated subdomain for query tools and f-APIs?
• Discuss renaming tools and UI repo and domains
• ...

To complete this issue:

• Make a list of all of the services we host right now
• Group these services according to what subdomains they can share
• Discuss with the team what the subdomain and paths should be

Goals

• use fewer subdomains and more paths

• group related things / make them look more nice / expected

• make our subdomains an example for other places to follow

  • specifically wrt full-stack deploy + nginx

Subdomains we have right now

• api-bic
• api
• crm
• digest
• enigma-federate
• enigma-query
• federate-bic
• federate
• indi
• internal
• llm-query-api
• node
• plausible
• qpn
• query-bic
• upload
• annotate
• portainer
• query
• status
• upload-ui

Sensible grouping:

• node.neurobagel.org or api.neurobagel.org
  • node -> not used yet, could make it point to list of nodes or homepage
  • api -> /public/openneuro
  • api-bic -> /internal/mni (might also need a separate subdomain for internal)
  • indi -> /public/indi
  • qpn -> /public/qpn
• federate.neurobagel.org
  • federate -> / (i.e. stays the same)
  • enigma-federate -> /internal/enigma
  • federate-bic -> /internal/bic
• internal.neurobagel.org
  • internal -> not use yet (afaik), so let's ignore / reuse
  • plausible -> /plausible
  • status -> /status (not sure if this is possible due to GH pages setup, in which case I'd say: let's keep status.neurobagel.org)
  • portainer -> /portainer
  • crm -> not used any more. retire
• service.neurobagel.org (or app.neurobagel.org)
  • query -> /public/query (definitely keep an alias / link from query.neurobagel.org for a long time and ideally also monitor which is used more. Would also have to update OpenNeuro and ANC link)
  • annotate -> /public/annotate (same here, maybe not wise to change)
  • upload -> /public/contribute-openneuro
  • query-bic -> /internal/query/bic
  • upload-ui -> ...
  • digest -> /public/digest (also needs alias)

[alyssadai]

Thanks @surchs for the suggestions! Some initial thoughts below.

For a single node we host with a full-stack deployment, what would be the different paths for

• the node API
• the federation API
• the query tool
  ?

e.g., for our internal BIC node, we currently have:

• api-bic.neurobagel.org
• federate-bic.neurobagel.org
• query-bic.neurobagel.org

from your grouping above, IIUC, the current proposal is something like:

• api-bic.neurobagel.org -> node.neurobagel.org/internal/bic
• federate-bic.neurobagel.org -> federate.neurobagel.org/internal/bic
• query-bic.neurobagel.org -> service.neurobagel.org/internal/query/bic

I think the node.neurobagel.org and federate.neurobagel.org stems make sense. Another option could be the more explicit napi.neurobagel.org and fapi.neurobagel.org. However, for either, I'd suggest to have a single subdirectory /bic or /bic-internal rather than internal/bic, since:

• we can follow a consistent structure of node.neurobagel.org/<name-of-node-we-host> = easier to remember, makes the URL less cluttered for API requests
• it's not obvious to me in what other scenario we would use the /internal parent path / what it means (is it nodes that we host which are also private?)

To replace query-bic.neurobagel.org, rather than service.neurobagel.org/internal/query/bic, I'd propose as alternatives:

1. query.neurobagel.org/bic
   or
2. bic.neurobagel.org/query

I think option 2 also represents a more generic alternative structure to having subdomains that group by service type, which is having them group by node instead. e.g., if we want to keep the BIC services separated from our public services (since the BIC essentially represents our true local node), we could use bic.neurobagel.org as the stem for all services:
- bic.neurobagel.org/query
- bic.neurobagel.org/napi
- bic.neurobagel.org/fapi

This would probably be most similar to what an external institute's deployment (e.g., ANC) would look like as well, and so is both a nice example while also being intuitive. It makes the path configuration very straightforward from the perspective of the Docker Compose recipe & reverse proxy (since it aligns with Neurobagel's understanding of what a 'node' is). Similarly, we could consider openneuro.neurobagel.org/api, openneuro.neurobagel.org/upload, etc.

On the digest, I would prefer to keep it to its own subdomain since:

• it's not really related to any of our other services (of which there might be multiple deployments we host, necessitating a common subdomain)
• it should be easy to remember for Nipoppy users who may not use Neurobagel
• it may make sense to be switched over to a Nipoppy subdomain at some point (? need to consult with Nipoppy maintainers) b/c of its Nipoppy dependency + to minimize confusion between Nipoppy and Neurobagel conceptual domains

[surchs]

Thanks, those are good points. I think there are roughly three things we have URLs for:

• tools that are meant for anyone, i.e. not tied to a specific dataset or node
  • public query, public federation API, annotation tool, digest, future cool things
• public nodes that we host (i.e. the n-APIs for these)
  • openneuro, indi, qpn, ...
• project specific things that are either tied to a specific node (but aren't the node itself) or a collaboration (e.g. enigma-pd)
  • openneuro-uploader, the bic-query portal (and corresponding f-API), enigma-pd query portal and future nodes.

People are most likely to have / make bookmarks or remember the URLs for the public tools, so changing them might be a bit rough for that reason - or at least we need to keep the alias. For nodes and project tools that's likely less the case

[alyssadai]

Decisions:

• central, node-agnostic / multi-node services such as the public query tool, annotation tool, federation API etc. will keep their own subdomain
  • generally, public frontend services should be accessible at the subdomain root
  • api.neurobagel.org is an exception because it is actually the OpenNeuro API - it will become openneuro.neurobagel.org/api
• non-federation nodes as well as full-stack nodes will have a node-based subdomain, e.g. openneuro.neurobagel.org, indi.neurobagel.org
  • if the node has a query tool, place it at the root path /
• our upload service will have its own subdomain: upload.neurobagel.org
  • UI accessible at root
  • API accessible at /api
• plausible will remain accessible at plausible.neurobagel.org
• status = status.neurobagel.org

We will remove entirely (not replaced or renamed):

• internal
• crm
• node
• upload-ui
• portainer

[surchs]

Closing, implementation is tracked in #231