My personal opinions: if you have queries or components that are used in multiple places, then sure, factor them out into separate files. I have one or two projects with a query.clj file, for example; and the example project already comes with a ui.clj file. As your app grows you can break those out into more files if it feels natural. But I wouldn't treat the db as something to try to abstract over or try to keep all db access code in separate files as a rule. https://htmx.org/essays/locality-of-behaviour/ is relevant to the latter (LoB vs. SoC) In general I'd say just do what feels right in the moment and don't worry too much about sticking to some predefined structure. Jamie Brandon has a few tidbits about code organization I agree with too: > A special case of this trap is trying to organize everything into some hierarchy. The point of any kind of code organization tool is to capture repeated patterns in the desired behavior so that we don't have to write out a bajillion slightly different versions of the same thing. But there isn't any law that says that those patterns must always be tree-shaped. Sometimes useful categories will overlap. Trying to force the structure of the problem to fit into some class hierarchy is just borrowing trouble. > The same goes for organizing code into files and folders. There are always different cross-cutting concerns which suggest different ways to organize the code into a tree. It really isn't worth wasting a lot of time trying to find the 'right' one. > Within a single file, you can introduce things in a logical order. If the same code is split across a lot of small files then that context is lost. So I lean towards bigger files. (https://www.scattered-thoughts.net/writing/coding/)

Oh dang… this is really helpful. It’s interesting the role that editor familiarity plays in all of this. In other words, if one isn’t able to easily find code it drives one to try to ‘put it all in one place’. That’s also mentioned by the Tailwind folks… they point out that to use Tailwind being able to easily search/replace is key. > As your app grows you can break those out into more files if it feels natural. That is probably the key thing… thank you! Wait to do it and and avoid preemptive optimization. > If the same code is split across a lot of small files then that context is lost. This I what I started experiencing as I tried to get ‘organized’.

I’m just a third of a way into the video, and before I continue… I’m amazed at how far along Platypub has come. I had avoided looking at Platypub because I am still learning Biff and I think I thought I was going to be too complex for me. As it turns out, almost all the questions I’ve asked in #C013Y4VG20J are answered right in the Platypub code. Also, it’s amazing to see Biff in action here in this more complex project. All right… back to watching it.

that's great to hear! platypub is fulfilling its purpose haha