Add initial setup for a basic shared cache server #1318
Conversation
|
It could help to have some discriptions for what these are |
|
Oh sure, "entity" and "migration" are the standard names used by sea-orm to make sea-orm work. The "entity" package is generated by sea-orm from an active database but can be modified by hand easily enough as well. Each "entity" is a rust type that corresponds to a table in the database schema. An instance of an entity is equivalent to a row in the database. The "migration" crate is partially managed by sea-orm and partially not. The individual migrations have to be written by hand. Each migration has an "up" and a "down" to go back and forth between them and there's a list of migrations that is kept in chronological order. This lets you move a database up and down and give good error messages when you can't migrate all the way to the latest version expected by your current service. This is also how we plan on not loosing terrabytes of data in the shared cache when we inevitably update the schema. The "gsc" crate is short for "global shared cache" and implements a JSON RPC web service. |
|
FWIW: |
rust/gsc/src/main.rs
Outdated
| ); | ||
|
|
||
| // run it with hyper on localhost:3000 | ||
| axum::Server::bind(&"127.0.0.1:3000".parse().unwrap()) |
There was a problem hiding this comment.
I realize this is early scaffold, but for later:
This relies on the host machine being able to route between the loopback device and other devices, and that the loopback hasn't been assigned to a WAN address. Can this be a less specific address like 0.0.0.0 or ::, or to take the interface and/or ip address/port from a configuration file
There was a problem hiding this comment.
The plan is to take the ip address and port from an environment variable
This change is just to get us started down the development path for a shared caching server that can be used to repopulate the local shared caches.