get multiple group by sum in javascript

 

let jsonData = {

"status": true,

"data": [

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Global",

"esg_audited": "non-audited",

"size": "large",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Global",

"esg_audited": "audited",

"size": "large",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Global",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 5

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Global",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 5

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Global",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Global",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 7

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "non-audited",

"size": "large",

"invoice_count": 7

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "non-audited",

"size": "sme",

"invoice_count": 23

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "large",

"invoice_count": 3

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 13

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 5

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 2

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 4

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 4

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 1

},

{

"year": 2021,

"quarter": 4,

"month": 12,

"mthkey": 202112,

"supplier": "root",

"demography": "Local",

"esg_audited": "audited",

"size": "sme",

"invoice_count": 2

}

]

}

----------------------------------

Function

----------------------------------

groupByMultis(data, keys,count_property_name) {

const counts = {};

data.forEach(item => {

let currentLevel = counts;

keys.forEach((key, index) => {

const value = item[key];

if (!currentLevel[value]) {

currentLevel[value] = { count: 0 };

}

currentLevel[value].count += item[count_property_name];

let val = parseFloat(parseFloat(currentLevel[value].count).toFixed(2));

currentLevel[value].count = val;

currentLevel = currentLevel[value];

});

});

return counts;

}

----------------------------------

Use

----------------------------------

let groupByMultisResult = this.groupByMultis(jsonData.data,

['esg_audited','demography','size'],'invoice_count');

----------------------------------

Result

----------------------------------

{

"non-audited": {

"count": 101,

"Global": {

"count": 36,

"large": {

"count": 2

},

"sme": {

"count": 34

}

},

"Local": {

"count": 65,

"large": {

"count": 14

},

"sme": {

"count": 51

}

}

},

"audited": {

"count": 147,

"Global": {

"count": 36,

"large": {

"count": 2

},

"sme": {

"count": 34

}

},

"Local": {

"count": 111,

"large": {

"count": 28

},

"sme": {

"count": 83

}

}

}

}

loopThroughObjRecurs (obj, count,propExec) {

for (var k in obj) {

if (typeof obj[k] === 'object' && obj[k] !== null) {

let currentCount = obj[k].count;

let percentage:any = (currentCount*100/count);

let val = parseFloat(parseFloat(percentage).toFixed(2));

obj[k]['percentage'] = val;

this.loopThroughObjRecurs(obj[k], obj[k].count,propExec)

} else if (obj.hasOwnProperty(k)) {

propExec(k, obj[k])

}

}

}

let rootCount = _.sumBy(jsonData.data,'invoice_count');

let withPercentage = loopThroughObjRecurs(groupByMultisResult,rootCount,

function(k, prop) {

//console.log(k + ': ' + prop);

});

Microservices patterns

 here is a list of some common microservices patterns

1. **API Gateway Pattern**:

   - **Description**: A single entry point for client requests that routes them to the appropriate microservices. It can handle tasks like authentication, load balancing, and caching.

2. **Service Discovery Pattern**:

   - **Description**: Microservices need to locate and communicate with each other dynamically. Service discovery patterns use tools like Consul, etcd, or DNS for automatic service registration and discovery.

3. **Circuit Breaker Pattern**:

   - **Description**: A fault-tolerant pattern that prevents a microservice from repeatedly trying to invoke a failing service. It "opens" the circuit when failures occur and "closes" it when the service becomes available.

4. **Retry Pattern**:

   - **Description**: In cases of transient failures, this pattern retries failed requests to a microservice. It helps ensure that occasional network glitches or temporary service unavailability doesn't lead to failures.

5. **Event Sourcing Pattern**:

   - **Description**: Instead of storing the current state of data, this pattern maintains a log of all changes (events) that have occurred. It can be useful for building event-driven architectures.

6. **Saga Pattern**:

   - **Description**: A way to manage distributed transactions across multiple microservices. Sagas break complex transactions into a series of smaller, individual steps with compensating actions in case of failure.

7. **Bulkhead Pattern**:

   - **Description**: Inspired by ship design, this pattern isolates failures in one microservice from affecting others. It involves using separate resources or processes for different parts of the application.

