Determining whether or not to show a link to Inxight should be less of a burden to inxight

[kkelleher]

GSRS is hitting Inxight to determine if it should show a link to Inxight

GSRSFrontend/src/app/core/substances-browse/substance-summary-card/substance-summary-card.component.ts

Line 106 in f46ed1c

this.substanceService.hasInxightLink(this.substance.approvalID).subscribe(response => {

and it happens on list pages for every entry in the list
https://gsrs.ncats.nih.gov/ginas/app/ui/browse-substance

I found this by digging into the instability issues on Inxight, to find that when Inxight is struggling, it is spending loads of time handling /substances/search requests with an approvalId.
From there the access logs showed me that the various flavors of GSRS are making those requests to /substances/search. For example. these are the counts, and the http_referer for those requests.

    517 https://gsrs.ncats.nih.gov/
    397 https://gsrs.fda.gov/
    208 https://app-uksrs-gateway-prod-uks.azurewebsites.net/
    168 https://gsrsp.usp.org/
    163 https://online.uspdictionary.com/
     95 -
     62 http://localhost:8081/
     50 https://cn.bing.com
     36 https://precision.fda.gov/ginas/app/ui/browse-substance

I think there are a few ways to fix it.

1. Always show the link.

• This mostly works because Inxight is supposed to have a page for every page that GSRS has, but that isn’t always true because the GSRS version will usually be a bit ahead of Inxight, so new substances in GSRS would show a link that won’t resolve to a valid substance in Inxight

2. Hit the stitcher API instead

• https://stitcher.ncats.io/api/stitches/latest/{{unii}}
• This should work and be fast, because all those stitcher responses are prerendered, and the webserver is just serving up static files.
• and since the GSRS frontend is just determining if there’s any response at all it shouldn’t matter that the data returned is different

3. something else, because there’s always other options I didn’t think of