Herbs Container DI for applications

[maikvortx]

Describe the solution you'd like

The purpose of this tool is to make it more scalable and make service dependency management easier in your applications that uses gotu usecases and services and take advantage of the inversion of control pattern to loosely couple the components of your application and make them easier to test and maintain

This library can resolve services using Proxy to lazy loading services requesting and register multiples services types like:

• Function
• Class
• Single Value

Describe alternatives you've considered

• bottlejs
• awilix

Additional context

This library can be found in herbs-di and a example of express middleware

container
    .addAsFunction(userRepository)
    .addAsClass(UserService)
    .addAsValue('cache', cache)
    .addAsFunction(getUsersUseCase);

const useCase = container.factoryContainer().getUsersUseCase;
var output = await useCase.run({ name: 'Kenedy' });

[dalssoft]

Hi @maikmb , thank you for your contribution.

Could you please explore what is the exatly problem you are trying to address here?

[jhomarolo]

This is still valid?

[maikvortx]

Hello guys!

I'm not comfortable with the current dependency format in the project. I suggest this format to make a dependency container clean and easy to manage dependencies in the project.

What do you think about working in a dependency container like this project awilix nodejs?

[maikvortx]

@dalssoft
@jhomarolo

I have created an example of a dependency injection container in this project: https://github.com/maikmb/herbs-di

I trust in this pros points:

• Remove the dependency variable of the usecase and create a more declarative code
• Register all dependencies in one place
• The UnitTest will be more trusted because generally if you forget a mock parameter the usecase assumes default dependence

Example project:

Container DI :

const injection = container
    .addAsClass(userRepository)
    .addAsFunction(getUsersUseCase);

Usecase

const getUsersUseCase = ({ userRepository }) =>
  usecase("Get All Users", {
    request: {
      name: String,
      email: String
    }
    'Get users from data base': step(async ctx => {
      ctx.users = userRepository.getAll()
      return Ok(ctx.users)
     })
})      

Server/Controller:

const app = express()
const port = 3000

**app.use(useHerbsDi(injection))**

app.get('/', async (req, res) => {
    const { getUsersUseCase } = req.injection;
    const ret = await getUsersUseCase.run({ name: 'Jhon' });
    if (ret.isOk) {
        res.send({ users: ret.value });
        return;
    }
    res.send({ error: ret.err })
})

[dalssoft]

The way I see now, the solution is well defined, however the problem is not. I still have a hard time understanding what problem this solves. I think it would be good to have a more concrete example of scenarios where the current solution is not enough and this one is better.

About the points you mentioned:

Remove the dependency variable of the usecase and create a more declarative code

Looks more like a personal preference. How is this a problem? I don't see how this is better than the current solution.

Register all dependencies in one place

I can't see how this is better than the current solution. I think it's better to have the dependencies close to the use case, so it's easier to understand what the use case needs to work.

Having all dependencies in one place makes creates this indirection that makes it harder to understand what the use case needs to work, also it makes it harder debug in case of errors.

The UnitTest will be more trusted because generally if you forget a mock parameter the use case assumes default dependence

It is a tradeoff and a design decision. If you have your production dependencies defined as your default dependencies (as it is now), you need to make sure that your tests are using the correct dependencies. It forces you to think about what dependencies you need to use in your tests.

I'm open to discuss this further, but I think it's important to have a more concrete example of a problem that this solves.