Nhiệm vụ: Hợp nhất dịch vụ next-js và app

Hợp nhất dịch vụ next-js và app

14.06.2026gorodskie-bani.ru

Hiện tại, trang web đang chạy trên next-js cũ, trong khi AI agent nằm trong app. Đồng thời, dịch vụ next-js cũ ngốn tới 1GB RAM.

Cần phải chuyển mọi thứ sang app.

Ворклоги

22 сент. 2026 г., 10:19:05

Di chuyển trang web cũ sang engine mới và chuẩn hóa mô hình dữ liệu

Công việc chính ở giai đoạn này không chỉ đơn thuần là di chuyển từng trang hoặc tài nguyên riêng lẻ, mà thực chất là tái cấu trúc trang web cũ trên engine mới haih-agent cùng với việc loại bỏ hoàn toàn cấu trúc dữ liệu cũ vốn hình thành từ thời MODX.

Vấn đề ở đây cơ bản cũng giống như khi nâng cấp các trang web cũ khác: theo thời gian, xung quanh CMS ban đầu đã tích lũy một cấu trúc dữ liệu riêng, rất nhiều template, các trường TV, các loại tài nguyên đặc biệt và logic ứng dụng gắn liền với các đặc điểm của engine cũ. Do đó, việc "cập nhật" ứng dụng thông thường là không đủ — trang web mới cần phải được di chuyển về mặt kiến trúc, bảo lưu nội dung hiện có nhưng loại bỏ các giới hạn kỹ thuật cũ.

Những gì đã có trong phiên bản cũ

Ban đầu, trang web chạy trên MODX, và phần lớn cấu trúc cơ sở dữ liệu vẫn kế thừa mô hình này cho đến nay. Các thực thể ngữ nghĩa khác nhau tồn tại độc lập với nhau và thường có các template cùng tập hợp trường TV riêng.

Cụ thể, các thành phần tồn tại độc lập gồm có:

thành phố;
công ty;
nhà tắm và phòng xông hơi;
đánh giá;
bài viết và ấn phẩm;
tài nguyên/trang thông thường;
blog và các loại nội dung khác.

Nói cách khác, sự khác biệt giữa các đối tượng không chỉ được ấn định ở cấp độ ý nghĩa kinh doanh mà còn ở cấp độ cấu trúc lưu trữ: các thực thể khác nhau, template khác nhau, trường dữ liệu khác nhau và logic xử lý riêng biệt. Đối với MODX, đây là cách tổ chức trang web tự nhiên, nhưng khi phát triển ứng dụng mới, sơ đồ này chỉ làm phức tạp thêm việc bảo trì và buộc phải chuyển các giới hạn cũ sang kiến trúc mới.

Chuyển sang `KbConcept`

Hiện tại, trang web đang dần tách khỏi cơ sở dữ liệu cũ và mô hình thực thể cũ. Đối với tất cả các loại dữ liệu chính, các trình nhập dữ liệu (importers) đã được viết và hoạt động để chuyển các bản ghi từ cơ sở dữ liệu cũ sang cơ sở dữ liệu mới.

Thay đổi kiến trúc cốt lõi nằm ở chỗ hầu như toàn bộ nội dung giờ đây được quy về một thực thể cơ sở duy nhất — KbConcept. Sự khác biệt về ngữ nghĩa giữa các đối tượng không được xác định bằng một bảng riêng hay một lớp mô hình riêng, mà thông qua trường type.

Ví dụ:

city:default — thành phố;
company:default — công ty;
resource:default — trang web thông thường;
review:company — đánh giá công ty;
blog:default — blog công khai;
blog:personal — blog cá nhân;
topic:default — ấn phẩm.

Do đó, thay vì một tập hợp lớn các thực thể phình to theo lịch sử, chúng ta có được một mô hình dữ liệu thống nhất với hệ thống kiểu rõ ràng. Điều này giúp đơn giản hóa đáng kể GraphQL schema, frontend, việc tái sử dụng component, các truy vấn, nhập dữ liệu và sự phát triển tiếp theo của trang web.

Đồng thời, việc chuẩn hóa không có nghĩa là mất đi tính kiểu dữ liệu (typing). Ngược lại, TypeScript cho phép định nghĩa khá chặt chẽ các kiểu phụ cụ thể dựa trên KbConcept chung và làm việc an toàn với chúng trong mã nguồn ứng dụng.

Định kiểu `KbConcept` thông qua template literal types

Tính năng sử dụng chuỗi ký tự mẫu trong kiểu (template literal types) của TypeScript tỏ ra cực kỳ hữu ích trong trường hợp này. Hiện tại, mã nguồn kiểu dữ liệu trông như sau:

import { EnumValueConfigMap, SchemaTypes } from '@pothos/core'
import { KbConceptFragment } from 'src/gql/generated'

export const CustomKbConceptType = {
  City: {
    value: 'city:default',
    description: 'Город',
  },
  Company: {
    value: 'company:default',
    description: 'Компания',
  },
  ResourceDefault: {
    value: 'resource:default',
    description: 'Веб-страница',
  },
  ReviewCompany: {
    value: 'review:company',
    description: 'Отзыв о компании',
  },
  BlogDefault: {
    value: 'blog:default',
    description: 'Публичный блог',
  },
  BlogPersonal: {
    value: 'blog:personal',
    description: 'Персональный блог',
  },
  TopicDefault: {
    value: 'topic:default',
    description: 'Публикация',
  },
} as const satisfies EnumValueConfigMap<SchemaTypes>

export type MapItemCompany = KbConceptFragment & {
  type: `company:${string}`
  lat: number
  lng: number
}

export function isMapItemCompany(
  concept: KbConceptFragment,
): concept is MapItemCompany {
  return concept.type?.startsWith('company:') && concept.lat && concept.lng
    ? true
    : false
}

export type Company = KbConceptFragment & {
  type: `company:${string}`
}

export function isCompany(concept: KbConceptFragment): concept is Company {
  return concept.type?.startsWith('company:') ? true : false
}

export type City = KbConceptFragment & {
  type: `city:${string}`
}

export function isCity(concept: KbConceptFragment): concept is City {
  return concept.type?.startsWith('city:') ? true : false
}

export type ReviewCompany = KbConceptFragment & {
  type: typeof CustomKbConceptType.ReviewCompany.value
}

export function isReviewCompany(
  concept: KbConceptFragment,
): concept is ReviewCompany {
  return concept.type === CustomKbConceptType.ReviewCompany.value
}

Có một số điểm đặc biệt hữu ích ở đây.

`as const satisfies ...`

Cú pháp:

} as const satisfies EnumValueConfigMap<SchemaTypes>

giải quyết đồng thời hai nhiệm vụ.

as const ngăn không cho TypeScript mở rộng các giá trị như 'city:default' thành kiểu string chung. Kết quả là các chuỗi cụ thể được giữ nguyên dưới dạng kiểu literal. Ví dụ, CustomKbConceptType.ReviewCompany.value có kiểu chính xác là 'review:company' chứ không chỉ là string.

Đồng thời, satisfies EnumValueConfigMap<SchemaTypes> kiểm tra xem toàn bộ đối tượng có tuân thủ hợp đồng mà Pothos mong đợi hay không, nhưng không làm mất đi thông tin chính xác về các giá trị literal bên trong đối tượng. Kết quả là sự kết hợp thuận tiện giữa kiểm tra cấu trúc nghiêm ngặt và suy luận kiểu chính xác tối đa.

Template literal types trong các kiểu dữ liệu

Phần thú vị nhất:

type: `company:${string}`

và tương tự:

type: `city:${string}`

Điều này cho phép thể hiện ngay ở cấp độ hệ thống kiểu nguyên lý cấu trúc của KbConcept.type: một đối tượng được coi là công ty không chỉ khi có một giá trị cụ thể company:default, mà với bất kỳ loại nào thuộc không gian company:*.

Ví dụ, nếu sau này xuất hiện company:premium, company:branch hoặc các biến thể chuyên biệt khác, kiểu Company đã có thể mô tả chúng mà không cần phải tạo thủ công một union riêng biệt.

Nói cách khác, thỏa thuận đặt tên kiểu dạng:

<nhóm>:<phân_loại_phụ>

không chỉ đơn thuần là một quy ước chuỗi trong cơ sở dữ liệu, mà đã trở thành một phần của hệ thống định kiểu tĩnh trong ứng dụng.

Type guards

Các hàm dạng:

export function isCompany(concept: KbConceptFragment): concept is Company

là các type guard do người dùng định nghĩa. Sau khi kiểm tra qua isCompany(concept), TypeScript biết rằng bên trong nhánh tương ứng, concept.type có dạng company:${string}.

Điều tương tự được áp dụng cho các thành phố và đánh giá.

isMapItemCompany đặc biệt hữu ích ở điểm: nó không chỉ kiểm tra tiền tố company:, mà còn thu hẹp đối tượng về một kiểu dữ liệu đảm bảo có sẵn các tọa độ lat và lng dưới dạng số. Nhờ đó, mã nguồn bản đồ phía sau không phải làm việc với một "đối tượng có thể là công ty và có thể có tọa độ", mà làm việc với một đối tượng bản đồ đã được định kiểu chuẩn chỉnh.

Đối với các biến thể chuyên biệt chính xác, bạn có thể sử dụng một cách kiểm tra nghiêm ngặt hơn nữa:

type: typeof CustomKbConceptType.ReviewCompany.value

Ở đây, kiểu ReviewCompany được liên kết trực tiếp với giá trị từ đối tượng trung tâm CustomKbConceptType. Nếu giá trị chuỗi của loại này bị thay đổi ở đó, kiểu dữ liệu sẽ không cần phải sao chép thủ công ở nhiều nơi.

Cuối cùng, thực thể chung KbConcept không biến ứng dụng thành một tập hợp các đối tượng không có kiểu. Ngược lại, nhờ thỏa thuận về type, template literal types và type guards, chúng ta có thể duy trì sự tiện lợi của một mô hình dữ liệu thống nhất, đồng thời đạt được định kiểu nghiêm ngặt cho các kịch bản cụ thể ở frontend.

Nhập dữ liệu cũ

Tính đến thời điểm hiện tại, các trình nhập dữ liệu cho các thực thể cũ đã được viết và đang hoạt động. Các dữ liệu chính đã được nhập, bao gồm tài nguyên, công ty và các loại nội dung liên quan.

Đây là một giai đoạn quan trọng trong bối cảnh chuyển đổi toàn diện: phiên bản mới của trang web không nên tiếp tục đọc cơ sở dữ liệu MODX cũ làm nguồn dữ liệu chính nữa. Các thực thể cũ được chuyển đổi thành mô hình chuẩn hóa mới, và từ đó ứng dụng sẽ làm việc hoàn toàn với cơ sở dữ liệu mới và KbConcept.

Như vậy, nhiệm vụ dần dịch chuyển từ việc tạo "giao diện mới phủ lên trang web cũ" sang việc di chuyển hoàn toàn sang một nền tảng mới.

Bản đồ

Bản đồ hiển thị các công ty cũng đã được di chuyển. Chức năng phân cụm (clustering) các điểm đánh dấu vẫn được giữ nguyên: khi có số lượng lớn đối tượng nằm gần nhau, chúng sẽ được gom thành các cụm, và khi phóng to bản đồ, chúng sẽ bung ra thành các phần tử riêng lẻ.

Đối với bản đồ, kiểu chuyên biệt MapItemCompany được sử dụng để sau khi lọc ở cấp độ TypeScript, chúng ta có thể đảm bảo chắc chắn rằng thực thể thuộc về company:* và có sẵn tọa độ.

Kết quả hiện tại

Tính đến thời điểm hiện tại:

kiến trúc trang web mới đã được xây dựng xoay quanh KbConcept;
các thực thể cũ chính không còn yêu cầu các mô hình riêng trong ứng dụng mới;
các trình nhập dữ liệu từ cơ sở dữ liệu cũ đã được viết và hoạt động;
tài nguyên, công ty và các thực thể chính khác đã được nhập;
các loại nội dung đã được quy về sơ đồ thống nhất <nhóm>:<phân_loại_phụ>;
các type guard và định kiểu nghiêm ngặt cho các biến thể cụ thể của KbConcept đã được thêm vào frontend;
bản đồ đã được di chuyển thành công;
tính năng phân cụm đối tượng trên bản đồ đã được khôi phục.

Giai đoạn tiếp theo là hoàn thiện thiết kế và tinh chỉnh phần giao diện trực quan của trang web mới. Sau đó, dự kiến sẽ xuất bản phiên bản trang web mới và chính thức chuyển đổi sang nó.

24 сент. 2026 г., 13:56:03

Cổng thông tin "Gorodskie bani" được viết lại hoàn toàn trên haih-agent

Trong khuôn khổ nhiệm vụ, trang web không chỉ đơn thuần được chuyển sang một engine khác, mà thực chất đã được viết lại hoàn toàn từ đầu trên kiến trúc haih-agent / haih CMS.

Kho lưu trữ của engine: https://github.com/haih-net/agent/

Phiên bản cổng thông tin cũ: https://old.gorodskie-bani.ru/

Phiên bản mới: https://gorodskie-bani.ru/

Mục tiêu chính của việc đại tu là loại bỏ kiến trúc nặng nề và phân mảnh của dự án Next.js cũ, đồng thời chuyển cổng thông tin sang mô hình đơn giản hơn, thống nhất hơn và hướng tới AI (AI-first), nơi nội dung, cấu trúc trang và sự phát triển tiếp theo của trang web thuận tiện nhất cho việc làm việc thôngผ่าน AI.

Những gì đã được thực hiện

Trên thực tế, bốn khối công việc lớn đã được hoàn thành:

xây dựng hoàn toàn phiên bản công khai mới của trang web trên haih-agent;
tái cấu trúc kiến trúc lưu trữ nội dung;
chuyển toàn bộ cơ sở dữ liệu lịch sử từ MySQL sang PostgreSQL;
chuyển trang web sang mô hình trong đó phần lớn việc quản lý và phát triển có thể được thực hiện bởi AI agent thông qua API và các thực thể nội dung được chuẩn hóa.

Do đó, sẽ chính xác hơn nếu xem xét giai đoạn này không phải là một "thiết kế lại" thông thường hoặc "thay đổi CMS", mà là một cuộc đại tu kiến trúc hoàn chỉnh của sản phẩm.

Di chuyển MySQL → PostgreSQL

Phiên bản cũ của trang web lưu trữ dữ liệu trong MySQL và sử dụng số lượng lớn các thực thể và bảng riêng biệt cho các loại nội dung khác nhau.

Để chuyển sang hệ thống mới, các trình nhập (importers) chuyên dụng đã được viết để:

đọc dữ liệu từ cơ sở dữ liệu MySQL cũ;
chuyển đổi các cấu trúc cũ thành mô hình chuẩn hóa mới;
chuyển dữ liệu sang PostgreSQL;
duy trì các liên kết, nội dung lịch sử và các URL hiện có ở những nơi cần thiết;
điều chỉnh nội dung cũ cho hệ thống tệp, hình ảnh và trang mới.

Việc di chuyển cơ sở dữ liệu lịch sử là một trong những phần quan trọng nhất của công việc, bởi vì trang web mới không chỉ bắt đầu từ tờ giấy trắng mà phải giữ lại nội dung đã tích lũy qua nhiều năm.

Thay vì nhiều thực thể — một Concept duy nhất

Một trong những thay đổi kiến trúc quan trọng là việc từ bỏ số lượng lớn các thực thể chuyên biệt.

Trong dự án cũ, ví dụ, có các thành phần tồn tại riêng biệt:

thành phố;
nhà tắm và phòng xông hơi;
đánh giá;
bình luận;
bài viết;
các loại nội dung khác.

Đối với mỗi loại như vậy, thường cần có các mô hình, truy vấn, mẫu (templates), logic hiển thị, API và kịch bản quản trị riêng.

Trong kiến trúc mới, phần lớn nội dung được quy về một thực thể phổ quát — Concept.

Concept chỉ chứa một vài trường cơ bản:

Tên;
Mô tả SEO;
Phần giới thiệu cho danh sách;
Nội dung;
Hình ảnh;
Danh sách tệp cho thư viện ảnh;
Tọa độ cho bản đồ.

Đồng thời, ý nghĩa của thực thể không được xác định bằng một bảng cứng nhắc riêng biệt trong cơ sở dữ liệu, mà bằng ngữ cảnh, các mối liên kết, đường dẫn và nội dung.

Cơ chế cơ bản giống nhau có thể được sử dụng cho thành phố, cơ sở, bài viết hoặc loại tài liệu khác.

Tại sao việc chuẩn hóa lại đơn giản hóa đáng kể cơ sở mã

Phương pháp tiếp cận này làm giảm đáng kể khối lượng mã ứng dụng.

Trước đây, mỗi loại nội dung mới có tiềm năng yêu cầu:

mô hình dữ liệu mới;
các thao tác CRUD riêng biệt;
các hợp đồng API riêng biệt;
biểu mẫu quản trị riêng biệt;
các mẫu hoặc thành phần React riêng biệt;
logic lựa chọn và hiển thị bổ sung.

Sau khi chuyển sang Concept, phần lớn cơ sở hạ tầng này trở thành chung.

Điều này làm giảm:

số lượng mô hình chuyên biệt;
số lượng các truy vấn trùng lặp;
khối lượng logic mẫu (boilerplate logic);
số lượng nơi cần duy trì hành vi giống nhau;
chi phí phát triển trang web sau này.

Càng ít thực thể đặc biệt, càng ít mã liên quan cần được giữ trong bộ nhớ của ứng dụng và thực thi khi hiển thị trang.

Kết quả là kiến trúc trở nên đơn giản hơn đối với cả máy chủ và nhà phát triển.

Giảm tải cho việc tạo mẫu (templating)

Việc chuẩn hóa nội dung không chỉ ảnh hưởng đến cấu trúc cơ sở dữ liệu mà còn ảnh hưởng đến việc hiển thị.

Thay vì số lượng lớn các mẫu riêng biệt cho các loại trang khác nhau, một tập hợp chung các thành phần và quy tắc hiển thị được sử dụng.

Các trang có thể được lắp ráp từ Markdown và các thành phần đặc biệt: thẻ, ảnh bìa, thư viện ảnh, bản đồ, cột, liên kết, khối tương tác với AI và các phần tử khác.

Điều này cho phép một hệ thống kết xuất duy nhất phục vụ số lượng lớn các trang khác nhau mà không cần phải tạo một trang React riêng biệt hoặc một tập hợp các mẫu đặc biệt cho từng thực thể.

Nói cách khác, độ phức tạp được chuyển từ nhiều mô hình chương trình rời rạc sang nội dung được chuẩn hóa + các thành phần có thể tái sử dụng.

Thay đổi chính — trang web đã trở thành AI-first

Điều quan trọng nhất trong việc đại tu này không phải là thiết kế mới hay thậm chí là việc thay đổi stack công nghệ.

Kiến trúc mới từ đầu đã được xây dựng sao cho trang web có thể được phát triển và duy trì đầy đủ thông qua AI.

AI agent sẽ dễ dàng hơn rất nhiều khi làm việc với một hệ thống mà thay vì hàng chục hợp đồng khác nhau, chỉ có một mô hình Concept dễ hiểu và một số thao tác chuẩn.

Đối với agent, không còn cần phải hiểu riêng biệt:

bảng thành phố được sắp xếp như thế nào;
API của bài viết khác với API của nhà tắm ở điểm nào;
các trường đánh giá nằm ở đâu;
phương pháp riêng biệt nào được sử dụng để cập nhật một loại tài liệu cụ thể;
biểu mẫu quản trị nào chịu trách nhiệm cho đối tượng này hay đối tượng khác.