8. **Database per Service Pattern**:

   - **Description**: Each microservice has its own database. This pattern ensures loose coupling but may require mechanisms for data consistency and synchronization.

9. **Shared Database Pattern**:

   - **Description**: Some microservices share a single database. While it simplifies data access, it can lead to tight coupling and potential issues with data consistency.

10. **Backends for Frontends (BFF) Pattern**:

    - **Description**: Tailoring microservices for specific client applications. It helps optimize performance and reduces over-fetching of data for various client types.

11. **Asynchronous Messaging Pattern**:

    - **Description**: Communication between microservices through message queues (e.g., Kafka, RabbitMQ) for decoupling and scalability.

12. **Materialized View Pattern**:

    - **Description**: Creating precomputed views of data to improve query performance in read-heavy microservices.

13. **Choreography vs. Orchestration**:

    - **Description**: Deciding whether to use an event-driven choreography approach where microservices communicate directly or an orchestration approach with a central controller managing interactions.

14. **API Composition Pattern**:

    - **Description**: Aggregating data from multiple microservices to serve a client request in a single response, reducing the number of client-server interactions.

15. **Sidecar Pattern**:

    - **Description**: An auxiliary service that runs alongside a microservice to provide additional capabilities like logging, monitoring, or security.

16. **Gateway Aggregation Pattern**:

    - **Description**: Aggregating multiple microservices into a single, unified API gateway for clients, simplifying client interactions.

These patterns can be combined and tailored to meet the specific requirements of your microservices architecture. The choice of patterns will depend on factors like the nature of your application, scalability needs, and team expertise.

17. **External Configuration Pattern**:

    - **Description**: Managing configuration settings for microservices externally, allowing for dynamic updates without redeploying the services.

18. **Leader Election Pattern**:

    - **Description**: Used in scenarios where one microservice needs to be designated as the leader to perform certain tasks (e.g., in distributed systems).

19. **Fan-Out on Read Pattern**:

    - **Description**: When a microservice receives a read request, it fetches data from multiple other microservices in parallel to fulfill the request.

20. **Priority Queue Pattern**:

    - **Description**: Assigning priorities to tasks or messages in a microservices system to ensure high-priority tasks are processed before lower-priority ones.

21. **Stateless vs. Stateful Microservices**:

    - **Description**: Deciding whether microservices should be stateless (no local state) or stateful (maintaining some form of local state) based on application requirements.

22. **Bulkhead Isolation Pattern**:

    - **Description**: Isolating microservices into separate pools of resources (e.g., threads, processes, or containers) to prevent resource exhaustion from impacting other services.

23. **Shared Cache Pattern**:

    - **Description**: Storing commonly accessed data in a shared cache (e.g., Redis) to reduce redundant database calls and improve performance.

24. **API Versioning Pattern**:

    - **Description**: Managing changes to APIs by versioning them to ensure backward compatibility for existing clients while allowing for updates.

25. **Health Check Pattern**:

    - **Description**: Regularly checking the health and status of microservices to determine if they are available and responsive.

26. **Compensating Transaction Pattern**:

    - **Description**: Handling failures in distributed transactions by executing a compensating action to undo the effects of a failed transaction.

27. **Cross-Functional Teams Pattern**:

    - **Description**: Organizing development teams around microservices, where each team is responsible for one or more services, to promote ownership and accountability.

28. **Database Replication Pattern**:

    - **Description**: Replicating data across multiple databases or data centers to ensure data availability and fault tolerance.

29. **Service Mesh Pattern**:

    - **Description**: Implementing a service mesh (e.g., Istio, Linkerd) to manage communication, security, and observability between microservices.

30. **Concurrency Control Pattern**:

    - **Description**: Managing concurrent access to resources, such as databases or shared caches, to prevent conflicts and ensure data consistency.

Remember that not all of these patterns will be relevant to every microservices project. The choice of patterns should align with your specific architectural needs, scalability requirements, and the characteristics of your application. Understanding these patterns can help you design and implement microservices architectures more effectively.