Comment by nightpool | Hacker News Reader

Comment by nightpool | Hacker News Reader

Parent Full thread

I don't understand this. Can you help explain it with a more practical example? Say that N1 (the root service) is a GraphQL API layer or something. And then N2 and N3 are different services feeding different parts of that API—using Linear as my example, say we have a different service for ticket management and one for AI agent management (e.g. Copilot integration). These are clearly different services with different responsibilities / scaling needs / etc.

And then N4 is a shared utility service that's responsible for e.g. performance tracing or logging or something similar. To make the dependency "harder", we could consider that it's a shared service responsible for authentication and authorization. So it's clear why many root services are dependent on it—they need to make individual authorization decisions.

How would you refactor this to remove an undirected dependency loop?

Yeah, a lot of cross-cutting concerns fall into this pattern: logging, authorization, metrics, audit trails, feature-flags, configuration distribution, etc

The only way I can see to avoid this is to have all those cross-cutting concerns handled in the N1 root service before they go into N2/N3, but it requires having N1 handle some things by itself (eg: you can do authorization early), or it requires a lot of additional context to be passed down (eg: passing flags/configuration downstream), or it massively overcomplicates others (eg: having logging be part of N1 forces N2/N3 to respond synchronously).

So yeah, I'm not a fan of the constraint from TFA. It being a DAG is enough.

I think this philosophy only reasonably applies behind the public-facing API gateway. So the GraphQL API server wouldn't be part of the microservice graph that you're trying to make into a polytree (you also wouldn't consider the client-side software to be part of this graph). You can use GraphQL delegation or similar to move more responsibility to the other side of the line.

The only alternative I can think of is to have a zillion separate public-facing API servers on different subdomains, but that sounds like a headache.

I tried and cannot. Just keep thinking of it as: if something is doing 2 jobs, split it, if 2 things have the same as they say goes-in-tos and -goes-out-ofs, combine them. And same doesn't mean bit for bit match (though obviously don't needlessly duplicate data), but just a bit higher level.

The problem is that I don't sit in the microservice or enterprise backend spaces, so I an struggling to formulate explanations in those terms.

Reply on news.ycombinator.com