3 ms·
If you follow typical Clojure usage recommendations (avoid global state), you can often get started with a fat prototype that is trivial to slice up as your ide
by emidln 10y ago
If you follow typical Clojure usage recommendations (avoid global state), you can often get started with a fat prototype that is trivial to slice up as your ideas become more clear. As a lone developer, I would recommend not making your nREPL and generic dev experience harder than it has to be.
- malloryerik 10y agoI guess you're saying, stay monolithic, but with an eye to modularity later when it makes more sense. Might be wise advice.
- emidln 10y agoSorta. I'd advocate for separating the deployment story (which might be simple or might be something complicated like microservices) from the development story (needing to add :checkouts to your lein project and/or manage multiple nREPLs is a real headache). The way most libraries get written, you end up with a namespace or two that matters. If you have three conceptually independent services, put them in separate namespaces like foo.bar, foo.baz, and foo.quux. If you later find the project is too large to manage, you can just move directories containing namespaces. Until then, you can use facilities in leiningen or boot to spit out multiple jars, or a single jar that can run multiple services (perhaps based on flags you invoke or a class you load). Further, until you need to have separate services, I'd probably just load all of them in the same process. Through all of this, your development story is much nicer, and there are fewer git repos to reason about. If you really do think you'll eventually need different git repos for your services, you might consider prefixing commit messages based on the logical service they relate to, so that you can migrate the history easily later on in an organized and linear way.