Fork me on GitHub
#architecture
<
2021-12-02
>
Lukas Domagala11:12:49

I’m thinking about the structure of an open-source dev tool/lib that is supposed to be easy to consume and integrate with optional dependencies. Might even want to make it extensible from the outside at some point. Currently, the project is just a library (https://github.com/Cyrik/omni-trace) that you put into your dependencies and consume during repl time. The problem with it is that it’s not useful without having portal as well since the easiest way to look at its output is a Vega flamegraph. I’m thinking about adding a UI part to it that can be used on its own or embedded as an IFrame in other things (portal, re-frisk, your cljs site, …). The general question that follows from all this: do I put all of this into the same project, so you have to depend on all of it, or do I build the UI part as its own thing and then a third lib that combines both. If I choose the second path, do I throw all of it into the same repo and have multiple build targets or keep it strictly separate? not sure if this topic belongs here, since it’s more about open-source project architecture than about systems, but anyway.

pithyless11:12:03

IMO, if you split the core from the UI, you are more likely to develop good API boundaries that won't rely on some internal implementation details. The next question is how to split it? Keeping it as a monorepo with separate artifacts may help you develop it faster (easier to jump back-and-forth and push new versions that are dependent on most recent changes), while using separate repos will encourage streamlining the workflow for external contributions (ie. how likely is someone to work on alternative UI concepts for omni-trace-core). I think those are some of the tradeoffs you may want to consider.

1
pithyless11:12:53

PS. Looking forward to trying out omni-trace; it's on my TODO short list for this week. :)

Lukas Domagala12:12:59

@U05476190 thanks, it’s good to know other people come up with the same pros/cons. Btw when you play with it, I’m very open to suggestions/criticism of anything about it, from the flow to the api to the implementation 🙂

Marcus Pemer12:12:48

If you make use of Polylith (https://github.com/polyfy/polylith and https://polylith.gitbook.io/polylith/) you could implement several project outputs leveraging the same code base. We have been using polylith for some time now with great results. Initial threshold seemed high but once we were up and running we are actually saving time.

Lukas Domagala12:12:49

@U9FNGNS3T that’s what I’ve been look at using if I go the monorep route, but it’s good to hear that you are having good results with it!

👍 1