chore: update README

README.md

@@ -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).