Merge projects in the short term

[stuartleeks]

In the discussion with @krist00fer yesterday about project structure, my initial reaction was that we'd decided on the requirements and structure and should just "suck it up". I spent some time thinking about it afterwards, and now I think I've changed my mind!

A large part of the current project structure is driven by the desire to be able to run and scale each service independently. However, the split in the projects is also slowing the implementation and iteration of design, has added some extra challenges for the "clone, build, run" developer experience, adds complications for deployment (which also impacts integration testing), and potentially complicates authentication.

All of these are challenges that we will need to face, but after thinking about it last night I'm not sure whether they're challenges that we want to face now. My feeling is that we would be better of accelerating the initial implementation of the API, build & run, integration tests etc, as this will allow us to have something to share (both with other people interested in contributing and with people who we're targeting as users of nether). With a bit of thought, we should be able to set up a structure that helps to minimise the amount of code refactoring when we are ready to pick up the work of splitting the services out again.

Thoughts? :-)

[krist00fer]

I agree, I think this is what we should do. Keep it super simple so we can have something to show. Still keep the vision of the "perfect architecture" in our heads, but keep everything simple. If we just adhere to a few rules a more simple architecture right now would not be that hard to split later on if needed to.

[stuartleeks]

I've just started on a branch with some thoughts on how to implement this. I'll try to get it as a pull request later today for comment as part of this discussion.

[stuartleeks]

The turning point for me was thinking about how many things we want to get set up to enable others to join and contribute to drive the functionality forward, and how many of those are things complicated by the current choice of project structure. We still have to come back and figure those things out later, but I think that we can unblock a lot of things to get us to the point of being able to involve others sooner by simplifying the project structure. We can then work out the other challenges incrementally from there :-)

When I send the PR, one aspect to discuss will be around approaches to keeping the logical separation of code to ease splitting out again in the future.

[krist00fer]

We could also argue that perhaps we don't neet to split out ever again as long as we keep it configurable and open source. For example if I deploy Nether I'll get the full blown package, but I can select to enable the APIs for leaderboard, playermanagement and analytics independently. If I don't like the idea of having source code there that I'm not currently using then I can go into the source and remove it. If I want to plug in a different behavior, i.e. using another leaderboard service or similar, I just plug in that dependency.

[stuartleeks]

He he - that discussion is going to be fun ;-)

[stuartleeks]

Closing as this is implemented in #77