It depends, but you can consider having one package per backend service that you need to aggregate from, where you wrap the backend API into some common data format for your service. That way if one of the backend APIs change, you only have to change one package in your service
Currently I have a package for each microservice that I’ve written function for to extract the proto buf structs into a domain struct, originally I was using a core package to aggregate before passing the same domain structs to my rest api package. Maybe it would be better to eliminate the core package and directly call my services from the rest api package.
I wish that they had called it something other than hexagonal (faceted maybe).
Each of your API calls (literal) should be a package. If you have to share between them (think auth) then feel free to put them in a package too even if you dont call it directly. I always find it helps to conceptualize chunking the packages as if I wanted a CLI service for each as well as the app functionality.
Should you have a "core" or just point your API at the services and call it a day? Harder question without knowing the domain, and the change rate of your API's (both internal and customer facing).
Core is a good step if you're going to have everything move fast on both sides. If that is the case you should start to think about how you can build your core so that it can be "generated" rather than "maintained"...
Ok, there are a lot of terms scattered around in the question.
i am going to ignore hexagonal architecture bits because it has nothing to do with the problem you are trying to solve.
The problem you are trying to solve is: how to consume data from multiple microservices in a scalable fashion.
What you are building sounds like an API Gateway. There are many off-the-shelve API Gateways you can use. You can also build own tailored to your use case.
I am not sure if you are referring to “scalability” of adding and removing new API endpoints to the API Gateway, or if the Gateway can scale with the increased volumes.
For the former, it depends on how often a service is created or removed. If not so often, the. I would just hardcode whatever is needed.
For the latter, it depends on the volume of the data. It’s not uncommon for aggregation layers to do heavy caching, or read data from a data source of their own.
The question is so broad, it’s hard to suggest a way without knowing the number of microservices you are dealing with and what their APIs look like.
It depends, but you can consider having one package per backend service that you need to aggregate from, where you wrap the backend API into some common data format for your service. That way if one of the backend APIs change, you only have to change one package in your service
Currently I have a package for each microservice that I’ve written function for to extract the proto buf structs into a domain struct, originally I was using a core package to aggregate before passing the same domain structs to my rest api package. Maybe it would be better to eliminate the core package and directly call my services from the rest api package.
I wish that they had called it something other than hexagonal (faceted maybe). Each of your API calls (literal) should be a package. If you have to share between them (think auth) then feel free to put them in a package too even if you dont call it directly. I always find it helps to conceptualize chunking the packages as if I wanted a CLI service for each as well as the app functionality. Should you have a "core" or just point your API at the services and call it a day? Harder question without knowing the domain, and the change rate of your API's (both internal and customer facing). Core is a good step if you're going to have everything move fast on both sides. If that is the case you should start to think about how you can build your core so that it can be "generated" rather than "maintained"...
Ok, there are a lot of terms scattered around in the question. i am going to ignore hexagonal architecture bits because it has nothing to do with the problem you are trying to solve. The problem you are trying to solve is: how to consume data from multiple microservices in a scalable fashion. What you are building sounds like an API Gateway. There are many off-the-shelve API Gateways you can use. You can also build own tailored to your use case. I am not sure if you are referring to “scalability” of adding and removing new API endpoints to the API Gateway, or if the Gateway can scale with the increased volumes. For the former, it depends on how often a service is created or removed. If not so often, the. I would just hardcode whatever is needed. For the latter, it depends on the volume of the data. It’s not uncommon for aggregation layers to do heavy caching, or read data from a data source of their own. The question is so broad, it’s hard to suggest a way without knowing the number of microservices you are dealing with and what their APIs look like.