Split up most things into separate libraries

[swlkr]

I've been working on this and I always forget to update this repo/twitter with issues/progress.

Here's the break down so far:

• coast (the main lib responsible for combining all of the other libs and middleware)
• env (env variables)
• helper (a bunch of utility functions)
• router (the coast request router)
• validator (map validations)
• logger (logging)
• time (time helpers)
• assets (asset management)
• db (for database interaction in coast)
• authenticator (coast-specific authentication middleware)
• worker (a background job executor, a la sidekiq: in memory OR redis OR database backed jobs)
• mailer (send emails from coast apps)
• filer (file, s3, azure, google cloud storage, b2 cloud storage)
• phaser (websockets?)
• editor (rich text editor)

Most of this stuff has already been written/wrapped, just need to break it out into it's own repo with it's own tests/readme/docs. Check the env link for how this looks.

I'm open to wrapping existing clojure libs for most of this stuff too, like mailer/worker. I'm also planning on wrapping buddy for authentication as an example for #74

I've also made quite a few changes to coast itself, so #49 and #62 are finally solved, not to mention a bunch of other stuff that was rough around the edges. Super excited about it.

I'm also planning on dropping all this weird greek stuff (theta, eta) and just pushing one coast namespace with a proper v1 and then I'll just follow semantic versioning from now on.

I'll update this issue with links to each of the repos as they get pushed.

[zcaudate]

It's a matter of taste but I find it easier that code is contained in a monorepo. I've written a library to automatically split code on deployment. Here is an example: https://github.com/zcaudate/tech.monorepo.

[swlkr]

Hm, I've never used a monorepo before, seems like a lot of work. I was interested in how rails organized their code though, seems like just subfolders under the main rails/rails repo.

If the multiple repo thing is too complex, I'm open to a monorepo and if that's too complex, I'll just go back to subfolders haha

[zcaudate]

I wrote hara.deploy to manage my own code base: https://caudata.gitlab.io/base. I do all my development together and then deploy modular packages. The library automatically resolves internal dependencies and packages the code into seperate jar files. You have alot of code. I'm betting that you're going to get sick of versioning everything. I can do an example setup based on an earlier repo where you haven't started seperating the files.

[swlkr]

Yeah that works, let me know when the example setup is done and I'll play around with it

[zcaudate]

great. can you choose a commit that would make a good starting point?

[swlkr]

Current master is good: 703bdf0

[zcaudate]

I've updated some files here to show how it might work zcaudate@8f0f511

It's not working just yet.

Running (hara.deploy.linkage/collect) I'm getting this error:

Execution error (ExceptionInfo) at hara.core.base.sort/topological-sort (sort.clj:88).
Graph Contains Circular Dependency.

It means that some of the files within the designated packages reference each other and so a deps graph cannot be generated.

[swlkr]

haha i dont doubt there are circular dependencies. i’ll check it out and see how it works

[zcaudate]

The file that determines how the packages are seperated is packages.edn:

zcaudate@8f0f511#diff-105c90dde34ff971dd15eff7aabf2642R1-R46

It might be better to start with something a bit smaller.

[swlkr]

Hmm, seems kind of complicated… do I have to have a project.clj?

I don't know if I have too much of a problem bumping things manually, I pretty much 0.1.0-SNAPSHOT things if they're changing frequently.

Plus the whole goal of this, which I tried to do before but failed and wound up inlining every single namespace in directories is to not change things as frequently. If it were up to me, I would be changing every little thing every five seconds, the goal for me at least is to add friction to changing the underlying libs.

[zcaudate]

That kind of makes sense.

When I have more time at a later stage I'd still like to give it a go. full deps.edn support for the lib is not too hard to put in. It's a little bit crazy with the new tooling coming out deps/prepl vs lein-boot/cider. I haven't really caught on to the new tooling just yet (is there autocomplete?)

There are also a couple of other monorepo libs: https://github.com/tomasd/depify.monorepo and https://github.com/amperity/lein-monolith around.

[Immortalin]

There are videos on Coast which you can embed for marketing:

https://youtu.be/bPz4-Vcx27A