Take into account that the Travis tests will fail since the DB Docker container hasn't been added until the next PR #8.
Highlights to take into account
Add database tables definition
Replace in memory users repository by an actual implementation of the repository using MySQL and Doobie
Define ActorSystem, ActorMaterializer, and ExecutionContext dependencies on the SharedModuleDependencyContainer in order to do not repeat their definition in prod, integration, and acceptance tests.
Add Doobie mappings for all the Video types
Remove in memory repository implementations in order to use MySQL instead
Update application service and domain interfaces contracts in order to return a Future[T] instead of directly returning T. This is because of using an async implementation of the repositories instead of a sync one. This will be refactored to type classes in further PRs in order to illustrate how to decouple from Future.
Define the ExecutionContext as an implicit dependency in order to follow the idiomatic way of dealing with it in the repositories. This had made to define it also as implicit while declaring the SharedModuleDependencyContainer. It feels a little weird so we can discuss it if you have better alternatives.
Add custom names while marshalling Video to JSON in order to be able to expose the video duration as duration_in_seconds instead of just duration. It feels a little weird, but it's the only way to make publicly explicit the duration measure unit.
Renamed UserSpec to UserEntryPointShould test naming. Why changing User to UserEntryPoint: It matches in a more direct way with the production code it tests out. Why changing Spec to Should: It enables to read the test cases more fluently without having to add one nesting level to our test classes (we can remove what we used to define as "User Entry Point" should {} and directly add the test cases "return all the system users" in {})
Dinamicaly add videos while testing out the videos entry point instead of having them hardcoded
Some concerns to discuss
I've used the Doobie unsafeToFuture operation despite of being the worst option their API offer. I've done this in order to illustrate the refactor to an abstract type class constructor in further functional courses. What do you think?
The dependencies graph is growing a little bit and it start feeling a little bit messy, don't you think?
The application configuration is also growing and we should isolate it into case classes such as the DbConfig one and initialize it into its own very object. Use Circe (?)
Should we extract secret config such as the database user & password to environment variables?
Take into account that the Travis tests will fail since the DB Docker container hasn't been added until the next PR #8.
Highlights to take into account
ActorSystem,ActorMaterializer, andExecutionContextdependencies on theSharedModuleDependencyContainerin order to do not repeat their definition in prod, integration, and acceptance tests.Future[T]instead of directly returningT. This is because of using an async implementation of the repositories instead of a sync one. This will be refactored to type classes in further PRs in order to illustrate how to decouple fromFuture.ExecutionContextas animplicitdependency in order to follow the idiomatic way of dealing with it in the repositories. This had made to define it also as implicit while declaring theSharedModuleDependencyContainer. It feels a little weird so we can discuss it if you have better alternatives.Videoto JSON in order to be able to expose the video duration asduration_in_secondsinstead of justduration. It feels a little weird, but it's the only way to make publicly explicit the duration measure unit.UserSpectoUserEntryPointShouldtest naming. Why changingUsertoUserEntryPoint: It matches in a more direct way with the production code it tests out. Why changingSpectoShould: It enables to read the test cases more fluently without having to add one nesting level to our test classes (we can remove what we used to define as"User Entry Point" should {}and directly add the test cases"return all the system users" in {})Some concerns to discuss
unsafeToFutureoperation despite of being the worst option their API offer. I've done this in order to illustrate the refactor to an abstract type class constructor in further functional courses. What do you think?case classes such as theDbConfigone and initialize it into its own very object. Use Circe (?)