Replies: 1 comment 2 replies
-
Thanks for the detailed document, do you think the migration container is the way to go? I made that since I had issues with enums when the back was doing the migrations and tried the recommended way of doing it. My opinion on the migration container is: Pro:
Cons:
I also dislike the way EF does migrations with lots of generated c# files and all, but I think we're stuck with it since that's the way the ORM works. Overall, I think moving back migrations to the api's container might be good, what do you think? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
There has been a bit of discussion about how to handle managing databases and the amount of containers. Taking a few moments to write out some of my thoughts.
CONTEXT
Currently Kyoo currently leverages a dedicated container, ghcr.io/zoriya/kyoo_migrations, for managing the database that kyoo_back application connects to. That container is built using the Kyoo backend source code in the
back
directory. Looking through the source code, EntityFrameworkCore is used for both generating schema and storing migrations. Those migrations are bundled/packaged into a single purpose artifact dedicated to managing any database setup.PRO
Having separate containers does have some notable benefits including: reducing application runtime permissions, avoiding supporting long startup times due to database management in the application, and overall makes support easier.
CON
Dedicated migration container is overkill in most situations, especially with microservice architecture where the schema tends to be only a few tables/relationships. Each application should be expected to have its own database. Modern developers are expected to be the DBAs for their application. Separating out different users/roles/permissions between migration and application tend to be a lot of additional overhead especially for those getting started.
REALITY
EFCore does not have a way for handling concurrent migrations. https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/applying?tabs=dotnet-core-cli#apply-migrations-at-runtime. So running inside of the application OR as an init container can potentially lead to conflicts. Other database versioning tools, such a Liquibase, add database locks to prevent that issues. A dedicated container is only EFCore supported way.
SUGGESTIONS
Taking the jump into a distributed systems is challenging. So far everything I see in Kyoo is going in the right direction! Use as many containers as needed for avoiding monoliths.
Beta Was this translation helpful? Give feedback.
All reactions