DEV Community: Brian,Kun Liu

Hi, I'm Brian, a Senior SDE. This is my latest article from my workflow platform with langgraphjs

Brian,Kun Liu — Wed, 16 Apr 2025 12:36:41 +0000

Brian,Kun Liu

Apr 16 '25

Dynamic Pruning Strategy - Fixing Flow Defects in Merged Nodes of LangGraphJS Graphs

#ai #agentaichallenge #langgraphjs #langchain

Comments 1

6 min read

Dynamic Pruning Strategy - Fixing Flow Defects in Merged Nodes of LangGraphJS Graphs

Brian,Kun Liu — Wed, 16 Apr 2025 12:29:47 +0000

Author's LinekdIn

Key LangGraphJS Features

1. What is LangGraphJS?

LangGraphJS is designed for building controllable agents. While LangChain provides integrations and composable components for LLM applications, LangGraphJS focuses on agent orchestration, offering customizable architectures, long-term memory, and human-in-the-loop support. Its core job is to connect nodes in a workflow and manage execution between nodes and their functions.

2. How Edges Work: `addEdge()` and `addConditionalEdge()`

addEdge()
- If you use addEdge(sourceNode, targetNode), the target node runs after the source node.
- If you call addEdge(sourceNode1, targetNode) and addEdge(sourceNode2, targetNode) separately, the target node runs twice—once after each source node.
- If you use addEdge([sourceNode1, sourceNode2], targetNode), the target node runs once, but only after both source nodes finish.

Figure 1.1: Separate addEdge calls: TargetNode runs twice

Figure 1.2: Array-based addEdge: TargetNode runs once after both finish

addConditionalEdge()
- Like addEdge(), but the target node is triggered based on a condition.
- If you use both addEdge() and addConditionalEdge() to add the same target node, it may run multiple times.

3. Context During Execution

State:
- The state is the full context passed through the graph. Node functions receive and return this state.
Runnable:
- Provided by the engine, it contains metadata about the current execution, such as thread ID, step, node name, triggers, and execution path.

Example runnable metadata:

{
  "tags": [],
  "metadata": {
    "thread_id": "test-001",
    "langgraph_step": 4,
    "langgraph_node": "nodem",
    "langgraph_triggers": [
      "branch:node1:condition:nodem",
      "branch:node2:condition:nodem",
      "join:node1+node2:nodem",
      "node1",
      "node2"
    ],
    "langgraph_path": ["__pregel_pull", "nodem"],
    "langgraph_checkpoint_ns": "nodem:aa367e6e-800f-5af9-9a39-8c24d08103a2",
    "__pregel_resuming": false,
    "__pregel_task_id": "aa367e6e-800f-5af9-9a39-8c24d08103a2",
    "checkpoint_ns": "nodem:aa367e6e-800f-5af9-9a39-8c24d08103a2"
  },
  "recursionLimit": 25,
  "callbacks": [],
  "configurable": {}
}

From this, you can see that the current node is nodem, triggered by both node1 and node2 via addEdge() and addConditionalEdge(). The langgraph_triggers array shows exactly how the node was triggered.

branch:node1:condition:nodem means addConditionalEdges(node1, decideNextNode, [nodem, nodem-else1])
branch:node2:condition:nodem means addConditionalEdges(node2, decideNextNode, [nodem, nodem-else2])
join:node1+node2:nodem means addEdges([node1, node2], nodem)

Figure 1.3: Visualization of triggers in langgraph_triggers

In this case, nodem is triggered three times, but all triggers arrive at the same time.

Common Workflow Issues

1. Downstream Blocking at Encounter Nodes

When branches from the same conditional node converge, downstream nodes may block if not all branches are executed. For example:

graph.addConditionalEdges(conditionalNode, decideNextNode, [
  "node1-1",
  "nodem",
]);
graph.addEdge(["nodem", "node2-1", "node1-1-1"], "nodec");

Figure 2.1: Downstream blocking: nodec waits for all branches

If only one branch is triggered by conditionalNode, nodem may never execute, as it waits for both branches. To solve this, you can add addEdge([node-1, node2], nodem) and use the Dynamic Pruning Strategy to ensure only the relevant branch is processed.

