Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

questions #309

Open
Zorodebug5 opened this issue Oct 8, 2024 · 1 comment
Open

questions #309

Zorodebug5 opened this issue Oct 8, 2024 · 1 comment

Comments

@Zorodebug5
Copy link

First, this is one of the best examples on GitHub, I all most reviews more than 100 code base on GitHub
just I have few questions please if you could help me improving myself,

  1. why do you think creating a special module for logger contains a few classes is better than putting logger in util module for example, because each module will add a complexity for the project

  2. what is the purpose of splitting api,implementation modules into two modules instead of one module with two packages

@thomaskioko
Copy link
Owner

thomaskioko commented Nov 8, 2024

Hi @Zorodebug5, sorry for the late replay. Thanks so much for the compliment. 🙂

  1. The logger was in the util module; I moved it out to experiment with a few things. I plan on adding Firebase to it. But only time will tell.
  2. Your question is valid. I admit this is an overkill and could be simplified. I started with them being in a single module(common), but things were getting out of hand.

The whole idea of the API/Module implementation is this:

  • It makes experimenting with new/different technologies easier without changing a lot in other modules.

  • Better communication/sharing between modules. One "complex" feature is the show details. We need to get Show Information, Trailer Information, Season Information, etc. If you think about it, show-details module doesn't care about the implementation or dependencies. We just need to use the api modules to request data. To sum it up

    • api -> Describes the module on a high level . Eg, Gets me a list of shows.
    • implementaiton -> Contains all the implementation details, dependencies/libraries used.
  • Better dependency hierarchy & encapsulation. (Transitive dependencies can be a pain.)

  • Using Fixtures for testing: One huge thing that I like with this approach is I can easily create fixtures and use them in my tests instead of using mocks. So, better tests. 😄 So if the implementation ever changes, we can catch anything that's broken with the tests.

  • It's not visible here, but when you scale, it helps with build speeds.

I wrote an article about it here. It will give you a glimpse of how. I got here.

I hope this answers your question. If you need help or more clarification, feel free to ask.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants