🚨 LangGraph.js V1 planning - looking for feedback! #276

Closed
opened 2026-02-15 18:15:24 -05:00 by yindo · 9 comments
Owner

Originally created by @hntrl on GitHub (Jun 6, 2025).

We're actively working towards a release of LangGraph v1 (for both python and js), and we're looking for input from everyone using it!

If you are looking for a way to shape the core of LangGraph, or have noticed any shortcomings/nits when it comes to working with LangGraph.js, then now is high time for you to get your voice heard. In particular we want to hear from you regarding:

  • What parts of LangGraph are confusing or unclear?
  • What feels unnecessarily complex or boilerplate-heavy?
  • What's missing / what features should be top priority?

This is an effort where we're reaching across the entire LangGraph ecosystem to collect feedback. Although we have LangGraph implementations for both python and javascript, we're striving to keep the high-level details conceptually transferable between them. That means your feedback will be used in a few ways ways:

(1) To shape high level details pertinent to LangGraph python and javascript.
(2) To prioritize improvements to public APIs/documentation.
(3) To plan the specific upgrades that we need for JavaScript.

(Obligatory note: backwards compatibility is something we're keeping top of mind, and we don't plan on making any major breaking changes that makes the path from v0 to v1 difficult.)

https://github.com/langchain-ai/langgraph/issues/4973

Thanks!

Originally created by @hntrl on GitHub (Jun 6, 2025). We're actively working towards a release of LangGraph v1 (for both python and js), and we're looking for input from everyone using it! If you are looking for a way to shape the core of LangGraph, or have noticed any shortcomings/nits when it comes to working with LangGraph.js, then now is high time for you to get your voice heard. In particular we want to hear from you regarding: * What parts of LangGraph are confusing or unclear? * What feels unnecessarily complex or boilerplate-heavy? * What's missing / what features should be top priority? This is an effort where we're reaching across the entire LangGraph ecosystem to collect feedback. Although we have LangGraph implementations for both python and javascript, we're striving to keep the high-level details conceptually transferable between them. That means your feedback will be used in a few ways ways: (1) To shape high level details pertinent to LangGraph python **and** javascript. (2) To prioritize improvements to public APIs/documentation. (3) To plan the specific upgrades that we need for JavaScript. _(Obligatory note: backwards compatibility is something we're keeping top of mind, and we don't plan on making any major breaking changes that makes the path from v0 to v1 difficult.)_ https://github.com/langchain-ai/langgraph/issues/4973 Thanks!
yindo closed this issue 2026-02-15 18:15:24 -05:00
Author
Owner

@denghongcai commented on GitHub (Jun 17, 2025):

Confused about how to implement client tool, like work with ai-sdk https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling#tool-calling. Currently all tool in langgraph.js must provide execute func run run in server side and can't forward tool call to client.

@denghongcai commented on GitHub (Jun 17, 2025): Confused about how to implement client tool, like work with ai-sdk https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling#tool-calling. Currently all tool in langgraph.js must provide execute func run run in server side and can't forward tool call to client.
Author
Owner

@mauriciocirelli commented on GitHub (Jun 24, 2025):

I have seen a couple issues #245 and #755 related to how the graphs handle structured output and artifacts generated by the tools. I am myself struggling a bit trying to create a custom ToolNode that can handle it properly.

I think that these problems have a huge importance nowadays, since tools are querying lots of data from database, generating lots of text, audio, video, etc... which is not feasible to just input into the message's content and workaround it on the ToolNode. Or worse, expecting that the LLM would be able to parse it properly to push it into the next stages of the flow.

Handling artifacts on the ToolNode class is something I think the framework should really care about for the first major release.

Please, let me know if I am missing something.

Thank you!

