API

[brunorzn]

Hi,

Several issues ( for instance, #117 ) are discussing the possibility of having a backend API.

Indeed, there would be many interesting things to do with such API (saving / caching results, sharing data, doing quantile projections (<-- yes, I've just copied pasted this one), etc) that we could discuss here.

Based on what has already been done on the serializeURL/deserializeURL part, I quickly made a simple server in NodeJS, which serves, for now, a single route. This route accepts the same query search parameter as the front, so it can be copied directly from the URL, and outputs a TSV.

What I've done, basically, is :

• copy data/ and model directories from covid19_scenarios along with a couple of other utils
• removed all "front" references (like D3 calls, etc), and fixed all typescript errors (everything is strictly typed now)
• running more or less the same code as "runSimulation" from "Main.tsx", based on the query string.

The code is here : https://github.com/brunorzn/covid19_scenarios_api

And it can be tested at this address : http://165.22.205.29/api/run?q=YOUR_QUERY

And it can be tested at this address : http://covid19.velours.io/api/run/tsv?q=YOUR_QUERY

And it can be tested at this address : http://covid19.velours.io/api/run/tsv?v=1&q=YOUR_QUERY

I hope you'll find it interesting and useful, and that we can discuss here how, and where, such API should be properly implemented.

[rneher]

Very cool!

[brunorzn]

I don't think moving the computing tasks from the client side to the server side is a good idea at this point, I think we're better off letting client CPUs do their part. But that's always an option of course, which would lead to much more light client. Tell me what you think about it.

The other option is to have both the server and the client perform the same operations, on the same data. If we want to move forward in that direction, we need to figure out the best way to share code and data between both client and server applications.

NPM module is an option, sharing things manually in the same monorepo is another one.

What do you think ?

[nnoll]

These are exactly the two options we are debating internally. The pros of moving to the server are greater flexibility in the sophistication of computation/model we can simulate. The downside is the overall friction it will add to the project which has the benefit of being fully static right now. The NPM option might be a good middle-ground as we can still provide our model as a library, but it doesn't come with the bonus of potential computing power. I personally oscillate on this daily, and overall since I am a Physicist by training don't know fully what it means to provide a back-end. I can say that having the potential for more computation seems appealing.

I'll also say that this is super awesome.

[brunorzn]

By experience, a lot of friction will come from the NPM module option too, at least the same (I bet much more) than having a client focusing on consuming an API and displaying data (a lot of people are very good at it) and a server computing said data and offering an API (a lot of people are very good at it too).

I agree with the argument of a greater possible model being computed on the server side, nevertheless, we must keep in mind that computational power will have to handle all the requests from the clients, whereas it's kind of fully distributed right now ;)

But here is the 1000$ question : how many requests are we talking about ?

[nnoll]

Richard is more in a better place to answer this accurately, but the number of HTTP requests we get is ~100-200K/day but I could be misremembering

[brunorzn]

And I guess we have no idea how much people "play" around with the data... maybe 10 times more, in average ? That would be about 2M req / day, about 50 req/s, at peak? I'm just guessing here :)

[brunorzn]

Hi,

API change : you can now query results in both TSV and binary format :

• in TSV : /api/run/tsv?q=YOUR_QUERY
• in binary : /api/run/binary?q=YOUR_QUERY

I've updated the API address in my initial post.

I've simply used msgpack ( https://msgpack.org/index.html ) to serialise the whole UserResult

To decode the binary result back to a UserResult object, simply do something like :
const deterministic: UserResult = msgpack.decode(x)

I'll quickly make a demo that uses this in the client.

[brunorzn]

I'll have a look at that. And I will keep my version up-to-date with master as soon as I can, and hopefully once #329 is merged, the results will be coherent (right now, I think if you refresh the page after modifying some values, the results are not coherent / persisted, even in the client).

On your side, does this TSV format suits you ? How do you plan to use this API ? What would be best for you ? I'll be happy to help by providing a ready-to-use API that suits your needs.

[jc92]

Not sure what you mean in terms of coherence, reloading is currently working.
TSV is fine. I am currently running your code locally and run some scripts in python.

[brunorzn]

Sorry I meant : "coherent between the parameters and the result", but it's probably not the good word.

Okay, so the API is fine for you now, you just need the results to be correct. I'll try to resolve this situation as soon as possible !

[jc92]

hmm interesting. With the changes I mentioned above I am able to get the same results as if I were to export from http://staging.covid19-scenarios.org
Do you know if the results from http://staging.covid19-scenarios.org are wrong a well ? Thanks either way!

[jc92]

Hi the website changed quite a bit and I saw you contributed a fair amount. I see slight differences in results compared to the old website. Hence I was wondering when you think you cold update your api? If you don't have time. Could you point me where the major changes happened that resulted in difference in outputs? Thanks a lot!

[brunorzn]

Yes, many changes indeed. I'll update the API.

[jc92]

Great! Let me know if I can help somehow! I have build a simple wrapper around your previous API version in Python out of curiosity. Happy share once it's updated.

[brunorzn]

Hi,

I've updated the API.

Now works with the query copied from www.covid19-scenarios.org (don't forget the ?v=1 !)

Results are consistent with TSV export from the website.

Have fun !

[jc92]

thanks for the quick update!
One more thing...
I am trying following query, but I get "Not Found" error, I am sure it's something stupid. Could you please point me what is wrong ? Thanks !
http://127.0.0.1:5000/?v=1&q=~(current~%27United*20States*20of*20America~containment~(~(id~%2748cd8424-8d33-474b-9f62-6d3c433dedb4~name~%27Intervention*20*231~color~%27*23bf5b17~mitigationValue~40~timeRange~(tMin~1584662400000~tMax~1598918400000))~(id~%2720f4152b-3432-4e1a-bf1a-6c4ecb1bb417~name~%27Intervention*20*232~color~%27*23666666~mitigationValue~60~timeRange~(tMin~1585094400000~tMax~1598918400000)))~population~(cases~%27United*20States*20of*20America~country~%27United*20States*20of*20America~hospitalBeds~1485000~ICUBeds~49499~importsPerDay~0.1~populationServed~330000000~suspectedCasesToday~9)~epidemiological~(infectiousPeriod~3~latencyTime~3~lengthHospitalStay~3~lengthICUStay~14~overflowSeverity~2~peakMonth~0~r0~3.2~seasonalForcing~0)~simulation~(simulationTimeRange~(tMin~1580515200000~tMax~1598918400000)~numberStochasticRuns~0)~ageDistribution~(0-9~39721484~10-19~42332393~20-29~46094077~30-39~44668271~40-49~40348398~50-59~42120077~60-69~38488173~70-79~24082598~80*2b~13147180))

[brunorzn]

it should be http://127.0.0.1:5000/run/tsv?v=1&q=...

[brunorzn]

Note that The README it not up to date though. you have tu run :
yarn install
yarn update
yarn build
yarn start

[AxiaTim]

Thanks for the work that you've done on this so far - it's been interesting to read back and follow the development.

We're looking to run mutiple scenarios for multiple regions and an API would be really make a difference to be able to do this. Currently, I'm looking at using selemium to automate this process however, its obviously not the most reliable or robust solution.

Is it possible to/are there plans for allowing changing the age-specific assumptions?

[brunorzn]

Hi Tim,

This feature needs to be shipped on the website first. It's set to be released for the 1.3 https://github.com/neherlab/covid19_scenarios/milestone/4 milestone.

Once this is done, there will probably be some work to do to make it work in this API, but it should be very doable.