-
Notifications
You must be signed in to change notification settings - Fork 0
Implements backend API, integrates with frontend #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…der script similar to ECCO
…me rather than ID
❌ Deploy Preview for m2on failed.
|
|
Hey @vincerubinetti, thanks for the response. So, those errors look like the backend is attempting to access the database, but it's failing because the db isn't ready to receive connections yet. In this PR I made some service dependency changes in the Compose file to make the backend wait until the database is healthy (e.g., it's ready to accept connections), but I'm assuming they didn't trigger Compose to recreate the containers, thus they weren't applied. (FWIW, I assume this would only happen if you were coming from When you're back and if you're up to it, you can try bringing the stack down completely, including purging the database volume, and then bringing it back up to see if it correctly waits for the db before starting the backend: # removes all services, purges containers
./run_stack.sh down -v
# recreates services, after which hopefully they'll use the current healthchecks
./run_stack.shIf it's working, you should see two lines in the following order, indicating the backend waited until the database was ready: Thanks for the summary of the todos as well, appreciated. Happy holidays! |
|
I thought I had done a complete teardown via my brute force method of doing a factory reset through Docker compose (which I do periodically to save drive space, and which supposedly clears all images/vols/etc). But I must not have because it is working without error now, after waiting a bit extra for all the services to spin up. I tested out what you have so far and also made some more modifications to the frontend. It looks good. Not sure how far you want to go with this PR vs. a new PR. One of the first things that would be helpful is to get the open API spec hooked up to the frontend so I don't have to manually type out schemas. Also at the moment it seems like the field names could use some normalization/consistency, e.g. dates always being in a form like |
Sounds good; I'm planning to use drf-spectacular to generate a client, the results of which will be placed somewhere in the frontend's source tree, like under
At the moment the column names are taken from the sources they come from to minimize confusion about how they map back to their source files, but I think it's a good idea to normalize them. As with the API client generation change, I think this should come in a new PR, probably after that one. |

This PR adds the following:
run_stack.shmemcachedfor caching expensive responsesRegarding the frontend, here are a few significant changes:
/api/cart/downloadrather than getting a link and fetching thatCaveats
Note that the backend API structure is very much a work in progress. For example, I'd like to combine the GEO metadata series table with the regular Series table, decide between whether it's going to be flat or nested, normalize how queries and pagination are done (there are some custom endpoints, for example), etc. There's also currently no formal type definition for the API; I intend to add that, as well as Swagger or ReDoc to surface that information better, as well as add an OpenAPI schema endpoint for programmatic use.
The data model is also kind of all over the place, due to not knowing how (or, in many cases, if) the data i was provided would be used in the app. I have a lot of cleanup to do both on the model and the interface, but I imagine that it'll be best to address it in a future PR.
The way that searches are conducted is currently complicated, but I figure I should get the PR out first. I'll explain it in a subsequent comment on this PR.
Trying it Out
Since I was only given a subset of ontology terms for testing, only a small subset of entities in the ontology will actually be able to be matched to results. (They're all disease entities from the MONDO ontology, and only a small selection of them at that.) Here's a few entries that you can search for that actually return responses, pulled from the
api_searchtermstable joined withapi_ontologyterms: