Yandex Cloud explains why the frontend leads AI integration in DataLens at launch

Yandex Cloud suggests treating the integration of neural networks into a product as more than a backend-only task. In DataLens, a frontend team built the first working layer of Neuroanalyst: it put together the chat interface, a BFF layer and the logic for talking to the model, without waiting for a major server-side rework. The idea is that for an early launch of AI features, a perfect architecture built to last years matters less than getting to market quickly with a clear division of responsibility.

The case in question is DataLens, Yandex Cloud's BI system for visualizing large datasets. The service now includes Neuroanalyst, an assistant that helps build charts, write formulas and solve analytical tasks in a dialogue. Instead of the classic setup in which the backend fully owns the LLM integration, the team proposed a different order: a BFF layer sits between the client and the model, and the frontend is responsible for it. Such a layer can run on Node.js, Bun or another familiar stack and serve as a separate server geared to the needs of the interface.

The author illustrates the approach with a demo project: a monorepo with Express and React, in which a BI dashboard runs next to a chat assistant. In this setup the existing backend does not need to be rewritten urgently. The BFF stores the model access keys, handles rate limiting, CORS, logging and monitoring, and manages response streaming.

For frontend developers this is not foreign territory: in many product teams they have long worked as full-stack engineers, maintaining server code, CI/CD and the infrastructure around the client application. So the first stage of integration can be done closer to the interface, where the effect on users is most quickly visible. If the hypothesis fails, the cost of the mistake is lower than with a deep rework of the main backend.

The authors of the approach identify four basic components of such an integration. First, a UI kit for the chat interface and related elements: input fields, cards, action lists, message streaming. Second, an SDK for working with the model through an API; what matters here is not the specific provider but compatibility, because many services replicate the OpenAI API format.

Third, tooling, meaning function calling and the model's access to application functions, for example fetching data for a chart or selecting the top 5 products. Fourth, context: dialogue history, application state, user code, computation results and errors that the model needs to give a meaningful answer. These four layers are, at a basic level, enough to launch a working AI feature in an interface.

The author sees context as the main argument for the frontend. An LLM has no memory of its own, so every request must pass along the conversation history and everything needed for the answer. In BI products a significant share of the data lives on the client: open tabs, current dashboard settings, query fragments, error messages, intermediate results and sometimes pieces of user code.

Sending all of this to the backend for every model response is expensive and not always sensible. Meanwhile, although models' context windows keep growing, they are usually still limited to tens or hundreds of thousands of tokens, and sometimes a million, and they cannot be used without selection. Models also still handle exact calculations poorly, so they need not just a lot of data but well-packaged data and access to tools that compute and retrieve the necessary facts.

For the market this is an important signal: integrating AI into a product is ceasing to be a backend monopoly and becoming a joint engineering task, in which the frontend can take on the starting stage and bring an idea to users faster. As load grows, background operations appear and ties to internal systems deepen, the backend's role will, of course, grow again. But at an early stage, this BFF approach lets teams test scenarios faster, gather product insights and avoid delaying the launch over a large architectural overhaul. For teams still looking for a place for their first LLM feature, it is a practical way to start without excess organizational weight.