Demo with two repos?

[davix]

Hi, first, I love your articles and this repo very much and want to learn from them.

One thing not quite clear to me is that the two services trainer and trainings are in the same repo. It's different from our usual case that different services are in their own repos.

Since they are in the same repo, there is common folder that used for some shared info. This is not easy if they are two repos. Also component test and end-to-end test seem a little easier.

It'll be better to demo the same with two repos and I'd love to see how it looks.

Thanks!

[m110]

Hey @davix, I'm glad to hear you like the articles. :)

You're totally right, the current structure is not usual when working with microservices. We picked this way to make it simpler to understand the codebase and the refactors - it's easier to go through a single commit in one repository.

We plan to build new features on top of the current example, and perhaps we'll show the approach with separate repos in the future.

But the crucial thing is, the current project is designed so that it'll be trivial to split it into 4 repositories. The three services don't refer to each other at all, the only shared part is the common package, as you mentioned, and the OpenAPI/protobuf definitions. You can see that each package has its own go.mod.

You can try it yourself - the application should work out of the box when put in different repositories. The hard part is the infrastructure setup (docker, docker-compose, cloudbuild), as now they are shared. We don't focus on this in the series (yet). :) You could just copy these for now.

Component tests should work the same in separate repositories, as by definition they don't call external services. End-to-end are the hard part, as usual. You could have another repository just for that, with a docker-compose running all services.

Another important thing to think about is how you will maintain the common library. Usually, you would have a dedicated CI job that would bump the version on a new master commit (push a git tag, basically). Then you need to decide how it will be bumped in other repositories, which can be manual or fully automated.

I hope it clears things up a bit, let me know if you have any questions!

[koolay]

@m110 @davix We can try monorepo. https://medium.com/goc0de/how-to-golang-monorepo-4f62320a01fd