2. Multiple Triggers for Encounter Nodes

If an encounter node is a direct successor of a conditional node, it may be triggered prematurely, before all necessary branches complete. To prevent this, introduce a virtualNode between the branch nodes and the encounter node, ensuring correct execution order.

Figure 2.2: Using a virtualNode to prevent premature triggering

The Dynamic Pruning Strategy

Solution Overview

Figure 3.1 The actual workflow built in LanggraphJS

In the Figure 3.1, it's the problem solved graph deprived from Figure 2-2. About the Edges, the original Edges between conditional node and successors are broken and placed with the dashed Edges.

The Dynamic Pruning Strategy dynamically determines whether a node should execute its function or simply pass through, based on the status of upstream nodes and branches.

Branch Tracking: Assign unique IDs to each branch and use prefix matching to identify related execution paths.
Node Status Calculation: Before executing a node, check the status of all relevant upstream nodes and branches.
Conditional Pruning: Skip nodes and branches that are no longer relevant due to conditional logic.

Execution Flow

Figure 3.2: Dynamic Pruning Strategy execution flow

When a node is triggered, gather the status and branch IDs of all dependent nodes.
If all relevant upstream nodes are executed, proceed; if some are skipped, collect skipped branch IDs and if others are executed, collect executed branch IDs.
Remove skipped branch IDs whose prefix is same with one of executed branch IDs, as they share the same ancestor conditional node.
If all skipped branch IDs are removed, the node can execute; otherwise, it is skipped.

Example Implementation

Main Steps

//steps of the Flow
async execute(
  state: WorkflowStateType,
  langgraphRunnableConfig: LanggraphRunnableConfig,
): Promise<WorkflowStateType> {
  try {
    /** langgraphRunnableConfig.metadata
     * Metadata for this call and any sub-calls (eg. a Chain calling an LLM).
     * Keys should be strings, values should be JSON-serializable.
     */
    this.runnable = langgraphRunnableConfig;
    const curNode = langgraphRunnableConfig?.metadata
      ?.langgraph_node as string;
    const triggers = (langgraphRunnableConfig?.metadata?.langgraph_triggers as string[]) || [];

    const [shouldExecuted, updatedState] = await this.shouldExecute(
      state,
      curNode,
      this.node.NodeType,
      triggers,
      langgraphRunnableConfig,
    );

    if (!shouldExecuted || this.node.NodeType === FlowNodeTypeEnum._FAKE) {
      return updatedState;
    }

    const input = await this.normalizeData(Object.freeze(updatedState));

    const runData = this.createRunData(input);
    const stateWithRunData = await this.beforeHandle(
      updatedState,
      runData,
      langgraphRunnableConfig,
    );

    const result = await this.handle(input, Object.freeze(stateWithRunData));

    const finalState = await this.afterHandle(
      stateWithRunData,
      result,
      runData,
      langgraphRunnableConfig,
    );

    return finalState;
  } catch (error) {
    await this.handleError(error);
    throw error;
  }
}

Dynamic pruning strategy

