IHTSDO / sct-browser-frontend

HMTL & Javascript for the front end for the SNOMED CT Browser.
http://browser.ihtsdotools.org
Other
84 stars 32 forks source link

Basic installation - more clues for mortals plz #70

Closed abelardy closed 1 year ago

abelardy commented 2 years ago

Like another newbie earlier this year, I'm struggling trying to hook up the browser front end to a Snowstorm backend with both running inside the same virtual Ubuntu machine, but with neither Dockerised for now. I've got the Snowstorm half of the equation up and running and populated with data, but the README instructions for installing the browser have proved to be a bit too telegraphic for me. Perhaps rather more Ninja Developer knowledge is assumed (or required?) than I have!

For example, the "Run locally" section of the README instructs how the local api-endpoint information configuration should be written ... but not where. The example syntax looks like its a fragment of the nginx.conf file within the docker subfolder, but I'm therefore guessing that this is only relevant if you're trying to run the thing Dockerised, which for now I am not.

Also, if the original download distro for the browser is unzipped into a working subfolder somewhere, and grunt then run, what is the minimum set of files and subfolders that would then need to be copied across to an apache "home" folder in order for the thing to then actually work when I open a browser on http://localhost/index.html ?

Chris-Swires commented 2 years ago

Hey @abelardy

Basic setup instructions are as follows:

Clone repository onto the server. Run npm install Run grunt

This will create a number of files, all contained within: /snomed-interaction-components/dist/

If you wish to use a home folder with apache I'd then copy the entire repository over for simplicity.

You will still however need some web server config. The nginx example is intended for local direct usage, docker, and we actually use something similar in our server environments.

The relevant section here is:

location /snowstorm/ {
      proxy_pass {{locationOfSnowstormInstance}};
    }

The browser code is simply calling the endpoint '../snowstorm' - it isn't aware of the location of a configured snowstorm instance. The proxy_pass allows the server to route that request to the backend installation.

I believe mod_proxy is the equivalent function in Apache but I'm not hugely familiar.

abelardy commented 2 years ago

So....the endpoint URL to which /snowstorm has to be internally redirected by some variant of a proxy pass configuration, is the same http://localhost:8080/ that brings up the SWAGGER UI on the same machine?

I'm also wondering then how the other locations that nginx.conf also seems to redirect may need to be similarly treated:

/ /snowstorm/snomed-ct /browser /fhir /ecl

...noting in passing that the vanilla /snowstorm variant that you've already mentioned isn't itself part of the nginx configuration..

Chris-Swires commented 2 years ago

Are you referring to the nginx.conf from the docker config?

Chris-Swires commented 2 years ago

To answer the first question though, sorry - yes. Exactly that.

Looking at that config file, the /browser section is simply an alias for root - so would only come into play if you visited localhost/browser - fhir is unnecessary to access the fire API within snowstorm locally, it's adding cors to allows cross site Comms with an external source.

The ecl config I'll check on, same with the more specific snomed-ct route, but should also be unecesary.

kaicode commented 1 year ago

Closing as expired.