Reading about micro services and they sort of sound like mini APIs wrapped by individual HTTP servers.

But if all the APIs need to send requests to each other wouldn't the overhead from just making the connections for each request add up and be huge?

If [micro service] == [single class as service] yes it will catch up to you. And if you build your micro services as a “microlith” (micro service monolith) it should just be collapsed to a service.

The goal of DRY is to write it once; the goal of micro services are DRY across your architecture. However if you write a micro server called “compare_service” where you API in two things and it returns json that’s says left is bigger, they are equal, cannot compare, etc then you have taken things to far.

@bkwilliams So our current architecture is all data is loaded into 1 MongoDB, many collections (Entities). But a lot of API functions are complex. If this were a SQL query, it would involve several Joins and Wheres

I was thinking a good rule would be all collections should only be accessed thru their own microservice. But then it feels like we're just rewriting DB functionality but limiting it.

I actually remember on my old team we did that but then users wanted so many different functions for different sets of parameters, I just said screw it. Wrote a query string parser that just translates whatever parameters they pass in to the SQL equivalent and then run it...