Feature/fiat payments

[ygrishajev]

Proposal for Billing Feature Structure

This PR proposes a structure for the upcoming billing feature. It includes some entities to showcase the structure, so please overlook any weak typing or lack of implementations for now.

Main Concepts

Dedicated Module

• The billing module should ideally include all entities necessary to implement its business requirements within its domain.
• It would be beneficial for the module to contain database accessors, services, controllers, and routers.
• The module should aim to hide the complexity of business logic under the hood.
• It should expose only HTTP APIs and control what can be imported by other modules.

Flat Structure

• To maintain clarity, avoid deeply nested submodules. Since the application domain is already clear, a flat structure is suggested.
• Recommended directory structure:

Correct:
-- billing
-- -- services
-- -- -- wallet-manager
-- -- -- -- WalletManager.ts
-- -- -- -- WalletManager.spec.ts
-- -- -- wallet-refill-service
-- -- -- -- WalletRefillService.ts
-- -- -- -- WalletRefillService.spec.ts

Wrong:
-- billing
-- -- services
-- -- -- wallet-manager
-- -- -- -- WalletManager.ts
-- -- -- -- WalletManager.spec.ts
-- -- -- -- WalletRefillService.ts
-- -- -- -- WalletRefillService.spec.ts

Naming

• Aim to use consistent naming conventions:
  • kebab-case for directories.
  • CamelCase for files.
• Names should ideally reflect the main export. While names like utils and helpers are common, they can be misleading. Instead, consider using names that clearly describe their purpose, such as StringService for something that works with strings.

Exports

• It's generally better to avoid files containing code for multiple purposes. Splitting them can help ensure each file serves a single purpose, which aids in clarity and maintenance.

Database

• Direct access to Sequelize DB models should be limited. Abstracting Sequelize using a repository pattern can help ensure the app doesn’t depend heavily on the storage mechanism.
• This abstraction can be beneficial, especially if ORM or DB changes are needed in the future.

Workers

• Workers should operate independently of the main HTTP app to prevent potential performance issues under load.
• Consider using a CLI as a dedicated entry point for workers. Building a container for the job and running it with the infrastructure (e.g., this example) can provide a dedicated environment while maintaining a unified codebase.

Dependency Injection (DI)

• Utilizing dependency injection can produce more testable and independent code that relies on interfaces.
• While classes are a natural fit for DI, a functional approach can also be effective. DI can be beneficial even in apps without a specific framework.

Migrations

• We need to discuss our approach to migrations. Using Sequelize for this might increase our dependency on it and impose structural obligations on our app.
• It may be worth considering other tools or methods for handling migrations to maintain flexibility.

Note: This is a proposal. I welcome counter-arguments and suggestions. The goal is to have a constructive discussion and agree on an approach we can follow consistently.

[baktun14]

How do you DI being implemented? I know there's some libraries to automate the instantiation based on the type.

[ygrishajev]

@baktun14 DI is an approach. Instead of importing a dep and using directly it should be provided as an arg to a function/class. Like I did in the example.

Although I agree some automation would be nuts.

[ygrishajev]

@baktun14 @Redm4x BTW decided to investigate DI question just a bit. Some options:

• https://github.com/zazoomauro/node-dependency-injection/wiki
• https://docs.nestjs.com/standalone-applications

both things should be easy to use from the start.

Basically the flow would be: 1) use classes as usual 2) register them 3) create context and put it into hono route context

Say, we have these dependency flow: WalletController -> WalletService -> UserWalletModel

These classes are the same as if there's no automated DI, so no extra work. What needs to be done: 1) install new lib to manage that (no effort) 2) create a simple service defining all the deps. In case with the lib that would be creating a container and a lib, in case with nest it would be a module + context. (we have 2-4 classes to start with - 30min?) 3) add it to hono with a middleware (30min to try and test)

I don't see too much effort in this. If you guys think this is beneficial it's better be done imo.

[ygrishajev]

oh, this one seems even better https://www.npmjs.com/package/typedi

[baktun14]

oh, this one seems even better https://www.npmjs.com/package/typedi

Yea this is the one I saw in an article.

[ygrishajev]

Ok, added TypeDI - this is really not a big deal in terms of effort, the impact though is changing imo.

UPDATE:

ugh... I don't like this https://github.com/typestack/typedi/issues/1235

will try some of these

UPDATE:

ok, TSyringe from Microsoft looks real nice and must be reliable https://github.com/akash-network/cloudmos/pull/251/commits/b2cf5ac228eb4b710fb74c8dad97c84e6c900b47

[ygrishajev]

added drizzle https://github.com/akash-network/cloudmos/pull/251/commits/837319c7c6a27a671acff033ac6ccf440d3bfefb

this is a fully functional example. I personally see no reason not to start migrating slowly.

[ygrishajev]

What's the naming convention for services? camelCase or PascalCase?

I tried to describe is the convention in the description of this PR. I personally like it in a different way. However, I tried to match something that we already have in the project. I am open to change this to something we can commonly agree to.

I personally like nest JS convention when directories are named in snake case and files are named in snake case with an extension containing the type of the file. Like some-class.service.ts. The file should contain a class or a function that that is named the same as the file by camel case. To me, this approach reduces cognitive load when going through the code radically.

[baktun14]

What's the naming convention for services? camelCase or PascalCase?

I tried to describe is the convention in the description of this PR. I personally like it in a different way. However, I tried to match something that we already have in the project. I am open to change this to something we can commonly agree to.

I personally like nest JS convention when directories are named in snake case and files are named in snake case with an extension containing the type of the file. Like some-class.service.ts. The file should contain a class or a function that that is named the same as the file by camel case. To me, this approach reduces cognitive load when going through the code radically.

I was referring to logHttpRequests.ts and postgres.ts that are camelCase.

[ygrishajev]

What's the naming convention for services? camelCase or PascalCase?

I tried to describe is the convention in the description of this PR. I personally like it in a different way. However, I tried to match something that we already have in the project. I am open to change this to something we can commonly agree to.

I personally like nest JS convention when directories are named in snake case and files are named in snake case with an extension containing the type of the file. Like some-class.service.ts. The file should contain a class or a function that that is named the same as the file by camel case. To me, this approach reduces cognitive load when going through the code radically.

I was referring to logHttpRequests.ts and postgres.ts that are camelCase.

Right, those are files and match the main exported function