@mauriciocirelli commented on GitHub (Jun 24, 2025): I have seen a couple issues [#245](https://github.com/langchain-ai/langgraphjs/issues/245) and [#755](https://github.com/langchain-ai/langgraphjs/issues/755) related to how the graphs handle structured output and artifacts generated by the tools. I am myself struggling a bit trying to create a custom ToolNode that can handle it properly. I think that these problems have a huge importance nowadays, since tools are querying lots of data from database, generating lots of text, audio, video, etc... which is not feasible to just input into the message's content and workaround it on the ToolNode. Or worse, expecting that the LLM would be able to parse it properly to push it into the next stages of the flow. Handling artifacts on the ToolNode class is something I think the framework should really care about for the first major release. Please, let me know if I am missing something. Thank you!
Author
Owner

@baninaveen commented on GitHub (Jul 2, 2025):

Hey @hntrl There are lot of outdated docs for Javascript. How do I contribute to update docs and examples

@baninaveen commented on GitHub (Jul 2, 2025): Hey @hntrl There are lot of outdated docs for Javascript. How do I contribute to update docs and examples
Author
Owner

@simozampa commented on GitHub (Jul 16, 2025):

hi @hntrl i found particularly confusing working with human-in-the-loop:

  • examples only show running the agent locally
  • docs don't explain how to enable interrupt events when streaming (need to set streamMode to "updates")
@simozampa commented on GitHub (Jul 16, 2025): hi @hntrl i found particularly confusing working with human-in-the-loop: - examples only show running the agent locally - docs don't explain how to enable interrupt events when streaming (need to set `streamMode` to `"updates"`)
Author
Owner

@andruhon commented on GitHub (Jul 21, 2025):

@andruhon commented on GitHub (Jul 21, 2025): - Provider's built in are somewhat confusing. Meant to be easy to use, but need some conjurations to avoid errors. See errors with Claude web_search. According to LangChain release this should be easy as https://github.com/langchain-ai/langchainjs/releases/tag/langchain%3D%3D0.3.29 , but with createReactAgent always causing INVALID_TOOL_RESULTS.
Author
Owner

@amitav13 commented on GitHub (Jul 25, 2025):

Documentation for deployment instructions within a monorepo (I use turborepo) is lacking. Best practices around whether this should be an app or package, how to set up langgraph.json deps if I have other packages that I rely on (like a database package with my prisma), are missing. Still trying to figure out how to make this work!

@amitav13 commented on GitHub (Jul 25, 2025): Documentation for deployment instructions within a monorepo (I use turborepo) is lacking. Best practices around whether this should be an app or package, how to set up langgraph.json deps if I have other packages that I rely on (like a database package with my prisma), are missing. Still trying to figure out how to make this work!
Author
Owner

@ibbybuilds commented on GitHub (Jul 28, 2025):

Problem

Every ThreadState returned by /threads/{id}/history contains the entire message array. For long conversations (>100 messages) each state is 100-200 KB, making history N × that size and harming mobile & weak-network users.

Proposal

  1. Split messages into a dedicated messages table (immutable).
  2. Store only message_ids (or page hashes) in checkpoint rows.
  3. Add added / removed delta storage to further reduce size.
  4. Provide new API flags:
    ?messages=full (current behaviour, default for legacy SDK)
    ?messages=ids (only IDs, client will hydrate)
    ?messages=none (no messages, checkpoint metadata only)
  5. Materialise every N checkpoints to cap worst-case reconstruction work.

Benefits

  • Reduces bandwidth & DB storage by O(history_length).
  • Branching/forking becomes constant-time (no full copy needed).
  • Paves way for infinite-scroll & virtualised chat UI.

Work Needed

  • DB migration: messages table, back-fill IDs.
  • API changes: new query params, serializers.
  • SDK changes: hydrate messages client-side, or automatic fallback.
  • Front-end: virtualised list, paged hydration.
  • Docs & examples.
@ibbybuilds commented on GitHub (Jul 28, 2025): ### Problem Every ThreadState returned by `/threads/{id}/history` contains the entire message array. For long conversations (>100 messages) each state is 100-200 KB, making history N × that size and harming mobile & weak-network users. ### Proposal 1. Split messages into a dedicated `messages` table (immutable). 2. Store only `message_ids` (or page hashes) in checkpoint rows. 3. Add `added` / `removed` delta storage to further reduce size. 4. Provide new API flags: ?messages=full (current behaviour, default for legacy SDK) ?messages=ids (only IDs, client will hydrate) ?messages=none (no messages, checkpoint metadata only) 5. Materialise every N checkpoints to cap worst-case reconstruction work. ### Benefits - Reduces bandwidth & DB storage by O(history_length). - Branching/forking becomes constant-time (no full copy needed). - Paves way for infinite-scroll & virtualised chat UI. ### Work Needed - [ ] DB migration: `messages` table, back-fill IDs. - [ ] API changes: new query params, serializers. - [ ] SDK changes: hydrate messages client-side, or automatic fallback. - [ ] Front-end: virtualised list, paged hydration. - [ ] Docs & examples.
Author
Owner

@ddewaele commented on GitHub (Jul 29, 2025):

Just a comment on the overall production-readiness of the entire platform / eco-system when moving to a v1.x

I do have the impression that stuff breaks very easily in the current 0.3.x version due the minor version bumps (that get pulled in automatically if you start new projects now).

For example here are some things that "suddenly" broke due to minor version bumps of other transitive dependencies

It would be nice to have clear changelogs for the different parts of langgraphs / langchainjs so that it is easier to pinpoint certain issues. (The fact that these are mono-repos with lots of other components that have their own versioning scheme also makes it difficult to follow sometimes.)

What we often do now is bump into these issues, revert back to older versions if possible and log tickets for them.
But we lack some visibility as to why certain versions / components got bumped when we look at the releases in langchainjs and langgraphjs.

We also notice that not every component has a changelog.
LangGraphJS does a pretty good jobs with changelogs, although more descriptive changelogs would be better, with links to the actual commits.
Langchainjs doesn't have individual changelogs for the components. As LangGraph relies a lot on LangChain components (and transitive dependencies) I think managing that better is key.

But great framework and platform, great community and eco-system, and exciting to build AI applications with it !

@ddewaele commented on GitHub (Jul 29, 2025): Just a comment on the overall production-readiness of the entire platform / eco-system when moving to a v1.x I do have the impression that stuff breaks very easily in the current 0.3.x version due the minor version bumps (that get pulled in automatically if you start new projects now). For example here are some things that "suddenly" broke due to minor version bumps of other transitive dependencies - https://github.com/langchain-ai/langgraphjs/issues/1460 - https://github.com/langchain-ai/langgraphjs/issues/1453 It would be nice to have clear changelogs for the different parts of langgraphs / langchainjs so that it is easier to pinpoint certain issues. (The fact that these are mono-repos with lots of other components that have their own versioning scheme also makes it difficult to follow sometimes.) What we often do now is bump into these issues, revert back to older versions if possible and log tickets for them. But we lack some visibility as to why certain versions / components got bumped when we look at the releases in langchainjs and langgraphjs. We also notice that not every component has a changelog. LangGraphJS does a pretty good jobs with changelogs, although more descriptive changelogs would be better, with links to the actual commits. Langchainjs doesn't have individual changelogs for the components. As LangGraph relies a lot on LangChain components (and transitive dependencies) I think managing that better is key. But great framework and platform, great community and eco-system, and exciting to build AI applications with it !
Author
Owner

@dqbd commented on GitHub (Sep 8, 2025):

We've released our first alpha version of langgraph 1.0.0! Moving the discussion to #1602

@dqbd commented on GitHub (Sep 8, 2025): We've released our first alpha version of `langgraph` 1.0.0! Moving the discussion to #1602
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langgraphjs#276