Phần lớn nội dung được xử lý theo cùng một cách.

Điều này có nghĩa là agent có thể sử dụng các thao tác giống nhau để:

tạo tài liệu;
cập nhật văn bản;
thay đổi mô tả SEO;
thêm hình ảnh;
chỉnh sửa phần giới thiệu;
làm việc với tọa độ;
chuẩn bị thư viện ảnh;
xây dựng lại các trang;
cập nhật hàng loạt nội dung;
tìm kiếm và phân tích thông tin bên trong trang web.

Quản lý nội dung hoàn toàn thông qua AI

Trong hệ thống mới, bảng điều khiển quản trị cổ điển không còn là phương thức chính để quản lý trang web nữa.

Nội dung có thể truy cập thông qua API và AI agent có thể thực hiện các thay đổi theo tác vụ của con người.

Trên thực tế, quy trình làm việc giờ đây trông như sau:

con người diễn ạt tác vụ → AI phân tích trang web và dữ liệu → thực hiện các thay đổi thông qua API → con người kiểm tra kết quả.

Điều này hoàn toàn khác biệt so với CMS truyền thống, nơi con người buộc phải thủ công đi qua các biểu mẫu quản trị và chỉnh sửa từng thực thể riêng biệt.

Kết quả là AI không còn là một "phòng chat" bổ sung nằm trên trang web, mà trở thành một giao diện quản lý và phát triển dự án đầy đủ.

Trợ lý AI cho người dùng cuối

Việc chuẩn hóa nội dung tương tự cũng rất hữu ích cho agent trò chuyện với khách truy cập cổng thông tin.

Vì các thành phố, cơ sở, ấn phẩm và các tài liệu khác được trình bày theo định dạng nhất quán, agent sẽ dễ dàng hơn trong việc:

tìm kiếm thông tin cần thiết;
hiểu các mối liên hệ giữa các đối tượng;
tìm các cơ sở ở một thành phố cụ thể;
sử dụng tọa độ và dữ liệu địa lý;
làm việc với các mô tả và ấn phẩm;
tạo câu trả lời dựa trên nội dung hiện có.

Nói cách khác, kiến trúc mới đồng thời cải thiện hai phía của việc làm việc với AI:

AI như một công cụ của nhà phát triển và chủ sở hữu trang web — tạo và chỉnh sửa nội dung, thay đổi cấu trúc trang và giúp phát triển dự án.
AI như một giao diện cho khách truy cập — điều hướng trong danh mục và trả lời các câu hỏi của người dùng.

Cập nhật giao diện và phần công khai

Song song với việc di chuyển kiến trúc, phần công khai của cổng thông tin đã được cập nhật hoàn toàn.

Trong phiên bản mới, các tính năng sau đã được triển khai:

trang chủ được cập nhật;
điều hướng và kiểu chữ mới;
danh mục cơ sở;
trang cá nhân của các nhà tắm và phòng xông hơi;
thư viện ảnh;
phân trang (pagination);
danh mục thành phố;
điều hướng theo bảng chữ cái và tìm kiếm;
các trang thành phố với các bộ sưu tập cơ sở;
bản đồ với các điểm đánh dấu và nhóm đối tượng;
các ấn phẩm theo địa chỉ lịch sử;
giao diện gọi trợ lý AI.

Do đó, kiến trúc mới không bị giới hạn ở việc tái cấu trúc bên trong — phiên bản công khai hoạt động của cổng thông tin với dữ liệu lịch sử thực tế đã được lắp ráp hoàn chỉnh trên đó.

SEO và bảo tồn nội dung lịch sử

Trong quá trình di chuyển, điều quan trọng là không làm mất giá trị tìm kiếm của trang web hiện có.

Do đó, trong quá trình chuyển đổi, các yếu tố sau đã được tính đến:

URL lịch sử;
các ấn phẩm cũ;
trang cơ sở;
trang thành phố;
liên kết nội bộ;
mô tả SEO;
nội dung hiện có.

