The Broom Stack is software to manage a curling club, including a back end and web interface.
Currently, it is being re-written from the ground-up, so there's not much to demo right now. You can check out the code, however.
You will find project configuration at the root, and all source code in /src/. Fastify uses a plugin model ("everything is a plugin!"), so from there you will find a plugins/ directory. Everything that is dependent on the request lifecycle will live in this folder.
Since the client is dependent on the request lifecycle, it's a plugin, too! Client code lives in /src/plugins/page/client/. This is also where you will find the webpack build configuration.
The other largest plugin is the api plugin. It implements the REST API for The Broom Stack. Within plugins/api/ you will find controllers and components. Controllers are plugins (remember, everything is a plugin!) that define routes and their implementations. Components are plugins that share common functionality among many controllers. For example, the crud component automatically provides create/read/update/delete routes to any controller.
Next we have services. Services live outside the request lifecycle and do the heavy-lifting of implementing features. Generally, a controller will define a route and implement it by doing 3 things:
- Parse the request into more salient data types and structures.
- Use services to perform the necessary computations.
- Serialize the response.
Finally, the dataModel contains our persisted object models using Deepkit ORM's patterns. Each table in the database has a corresponding class in this folder. The database object is constructed in database.ts.
Core tech is still:
- Node.js
- TypeScript everywhere
- React
And some finer stack details:
- Deepkit Framework application framework for Node.js and TypeScript
- Deepkit ORM
- Not 100%, but for now: Fluent UI
Most major questions about the architecture have been answered, but some finer points remain. I am going to build some basic CRUD pages to get some mileage on this architecture before diving into story-based features.
These are not high-level goals, but rather architecture goals.
- Client-side rendered SPA, but with all data needed to render available on the initial request payload.
- Real-time support for certain data objects
- Markdown-defined content, including articles
- Many more to come
- What is the best way to manage data for switching pages vs. loading a URL fresh?
The first pass at building an object schema is done. Several planned features are intentionally omitted, but this is a good starting point:
