4 ms·

I am not sure what a web framework is, to be honest. The choices for many parts of a web application are really domain-specific and I'm not sure a single "frame

by jwr 3y ago

I am not sure what a web framework is, to be honest. The choices for many parts of a web application are really domain-specific and I'm not sure a single "framework" would work for everyone. As far as web-related components go, my app uses Rum (as an interface to React), ring, http-kit, pushy (for history manipulation), sente (for websockets), buddy (for authentication tools). If you are looking for a batteries-included "I want to have some sort of webapp right away" thing, I think https://kit-clj.github.io https://kit-clj.github.io would fit the bill, but the general feeling in the Clojure community is that unlike Python with Django or Ruby with Rails, the choice of app components is not predetermined by the language.

22289d 3y ago
> I'm not sure a single "framework" would work for everyone. I guess you weren't lying because that is not what a web framework is. If it works for just me, that's a web framework. The fact that there are so many web frameworks shows that none work for everyone.
spelufo 3y ago
What about the database side of things?
- stefcoetzee 3y ago
  next.jdbc is the go-to library to interact with SQL databases. https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.894/doc/readme https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.8...
- jetrink 3y ago
  If you don't need something as low-level as next.jdbc, HugSQL is my preferred library. It lets you write queries in .sql files, and the queries are then loaded as functions. If you want to dynamically generate queries, there are also libraries like HoneySQL.
- simongray 3y ago
  Probably worth mentioning that triplestores/Datomic-like databases are relatively mainstream in Clojure: https://github.com/simongray/clojure-graph-resources#datalog https://github.com/simongray/clojure-graph-resources#datalog
shortrounddev2 3y ago
Components of a web framework: 1. Routing 2. ORM 3. Auth handling 4. Request middleware 5. Templating (if your application requires it) 6. User input validation Many other components that are escaping me right now
- PaulHoule 3y ago
  I think routing makes the minimal viable "framework" -- look at the many systems like Sinatra, JAX-RS, aiohttp, etc where you write functions and supply metadata to tie URLs to functions.
- Capricorn2481 3y ago
  For clojure, that would be biff
- WJW 3y ago
  Some more standard components I would no longer want to do without in a full-featured framework: - background job system - email sending - translation/localisation - a decent configuration system suitable for differentiating dev/test/staging/prod/etc, and handling both secret and non-secret values in a sane way
  - shortrounddev2 3y ago
    Secret handling has been abstracted away from the framework for everything I worked on; usually our deployment system would mount secrets as a file system and then you read them as a file of key->value pairs. That, or they were just set as environment variables. I guess the framework could provide a standardized secret service, but I usually just write that myself
    - WJW 3y ago
      > but I usually just write that myself Not saying you shouldn't, but part of the point of a framework is all the things you don't have to write yourself. What I like about (say) Rails secret handling is that the secrets file is an encrypted file in the repo itself. This makes it so that you can easily check out and run different versions of the repo from different times and not have to worry about that one time you renamed an envvar or something. Secrets get version controlled together with the app. The autogenerated .gitignore even includes patterns for the key files so you have to go out of your way to check them into the repo. The downside is that merging encrypted files can be a right pain in the arse, for example when two devs added different secrets in different branches.

by jwr 3y ago

22289d 3y ago

> I'm not sure a single "framework" would work for everyone. I guess you weren't lying because that is not what a web framework is. If it works for just me, that's a web framework. The fact that there are so many web frameworks shows that none work for everyone.

spelufo 3y ago

What about the database side of things?

stefcoetzee 3y ago
next.jdbc is the go-to library to interact with SQL databases. https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.894/doc/readme https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.8...
jetrink 3y ago
If you don't need something as low-level as next.jdbc, HugSQL is my preferred library. It lets you write queries in .sql files, and the queries are then loaded as functions. If you want to dynamically generate queries, there are also libraries like HoneySQL.
simongray 3y ago
Probably worth mentioning that triplestores/Datomic-like databases are relatively mainstream in Clojure: https://github.com/simongray/clojure-graph-resources#datalog https://github.com/simongray/clojure-graph-resources#datalog

shortrounddev2 3y ago

Components of a web framework: 1. Routing 2. ORM 3. Auth handling 4. Request middleware 5. Templating (if your application requires it) 6. User input validation Many other components that are escaping me right now

PaulHoule 3y ago
I think routing makes the minimal viable "framework" -- look at the many systems like Sinatra, JAX-RS, aiohttp, etc where you write functions and supply metadata to tie URLs to functions.
Capricorn2481 3y ago
For clojure, that would be biff
WJW 3y ago
Some more standard components I would no longer want to do without in a full-featured framework: - background job system - email sending - translation/localisation - a decent configuration system suitable for differentiating dev/test/staging/prod/etc, and handling both secret and non-secret values in a sane way
- shortrounddev2 3y ago
  Secret handling has been abstracted away from the framework for everything I worked on; usually our deployment system would mount secrets as a file system and then you read them as a file of key->value pairs. That, or they were just set as environment variables. I guess the framework could provide a standardized secret service, but I usually just write that myself
  - WJW 3y ago
    > but I usually just write that myself Not saying you shouldn't, but part of the point of a framework is all the things you don't have to write yourself. What I like about (say) Rails secret handling is that the secrets file is an encrypted file in the repo itself. This makes it so that you can easily check out and run different versions of the repo from different times and not have to worry about that one time you renamed an envvar or something. Secrets get version controlled together with the app. The autogenerated .gitignore even includes patterns for the key files so you have to go out of your way to check them into the repo. The downside is that merging encrypted files can be a right pain in the arse, for example when two devs added different secrets in different branches.