//core step of should Execute
protected async shouldExecute(
  state: WorkflowStateType,
  curNode: string,
  nodeType: string,
  triggers: string[],
  runnable: LanggraphRunnableConfig,
): Promise<[boolean, WorkflowStateType]> {
  // avoid the state be changed randomly
  const newState = { ...state };
  if (newState.statusNodes) {
    newState.statusNodes = { ...newState.statusNodes };
  }
  if (newState.branchNodesMap) {
    newState.branchNodesMap = { ...newState.branchNodesMap };
  }

  const statusNodes = newState.statusNodes || {};
  const branchNodeSet = runnable.configurable?.branchNodeSet;
  let curNodeStatus: NodeCalStatus = NodeCalStatus.WAITING;
  const curNodeBranches = new Set<string>();

  let skippedNodeBranch = new Set<string>(),
    executedNodeBranch = new Set<string>();
  let joinedStr: string = '';

  if (nodeType === FlowNodeTypeEnum.START) {
    curNodeStatus = NodeCalStatus.EXECUTED;
    newState.statusNodes = {
      ...newState.statusNodes,
      [curNode]: {
        status: curNodeStatus,
        branches: Array.from(curNodeBranches),
      },
    };
    return [true, newState];
  }

  // process the langgraph triggers
  for (const trigger of triggers) {
    if (trigger.startsWith('branch')) {
      // matched the triggers:["branch:node1:condition:nodec"]
      const branchArray = trigger.split(':');
      const branchId = branchArray[1],
        conditionNode = branchArray[3];

      //save the context with the matched next node of conditionNode
      if (branchId || conditionNode) {
        newState.branchNodesMap = {
          ...newState.branchNodesMap,
          [branchId as string]: conditionNode,
        };
      }
    }
    if (trigger.startsWith('join')) {
      joinedStr = trigger;
    }
  }

  const branchNodesMap = newState.branchNodesMap;

  //the encounter node status calculation
  if (joinedStr) {
    curNodeStatus = NodeCalStatus.EXECUTED;
    const dependentNodes = joinedStr.split(':')?.[1]?.split('+') || [];

    for (const dependentNode of dependentNodes) {
      const dependentBranches: string[] =
        statusNodes[dependentNode]?.branches || [];
      const dependentNodeStatus: number =
        statusNodes[dependentNode]?.status || 0;

      if (dependentNodeStatus === NodeCalStatus.WAITING) {
        curNodeStatus = NodeCalStatus.WAITING;
        break;
      }

      const branchIdsFromParentNode = await this.getBranchIdsFromParentNode(
        branchNodeSet,
        dependentNode,
        dependentBranches,
      );
      const statusFromParent = await this.getNextStatusFromParent({
        parentNode: dependentNode,
        parentNodeStatus: dependentNodeStatus,
        branchNodeSet,
        curNode,
        branchNodesMap,
      });
      branchIdsFromParentNode.forEach((branchId) => {
        curNodeBranches.add(branchId);
        if (statusFromParent > 0) {
          executedNodeBranch.add(branchId);
        } else {
          skippedNodeBranch.add(branchId);
        }
      });
    }
  }

  // remove the branchIds with the prefix matched rule
  skippedNodeBranch = await this.removeSkippedNodeBranchIds(
    skippedNodeBranch,
    executedNodeBranch,
  );

  if (curNodeStatus > 0) {
    curNodeStatus = skippedNodeBranch.size
      ? NodeCalStatus.SKIPPED
      : NodeCalStatus.EXECUTED;
  }

  newState.statusNodes = {
    ...newState.statusNodes,
    [curNode]: {
      status: curNodeStatus,
      branches: Array.from(curNodeBranches),
    },
  };

  return [curNodeStatus === NodeCalStatus.EXECUTED, newState];
}

private async getBranchIdsFromParentNode(
  branchNodeSet: Set<string> | undefined,
  parentNode: string,
  parentBranchIds: string[],
): Promise<Set<string>> {
  const branchIdsFromParentNode = new Set<string>();
  if (branchNodeSet?.has(parentNode)) {
    if (!parentBranchIds.length) parentBranchIds.push(`branch`);
    parentBranchIds.forEach((v) =>
      branchIdsFromParentNode.add([v, parentNode].join(':')),
    );
  } else {
    parentBranchIds.forEach((v) => branchIdsFromParentNode.add(v));
  }
  return branchIdsFromParentNode;
}

private async getNextStatusFromParent(props: {
  parentNode: string;
  parentNodeStatus: NodeCalStatus;
  branchNodeSet: Set<string> | undefined;
  curNode: string;
  branchNodesMap?: Record<string, any>;
}): Promise<NodeCalStatus> {
  const {
    parentNode,
    parentNodeStatus,
    branchNodeSet,
    curNode,
    branchNodesMap,
  } = props;

  let curNodeStatus = parentNodeStatus;

  if (parentNodeStatus < 0) {
    curNodeStatus = NodeCalStatus.SKIPPED;
  } else {
    if (branchNodeSet?.has(parentNode)) {
      if (branchNodesMap?.[parentNode] != curNode) {
        curNodeStatus = NodeCalStatus.SKIPPED;
      } else {
        curNodeStatus = NodeCalStatus.EXECUTED;
      }
    } else {
      curNodeStatus = NodeCalStatus.EXECUTED;
    }
  }

  return curNodeStatus;
}

