mirror of
https://github.com/Xevion/the-office.git
synced 2026-01-31 08:26:13 -06:00
45 lines
2.7 KiB
Markdown
45 lines
2.7 KiB
Markdown
# draft
|
|
|
|
A draft of my vision for `the-office` project.
|
|
|
|
## Project Goals
|
|
|
|
A mobile-friendly, responsive and fast-loading site. Looks good on most devices, and is easy to navigate and read.
|
|
|
|
Provides access to episode scripts, popular quotes, and character/episode/season information.
|
|
|
|
Has a fast and simple search interface for finding any quote someone might be looking for.
|
|
|
|
## Engineering Goals
|
|
|
|
- Real-time, low latency searching
|
|
|
|
For the time being, Typesense seems like the best option. With easy Docker-based self-hosting on Railway, it appears to
|
|
be the cheapest, fastest, and overall easiest option. Keeping the price down is a priority, and overall it seems like ~$4/month is hard to beat with Railway.
|
|
The rest of the options are either incredibly expensive, or would require a lot of engineering effort to re-implement.
|
|
|
|
As an alternative, I'm also considering in-browser pre-indexed solutions such as FlexSearch and Stork. The benefit of this is that it's far easier to host long-term, and the implementation is simpler overall.
|
|
|
|
Assuming there are no major complications with in-browser search and pre-built indexes, I think FlexSearch is the overall best option. Since it's a demo, I'm not too worried about performance on low-end devices, and more concerned with the cost of hosting long-term.
|
|
|
|
- Editable internal data
|
|
|
|
I already have a lot of data in the `data/` directory from the first iteration of the project. I'm looking for a way to edit the data in a easy, maintainable way.
|
|
|
|
As I see it, there are a couple of options:
|
|
|
|
1. A SQL database as the mutable, queryable, living document, which persists to Typesense, and can be exported into JSON as the source of truth within the repository.
|
|
|
|
- Requires another service to be running, increasing cost and complexity.
|
|
- More flexible in terms of editing interface, but requires a lot of engineering effort to implement.
|
|
- The ideas and improvements I create here could transfer to a more generic project in the future.
|
|
- Potentially, I could run with Cloudflare D1 as a mostly-idle database, I would fit within the free tier limits, and after initial development, the costs would be nil. I only need SQLite, and low-latency is my biggest concern.
|
|
|
|
2. The repository itself continues to be the source of truth storing XML or JSON file-based data, and the development server is used to mutate the data on-disk. The production site is statically generated from this.
|
|
|
|
- Simpler to implement, requires some effort, and is still somewhat flexible.
|
|
- More effort long-term, but short-term would be more likely to reach the goal of a working site.
|
|
- I really don't like the idea of manually editing XML or JSON files though, and I'm also not sure how I would want to go about editing files with a GUI.
|
|
|
|
-
|