I do work with different styles of monorepos for a few different clients and the one thing I absolutely always find is that a lot of the challenges end up really distilling down to business and organizational decisions rather than technical ones.
It's a balance between the convenience of having a central source of truth on versioning and maintaining separation of the individual packages/apps that sometimes developers can be contracted to contribute to but are not meant to have visibility on the larger ecosystem.
I will say that the idea of file locks on specific parts of the monorepo is new to me, do you have any more info or sources on that? My practice recently has been to handle those pieces as git submodules so that devs can be given specific access to those pieces individually and project leads can manage the monorepo, but of course submodules come with their own set of challenges.
Either way I appreciate the detailed response. Cheers.
Personally I haven't done file locks and am not too familiar i think with GitHub enterprise you could use git LFS but I was thinking initially to set authorization through a seperate PSQL prisma model database instance on either locally generated with LFS or online to check within the husky file (will probably be years till i get there).
Just looking at Apollo graphql fed and having subgraphs/schemas and gateway to have separation of concerns is pretty cool for performance while still having that monrepo feel. Still in the monorepo realm but what apollo fed has to offer is going to become interesting. especially when you have one graph it can't become performant for the certain graphs you need from the start.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice, I totally agree..
I do work with different styles of monorepos for a few different clients and the one thing I absolutely always find is that a lot of the challenges end up really distilling down to business and organizational decisions rather than technical ones.
It's a balance between the convenience of having a central source of truth on versioning and maintaining separation of the individual packages/apps that sometimes developers can be contracted to contribute to but are not meant to have visibility on the larger ecosystem.
I will say that the idea of file locks on specific parts of the monorepo is new to me, do you have any more info or sources on that? My practice recently has been to handle those pieces as git submodules so that devs can be given specific access to those pieces individually and project leads can manage the monorepo, but of course submodules come with their own set of challenges.
Either way I appreciate the detailed response. Cheers.
Personally I haven't done file locks and am not too familiar i think with GitHub enterprise you could use git LFS but I was thinking initially to set authorization through a seperate PSQL prisma model database instance on either locally generated with LFS or online to check within the husky file (will probably be years till i get there).
Just looking at Apollo graphql fed and having subgraphs/schemas and gateway to have separation of concerns is pretty cool for performance while still having that monrepo feel. Still in the monorepo realm but what apollo fed has to offer is going to become interesting. especially when you have one graph it can't become performant for the certain graphs you need from the start.