/**
 * 使用前缀算法从执行分支ID集合中移除跳过分支ID
 * @param skippedNodeBranchIds 跳过的分支ID集合
 * @param executedNodeBranchIds 执行的分支ID集合
 * @returns 更新后的跳过分支ID集合
 */
private async removeSkippedNodeBranchIds(
  skippedNodeBranchIds: Set<string>,
  executedNodeBranchIds: Set<string>,
): Promise<Set<string>> {
  if (skippedNodeBranchIds.size > 0) {
    const executedPrefixes = Array.from(executedNodeBranchIds);
    Array.from(skippedNodeBranchIds)
      .filter((branchId) =>
        executedPrefixes.some((prefix) => branchId.startsWith(prefix)),
      )
      .forEach((item) => skippedNodeBranchIds.delete(item));
  }
  return skippedNodeBranchIds;
}

Conclusion

The Dynamic Pruning Strategy provides a practical solution to two common execution flow problems in LangGraphJS:

Node blocking issues in workflows with converging branches
Premature triggering of nodes in conditional workflows

By intelligently calculating node execution status and using prefix matching to track branch relationships, this strategy enables complex agent workflows to run reliably without deadlocks.

While this approach requires adding some boilerplate code to your projects, it solves problems that don't yet have official solutions in LangGraphJS. The technique can be implemented as a wrapper around your existing node functions with minimal changes to your workflow design.

References

LangGraphJS: https://langchain-ai.github.io/langgraphjs/
GitHub Issues
- https://github.com/langchain-ai/langgraphjs/issues/765
- https://github.com/langchain-ai/langgraphjs/issues/1005

Best Practices for Building Multi-Architecture Images with a Unified Tag in Enterprise…

Brian,Kun Liu — Sat, 23 Nov 2024 16:16:13 +0000

Best Practices for Building Multi-Architecture Images with a Unified Tag in Enterprise Infrastructure

Background

With the growing adoption of ARM-based CPUs in enterprise environments, it’s increasingly important to build software images that support both traditional AMD64 (x86_64) and ARM architectures. To streamline the CI/CD process and minimize pipeline modifications, the goal is to build multi-architecture images that can be deployed under a single tag.

This article outlines how to set up the necessary tools and two approaches for achieving this: using an emulator for cross-platform builds or creating architecture-specific images and combining them with a manifest.

Prerequisites

Before getting started, ensure the following are installed and functional on your machine:

Docker : The primary tool for building and managing container images.
Docker Buildx : A plugin that enables advanced build capabilities like cross-platform builds and caching optimization.

Install Buildx on Linux :

mkdir -p ~/.docker/cli-plugins
# Download the appropriate buildx version for your architecture
curl -sLo ~/.docker/cli-plugins/docker-buildx ${download_link}

Create a Buildx Builder :

docker buildx create --name buildx --use

(Optional) Kaniko : An alternative image-building tool for environments where Docker isn’t suitable.

Approach 1: Cross-Platform Builds Using Emulation

(Not recommended for production environments)

Steps:

Install QEMU Emulator : Install the emulator library to support architectures different from your host machine.

docker run --privileged --rm tonistiigi/binfmt --install all

2. Build Multi-Platform Images : Use the buildx command with platform-specific parameters.

docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 \
-t your_image_name:tag --push .

Limitations :

• Performance is often subpar, especially on Linux machines.

• On AMD64 hosts, builds can be up to 100x slower, and binary compatibility issues may arise on ARM machines.

• This method is better suited for local development rather than production.

Approach 2: Architecture-Specific Builds with a Unified Tag

(Recommended for production environments)

Process Overview:

This approach involves building architecture-specific images and combining them into a single multi-architecture image using Docker’s manifest functionality.

Build Architecture-Specific Images :

Build and tag images for each architecture.

