05/09/2023, 6:06 PM
I think there are some open questions regarding our direction of microservices, grpc comms, API, etc. 1. What gets broken out into microservices? Auth I think is a good target and is in-progress. What else? Let's define that roadmap 2. gRPC comms between services - authenticated or no? I said no on today's call but I wonder if I'm wrong 3. How are we presenting a REST API to external consumers (incl. frontends)? 4. Is an API gateway necessary here or is it overkill?
For #1, I am worried a bit about sprawl. I don't want to do microservices just for the sake of microservices. But I also think that some places it makes sense, auth seems to be one of them. What areas can we define that should or should not be microservice'd?
For #3, to me it is imperative that we offer a human-readable API.
For #4 I know that many of the features we are implementing ourselves are also handled by an api gateway. For instance, authN/Z can be done at a gateway and we delegate that work away from the HF core. But does that make sense for us? How would an api gateway integrate with our existing RBAC model based on kubernetes roles? Should it?
Also if we decide to use an api gateway, we may not want to delegate authN/Z to that service. That would undo a lot of the efforts that Philip AB has made on writing the auth microservice


05/10/2023, 1:09 PM
the gateway might just use the autN/Z service. philip draw outlines of what micorservices we might need. He looked at all of the server / controllers available in garg right now. The conclusion was that we need 1 microservice per server in gargantua iirc.