Thanks for the article! It's good to have more examples of this sort of stuff, especially if people decide to go the lack/clack route rather than using e.g. hun

Thanks for the article! It's good to have more examples of this sort of stuff, especially if people decide to go the lack/clack route rather than using e.g. hunchentoot directly as I like to do. If you ever do a followup to go beyond the simple barebones, I'd like to see more on both development experience and production deployment. Some thoughts: Better attention to error handling, as well as the difference in developer mode where you might want the error to show up in your REPL and/or shown on a page, but in production mode to just be logged and/or emailed somewhere while the server returns an appropriate error page without too much information on it. >In a more complex application, I would add a way to invalidate the cache automatically if a template changes. By default, Djula actually recompiles the template if the file does change. What the cache here is doing is caching the association of a path string -> template file object, not the compilation status, as the template object can recompile itself. You have a lot of top-level forms (path / asdf references, add-template-directory, etc.) that don't fly if you wanted to compile a binary to push up to a server. Speaking of deploying to a server via binary, it's also easy to compile in an active or toggle-able swank server, so that if you do need to debug or want to develop/test things further "in production", the server doesn't need to know anything about Lisp or Lisp editors, you just use SSH port forwarding on the swank connection and talk to the production Lisp binary with your local editor. (The server does need to have a matching or newer libc than your build system though, and potentially other things like libmysqlclient. I just build stuff in an old debian docker image but Shinmera's Deploy is a great solution with a lot of headaches taken care of.) I like the @export macro when developing because I can be a bit lazier, but it's better form to just add the stuff to your defpackage :export list eventually. (I finally got around to making my own editor macro in vim to do that for me, so I don't think I'll use the cl-annot package much anymore.) That library is also LLGPL which might not be desirable for the trivial handful of lines of code you can write yourself if you don't need its slightly fancier support for class accessors. With sqlite, you should probably be using PRAGMA journal_mode=WAL when you create the schema, as well as consider changing its auto vacuuming behavior and a few other features. There are some per-connection pragmas worth looking at as well for a production scenario. Showing how to send headers like content security policy would be good, and also going beyond simple error pages to including support for live metrics (e.g. https://github.com/deadtrickster/prometheus.cl https://github.com/deadtrickster/prometheus.cl -- there might be a clack middleware even?) I wrap my Lisp web stuff in apache but I think nginx and caddy are popular too. Showing the full end-to-end with a let's encrypt SSL cert would be helpful for people getting into web apps who haven't already done it in some other ecosystem before.