42 lines
2.4 KiB
Markdown
42 lines
2.4 KiB
Markdown
# 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).
|