document how to run F-API locally

[surchs]

everything is already running, now you want to see what the rest of world knows

• first follow regular deploy
• add a f-API locally manually via docker run
• query tool needs to point to f-API now: update .env for query tool -> docker compose up again
• manually make a new .env file (call it something else?), put it somewhere else
• embed this new page on the overview with a little bit of context: https://neurobagel.org/overview/
• mention that if the number of local n-APIs increases, show how to add more

for reference: https://miro.com/app/board/uXjVNOZNJ9A=/?share_link_id=768891461417

[surchs]

I think deploying a local query tool with n-API + Graph is not a good idea anymore, now that we have the f-API scenario locally. Consider these deployment scenarios:

• one local node only:
  • deploy 1: 1x n-API, 1x graph, 1x query tool talking to n-API (what we have so far)
• one local node + remote federation
  • deploy 1: 1x n-API, 1x graph (default would be 1x query tool but that makes little sense)
  • deploy 2: 1x f-API, 1x query tool talking to f-API
• two local nodes:
  • deploy 1: 1x n-API, 1x graph
  • deploy 2: 1x n-API, 1x graph
  • deploy 3: 1x f-API, 1x query tool

Any time we ship a new version of the n-API images, it doesn't make sense to then

• shutdown the n-API and update
• redeploy the n-API stack including the query tool AND THEN
• shut down the query tool on every n-API stack except one again

Long story short: I propose that we change our deployment configuration recommendation and files like so:

• deployment recipe "local node": n-API + graph backend
• deployment recipe "f-API": f-API + query tool
• deployment recipe "query tool only": query tool (would only be used if you are running a single n-API locally, i.e. the old default)