Yandex Cloud explains why frontend leads AI integration in DataLens

Yandex Cloud proposes viewing the integration of neural networks into a product not as a backend-only task. In DataLens, the first working layer of Neuropanalytik was taken on by the frontend team: they assembled a chat interface, a BFF layer, and the logic for communicating with the model, without waiting for major server restructuring. The idea is that for an early AI feature launch, what matters more than perfect architecture for years to come is a fast market entry with a clear zone of responsibility.

We're talking about DataLens, Yandex Cloud's BI system for visualizing large datasets. Inside the service appeared Neuropanalytik — an assistant that helps build charts, write formulas, and solve analytical tasks in dialogue. Instead of the classical scheme where the backend takes full responsibility for LLM integration, the team proposed a different approach: between the client and the model appeared a BFF layer, for which the frontend is responsible.

Such a layer can be raised on Node.js, Bun, or another familiar stack and used as a separate server oriented to the interface's needs. The author illustrates the approach with a demo project in the form of a monorepo with Express and React, where a BI dashboard works alongside a chat assistant.

In this scheme, the existing backend doesn't need urgent rewriting. The BFF stores access keys to the model, handles rate limiting, CORS, logging and monitoring, and also manages response streaming. For frontend developers this is not unfamiliar territory: in many product teams they've long worked as fullstack engineers, maintaining server code, CI/CD, and infrastructure around the client application.

That's why the first stage of integration can be done closer to the interface, where the user effect is most quickly visible. If the hypothesis doesn't take off, the cost of error is lower than with deep reworking of the main backend. The authors of the approach identify four basic components of such integration.

First — a UI kit for chat interface and related elements: input fields, cards, action lists, message streaming. Second — an SDK for working with the model via API; what matters here is not the specific provider, but compatibility, because many services replicate the OpenAI API format. Third — tooling, that is, function calling and the model's access to application functions, for example, obtaining data for a chart or sampling top-5 products.

Fourth — context: conversation history, application state, user code, computation results, and errors that the model needs for a meaningful response. Basically, these four layers are already enough to launch a working AI function in the interface. It's precisely context that the author considers the main argument in favor of the frontend.

LLMs have no memory of their own, so with every request you have to re-transmit the conversation history and everything needed for a response. In BI products, a significant portion of data lives on the client: open tabs, current dashboard settings, query fragments, error messages, intermediate results, and sometimes even pieces of user code. Transferring all of this to the backend for each model response is expensive and not always sensible.

Meanwhile, while model context windows are growing, they're usually still limited to tens or hundreds of thousands of tokens, sometimes a million, and can't be used without selection. Moreover, models still perform poorly on precise calculations, so they need not just a lot of data, but properly packaged data and access to tools that compute and retrieve needed facts. For the market this is an important signal: AI integration into a product ceases to be a backend monopoly and becomes a joint engineering task, where the frontend can take on the startup phase and deliver the idea to users faster.

As load grows, background operations appear, and deeper coupling with internal systems emerges, the role of the backend, of course, strengthens again. But at an early stage, it's precisely this BFF approach that allows faster verification of scenarios, gathering product insights, and not slowing down the launch due to major architectural restructuring. For teams just seeking a place for their first LLM function in a product, this is a practical way to start without unnecessary organizational overhead.