Is langgraphjs production ready?

[logan272]

I'm considering whether to introduce a agent framework to my product and have a few questions:

1. Is LangGraph JS production-ready?
2. My team is more productive in TypeScript, so we want to use LangGraph JS when possible. This would allow us to use the same language for both the UI and server. However, it seems that LangGraph Python is more mature. Is there a significant gap between LangGraph JS and LangGraph Python?

Thanks!

[benjamincburns]

Hi Logan,

I recently joined LangChain after going through a similar journey in my past job. The very brief answer to your question is that I do believe the TS implementation of LangGraph is production-ready, but I think we need to reflect this better in our documentation. At my last job I helped build out an agent system to deploy in a multi-tenant SaaS product that was SOC 2 compliant. We had to handle concerns like data isolation, authX enforcement, GDPR requirements, disaster recovery, etc, and LangGraphJS didn't stand in the way - but the docs definitely could've been more helpful.

Regarding the perception that our TS implementation is lagging behind the JS one, I think this is also largely an issue in the docs moreso than it is in the code. We're currently working to make it so both implementations use a shared set of docs, and you'll just toggle a switch on the various pages to see the content tailored to your language of choice. This should hopefully go a long way to shoring up this problem.

Once that's done (hopefully in a couple of weeks) we're also looking to address any content gaps in the shared documentation around key areas of concern, like production readiness. I have a list of priority items for this (some of which I mentioned above), but I'd be curious - would you be willing to share your own "checklist" for production-readiness with us? That is - what are your must-haves w.r.t that you want to make sure we address in some way? I'll happily repay the favor by giving you some quick answers on those items here, and it'll help me to prioritize those gaps in our docs.

You can also ping me on our community slack if you'd like, although I'm based in NZ, so depending on your time zone it may be better to chat here.

[logan272]

Hi Ben,

Thank you for your detailed response; I really appreciate it.

The reason I’m asking about the production readiness of LangGraph JS is due to some confusion on my part. It seems that the documentation hasn’t clearly addressed the status of LangGraph JS and how it compares to LangGraph Python, leaving me uncertain about its production readiness.

Your confirmation about its production readiness has been very helpful.

Regarding my checklist for production readiness, here are few I’ve come up with:

• There're projects that have successfully used LangGraph JS in production.
• We expect the framework’s APIs to be relatively stable, and we expect migration docs to be available for any breaking changes.
• Given the rapid evolution of the field, we expect the underlying LLM capabilities to change significantly. When new capabilities are added, we want to be able to drill down to the LLMs without the framework imposing many limitations or requiring us to wait for it to be supported in the framework.

[benjamincburns]

Your confirmation about its production readiness has been very helpful.

Regarding my checklist for production readiness, here are few I’ve come up with:

• There're projects that have successfully used LangGraph JS in production.

This is very much the case. We fully support LangGraph JS on LangGraph Platform, and we have lots of people self-hosting. Let me check internally to see if I can share a few example companies/projects.

• We expect the framework’s APIs to be relatively stable, and we expect migration docs to be available for any breaking changes.

The LangGraph project as a whole follows semver, including on the JS side. This means that we communicate potentially breaking changes by incrementing the leftmost nonzero version number. We're still a 0.x build because it's still early days for us, but we do follow an informal deprecation process before most breaking changes. In rare cases where this process isn't followed, it'll be because there's substantial value added by making that change, and you'll see the breakages flagged in our release notes and in the version number change.

We do also occasionally mark some APIs as "beta" or "experimental." These are areas where we regard the API as not yet crystalized, and as such we might make breaking changes to improve those APIs without incrementing the leftmost build number. In practice this tends to be quite rare, but we like to do this for a period of time to allow for early feedback from users in case there's something substantial that we missed. The recent functional API release is a good example of this sort of thing.

I don't know if we have a concrete plan yet for a 1.x release, but I wouldn't expect a ton of API thrashing on anything that isn't listed as beta. Things will change periodically, but it won't be extreme.

• Given the rapid evolution of the field, we expect the underlying LLM capabilities to change significantly. When new capabilities are added, we want to be able to drill down to the LLMs without the framework imposing many limitations or requiring us to wait for it to be supported in the framework.

Good news here is that LangGraph isn't LangChain. It works with LangChain, but you can interface with the LLM however you like. LangChain is a great way to do that, but there are a bunch of other options for you to choose from as well. 😄

[benjamincburns]

Let me check internally to see if I can share a few example companies/projects.

This blog post is relevant. Elastic is using JS. Not sure about the others, sorry.

11x is also a major user of LangGraph JS.