docker buildx build -t your_image_name:tag-${{arch}} --push .

Create a Manifest, a special image tag :

Combine the architecture-specific images into a single tag.

docker manifest create your_image_name:tag \
your_image_name:tag-amd64 \
your_image_name:tag-arm64

Annotate the Manifest :

Add metadata for each architecture.

docker manifest annotate your_image_name:tag your_image_name:tag-amd64 --os linux --arch amd64
docker manifest annotate your_image_name:tag your_image_name:tag-arm64 --os linux --arch arm64

Push the Manifest to the Repository :

Sync the unified image to your repository.

docker manifest push your_image_name:tag

Conclusion

While QEMU-based emulation offers a way to build multi-platform images, its inefficiency and compatibility issues make it unsuitable for production. The recommended approach is to build images directly on their respective architectures and combine them using the manifest functionality. This ensures reliability, performance, and consistency across deployment environments. Now, it runs successfully in our production environment.

whole-build-images-pipeline

Resolving Yarn Version Issues in Multi-Node Setups

Brian,Kun Liu — Wed, 16 Oct 2024 13:09:10 +0000

For MacOS users, Homebrew is a convenient package manager for installing libraries and developer tools. However, when installing Yarn through Homebrew, you may encounter an issue where the Yarn version cannot be changed globally. This problem arises when older projects run on a stable version (e.g., 1.xx) and newer projects use different Node.js versions (e.g., v16, v10).

The root cause of this issue is that Yarn depends on the Node.js package. To resolve this, you need to install Yarn using npm install -g yarn instead of installing it directly with Homebrew. Additionally, you should use the system Node.js installation to avoid conflicts with any necessary global checks.

Here are the steps to resolve the issue:

Install the system Node.js version using Homebrew:

brew install node

Install the default Yarn version when using the system Node.js:

note: we need to have a yarn version globally to avoid some unexpected errors like husky

npm install -g yarn@berry #you can change `berry` to any version

Install Node Version Manager (nvm) to manage different Node.js versions:

brew install nvm

Install the desired Node.js versions using nvm:

nvm install v16 #you can change v16 to any version of node

Use a specific Node.js version and install the corresponding Yarn version:

nvm use v16 && npm install -g yarn@berry # you can change v16 to any node version

By following these steps, you can ensure that each project uses the appropriate Yarn version based on the Node.js version installed through nvm. This approach allows you to work seamlessly with different Node.js and Yarn versions across multiple projects.

“Please Be Cautious to Use Global Parameter” — A Warning for Developers

Brian,Kun Liu — Sat, 22 Apr 2023 04:19:58 +0000

“Please Be Cautious to Use Global Parameter” — A Warning for Developers

Developers sometimes use global parameters as a way to define and store a variable or constant value, which can then be used throughout the codebase. While this is a good way to make our codes efficient via saving hardware resources, developers should be aware of potential drawbacks to using global parameters and avoid using them in their projects as much as possible we can.

here are two cases partially caused by the inappropriate use of global parameters and appropriate solutions.

One scenario is that a global parameter in the file keeps the value temporarily to reduce Mongodb database connection checking in an AWS Lambda project. But when the AWS Lambda project shutdown and restart, it will copy the project in the previous container. So the global parameter won’t be changed once it’s given value.

One is that the developer is trying to define all the constants in the same file. The using function uses it with importing the unified constant defined file. However, ObjA is an object, when we pass the value of the ObjA property, the ObjA property in the cache will be changed. The next time, our function is running, the project is using the changed ObjA, not the original objA.

Case 1: a global parameter in the whole file of an AWS Lambda Project led to the wrong status of the MongoDB connection.

What happened and how did I analyze the process?

Our sms-blast function is reported by QA that didn’t work at all. By checking CloudWatch logs of the AWS Lambda, I find that there are so many connection timeout logs showing. So my first institution is the network between our AWS to MongoDB database isn’t working. And the unmatched VPC security policy with another health project also misled me that it’s the root cause. By restraining the project, it seems to be well

However, a week later, the QA relaunch the problem. I don’t know what happened, so I read the document about AWS Lambda and codes.

