Fastapi conversion#2071
Conversation
There was a problem hiding this comment.
Removing jupyter and local datadog reference
There was a problem hiding this comment.
Removing jupyter and local datadog reference
There was a problem hiding this comment.
Fastapi uses uvicorn
There was a problem hiding this comment.
Convenient command runner
There was a problem hiding this comment.
Switch from pip building to uv.
!! Needs further verification
There was a problem hiding this comment.
Not using MongoEngine.
!! Still need to implement unit checks, but will be outside of this scope
There was a problem hiding this comment.
Upgrade python to 3.14; move to uv, ruff, and basedpyright; removed outdated/unnecessary packages
There was a problem hiding this comment.
the base stack is still at python 3.11
There was a problem hiding this comment.
Yeah, I have a note in the Dockerfile about requiring a 3.14 image build - I assumed it would be a good time to bump our python version and use up to date package versions.
Do you think this should be in the scope of the rewrite?
There was a problem hiding this comment.
A lot of this logic is used to handle parsing dotted paths (data.x.y.z)
| wget -q https://github.com/materialsproject/MPContribs/blob/master/mpcontribs-api/mpcontribs/api/contributions/formulae.json.gz?raw=true \ | ||
| -O mpcontribs/api/contributions/formulae.json.gz |
There was a problem hiding this comment.
reason for removing the formulae file?
There was a problem hiding this comment.
The file seemed to just function as an id-to-formula translation. I made formulas required when POSTing.
If we want that moved back to optional and filled in automatically, I think I'd prefer actively fetching the formula over keeping it in a data file that we track in git. That would mean an extra query to mongo, and reaching into the nextgen database, but I feel that it is more reactive and resilient that way.
…across our stack easily, but loses centralization. We only had light centralization, but future efforts would not be immediately shared
| FROM materialsproject/devops:python-3.1113.4 AS base | ||
| RUN apt-get update && apt-get install -y --no-install-recommends supervisor libopenblas-dev libpq-dev vim && apt-get clean | ||
| # FROM materialsproject/devops:python-3.1113.4 AS base | ||
| FROM python:3.14-slim AS base |
There was a problem hiding this comment.
I moved off of the shared base image here. There are definitely both pros and cons (below), and I have to test a full build still.
Pros:
- UV uses a lockfile and doesn't need to rely on manually finding and building binaries - this seems to be the main benefit of the shared image (scipy, matplotlib, etc.)
- Allows each portion of the stack to upgrade python independently (we don't have to hold back one piece until we build a shared image and force every upgrade at once)
Cons:
- If we have truly shared logic, we will have duplication, or revert to a shared image
- If the underlying default image changes, we would silently change as well
…ser - users can no longer operate on components that their contributions dontown
…from Document instead of DocumentWithSoftDelet
…eporting the successes and failures via BulkWriteSummary
…ave consistent (re)serialization
2 participants
Summary
Start of major rewrite of the API server to FastAPI and other modern frameworks (pydantic, Beanie, etc.)
This PR is the essential groundwork of the rewrite. However, further PRs are necessary for full functionality.
Major TODOs after this PR
Minor TODOs after this PR: