Use monorepo?

[leoloso]

Hey guys, I can see your GraphQL server directly depends on many other packages, and you have each of them on its own GitHub repo. That will make it difficult for your contributors to send PRs, whenever the modification comprises 2 or more packages, if they don't know their way around.

I had my project with a similar set-up as yours (well, with over 100 packages though), and it was impossible to manage. Then I migrated the codebase into a monorepo, and use the Monorepo Builder, and now it's manageable. I highly recommend it. I have the impression you could benefit from it too.

[peldax]

Hello,
Thanks for your suggestion.

Currently this package depends only on tokenizer/parser (when counting only graphql related packages, but indeed I have some other sub-packages in mind as visualised in the diagram), and I believe those are standalone tools which should be completely decoupled and have its own versioning.

• Tokenizer can be used eg. for any Graphql syntax highlighting.
• Parser can be used, well, for parsing documents.

But I completely understand your reasoning. For example when new GraphQL syntax is accepted into specs, in this particular case It might require up to 3 different pull requests - for tokenizer (when new operator is intoduced), parser (to possibly include some feature in ast), and finally in the main package (to implement possible behaviour change). I believe those are rare cases and those big changes should be approached cautiosly and separately, so it would make sense for every package on its own.

The other packages with graphpinator reference are opt-in extensions and I simply dont want to force them to users which may never use it.

I had several other motivations for repository splitting:

• It is pretty much a standard in PHP package ecosystem on github to have a package-per-repo achitecture.
• The tests grew bigger and bigger and it started to be really hard to maintain. (This could be caused by bad design of some tests.)
• Splitting the code removes any unwanted coupling. Ofc this could be validated using some QA tools, but having it completely separate makes it easier to enforce and harder to miss.

I am gratefull that you started this discussion. Software design is a complicated subject and every approach have its pros and cons. Please, this is not a discard of your idea, I am trying to explain my reasoning on why I decided to go this way. I am looking forward for your possible response and I would be happy if it contained something that I missed, so I could re-evaluate a avoid possible problems.

Thanks.
VP

[peldax]

But I am definitely going to checkout the monorepo builder and evaluate how could this project benefit from it 👍.

[leoloso]

Sure, the decision is yours, I'm just making a suggestion.

Nevertheless, a monorepo is only for hosting code, without implications on if those packages must be tightly coupled or not. You can have a monorepo yet deploy each package on its own (indeed, you will still need a repo per package, if only because of Composer). So that's not a concern with your architecture.

From this article:

In a mono-repo approach, all services and codebase are kept in a single repository.

When engineers think of mono-repo, they generally think of a single-tiered application that runs multiple components in the same process, on the same system, packaged and deployed as a monolith. Yet a mono-repository app does not mean a monolithic app. You could house multiple services in a single repository and build and deploy each service independently. We can look at mono-repo as a way of structuring your project so that:

• multiple independent services live in the same code repository;
• the services may share a common code or libraries;
• a change to one service does not necessarily rebuild the entire project, but only the service that is affected by the change.

[peldax]

I understand that Monorepo serves only for code hosting without any implications on the architecture, but it feels to me that it makes it really easy to exploit with with some architectural blunders. Or are there any mechanism to prevent that? (Apart from QA tools which I am aware of.)

What about the code versioning in Monorepo design? If I understand it correctly, than all packages are versioned together.

[leoloso]

it feels to me that it makes it really easy to exploit with with some architectural blunders. Or are there any mechanism to prevent that?

I don't know what you mean

What about the code versioning in Monorepo design? If I understand it correctly, than all packages are versioned together.

Yes, that's how it is

[peldax]

For example, how do you handle cyclic dependencies between internal packages. Is there any mechanism to warn you about potential architecture flaw or does it just blindly bundle dependencies?

[leoloso]

You should not have cyclic dependencies, because you still need to use Composer. The monorepo hosts the code, but doesn't like the package to each other, that is always the same.

Also, you can run tests on the whole monorepo at once, but also on each package independently, so if there's a recursive dependency, Composer will complain, and if a required dependency is missing from composer.json, then running the tests will fail.

[peldax]

Thanks for the explanation!

Its definitely a possibility and it seems to solve most of the problems. However, I am still going to stand for myself and keep the repositories split. In my opinion its a matter of preference and I would like to continue this way. Still, I am very grateful that you started this discussion and showed me another way of doing it.

If you don't mind, I am going to convert this issue to discussion.