Our code is like this:

//index.js
const { connect } = require('./helpers/dbConnect');
const modelA = require('./helpers/modelA');
exports.handler = async (event, context) => {
    context.callbackWaitsForEmptyEventLoop = false;
    //executive connection
    await connect();
    for (const record of event.Records) {
        const { body } = record;
        const parsedBody = JSON.parse(body);
        const message = JSON.parse(parsedBody.Message);
        console.log(message);
        if (!message) {
            console.log('wrong message');
            return;
        }
        const data = message.data;
        //executive command:connection timeout error
        modelA.update;
    }
    return {
        statusCode: 200,
        body: JSON.stringify('Message sent'),
    };
};

//dbConnect.js
//the global parameter, error happened
let isConnected = 0;
module.exports = {
    connect: async function () {
        if (isConnected) {
            console.log('already connectd…');
            return;
        }
        var options = {
            keepAlive: 1,
            connectTimeoutMS: 30000,
            useNewUrlParser: true,
            readPreference: 'secondaryPreferred',
            maxStalenessSeconds: 90,
            poolSize: 100,
            socketTimeoutMS: 2000000,
            useUnifiedTopology: true,
        };
        mongoose.plugin(function (schema) {
            schema.options.safe = {
                j: 1, // the write must commit to the journal
                wtimeout: 10000, // timeout after 10 seconds
            };
        });
        mongoose.Promise = Promise;
        try {
            console.log('connecting to mongodb…');
            const db = await mongoose.connect(process.env.MONGO_DB_URL, options);
            isConnected = db.connections[0].readyState;
        } catch (error) {
            throw error;
        }
    },
};

So after observing the codes, the reference path is index -> connection->index-> execution. Does the error happen how to determine if it is connected? I find the previous developer used isConnected to store the value of the connection status.

But that ignores the connection of MongoDB has the expired time. The value in isConnected don’t have an expired time. it leads to the connection timeout when the command is executed.

Based on this, I’m not 100% confirming that’s the root cause. Because if every request is using the original codes, all things in theory should be successful until I got the rules of running AWS Lambda rules — t he Cold Start only happened in the first loading in a container. Only if the container is killed for no activities in a long time, the Cold Start will happen. Otherwise, the codes, especially the parameter are kept in the cache, also why it happens sometimes but not always.

Solutions:

Grounded on the analysis, we just need to have serval line codes changed to fix the problem below. Using the original property as the determination of the connection status.

//dbConnect.js
module.exports = {
    connect: async function () {
        //replace the global parameter with property
        const isConnected = mongoose.connection && mongoose.connection.readyState === 1;
        if (isConnected) {
            console.log('already connectd…');
        }
        return;
        var options = {
            keepAlive: 1,
            connectTimeoutMS: 30000,
            useNewUrlParser: true,
            readPreference: 'secondaryPreferred',
            maxStalenessSeconds: 90,
            poolSize: 100,
            socketTimeoutMS: 2000000,
            useUnifiedTopology: true,
        };
        mongoose.plugin(function (schema) {
            schema.options.safe = {
                j: 1, // the write must commit to the journal
                wtimeout: 10000, // timeout after 10 seconds
            };
        });
        mongoose.Promise = Promise;
        console.log('connecting to mongodb…');
        return mongoose.connect(process.env.MONGO_DB_URL, options);
    },
};

After that, we observe the performance for 1 week, and all things are good.

The incorrect status and connection timeout errors resulted from the incorrect use of a global parameter to store the MongoDB connection status. The root cause was the MongoDB connection’s expiration time, which was not taken into account when using the global parameter. The solution was to change the parameter so that the original property determined the connection status.

Case 2: the shallow copy of the cached ObjA leads to the wrong data.

What happened and how did I analyze the process?

The data in my report feature is not accurate to the report by our QA. After the project runs locally we find the wrong code below.

//wrong code
…
const {optionalAdvancedFields} = require(`./${name}/constants`);
…
advancedFieldsMap[measure] = optionalAdvancedFields[measure];
//change advancedFieldsMap value
…

