Hi Jérémie, nice work!
I am looking into integrating Keycloack service to service and user login into an app so I found this. But the number of dependencies scares me and I would prefer to use my existing web library over Yada. I think it would help adoption if you split it into multiple libraries or a library + an example, with minimal dependencies. F.ex. a core, a library for just service to service auth, a Yada-based library/example for auth backend.... I assume most applications will use but not create users, roles, etc. (Not sure if excluding that would limit the dependencies of the app, though). I find it strange to see talltale in production code as it seems to be primarily a test-time library... And perhaps cheshire could be made optional, allowing the user to provide their own edn<>json transformation (based on the libraries/versions they already use)...
Just some ideas :-)
Hi Jérémie, nice work!
I am looking into integrating Keycloack service to service and user login into an app so I found this. But the number of dependencies scares me and I would prefer to use my existing web library over Yada. I think it would help adoption if you split it into multiple libraries or a library + an example, with minimal dependencies. F.ex. a core, a library for just service to service auth, a Yada-based library/example for auth backend.... I assume most applications will use but not create users, roles, etc. (Not sure if excluding that would limit the dependencies of the app, though). I find it strange to see talltale in production code as it seems to be primarily a test-time library... And perhaps cheshire could be made optional, allowing the user to provide their own edn<>json transformation (based on the libraries/versions they already use)...
Just some ideas :-)