Frontend, backend, database хэрхэн холбогддог вэ?

Яагаад үүргийг салгах хэрэгтэй вэ?

Task-ийн гарчиг хоосон эсэхийг form дээр шалгаж болно. Гэхдээ хэрэглэгч browser-ийн шалгалтыг тойрч API руу шууд хоосон өгөгдөл илгээвэл яах вэ? Frontend-ийн шалгалтад ганцааранг нь итгэвэл database-д буруу өгөгдөл орж болно.

Системийн хэсэг бүр өөр асуултад хариулдаг:

• Frontend: Хэрэглэгч юу харж, яаж үйлдэл хийх вэ?
• Backend: Энэ хүсэлт зөвшөөрөгдөх үү, ямар дүрмээр боловсруулах вэ?
• Database: Баталгаажсан өгөгдлийг яаж удаан хугацаанд хадгалах вэ?

Үүргийг ингэж салгаснаар UI өөрчлөгдсөн ч business rule нэг газар үлдэнэ, database солигдсон ч хэрэглэгчийн form-ийн бүх кодыг дахин бичих шаардлага багасна.

Нэг Task Manager, гурван үүрэг

Энэ хичээлд дараах гурван үйлдлийг дагана:

1. Task үүсгэх
2. Task жагсаах
3. Task-ийн төлөв өөрчлөх

Task-ийн энгийн өгөгдөл:

{
  "id": "task_42",
  "title": "API урсгалаа зур",
  "completed": false
}

Frontend-ийн хариуцах зүйл

Frontend нь form, button, task list, loading болон error message-ийг хэрэглэгчид ойлгомжтой үзүүлнэ. Form-ийн хурдан feedback-д title хоосон эсэхийг шалгаж болно. Backend рүү хүсэлт илгээж, ирсэн хариултаар дэлгэцээ шинэчилнэ.

Frontend дараахыг ганцаараа баталгаажуулах ёсгүй:

• Хэрэглэгч тухайн task-ийг өөрчлөх эрхтэй эсэх
• Title-ийн server-side эцсийн дүрэм
• Өгөгдөл үнэхээр хадгалагдсан эсэх
• Database-ийн нууц credential

Backend-ийн хариуцах зүйл

Backend нь системийн итгэмжлэгдсэн хаалга. Request-ийн бүтэц, утгыг шалгана, business rule хэрэгжүүлнэ, database operation дуудна. Амжилт эсвэл алдааг тогтвортой response болгон frontend-д өгнө.

Task Manager-д backend:

• title string бөгөөд trim хийсний дараа хоосон биш эсэхийг шалгана;
• title 120 тэмдэгтээс урт байж болохгүй гэсэн дүрэм хэрэгжүүлж болно;
• database-д шинэ task үүсгэхийг хүснэ;
• үүссэн task-ийг 201 response-д буцаана;
• алдааны дотоод дэлгэрэнгүйг хэрэглэгчид задруулахгүй.

Database-ийн хариуцах зүйл

Database нь task-ийг request дууссаны дараа ч хадгалж үлдээх persistence үүрэгтэй. ID, title, completed state зэрэг талбар хадгална. Schema, constraint, index, transaction зэрэг механизм нь өгөгдлийн бүрэн бүтэн байдлыг хамгаална.

Database хэрэглэгчид button зурдаггүй, HTTP error message-ийн Mongolian copy сонгодоггүй. Мөн database constraint байгаа ч backend input validation шаардлагагүй болчихдоггүй: backend ойлгомжтой алдаа өгөх, зөвшөөрөл шалгах үүрэгтэй хэвээр.

Task үүсгэх үндсэн урсгал

Frontend form
→ Backend validation
→ Database write
→ Backend response
→ Frontend update

1. Хэрэглэгч form бөглөнө

   Frontend title-ийг state-д барьж, Save button дарахад request бэлдэнэ.

2. Backend input-ийг шалгана

   Body байгаа эсэх, title зөв төрөлтэй эсэх, business rule зөрчөөгүй эсэхийг server талд заавал шалгана.

3. Database-д бичнэ

   Validation давсан өгөгдлөөр database insert хийнэ. Database шинэ ID болон хадгалсан record буцааж болно.

4. Backend утгатай response өгнө

   Амжилттай бол үүссэн task болон 201; буруу input бол 400; санаандгүй server алдаа бол дотоод мэдээлэл задруулахгүй 500 response өгнө.

5. Frontend бодит хариултаар шинэчлэгдэнэ

   Амжилттай response-ийн task-ийг жагсаалтад нэмнэ. Алдаа ирвэл form-ийн утгыг устгалгүй, хэрэглэгч дараагийн алхмаа ойлгох message үзүүлнэ.

Task жагсаах ба төлөв өөрчлөх

Task жагсаах үед frontend page нээгдэхэд backend-ээс task collection хүснэ. Backend зөвшөөрөгдсөн records-ийг database-аас авч response болгоно. Frontend loading, empty, success, error төлөв бүрийг тусад нь үзүүлнэ.

Task complete болгоход frontend completed: true өөрчлөлт илгээнэ. Backend ID зөв эсэх, task байгаа эсэх, update хийх эрхтэй эсэхийг шалгаад database record шинэчилнэ. Хэрэв task байхгүй бол “амжилттай мэт” UI өөрчлөхийн оронд 404 response-ийг зөв боловсруулах хэрэгтэй.

Validation, business rule, persistence

Validation нь input хэлбэр болон утгын зөв эсэхийг шалгана: title string мөн үү, хоосон уу, зөв урттай юу?

Business rule нь бүтээгдэхүүний утгатай хязгаар: completed task-ийн title өөрчлөхийг зөвшөөрөх үү, нэг хэрэглэгч хэдэн active task-тай байж болох вэ?

Persistence нь баталгаажсан state-ийг request-ээс урт хугацаанд хадгална. Энэ нь ихэвчлэн database-ийн үүрэг.

Frontend usability-ийн validation давтаж болно, гэхдээ backend хамгаалалтын эцсийн шийдвэрийг гаргана. Database constraint хамгийн доод хамгаалалт болж болно.

Error flow-ийг урьдчилж зохиох

Frontend request
→ Backend validation fails
→ 400 response + safe message
→ Frontend field error

Frontend request
→ Backend validation passes
→ Database unavailable
→ logged internal error + 500 response
→ Frontend retry guidance

Internal database error, stack trace, connection string зэргийг response-д шууд буцааж болохгүй. Backend operator-д хэрэгтэй дэлгэрэнгүйг server log-д, хэрэглэгчид хэрэгтэй дараагийн алхмыг public error message-д тусад нь өгнө.

Түгээмэл алдаа

• Client validation-ийг authorization гэж андуурах
• Frontend-ээс database admin credential ашиглах
• Database write дуусаагүй байхад success message тогтмол үзүүлэх
• Backend error бүрийг 500 болгоод input алдааг ялгахгүй байх
• Database schema-г frontend component-ийн бүтэцтэй хэт холбох
• Error-ийг хоосон catch-аар нуух

Мэдлэгээ шалгах

Дүгнэлт

Frontend хэрэглэгчийн interaction болон харагдах төлөвийг, backend validation, business rule, authorization, response-ийг, database persistence болон өгөгдлийн бүрэн бүтэн байдлыг хариуцна. Task үүсгэх урсгалыг form-оос database, буцаад UI хүртэл мөрдөж чадвал алдаа болон хамгаалалтыг зөв давхаргад байрлуулах суурьтай болно.