The root cause shows that the initial value importing from the external file was changed, but my design's purpose requires it won't be changed. Cuz the swallow copy easily happens in Object, so I think the key to this is the swallow copy during passing the value.

The deep thinking about why it happened, it’s similar to case 1. The requirement will load the cached file first and then load the file without the cache.

Solutions:

Based on the analysis, we have two ways to solve the problem.

load the file every time, not the cache. But the rule of loading the stored first is to improve the efficiency of our running machine. so it will make our projects slower

//use delete require’s cache to forcefully load the constants from the original file, not recommended for low efficiency
...
const {optionalAdvancedFields} = require(`./${name}/constants`);

//fixed codes
delete require.cache[require.resolve(./${name}/constants)]

...
advancedFieldsMap[measure] = optionalAdvancedFields[measure];

//change advancedFieldsMap value
...

2. to avoid the swallow cache in concrete implementation. This way only affects the parameter without efficiency impact.

2.1 use JSON.parse() and JSON.stingy()

//1. use JSON.parse() and JSON.stingy()
...
const {optionalAdvancedFields} = require(`./${name}/constants`);
...
advancedFieldsMap[measure] =JSON.parse(JSON.stringy(optionalAdvancedFields[measure]));
...

2.2 use the function lodash npm package

import _ from 'lodash';
...
const {optionalAdvancedFields} = require(`./${name}/constants`);
...
advancedFieldsMap[measure] = _.cloneDeep(optionalAdvancedFields[measure]);
//change advancedFieldsMap value
...

2.3 create a factory function to resolve it

import _ from 'lodash';
...
const {optionalAdvancedFields} = require(`./${name}/constants`);
...
// factory.ts
export function getObjectTemplateData(param) {
  return {...param}
}

import { getObjectTemplateData } from './factory.ts'
advancedFieldsMap= getObjectTemplateData(optionalAdvancedFields);
//change advancedFieldsMap value

A shallow copy of the cached object led to erroneous data in a report feature. The root cause was the requirement to load the cached file first, followed by loading the file without the cache. The solutions to this problem are to either load the file each time (which may impair efficiency) or to change the shallow copy to a deep copy using JSON.parse() and JSON.stringify() or the deep copy function in “lodash” npm package.

Conclusion：

In conclusion, the two cases presented here demonstrate the potential drawbacks of using global parameters in software development.

These cases highlight the importance of being aware of potential drawbacks when using global parameters and avoiding them in software development as much as possible. By doing so, developers can ensure the efficiency and accuracy of their code.

Reference:

https://aws.amazon.com/cn/blogs/compute/operating-lambda-performance-optimization-part-1/

Mastering Dual-Currency Tax Rules in Chargebee: A Comprehensive Guide

Brian,Kun Liu — Fri, 24 Mar 2023 10:19:26 +0000

Chargee is a platform for our toB system to manage transactions with merchants (users of our toB platform). The transactions between the merchant and us are the credit charge and subscription billing cycles. The article is based on the credit charging revamp, but it can also be applied to other similar functions when using it. In the previous design, we didn’t include tax when we were setting the price for the product. Our first thought is to rely on the Chargebee setting. However, the Chargebee cannot support a kind of international currency, like the USD, with inclusive tax settings in many countries. Our charging system for merchants needs to support local currency and USD in Thailand and the Philippines.

Apart from this, our special point is that the financial team and product team don’t want to change our current setting. so that our credit charging feature does not interfere with other features like billing subscription cycling.

The goal:

Take the tax amount via the tax rate set by the country:

Malaysia: 6%; Thailand: 7%; the Philippines: 12%; other countries: 0%.

Tax rule in ChargeBee:

The tax rate is defined in ChargeBee by country, like the Philippines. https://storehub-test.chargebee.com/taxes

In practice, the type of price (Tax Exclusive or Tax Inclusive) doesn’t determine whether the tax is included.

Of course, we can use a pre-calculation, but the reception won’t show the tax amount in the Chargebee. It’s currently being applied in Thailand.

The type of tax is determined by the currency tax setting:

https://storehub-test.chargebee.com/taxes/currency_price_type

