Realworld: Microservices

[jonniedarko]

Would love to see/help with a microservice architecture where we could mix and match any of the current different technologies for different api's with a single authorization/authentication. Is this a realistic goal?

[Cameron-C-Chapman]

I was thinking of this as sort of a stretch goal with the Spring project. I think it would need to all be composed in a docker container with a single gateway the front end app could call. I think if it could be started up as easy as a single service and wasn't an entry barrier but demonstrated a microservice architecture it could be useful to people.

I don't think it makes sense as a standard though, could just be a flavor of backend implementation.

[lolripgg]

If this happened, I think it would be a ways down the road. Distributed systems (microservices) come with a whole host of issues that centralized systems (monoliths) don't have to deal with. I don't think we have the ability to do microservices well at the moment. If we decide to write some microservices implementations then we should do it when we have the resources to ensure we can do a good job.

[littleStudent]

Hi folks.
I thought about contributing a lightweight backend implementation based on micro. Each API CRUD endpoint would live in its own microservice.
Regarding the entry barrier. It should be possible to configure the project for simple usage. Running npm run server would start up all microservices with routing setup up already. Let me know what you think.

[jonniedarko]

Thats interesting. I was actually thinking in terms of using
Docker/Docker-Compose

[lolripgg]

I stand by my previous statement.

Using microservices creates a distributed system. One of the hardest parts about distributed systems is handling transactions across services. (e.g. If Service A succeeds and Service B fails, then Service A needs to be rolled back.) You also need to be able to trace transactions across services, which comes with it's own set of problems.

Using microservices is a bad idea in general. Given all of the problems associated with microservices, they should be a last resort.

TL;DR I think microservices are too advanced for the typical RealWorld user.

[Cameron-C-Chapman]

While I disagree that microservices are a bad idea in general, there are a lot of benefits to that architecture, I do agree that it's probably beyond the scope of what realworld is trying to accomplish. So maybe the final thought on this for now is that people are free to do it but it probably won't be merged into the master project?

[EricSimons]

^ yeah, that's the official stance IMO. Microservices kinda fall outside the core spec, but we def want to encourage people to get creative with extending Conduit beyond the spec itself :)

[lolripgg]

Is there anything left to add to this conversation or do we have a consensus? If the latter, should this issue be closed?

[Cameron-C-Chapman]

I was just thinking the same thing @brwr , I think this could be closed along with the 118n and test spec issues.

[lolripgg]

I think it's likely that others will agree too. I'm going to close this for now. Anyone who has objections should feel free to raise them and we can re-open this issue if needed.