Use this document, remove any extraneous content from top/bottom. Read line by line and extract the appropriate content.

Then use this in the same fashion as the geneids function.

1. Upload file to Minio
2. POST request with metadata.json, which lists bucket/file
3. Set key/value pairs in Redis based on parsed content from file
4. Create second function to handle GET requests

1. Write function that reads metadata.json and get the location of the gff3 file
2. Read the gff3 file, checking for every gene ID and name
3. For every ID/name, hit the endpoint and check the response status

See dictyBase/genomepage#35

In case of non existent gene name, say something like this,
https://betafunc.dictybase.org/genes/name/tbc1d5B, the error response returns,

{
  "meta": {
    "creator": "kubeless function api"
  },
  "source": {
    "pointer": "/genes/name/tbc1d5B"
  },
  "detail": "Cannot read property 'attributes' of undefined",
  "title": "Cannot read property 'attributes' of undefined",
  "status": 500
}

The detail and title at least expected to be informative, for example The gene name blah blah does not exist in the database. In addition, the following issues should be addressed,

1. This is not a HTTP 500 error, instead it should be 404 Not Found. Please have a read here. It's preferable to understand and return correct HTTP code for error situations.
2. The HTTP status code in the header and in the json output should match. In this current buggy implementation, check the following output.

HTTP/1.1 200 OK  ==========> HERE
Server: nginx/1.13.12
Date: Thu, 25 Oct 2018 13:00:52 GMT
Content-Type: application/vnd.api+json
Content-Length: 215
Connection: keep-alive
X-Powered-By: kubeless
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=15724800; includeSubDomains

{"status":500,"title":"Cannot read property 'attributes' of undefined","detail":"Cannot read property 'attributes' of undefined","source":{"pointer":"/genes/name/tbc1d5B"},"meta":{"creator":"kubeless function api"}}

Now, retuning success 200 also caching empty response in the redis which is apparently another side effect of this shortcoming.

1. Fetch request to get GO Name from GO ID

• URL: https://www.ebi.ac.uk/QuickGO/services/ontology/go/terms/{go_id}

2. Store that in Redis cache

• if it exists already, just get the value
• else, store it

This would work in junction with a modified clearCache function.

Generate all possible cache keys, look them up and expire their value (set to 1ms).

1. Create the key based on the logic of key creation
   1a) This means you read the source, get all possible gene id(or name)
   1b) The source is not Redis (can use gff3 file)
2. create the key
3. Lookup and expire if necessary

So new function needs to read file, extract name/id and create keys for each pair. Then the clearCache function should be updated to look these up and expire if necessary.

This is for practice, a last choice for when our system is hosed.

You need to have separate functions for GET and POST requests, one function serves only one type of requests.

Do read file line by line, do not read it all in the memory, that approach is not deployable in production.

Keep default as 15 days, but if there is an ENV then use that for the time

This could potentially dangerous as you using wildcard * to capture every keys or in other words crossing the boundary. Any simple mistake and it could remove other keys thereby potentially interfering with other services that depends on it. It is fine for the time being, however, could be potential gateway for subtle bugs.
So, try to use a regexp for redis query that retrieves your keys of interest. You should consult redis documentation for understanding.

As i discussed briefly in our slack chat, here will be the approach

1. Storing the map from gff3 file.
   It should go in the geneids function where the map between the gene identifier -> gene name is stored. All is needed is to store the reverse mapping. The following line should work.
   redisClient.hset(hash,feature.attributes.Name, feature.attributes.ID)
2. Creating backend endpoint.
   It should reside in geneids kubeless function, in fact this nodejs function https://github.com/dictybase-playground/kubeless-nodefn/blob/master/geneids/handler.js#L130 can be reused. All it has to do is to serve the mapping in reverse(gene name -> identifier). Then add an http trigger(ingress) to get the conversion, use /conversion/genenames/{name} or /conversion/names/{name} for the http get path.
   Make sure to update the documentation accordingly.
3. Frontend route.
   The existing routing should use regexp in react-router match either of an identifier or gene name. The gene identifier match goes first and goes to the name match as a failover. It's preferable to have separate react-components for the matches. The dictybase gene identifiers should be matched with a regex. The regex should match gene identifiers for all organisms and should not be hard coded only for D.discoideum identifier. We have more than one organisms in our database and we are going to add more, so hard coding is not a choice.
   The gene identifier match goes to existing component whereas the name match goes to a component that do fetch request to the backend(no. 2), gets the identifier and route to the default path with identifier. In case of no match from the backend route it to a error page with proper message.

It seems the function is not mapping all uniprot ids from dicty.txt file. Here is a redis session to show that

redis-cli -h ${REDIS_MASTER_SERVICE_HOST}
10.109.46.14:6379> HGETALL UNIPROT2NAME/uniprot
 1) "Q23911"
 2) "29C"
 3) "Q54P77"
 4) "4cl1"
 5) "Q54P78"
 6) "4cl2"
 7) "Q54P79"
 8) "4cl3"
 9) "Q54N73"
10) "7tmk1"
11) "Q54U65"
12) "7tmk2"
13) "P14196"
14) "AAC11"
15) "P14195"
16) "AAC1"
17) "P14197"
18) "AAC3"
19) "P14198"
20) "AAC4"

10.109.46.14:6379> HLEN UNIPROT2NAME/uniprot
(integer) 10

In contrast this is the gene id mapping.

10.109.46.14:6379> HLEN GENE2NAME/geneids
(integer) 12260

I believe there should be more entries tied to that uniprot hash key in the redis. So,

• Investigate the issue.
• Fix the issue.
• Write an explanation in the comment below about how the issue might have appeared and eventually got fixed.
• Verify and show(snapshot or count through a script) that all expected entries gets persisted in the redis.