"Teleworkers accidentally meeting each other"
This implementation is incomplete but contains examples of working web technologies.
This software has a web server (back end), a web user interface (front end), and a library shared between the two, all implemented in Rust.
The front end has a React-like implementation written in Rust by using yew v0.19 and compiled to Web Assembly (wasm) and bundled with trunk.
The back end is also written in Rust using the Rocket framework with rocket_auth and tokio_postgres working together to handle user-authenticated sessions.
The library ensures that data structures shared between the front end and back end are defined once.
The eHallway isn't finished, but this section covers the concepts guiding its direction.
In a physical workplace, accidental hallway meetings can spark new collaborations and new ways of working. The conversations aren't always expected or desired. You might find yourself trying to figure out how to get away while two colleagues discuss potato farming, but these unplanned interactions can keep a community fresh.
This proof of concept system attempts to provide some of the hallway-meeting serendipity that teleworkers don't often experience.
To that end, each user can create potential topics of conversation. Each user can create a named meeting. The meeting can be anything, like, "Monday 9am Discord", e.g. Each user can indicate the desire to attend a meeting.
When the meeting participants all check in, cohorts of three participants are randomly chosen. Each cohort sees nine topics, three from each participant in the cohort. Each cohort ranks all nine topics. The system uses the Borda Count method to select the top two scoring topics, and the cohort members are presented with the top two topics.
Now eHallway is a bare-bones framework. The parts below are in place.
- User authentication (email and password only) and authenticated sessions
- User-specific topic-list management
- Site-wide meeting management
- Meeting registration and joining
- Meeting topic ranking per user
- Vote casting
- Election results tallying and presentation
The system has a few main components.
- Third-Party
- eHallway Originals
- API Server
- Library
- UI
The back-end server creates tables on startup
if they do not already exist.
Beforehand, create an ehallway user
and set a password
by following the PostgreSQL documentation.
Pass that username and password to the back end when starting it, via command-line arguments.
Caddy is run as root in order to use the regular HTTPS port. If you use a script as shown in the example below, you do not have to configure Caddy.
Using rustup or your favorite method, ensure that the nightly toolchain is installed, and configure it to be used for building the back end. (The front end does not need the nightly toolchain.)
cd api
rustup override set nightly
Starting at the repository's top level, the user interface (UI) is built as follows in the example below.
cd ui && \
trunk build && \
sh -xe ../tpt-update.sh
Create a TOML config file that contains contents you edit to supply your own values. Example config-file contents are shown below.
static_path = "/path/to/ehallway/ui/dist"
postgres_user = "ehallway"
postgres_password = "mypgpassword"
Starting at the repository's top level, the web server is built and run as shown below.
cd api && \
cargo run -- --config-file myconfig.toml
Starting at the repository's top level, the reverse proxy server is started as shown below. Please edit the command, so that the path to your own caddy is used.
sudo ~/opt/bin/caddy reverse-proxy --to 127.0.0.1:8000
To access the system, use your web browser to visit this link.
Documentation uses semantic linefeeds.
Code should be committed after cargo fmt has formatted it.
Code should be cargo clippy clean before pull requests are opened.