| |
| ▲ | nightpool 3 days ago | parent | next [-] | | 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? | | |
| ▲ | whstl 3 days ago | parent | next [-] | | 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. | |
| ▲ | matt_kantor 3 days ago | parent | prev | next [-] | | 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. | |
| ▲ | Neywiny 3 days ago | parent | prev [-] | | 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. |
| |
| ▲ | throwaway894345 3 days ago | parent | prev | next [-] | | Most components need to depend on an auth service, right? I don’t think that means it’s all necessarily one service (does all of Google Cloud Platform or AWS need to be a single service)? | | |
| ▲ | Spivak 3 days ago | parent [-] | | That's immediately what I thought of. You'll never be able to satisfy this rule when every service has lines pointing to auth. You'll probably also have lines pointing to your storage service or database even if the data is isolated between them. You could have them all
be separate but that's a waste when you can leverage say a big ceph cluster. | | |
| ▲ | spyspy 3 days ago | parent [-] | | The trick I've used is the N1 (gateway) service handles all AuthN and proxies that information to the upstream services to allow them to handle AuthZ. N+ services only accept requests signed by N1 - the original authentication info is removed. |
|
| |
| ▲ | suspended_state 3 days ago | parent | prev [-] | | I think it does indeed make a lot of sense in the particular example given. But what if we add 2 extra nodes: n5 dependent on n2 alone, and n6 dependent on n3 alone? Should we keep n2 and n3 separate and split n4, or should we merge n2 and n3 and keep n4, or should we keep the topology as it is? The same sort of problem arises in a class inheritance graph: it would make sense to merge classes n2 and n3 if n4 is the only class inheriting from it, but if you add more nodes, then the simplification might not be possible anymore. |
|
