Oh, you like functional Scala? Write pure FP apps with Tagless Final? And still think you do it right? I got bad news for some of you. (a thread)

In case you still don't trace your apps (I mean distributed tracing), it's time to start doing it with trace4cats. Apart from direct benefits you'll get from introducing it, you may also learn a lot about your current design and discover some antipatterns in your code. 1/7

This will require your main logic effect to be contextual (i.e. Reader-like) and your service algebras to be traceable. What nasty things may stop you from having that? Below are common mistakes and my suggestions... 2/7

Problem: unnecessarily powerful bounds on F[_] contextual effects can't have (e.g. ConcurrentEffect). Advice: consider replacing it with UnliftIO - a less powerful typeclass, which can be derived for both contextual and non-contextual effects. 3/7

Problem: using the same effect for app initialization and business logic (e.g. returning Resource[F, Service[F]] in makers). Advice: prefer returning Resource[F, Service[G]] with different sets of bounds on F and G. 4/7

Problem: sticking to ReaderT rather than introducing another abstract effect with its own bounds. Advice: have as many effects as you need and declare their abilities directly via context bounds (algebras). Later you can provide ReaderT or ZIO to those parameters. 5/7

Problem: inability to mapK on any of your service algebras (e.g. using F not in covariant positions). Advice: prefer such that can have a FunctorK instance or at least a mapK method (if extra bounds on F are needed). My fav are such that have a RepresentableK instance btw. 6/7

Most of the opensource TF libraries I see suffer from some of these drawbacks. If you spot any of them, try to fix it. This will make your code easier to integrate with. 7/7