Việc giữ nguyên các đường dẫn cũ ở những nơi có thể sẽ làm giảm nguy cơ tụt hạng hàng loạt của các trang đã được lập chỉ mục sau khi thay đổi engine.

Đồng thời, việc chuyển sang haih-agent không có nghĩa là tự động tăng thứ hạng tìm kiếm. Hiệu ứng SEO của kiến trúc mới trước hết nằm ở chỗ trang web trở nên dễ bảo trì hơn, thay đổi nhanh hơn, dễ mở rộng nội dung hơn và thuận tiện hơn để cải thiện có hệ thống với sự trợ giúp của AI.

Giờ đây, việc cập nhật hàng loạt siêu dữ liệu (metadata), văn bản, cấu trúc trang và nội dung có thể được thực hiện nhanh hơn đáng kể so với kiến trúc trước đây.

Tại sao điều này lại quan trọng đối với sự phát triển trong tương lai

Kết quả chính của việc di chuyển không chỉ là giảm nợ kỹ thuật (technical debt).

Cổng thông tin giờ đây nằm trong một kiến trúc cho phép thực hiện các tác vụ trong tương lai nhanh hơn rất nhiều.

Quy trình làm việc mới trông như sau:

triển khai engine → cấu hình giao diện và các thành phần → lắp ráp các trang → tải lên hoặc tạo nội dung → tiếp tục phát triển trang web thông qua AI và API.

Nếu cần thiết, các quy trình nghiệp vụ phức tạp vẫn có thể có các mô hình chương trình riêng biệt, nhưng nội dung tiêu chuẩn không còn đòi hỏi phải tạo ra cơ sở hạ tầng riêng cho từng loại trang mới.

Điều này đặc biệt quan trọng đối với các dự án nội dung lớn, nơi chi phí bảo trì thường không được xác định bằng độ phức tạp của một trang, mà bằng số lượng các thực thể, biểu mẫu và mẫu khác nhau.

Thời gian thực hiện

Việc đại tu toàn bộ cổng thông tin, bao gồm giao diện mới, chuyển dữ liệu lịch sử và di chuyển sang kiến trúc mới, đã được hoàn thành trong khoảng ba ngày.

Đồng thời, phần lớn thời gian đã được dành cho việc đảm bảo khả năng tương thích với trang web cũ và nhập cơ sở dữ liệu hiện có.

Dự án mới nếu không cần phải chuyển đổi cấu trúc legacy trên một engine đã được chuẩn bị sẵn thì có thể được lắp ráp nhanh hơn đáng kể.

Tổng kết

Trong khuôn khổ nhiệm vụ, trang web "Gorodskie bani" thực chất đã được tạo lại từ đầu trên haih-agent.

Kiến trúc phân mảnh cũ với số lượng lớn các thực thể chuyên biệt đã được thay thế bằng mô hình thống nhất Concept, cơ sở dữ liệu lịch sử đã được chuyển từ MySQL sang PostgreSQL bằng các trình nhập được viết riêng, và phần công khai của cổng thông tin đã được lắp ráp lại hoàn toàn trên engine mới.

Thành tựu chính của công việc này là việc chuyển đổi sang kiến trúc trang web hướng dẫn bởi AI (AI-driven).

Giờ đây, AI không chỉ có thể trả lời khách truy cập mà còn có thể tham gia đầy đủ vào sự phát triển của chính dự án: làm việc với nội dung, thay đổi trang, cập nhật dữ liệu SEO, quản lý tệp, cấu trúc tài liệu và thực hiện các thao tác hàng loạt thông qua API.

Kết quả là trang web đã trở nên đơn giản hơn về kiến trúc, tiết kiệm chi phí hơn trong việc phát triển sau này và thích nghi tốt hơn đáng kể cho việc phát triển, điền nội dung và hỗ trợ với sự trợ giúp của trí tuệ nhân tạo.

haih CMS / haih-agent trong dự án này không chỉ được sử dụng như một engine mới, mà còn là nền tảng cho trang web, nơi AI là một thành viên đầy đủ của toàn bộ vòng đời — từ phát triển đến quản lý nội dung và giao tiếp với người dùng cuối.