paos VS component

Just library-driven-development.

I used the paos library (https://github.com/xapix-io/paos). Mainly followed the quick start examples on the github page. Fetched the wsdl from the API provider, pulled out the SOAP envelope which translates into a Clojure map. The API provider has a bunch of soap services that each provide a large number of keys in the envelope but many keys in many services aren't capable of actually doing anything server-side. This was . . . documented poorly.

We have dev and test environments for this specific API provider so I hacked around and made calls until I had everything working.

This is a perfect example of the kind of one-off stuff I often use Clojure for. Quick prototypes to get work done. There are many groups in my larger organization and a common experience for me is to have groups tell you "X can't be done because Y." In this case, a vendor was charging 5 figure fees per data migration effort for each planned migration. The plan was to roll out by group and there are many groups. My immediate question was "can't we do this with the API and save these fees?" The answer was "no, not possible." About three days later I had a working version for this admittedly simple use case, demo'd it, rolled it into production. The cost savings will be in the low six figures. Of course, once it was working the original internal group came back to re-implement the project in another language because "bus factor" but tbh there is lots of weirdness in my larger employer organization about who gets to do what. Once I had shown we could do it relatively easily, teams come out of the woodwork to grab it so that they can add the cost savings to their yearly brag results.

I could write for days about this type of thing . . .

* Lifecycle management: Mount, Integrant or Component (https://github.com/tolitius/mount https://github.com/weavejester/integrant and https://github.com/stuartsierra/component)

When you start to have multiple stateful components (the database, the HTTP server, your Redis connection, a page cache, etc.), then you'll want to use a library like component that manages their (inter-)dependencies and provides a consistent notion of lifecycle.

Today I released a new version of Reveal Pro — dev.vlaaad/reveal-pro {:mvn/version "1.3.308"} — that adds sticker integration for system libraries such as mount, component and integrant!

I agree with the main sentiment from the article. Although I do think they are discussing Inversion of control more-so than dependency injection.

One of my first languages was .net and I was never able to really understand DI in that context that well.

Actually using javascript and ducktyping made me understand what it actually was.

I remember a .net job interview where I had to write a micro-service and opted to construct the dependency graph in the main function initialising "all" the classes there. Instead of discussing the pro's and con's of that approach they berated me for not using a DI framework (No I did not land that job, but in hindsight it was the most expensive job interview I've ever had. The room was filled with 8 developers going over my code).

The main thing the article glosses over is state. something people with a functional background hide from. But if you look at something like the httpclient in .net. I think it took the .net world like 10 years to start using the httpclient properly. Scope and lifetime of those kind of objects are important. managing connection pools, retry state, throttling or the incoming http request. DI does make that kind of thing easieR (I'm not saying it makes it better)

Look at clojure's component(https://github.com/stuartsierra/component), I'm not a clojure expert by far. But it is kinda DI/IOC in a functional language.

In closing we can agree that it is underused in the right places and overused in the wrong ones.

https://github.com/stuartsierra/component#no-function-should-take-the-entire-system-as-an-argument

Yeah like I mentioned I'm not like super sold on the everything-should-be-an-actor paradigm, but I find value in DDD + a light implementation of Components (similar to stuartsierra/component).

https://github.com/stuartsierra/component for managing components lifecycles in projects