Worklog for task "Merge next-js and app services"

The "Gorodskie Bani" portal has been completely rewritten on haih-agent

As part of the task, the website was not just migrated to another engine, but essentially completely rewritten from scratch on the haih-agent / haih CMS architecture.

Engine repository: https://github.com/haih-net/agent/

Old version of the portal: https://old.gorodskie-bani.ru/

New version: https://gorodskie-bani.ru/

The main goal of the redesign was to abandon the heavy and fragmented architecture of the old Next.js project and move the portal to a significantly simpler, unified, and AI-first model, where content, page structure, and further website development are as convenient as possible for working via AI.

What was done

Four major blocks of work were actually completed:

• a completely new public version of the website was built on haih-agent;
• the content storage architecture was redesigned;
• the entire historical database was migrated from MySQL to PostgreSQL;
• the website was transferred to a model where a significant part of management and development can be performed by an AI agent via API and unified content entities.

Therefore, it is more accurate to consider this stage not as a routine "redesign" or "CMS change", but as a complete architectural redesign of the product.

MySQL → PostgreSQL Migration

The old version of the website stored data in MySQL and used a large number of separate entities and tables for different types of content.

To transition to the new system, custom importers were written that:

• read data from the old MySQL database;
• transformed old structures into the new unified model;
• migrated data to PostgreSQL;
• preserved links, historical content, and existing URLs where necessary;
• adapted old content to the new file, image, and page system.

Migrating the historical database was one of the most substantial parts of the work, because the new website needed not just to start with a blank slate, but to preserve the content accumulated over the years.

Instead of Multiple Entities — One Concept

One of the key architectural changes is the abandonment of a large number of specialized entities.

In the old project, there existed separately, for example:

• cities;
• bathhouses and saunas;
• reviews;
• comments;
• articles;
• other types of content.

Each such type usually required its own models, queries, templates, display logic, API, and administrative scenarios.

In the new architecture, most content is reduced to a single universal entity — Concept.

Concept contains just a few basic fields:

• Title;
• SEO description;
• Intro for lists;
• Content;
• Image;
• List of files for the gallery;
• Map coordinates.

At the same time, the meaning of the entity is determined not by a separate rigid table in the database, but by the context, relationships, route, and contents.

The same basic mechanism can be used for a city, an establishment, an article, or another type of material.

Why Unification Greatly Simplifies the Codebase

This approach significantly reduces the volume of application code.

Previously, each new content type potentially required:

• a new data model;
• separate CRUD operations;
• separate API contracts;
• a separate administrative form;
• separate templates or React components;
• additional fetching and rendering logic.

After switching to Concept, most of this infrastructure becomes shared.

This reduces:

• the number of specialized models;
• the number of repetitive queries;
• the amount of boilerplate logic;
• the number of places where identical behavior must be maintained;
• the cost of subsequent website development.

The fewer special entities there are, the less related code needs to be kept in the application's memory and executed when rendering pages.

As a result, the architecture becomes simpler for both the server and the developer.

Less Load on Templating

Content unification affects not only the database structure, but also rendering.

Instead of a large number of separate templates for different page types, a common set of components and display rules is used.

Pages can be assembled from Markdown and special components: cards, covers, galleries, maps, columns, links, AI interaction blocks, and other elements.

This allows a single rendering system to serve a large number of different pages without the need to create a separate React page or a set of special templates for each entity.

In other words, complexity is shifted from many disparate software models to unified content + reusable components.

The Main Change — The Website Has Become AI-First

The most important thing in this redesign is not the new design or even the change of stack itself.

The new architecture is initially built so that the website can be fully developed and maintained via AI.

It is much easier for an AI agent to work with a system where, instead of dozens of different contracts, there is one clear Concept model and a few standard operations.

The agent no longer needs to separately understand:

• how the city table is structured;
• how an article's API differs from a bathhouse's API;
• where the review fields are located;
• what specific method is used to update a particular type of material;
• which administrative form is responsible for a particular object.

Most content is processed in the same way.

This means the agent can use the same operations for:

• creating materials;
• updating texts;
• changing SEO descriptions;
• adding images;
• editing intros;
• working with coordinates;
• preparing galleries;
• rebuilding pages;
• mass content updates;
• searching and analyzing information within the website.

Full Content Management via AI

In the new system, the classic administrative panel ceases to be the central way to manage the website.

Content is available via API, and the AI agent can perform changes based on a human task.

In fact, the workflow now looks like this:

a human formulates the task → AI analyzes the website and data → performs changes via API → a human checks the result.

This is fundamentally different from a traditional CMS, where a person is forced to manually go through administrative forms and edit each entity separately.

As a result, AI becomes not an additional "chat" on top of the website, but a fully-fledged management and project development interface.

AI Assistant for End Users

The same content unification is also useful for the agent interacting with portal visitors.

Since cities, establishments, publications, and other materials are presented in a consistent format, it is easier for the agent to:

• search for necessary information;
• understand relationships between objects;
• find establishments in a specific city;
• use coordinates and geographical data;
• work with descriptions and publications;
• generate responses based on existing content.

Thus, the new architecture simultaneously improves two sides of working with AI:

1. AI as a tool for the developer and website owner — creates and edits content, changes page structures, and helps develop the project.
2. AI as an interface for the visitor — navigates the catalog and answers user questions.

Interface and Public Part Update

In parallel with the architectural migration, the public part of the portal was completely updated.

The new version implements:

• an updated homepage;
• new navigation and typography;
• an establishment catalog;
• individual pages for bathhouses and saunas;
• photo galleries;
• pagination;
• a city directory;
• alphabetical navigation and search;
• city pages with establishment selections;
• a map with markers and object clustering;
• publications by historical addresses;
• an interface for addressing the AI assistant.

Thus, the new architecture was not limited to internal refactoring — a working public version of the portal with real historical data was fully built on top of it.

SEO and Preservation of Historical Content

During migration, it was important not to lose the search value of the existing website.

Therefore, the transfer took into account:

• historical URLs;
• old publications;
• establishment pages;
• city pages;
• internal linking;
• SEO descriptions;
• existing content.

Preserving old routes where possible reduces the risk of mass drop-off of indexed pages after changing the engine.

At the same time, the transition to haih-agent does not mean an automatic growth in search rankings. The SEO effect of the new architecture lies primarily in the fact that the website becomes easier to maintain, faster to modify, easier to scale in terms of content, and more convenient to systematically improve using AI.

Now, mass updates of metadata, texts, page structures, and content can be performed significantly faster than in the previous architecture.

Why This Is Important for Future Development

The main result of the migration is not only a reduction in technical debt.

The portal is now in an architecture that allows future tasks to be completed much faster.

The new workflow looks like this:

deploy the engine → configure the theme and components → build pages → upload or create content → continue developing the website via AI and API.

If necessary, complex domain-specific processes can still have separate software models, but standard content no longer requires creating separate infrastructure for each new page type.

This is especially important for large content projects where maintenance costs are often determined not by the complexity of a single page, but by the number of different entities, forms, and templates.

Completion Time

The complete redesign of the portal, including the new interface, transfer of historical data, and migration to the new architecture, was completed in approximately three days.

At the same time, a significant amount of time was spent specifically on compatibility with the old website and importing the existing database.

A new project without the need to transfer legacy structures on an already prepared engine could have been built significantly faster.

Summary

As part of the task, the "Gorodskie Bani" website was essentially recreated from scratch on haih-agent.

The old fragmented architecture with a large number of specialized entities was replaced with the unified Concept model, the historical database was migrated from MySQL to PostgreSQL using custom-written importers, and the public part of the portal was completely rebuilt on the new engine.

The main achievement of this work is the transition to an AI-driven website architecture.

Now AI can not only answer visitors, but also fully participate in the development of the project itself: work with content, modify pages, update SEO data, manage files, material structures, and perform mass operations via API.

As a result, the website has become simpler in architecture, cheaper in future development, and significantly better adapted for development, population, and maintenance with the help of artificial intelligence.

haih CMS / haih-agent in this project is used not just as a new engine, but as a foundation for a website where AI is a full participant in the entire lifecycle — from development to content management and communication with the end user.