Dependencies number

[decebals]

Hi,

First of all, congratulations for this library. The code looks good, the site is very good with a lot of useful information. I think to use your library in one of my project to improve the audit part. My concern is related to the number of dependencies. In my opinion is a little bit high. My application is a relative small application, that uses Pippo web framework (140K) and the target machine is ... Raspberry PI :) For this reason I wish to keep the amount of jars at minimum. I wrote in the past a tiny audit library but the performance of your library and the configurability of it, are the reasons to make me to write you. Your modular approach (audit4j-*) is very welcome but I need to reduce somehow the number of audit4j-core + dependencies.

[janithb]

Hi @decebals ,

Thanks for considering Audit4j. From the initial stage, audit4j is designed for the enterprise applications and we haven't designed audit4j for embedded systems.

I think If you are designed the Auditing(or logging) library you should consider below two things,

1. Auditing process should not interfere main business flow specially in performance critical systems, so the design should be based on async.
2. Throughput: unlike any other business function, auditing mechanism should handle high throughput since most of the business events captured through single entry point.

Initially we used ActiveMQ to handle audit events asynchronously but It's not the suitable mechanism when we consider the throughput since we had the requirement to process 25000 TP. After several considerations and evaluations we redesigned the Audit4j and used reactor for asynchronous processing. Currently audit4j is built around reactor and various streams. To cater your requirements, I would suggest fork the audit4j core in to embedded version (audit4j-core-embedded maybe) and eliminate the dependencies. You can easily eliminate other dependencies but the reactor-core.

Drop me a line if I can do anything else for you.

~Janith

[decebals]

Thanks for your explanations!

audit4j is designed for the enterprise applications

I understand what you say. In the context of enterprise the numbers of jars are not a problem (because they are a lot already). Personal, I prefer to not work with full stack product (for example Spring). I prefer to assembly small very good small libraries (to be agile, to be able to change small parts not the entire system).

Audit4j and used reactor for asynchronous processing

Very good choice the solution with reactor.

A solution is to add in audit4j-core only the API and a "decent" implementation and move the part with reactor in a audit4j-reactor (or audit-async) module. Of course someone may say that this comes with a little fragmentation.

I have a curiosity, what is the role of schedule package (where is used in audit4j)?

[decebals]

In the end I chose to create a tiny library, Auditor. I added in readme a link to your excellent library. Keep up the good work!