cerbervs/joist
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: update README

Browse Source
This commit is contained in:
Mark Bailey 2025-08-31 03:30:01 -04:00
parent f1c82f0c77
commit 983f02edf1
1 changed files with 41 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
README.md
View File

@ -0,0 +1,41 @@
# Joist
Joist is a basics-first framework for Go. It is a replacement for
[go-full-stack](https://git.markbailey.dev/cerbervs/go-full-stack). It draws
on the knowledge and experience I have gained in the first few runs of setting
up a enterprise grade solution for my current project. During the bulk of my
last updates to the internals, I realized that I need a common starting ground
for any web application I build. [Gin](https://github.com/gin-gonic/gin) is a
stellar solution for others, but I wanted to build a more opinionated kit that
is compliant with `net/http`, or easily extended to be so.
The biggest difference from `net/http` is that `Handlers` now have a signature
that allows them to return an error so that I can centralize error handling and
display (`func (w http.ResponseWriter, r *http.Request) error`). This is handled
via an exported adapter that sits just above the handler in the middleware
chain. I am using the excellent [Chi](https://github.com/go-chi/chi) under the
hood for routing and their convenient pre-built middleware collection (mainly
rate-limiting and `RealIP()`).
Not much else is really cached at this point, but I don't see a reason why that
won't change should I find I need more caching for obvious caching reasons.
Routes are auto-named (until I look into a better, user-defined solution) and
cached in a map for easy retrieval. A corresponding URL Builder for named routes
and a separate `New...` method are provided.
Both route caching and sessions are handled via an embedded in-memory
(persistent by default) store
([BadgerDB](https://github.com/hypermodeinc/badger)).
Eventually, I would really like to implement a declarative routing format that
will allow the user to define routes in a single structure, alongside their
middleware and any sub-routers/routing groups.
SQL will likely be managed via [SQLC](https://sqlc.dev) and backed by
PostgreSQL, although this will be the last piece of the puzzle I implement. I am
reluctant to pin myself to one solution here, hence the lean towards SQLC,
although the more I read up on [Ent](https://entgo.io) the more I like it.
Ultimately, I want to be able to freely swap out the database layer without
affecting the rest of the framework. Not quite [Doctrine
ORM](https://github.com/doctrine/orm), but implementations for a few selected
databases would be nice (namely: PostgreSQL, SQLite3, and MySQL/MariaDB).