pgx
AI 에이전트를 위한 경량 Postgres, Rust로 구현, 하나의 런타임에서 수천 개의 격리된 데이터베이스 제공
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기메이커가 쓴 소개는 위의 한 줄이 전부입니다. 더 자세한 내용은 저장소 README에서 읽을 수 있습니다. 저장소 README ↗
README 전체를 불러오는 중입니다.
README 전문 보기 ↗Website for displaying analytics and providing insights into your Codeforces profile.
Visit it at https://cf-insights.org.
The dashboard is split into four parts:
The data for the abovementioned charts is from the Codeforces API.
Performance calculation for the entire history of the user, displayed over the rating history chart.
This uses the standard elo rating system to calculate the probability of one rating achieving a higher rank in a contest than another.
It also utilizes Goroutines in a master-worker pattern for concurrent computation.
For more details see the performance documentation.
Practice problem recommendations based on the first problem the user did not solve in recent contests.
This is done by representing each problem as a vector of its tags.
Then we can take the vector sum of the recent unsolved problems, and find other problems with vectors similar to this.
For more details see the recommendation documentation.
Go for its high performance concurrency without sacrificing development speed.
PostgreSQL is primarily used as a local data store for caching Codeforces data to avoid waiting for their API.
SQLite would probably be a great fit for this as well.
To keep things fast and lean, also can't go wrong with the basics.
Docker is (very surprisingly) used for containerization and deploying the backend. The different images should be listed under "packages" on GitHub and are automatically updated when the main branch is pushed to. Chose Docker due to its simplicity when deploying, and Kubernetes would likely be overkill for this project.
esbuild is used for bundling and minimization. Chosen due to its speed.
The frontend is hosted on Cloudflare Pages, which also automatically redeploys on pushes to main.
This project uses Docker and Docker Compose for containerization and container orchestration.
If you want to install for use with a CLI you need to follow these instructions:
If you prefer a GUI you can install Docker Desktop instead. Here are the official instructions.
[!NOTE] Docker only runs natively on Linux. If you are on Windows I recommend using WSL2. Installation docs.
You can also use Docker Desktop, which should set this up automatically. (Haven't tested this).
To make the PostgreSQL database work, you need to create a .env file with these variables:
POSTGRES_DB, the name of the database.POSTGRES_USER, the name of the database user.POSTGRES_PASSWORD, the password to the user.It does not matter what these are for the dev environment, but they must be set.
If you wish to run the frontend in addition to the server, you must enable the frontend compose profile.
This can be done by adding COMPOSE_PROFILES=frontend to .env.
For running the site locally use the provided Makefile.
To build and start the containers normally:
make
and to stop them:
make stop
It is intended to visit the site locally through Nginx on port 443, for HTTP/2 with support for request cancellation.
Hot reload is also automatically configured with esbuild to watch for changes and rebuild the frontend,
while Browsersync automatically reloads the page.
[!NOTE] The Nginx container uses self-signed SSL certificates which will likely cause your browser to warn you about entering the site.
You can ignore this warning by clicking "Advanced" and then "Continue"/"Proceed" (or something similar depending on what browser you use).
When the Nginx container has started visit https://localhost.
The job of the fetcher is to fetch and store Codeforces data in a database to avoid waiting for the Codeforces API when requests are made.
It is mainly used as a cron job on the server, but is also useful for fetching data for local development.
To run this you can use the Makefile with arguments depending on what you want to fetch.
To fetch all data run:
make fetch ARGS="-contests -problems"
-contests to enable contest fetching.-maxContestAge contests older than this will be re-fetched. Example: -maxContestAge=24h to fetch all problems older than 24 hours.-maxContestUpdates to set maximum amount of contest fetches.-maxContestAge. Example: -maxContestUpdates=100.The fetcher finds all available Codeforces contests that are not currently stored in the database and fetches them.
This drastically speeds up performance calculations, as the server does not have to wait on the Codeforces API.
However, this is not mandatory, and the server figures out whether to use stored contests or fetch live from Codeforces on its own.
-problems to enable problem fetching.The fetcher finds all Codeforces problems with at least one tag and stores them in the database.
This is used for recommending problems, and is required for it to work, unlike the contests.
[!NOTE] The fetcher only stores problems of contests that already exist in the DB.