And Tax Exclusive means that Chargebee will take tax automatically in the Chargebee. We just need to provide the amount with

In conclusion, the country decides the tax rate, but the type of currency price determines the tax-taking action.

We planned not to take tax on USD currency during the design and implementation processes. Following this rule, tax-inclusive seems like a good choice. In reality, the tax-inclusive option can only support one country at a time while using a non-referenced tax rate in another. For example, the Philippines is considered a tax-inclusive country without tax in USD. However, the tax amount in USD will be taken by Chargebee automatically in Thailand. So tax-exclusive is the only option to keep the same in different countries.

Design flow:

Reference:

Chargebee API document: https://apidocs.chargebee.com/docs/api/v1?prod_cat_ver=1

How to Optimize Schema Syncing with Metabase: A Guide to Using Nested Subdocuments and Avoiding…

Brian,Kun Liu — Wed, 22 Mar 2023 10:34:21 +0000

How to Optimize Schema Syncing with Metabase: A Guide to Using Nested Subdocuments and Avoiding Mixed/Object/{} Types

Background

Mixed, Object, or {} Type is a special type in MongoDB that allows developers to store heterogeneous data types in a single field.

This can be useful for storing data that does not fit neatly into a specific schema, but it can also create problems that the field is stored as a whole string in the form when syncing data to Metabase. That can not be analyzed well by our BI worker and data engineer. Because we need to follow a defined structure when it shows up clearly in Metabase.

Solution:

To avoid issues with syncing data to Metabase, we recommend the following best practices for MongoDB schema design:

Use a consistent schema: It is best to define a consistent schema for your data model that closely matches the structure of your data. This makes it easier to extract and transform the data into a consistent Metabase schema.
Avoid Using Mixed/Object Type: Avoid using Mixed/Object Type in your schema design as much as possible. Instead, define fields based on data types such as String, Number, Boolean, Date, and so on.
Consider using nested subdocuments instead of Mixed/Object Type if you need to store complex data structures. This allows you to keep a consistent schema and makes extracting and transforming data for Metabase easier.
Use Mongoose.js validation : Mongoose.js provides built-in validation for schema fields, which can help ensure that your data is consistent and matches the expected schema.

References:

Mongoose.js Mixed Schema Defination: https://mongoosejs.com/docs/schematypes.html#mixed

DEV Community: Brian,Kun Liu

Hi, I'm Brian, a Senior SDE. This is my latest article from my workflow platform with langgraphjs

Dynamic Pruning Strategy - Fixing Flow Defects in Merged Nodes of LangGraphJS Graphs

Dynamic Pruning Strategy - Fixing Flow Defects in Merged Nodes of LangGraphJS Graphs

Key LangGraphJS Features

1. What is LangGraphJS?

2. How Edges Work: addEdge() and addConditionalEdge()

3. Context During Execution

Common Workflow Issues

1. Downstream Blocking at Encounter Nodes

2. Multiple Triggers for Encounter Nodes

The Dynamic Pruning Strategy

Solution Overview

Execution Flow

Example Implementation

Main Steps

Dynamic pruning strategy

Conclusion

References

Best Practices for Building Multi-Architecture Images with a Unified Tag in Enterprise…

Best Practices for Building Multi-Architecture Images with a Unified Tag in Enterprise Infrastructure

Resolving Yarn Version Issues in Multi-Node Setups

“Please Be Cautious to Use Global Parameter” — A Warning for Developers

“Please Be Cautious to Use Global Parameter” — A Warning for Developers

Case 1: a global parameter in the whole file of an AWS Lambda Project led to the wrong status of the MongoDB connection.

Case 2: the shallow copy of the cached ObjA leads to the wrong data.

Mastering Dual-Currency Tax Rules in Chargebee: A Comprehensive Guide

The goal:

Tax rule in ChargeBee:

How to Optimize Schema Syncing with Metabase: A Guide to Using Nested Subdocuments and Avoiding…

How to Optimize Schema Syncing with Metabase: A Guide to Using Nested Subdocuments and Avoiding Mixed/Object/{} Types

2. How Edges Work: `addEdge()` and `addConditionalEdge()`