ChatGPT Apps stack arxitekturası

1. Giriş

Əgər ChatGPT App-ə sadəcə “daha bir veb‑server” kimi baxsaq, çox tez arxitektura zooparkı başlayır: hardasa Next.js, hardasa MCP‑server, hardasa agent, hardasa commerce‑backend — və bunların hamısı beyində bir böyük “server”ə qarışır.

Bizim üçün bunu dərhal laylı piroq kimi qəbul etmək daha sərfəlidir:

• yuxarıda — nəzarət etmədiyimiz, amma uyğunlaşdığımız ChatGPT UI;
• onun altında — söhbətdə render olunan, Apps SDK (Next.js 16, React 19) üzərində çalışan widget-ımız;
• daha aşağıda — alətləri olan MCP‑server (tools/resources/prompts);
• opsional — mürəkkəb ssenariləri orkestrasiya edən agent layı;
• və ən aşağıda — sizin “yer üzündəki” servisləriniz: DB, xarici API-lər, commerce/ACP (commerce ssenariləri üçün protokol) və s.

Kurs konspektində bu yolu belə bir zəncir kimi çəkmək olar:

User → ChatGPT Widget → Apps SDK → MCP Gateway (Auth) → Agent Service → ACP / Stripe.

İndi vəzifəmiz — bu zənciri anlaşılan zehni modelə çevirməkdir.

2. Stack-ın ümumi sxemi

Əvvəlcə şəkilə bütöv baxaq, sonra qat-qat gedək.

flowchart TD
    U[Istifadəçi ChatGPT-də] --> C["ChatGPT UI söhbət + Apps paneli"]
    C --> W["Sizin App-in widget-i (Apps SDK, Next.js)"]
    W --> M["MCP serveri (tools/resources/prompts)"]
    M --> AG["Agent(lər) (Agents SDK, orkestrasiya)"]
    AG --> B["Backend-lər və ACP DB, servislər, ödəniş sistemi"]

Bəzi vacib məqamları qeyd etmək önəmlidir.

Birincisi, istifadəçi yalnız iki səviyyəni görür: ChatGPT UI və sizin widget. Bundan aşağısı — “kulisdir”.

İkincisi, MCP protokolu təsadüfi abreviatura deyil, Apps SDK-nın alətlərinizlə ünsiyyət qurduğu rəsmi standartdır: server tools-u sadalamalı, call_tool qəbul etməli və ChatGPT-də render üçün UI resursuna keçid qaytarmalıdır.

Üçüncüsü, Agents və ACP layları formal olaraq opsionaldır, lakin real kommersiya tətbiqlərində demək olar ki, həmişə üzə çıxır: haradasa çoxmərhələli ssenarini planlamaq, haradasa isə ödəniş qəbul etmək lazımdır.

İndi hər layı ayrıca nəzərdən keçirək.

Insight: ChatGPT — bu bir framework-dür

ChatGPT ilə inteqrasiya tək bir yerdə deyil — çox sayda inteqrasiya nöqtəsinə yayılıb. Proqramçı üçün bu, framework ilə işləməyə ən çox bənzəyir. Framework nə vaxt və harada kodunu çağıracağını özü qərar verir, sənə isə düzgün şeyləri düzgün yerlərə yazmaq qalır.

ChatGPT ilə də məhz belədir:

• widget-lər — mcp-resources vasitəsilə qeydiyyatdan keçirilir, GPT onları nə vaxt göstərəcəyinə özü qərar verir
• mcp-tools — GPT onları nə vaxt çağıracağını özü qərar verir
• product feed — modeli mcp-tool ilə doldurmaq olar, lakin standart yol — site register merchant
• ACP/InstantCheckout — ayrı API
• Avtorizasiya — ayrıca MCP auth server.

3. Lay 1 — ChatGPT UI: bizim “host”

ChatGPT UI — bu, OpenAI-nin brauzer (və mobil) interfeysidir, istifadəçi əsas dialoqu burada aparır. Burada tanış mətn daxil etmə sahəsi, mesaj tarixçəsi, model seçimi düymələri və tətbiqlər (Store/Composer) üçün bölmə var.

Bu layı biz proqramlaşdırmırıq. Onun koduna, DOM-na və üslublarına çıxışımız yoxdur. Amma o, çərçivələri müəyyənləşdirir:

• məhz burada istifadəçi tətbiqinizi ya açıq şəkildə (Store/Composer vasitəsilə), ya da qeyri-açıq şəkildə (model özü App təklif edir) “seçir”;
• məhz burada ChatGPT qərar verir: sadəcə mətnlə cavab vermək, sizin tool-u çağırmaq, widget-ı render etmək və ya hamısını birlikdə etmək;
• məhz burada əsas UX pattern-ləri yaşayır: inline widget, fullscreen rejim, PiP pəncərəsi və s. (8-ci modulda ətraflı).

Praktiki baxımdan yadınızda saxlayın: ChatGPT UI — bizim host tətbiqimizdir. Biz ona içəri daxil oluruq, yoxsa əksinə deyil. GPT server sizin widget kodunuzu öz serverinə yükləyəcək, lazımsızlardan təmizləyəcək və ancaq sonra onu öz söhbətinə öz domenindən yükləyəcək.

4. Lay 2 — Apps SDK və widget (Next.js 16 söhbətin içində)

Növbəti lay — Apps SDK istifadə olunan React/Next.js-də yazdığınız UI kodudur.

Zehni model sadədir: sanki söhbətə yerləşdirilən widget kimi render olunan kiçik bir SPA. Amma qeydlərlə:

• kodunuz sandbox-da işləyir: məhdud DOM, şəbəkə sorğuları üçün öz qaydaları, ChatGPT ilə əlaqə üçün xüsusi window.openai obyekti (bununla bağlı ayrıca mühazirə olacaq);
• widget dialoq axınına nəzarət etmir: istifadəçi ümumi söhbətə yazır, model App-inizi nə vaxt çağıracağını qərar verir, siz isə yalnız öz “çərçivənizdə” cavab verirsiniz;
• Apps SDK çox şeyi öz üzərinə götürür: widget vəziyyətinin dialoq tarixçəsi ilə sinxronizasiyası, tool nəticələrinin emalı, MCP ilə iş və s.

Next.js baxımından bu olduqca tanış görünür: səhifələr/komponentlər, hook-lar, props-larınız var. Amma klassik fetch('/api/...') əvəzinə daha çox MCP serverdə təsvir olunmuş alətlərə (tools) və Apps SDK-ın xüsusi hook-larına (kursun sonrakı hissələrində) güvənəcəksiniz.

Mövzunu bir az konkretləşdirmək üçün layihəmizi xatırlayaq — şərti GiftGenius. Bu, parametrlərə görə hədiyyə seçməyə kömək edən App-dir: kimə, hansı məbləğə, hansı münasibətlə və s.

Gələcək UI-dan kiçik bir hissə (hələ SDK detallarına girmədən, sadəcə ideya kimi):

// GiftSummary.tsx — App-imiz üçün sadə React komponenti
type GiftIdea = {
  id: string;
  title: string;
  price: number;
};

interface GiftSummaryProps {
  ideas: GiftIdea[];
}

export function GiftSummary({ ideas }: GiftSummaryProps) {
  return (
    <ul>
      {ideas.map((idea) => (
        <li key={idea.id}>
          {idea.title} — ${idea.price}
        </li>
      ))}
    </ul>
  );
}

Sonra bu komponent ideas-ı havadan deyil, MCP server alətinin nəticəsindən (ToolOutput) alacaq, amma arxitektura səviyyəsində vacib olan budur: belə kod “ikinci lay”da yaşayır və yalnız vəziyyətin göstərilməsi ilə məşğuldur.

5. Lay 3 — MCP‑server: alətlər və məlumatlar dünyası

İndi daha aşağı — server tərəfinə enirik.

Model Context Protocol (MCP) — LLM müştərinin (ChatGPT, Apps SDK, Agents) serverinizlə necə danışdığını təsvir edən standartdır. Hansı alətlərin mövcud olduğunu, onların input/output sxemlərini, necə çağırılacağını və hansı əlavə resurslar/promptların yüklənə biləcəyini müəyyən edir.

Apps SDK üçün minimal MCP‑server üç şeyi bacarmalıdır:

• alətlərin siyahısını (List tools) onların JSON Schema-sı və meta-məlumatları ilə qaytarmaq;
• alət çağırışlarını emal etmək (Call tools) — call_tool sorğusunu qəbul etmək, biznes məntiqini icra etmək və strukturlu nəticə qaytarmaq;
• html, js, css, ... qaytarmaq — əgər tool ChatGPT-də göstərilməsi lazım olan konkret widget ilə bağlıdırsa.

Vacib məqam: MCP — nəqliyyatdan asılı olmayan protokoldur. ChatGPT Apps üçün bizi onun HTTP variantı və streamable reallaşdırması maraqlandırır, lakin nəqliyyat detalları və mesaj formatları artıq MCP modulunun (səviyyə 6) mövzusudur. Hazırda bilməyiniz kifayətdir ki, Apps SDK “aşağıda” məhz MCP‑serverə müraciət edir, hər hansı təsadüfi REST endpoint-lərinə deyil.

Arxitektura baxımından MCP layı tez-tez ayrıca bir mikroservis kimi görünür:

flowchart LR
    subgraph App["Sizin ChatGPT App-ınız"]
      W["Widget (Next.js + Apps SDK)"]
      M["MCP serveri (@modelcontextprotocol/sdk)"]
    end

    W <-- JSON-RPC over HTTP/SSE --> M
    M --> DB[(Hədiyyə kataloqu)]
    M --> EXT[Xarici API-lər]

MCP‑serverin içində artıq adi TypeScript/Node kodu yazırsınız, verilənlər bazalarından, növbələrdən, üçüncü tərəf API-lərdən istifadə edirsiniz və s. MCP üçün rəsmi TypeScript SDK JSON‑RPC serializasiyasını, sxemlərin validasiyasını və çağırışların marşrutlaşdırılmasını öz üzərinə götürür.

Bizim GiftGenius üçün MCP alətlərindən biri məsələn search_gifts adlana bilər. TypeScript səviyyəsində bu, adi funksiya kimi görünə bilər:

// Psevdo-kod: biznes məntiqi MCP serverin içində
export async function searchGifts(params: {
  recipient: string;
  budget: number;
}) {
  // burada artıq DB/kataloqa müraciət edirsiniz
  const items = await findGiftsInCatalog(params);
  return items.slice(0, 10);
}

Sonradan onu sxem təsviri ilə MCP tool-a bükəcəyik, amma əsas fikir: bu lay — “normal” backend-inizdir, sadəcə dünya ilə MCP vasitəsilə danışır.

6. Lay 4 — Agents SDK: mürəkkəb ssenarilərin beyni

Hər tətbiqə agentlər lazım deyil, amma ssenari “bir alət çağırışı — bir cavab” çərçivəsindən çıxan kimi agent layı çox faydalı olur.

Agent — əslində idarə olunan LLM prosesidir, o:

• istifadəçinin sorğusunu və dialoq tarixçəsindəki faktları oxuyur;
• addımların ardıcıllığını planlayır: hansı alətləri, hansı ardıcıllıqla, hansı arqumentlərlə çağırmaq;
• nəticələri analiz edir, “tool-u yenidən çağırmaq”, “istifadəçidən dəqiqləşdirmə istəmək”, “daha mürəkkəb cavab qurmaq” qərarlarını verə bilər;
• bəzən addımlar arasında vəziyyəti saxlayır (yaddaş, sessiyalar, checkpoint-lər — bu artıq səviyyə 12-dir).

Agents SDK belə ssenariləri strukturlu şəkildə təsvir etməyə imkan verir: hansı alətlər agent üçün əlçatandır, vəziyyət necə saxlanılır və bərpa olunur, dövrlər necə məhdudlaşdırılır və s. Agentlər backend daxilində işə salınır və OpenAI gücündən istədiyiniz kimi istifadə etməyə imkan verir: ChatGPT Apps widget məhdudiyyətləri olmadan.

Bizim stack kontekstində agent adətən backend daxilində MCP layı ilə domen API-ləriniz arasında oturur. O, xarici API-ləri, daxili funksiyaları və MCP alətlərini “əllər” kimi istifadə edə, özü isə “beyin”lə məşğul ola bilər.

Məsələn, GiftGenius ssenarisi belə görünə bilər:

1. İstifadəçi “ana üçün 50 $-a qədər hədiyyə seç” yazır.
2. ChatGPT tətbiqinizin search_gifts alətini çağırır.
3. search_gifts alətinin arxasında backend-də əvvəlcə bir neçə detalı dəqiqləşdirməyi qərar verən Agent dayanır (maraq sahələri, münasibət).
4. İstifadəçi əlavə istəkləri izah edir.
5. ChatGPT əlavə arqumentlərlə tətbiqinizin search_gifts alətini yenidən çağırır.
6. Serverdəki Agent əlavə alətləri çağırıb (məsələn, mövcudluq yoxlamaları) istifadə edə bilər.
7. ChatGPT-yə artıq hazırlanmış variantları və bəlkə də vizuallaşdırma üçün widget linkini qaytarır.

Kursun sonrakı hissəsində agentin run‑dövrünü, idempotentliyi və təhlükəsizliyi detaylı öyrənəcəyik, amma ümumi arxitektura üçün vacib olan: agent layı opsionaldır, lakin mürəkkəb orkestrasiyanı üzərinizdən götürən çox güclü “beyin”dir.

7. Lay 5 — ACP/Backend: pul, məlumat və “yer” qayğıları

Ən aşağı lay — sizin adi servisləriniz:

• verilənlər bazaları (məhsul kataloqları, istifadəçilər, sifarişlər);
• xarici API-lər (ödəniş provayderləri, logistika, üçüncü tərəf SaaS);
• ACP (Agentic Commerce Protocol) kimi commerce ssenariləri və Instant Checkout üçün ixtisaslaşmış protokollar.

ACP, ChatGPT və agentlərin commerce backend-inizlə necə ünsiyyət qurduğunu təsvir edir: SKU seçimi sorğuları, səbətin yaradılması, sifarişin rəsmiləşdirilməsi, geri qaytarmalar, uğurlu/uğursuz əməliyyatlar barədə webhook-lar və s.

GiftGenius üçün bu təxmini belə olacaq:

• MCP aləti search_gifts məhsul feed/DB-dən oxuyur;
• agent, konkret məhsulu seçəndə commerce niyyətini (ACP vasitəsilə) başladır;
• ACP ilə uyğun backend PaymentService-ə “pulu çəkirik” deyir, status barədə ChatGPT-yə məlumat verir;
• istifadəçi ChatGPT-də saytdan kənara çıxmadan sifarişin rəsmiləşdirildiyini görür.

Laylardan keçdiyimizə görə indi konkret end‑to‑end ssenariyə baxaq.

8. Skvoz ssenari: istifadəçi sorğusu bütün laylardan necə keçir

Sorğu götürək: “Anam üçün 50 dollaradək hədiyyə seç, o, oxumağı və çayı sevir”.

Addım-addım açaq.

1. İstifadəçi ChatGPT-yə mətn yazır. Bu, birinci lay — ChatGPT UI-dir. İstifadəçi üçün hər şey adi söhbət kimi görünür.
2. Model dialoq tarixçəsini, App-inizin metadata-sını (təsvirlər, kateqoriyalar, icazələr) oxuyur və GiftGenius-un uyğun namizəd olduğuna qərar verir. Apps SDK-da discovery qaydalarına əsasən model həm alətlərin mətn təsvirlərini, həm keçmiş istifadələri, həm konteksti, hətta brend qeydini nəzərə alır.
3. ChatGPT ya:
   • UI göstərmədən dərhal App-inizin alətini çağırır (tool‑first ssenari);
   • ya da cavabda belə təklif edir: “Mən GiftGenius-dan istifadə edərək hədiyyə seçiminə kömək edə bilərəm” və sizin tool-u çağırır.
4. ChatGPT search_gifts aləti üçün MCP‑serverə call_tool sorğusu göndərir. MCP‑server öz növbəsində biznes məntiqini icra edir: DB/feed-ə gedir, büdcə və üstünlüklərə görə filtrlayır və uyğun məhsulların siyahısı olan JSON qaytarır.
5. Alətin nəticəsi ChatGPT-yə qayıdır. O, bunu:
   • sadəcə mətn cavabı üçün məlumat kimi istifadə edə bilər (“Budur 3 hədiyyə ideyası...”);
   • və ya ToolOutput-u komponentinizə ötürərək widget-ı göstərib məhsul kartlarını render edə bilər.
6. Yalnız bu anda sizin GiftGenius widget-ınız (Apps SDK) işə düşür və Next.js kodunuz söhbətin içində render olunur. Widget, məsələn, belə bir forma göstərə bilər: “Hədiyyə kimə?”, “Büdcə”, “Maraq sahələri”. İstifadəçi düymələrə klikləyə və ya söhbətdə yazmağa davam edə bilər — model bunu App ilə sinxronlaşdıracaq.
7. Widget-a real məlumatlar (hədiyyə kataloqu) lazım olan kimi, o birbaşa fetch('https://my-backend/gifts') etmir. Bunun əvəzinə MCP tool çağırışını özü təşəbbüsləndirir: ChatGPT yenidən MCP‑serverə call_tool sorğusu göndərir — alət search_gifts.
8. Ssenari çoxmərhələlidirsə (dəqiqləşdirmə istəmək, reytinqləmək, əlavə mövcudluq yoxlamaları aparmaq, alternativlər təklif etmək lazımdırsa), agent layı planlama, workflow idarəsi və agentlərin orkestrasiyasını üzərinə götürür.
9. İstifadəçi konkret məhsulu “almaq” qərarına gələndə ChatGPT ACP protokolu ilə alışı başladır. Commerce backend ACP və Instant Checkout vasitəsilə əməliyyatı aparır, status barədə cavab verir, webhook-ları işə salır, ChatGPT isə istifadəçiyə yekun statusu göstərir (“Sifariş rəsmiləşdirildi, bu da qəbz”).

Proqramçı baxımından yaxşıdır ki, hər səviyyədə məsuliyyət sərhədləri aydındır. Üstəlik bütün laylar yeni standartlaşdırılmış protokollar (MCP, ACP) ilə birləşdirilib, köhnə yorucu REST sorğuları ilə deyil.

Bunların hamısı — məntiqi mənzərədir: hansı laylar var və sorğu onlar vasitəsilə necə axır. Sonra bizi fiziki tərəf maraqlandıracaq: bu laylar kodda və infrastrukturda necə yerləşdirilə bilər — bir Next monoliti kimi, yoxsa bir neçə servis şəklində (söhbət monolit vs mikroservislər arxitekturalarından getmir).

9. Next.js monolit vs bölünmüş arxitektura

İndi məntiqli sual: “Bütün bunlar mütləq bir yığın ayrıca servis olmalıdır? Mən sadəcə bir Next.js monolit etsəm, bəs etməz?”

Cavab: olar. Kursda sadədən mürəkkəbə doğru gedəcəyik. Başlanğıcda “demək olar ki, hər şeyi” bir repo-da və hətta bir runtime-da toplamaq tamamilə normaldır:

flowchart LR
    U[ChatGPT] --> W["Next.js App (Apps SDK)"]
    W --> M["MCP endpoint (elə həmin Next.js-də)"]
    M --> DB[(DB/kataloq)]

Yəni Next.js serveriniz (API routelar və ya ayrıca server) eyni anda:

• UI widget-ını (Apps SDK səhifələr/komponentlər) verir,
• MCP endpoint-i (HTTP üzərindən JSON‑RPC) reallaşdırır,
• DB/xarici API-lərə gedir.

Bu, dev rejimində və App-in ilk versiyaları üçün rahatdır: hərəkətli hissələr azdır, deploy daha sadədir.

Bununla belə, funksionallıq artdıqca layları ayırmaq üçün səbəblər yaranır:

• MCP‑server ayrıca miqyaslandırılmalıdır (çox ağır alətlər var);
• maliyyə backend-i öz domenində yaşayır, başqa komandalar tərəfindən idarə olunur, xüsusi təhlükəsizlik tələb edir;
• agent məntiqi ayrıca monitorinq və SLA ilə ayrıca tətbiq kimi ayrılmalıdır.

Onda şəkil artıq gördüyümüzə daha çox bənzəyir:

flowchart TD
    U[ChatGPT] --> W[Next.js + Apps SDK]
    W --> MG[MCP Gateway]
    MG --> M1[MCP Gifts Server]
    MG --> M2[MCP Analytics Server]
    M1 --> AG[Agent Service]
    AG --> ACP[Commerce/ACP Backend]

Burada MCP Gateway anlayışı əlavə olunur — ChatGPT üçün ümumi giriş. O, çağırışları müxtəlif MCP serverlərinə marşrutlaşdırır, REST API ilə işləyir, avtorizasiya, sorğu limitləri (rate limiting) və s. idarə edir.

Nümunələri daha monolit ssenaridən yazmağa başlayacağıq, amma kodu elə təşkil edəcəyik ki, sonradan onu nisbətən ağrısız şəkildə hissələrə bölmək mümkün olsun.

10. Kodu məhz harada yazacaqsınız (və nəyi başqalarına həvalə edirsiniz)

Layların monolit və ya paylanmış arxitekturada necə toplanacağını qeyd etdiyimizə görə, hansı yerlərdə kod yazacağınızı, nələri isə digər servis/komandalara buraxacağınızı dəqiq qeyd etmək faydalıdır.

TypeScript/Next.js inkişaf etdiricisi kimi hansı zonalara nəzarət etdiyinizi birbaşa qeyd etmək faydalıdır.

Widget-da (Apps SDK + Next.js) siz:

• alətlərin vəziyyətini və istifadəçi daxilini göstərən React komponentləri yazırsınız;
• Apps SDK hook-larından istifadə edərək ToolInput/ToolOutput və widget vəziyyətini (widget state) oxuyursunuz;
• vizual rejimi (inline/fullscreen/PiP, mövzular, ölçülər — bu 8-ci səviyyədə olacaq) tənzimləyirsiniz;
• daha qabaqcıl ssenarilər üçün window.openai vasitəsilə ChatGPT ilə qarşılıqlı əlaqə qurursunuz (kursun ayrıca modulunda).

MCP‑serverdə siz:

• MCP SDK ilə tools/resources/prompts təsvir edirsiniz;
• alətlərin biznes məntiqini reallaşdırırsınız (mahiyyətcə DB, API və s. ilə işləyən adi TypeScript funksiyaları);
• sxemləri və cavabları modelin rahat oxuya biləcəyi kimi optimallaşdırırsınız (az səhv, daha çox strukturlaşdırma).

Agent layında (Agents SDK istifadə edirsinizsə) siz:

• agent üçün hansı alətlərin əlçatan olduğunu və onun məqsədlərini təsvir edirsiniz;
• run‑dövrünü, yaddaşı, dövrə nəzarəti tənzimləyirsiniz;
• agentin səhv iş görməməsinə və sonsuz planlaşdırmaya düşməməsinə nəzarət edirsiniz.

ACP/backend-lərdə siz:

• ya mövcud commerce servisləri ilə inteqrasiya edirsiniz (Stripe, product feed-li öz mağazanız və s.);
• ya da ACP-ni anlayan, sifariş qəbul edib qaytara bilən yeni backend layihələndirirsiniz.

Vacibdir: yetkin məhsulda eyni insan nadir hallarda bütün laylara tam sahib olur. Amma prototip mərhələsində (və bu kursda) ən azından hansı kodun harada yaşadığını başa düşəcəyinizi ümid edirik.

11. Arxitektura UX-ə və platforma siyasətinə necə təsir edir

UX və siyasətlər ayrıca modullardır, amma arxitektura səviyyəsində seçdiyiniz lay bölgüsünün UX-ə və platforma tələblərinə necə təsir edəcəyini indi başa düşmək vacibdir. Buna görə qabaqcadan bir neçə qeydi edək.

Birincisi, sandbox. Widget internetdə sərbəst gəzişib istifadəçi məlumatlarını toplamaz — hər şey nəzarət olunan alətlər və MCP/Store-da təsvir edilmiş icazələr vasitəsilə gedir. Platforma App-inizə hansı məlumat və hərəkətlərin lazım olduğunu dürüst şəkildə təsvir etməyinizi gözləyir və App discovery/təklifləri bu təsvirlərə əsaslanacaq.

İkincisi, UX axını. Model bəzən müvəqqəti olaraq App-inizi “unudur” və ya əksinə onu həddən artıq aqressiv təklif edir, buna görə arxitektura kəsilmələrə dözümlü olmalıdır: əgər agent uzun workflow-u bitirə bilmədi və istifadəçi mövzunu dəyişdi, tətbiq bunu sakit keçirməlidir. Kursda çoxmərhələli ssenarilər və workflow orkestrasiyası məhz MCP alətləri və agent layı üzərində qurulacaq.

Üçüncüsü, satış. App pul almağa başlayar-başlamaz əlavə təhlükəsizlik, jurnallaşdırma, ACP müqavilələri və s. tələblər qüvvəyə minir. Layları (UI, MCP, Agents, ACP/Backend) necə böldüyünüz Store‑review və təhlükəsizlik auditindən keçməyinizin nə dərəcədə ağrılı olacağına ciddi təsir göstərir.

İlk nəticələr

Ümid edirəm, başınızda icmal xəritəsini qurdunuz:

• yuxarı laylar (ChatGPT UI + Apps SDK) istifadəçinin App-inizi necə gördüyünü və hiss etdiyini müəyyənləşdirir;
• orta lay (MCP) — modelə alətlər və məlumat verməyin standart yoludur;
• agent və commerce layları App-inizi sadəcə “məlumat baxıcı” yox, məntiq və pulla tamhüquqlu məhsula çevirir.

İkinci səviyyədə ən maraqlısından başlayacağıq: Next.js əsasında rəsmi Apps SDK şablonunu endirəcəyik, onu lokalda işə salacağıq və Dev Mode-da ChatGPT-yə qoşacağıq. Yəni ilk növbədə Apps SDK/widget qatını əllə yoxlayacağıq, MCP/agentlər isə hələ ya stub, ya da daxili backend kimi yaşayacaq.

Amma mövcud sxemi indi də başınızda saxlamaq vacibdir: sanki monorepo-ya baxırsınız və anlayırsınız ki, apps/ — UI-dir, services/mcp — protokoldur, services/agent — orkestratordur, və services/commerce — puldur.

12. Stack arxitekturasını anlamaqda tipik səhvlər

Səhv №1: ChatGPT App = sadəcə “mənim REST API-mə webhook” hesab etmək.
“Botlar” dünyasından vərdişlə belə etmək olar: guya model sadəcə POST sorğuları mənim URL-imə göndərir, sonrası “necə alındısa”. Reallıqda model və kodunuz arasında Apps SDK və MCP dayanır. Siz alətləri, onların sxemlərini və davranışını təsvir etməlisiniz, sadəcə “istənilən” HTTP sorğularını “dinləməməlisiniz”.

Səhv №2: UI və biznes məntiqi laylarını qarışdırmaq.
Populyar anti‑pattern — mürəkkəb domen məntiqini birbaşa widget-a daşımaq, MCP layını isə nazik qat kimi saxlamaq. Nəticədə UI ağırlaşır, test etmək çətinləşir və ChatGPT xaricində yenidən istifadə üçün yararsız olur. Qaydaları və məlumat çıxışını MCP/agent səviyyəsində saxlamaq, widget-ı isə sırf göstərmə və sadə interaktivlə məşğul etmək daha dayanıqlıdır.

Səhv №3: MCP-ni görməzdən gəlib “öz protokolunu” yazmaq.
Bəzən belə bir cazibə yaranır: “mənə MCP lazım deyil, sadəcə JSON qaytararam, model özü anlayar”. Qısa demoda bu “işləyə” bilər, amma dərhal MCP və Apps SDK-nın “qutudan hazır” verdiyi discovery, inspeksiya, avtorizasiya və çoxmüştərili dəstək imkanlarını itirirsiniz.

Səhv №4: Bütün App-i bir layın ətrafında qurmaq.
Kimsə “hər şeyi agentdə” edir, agenti çox məsuliyyətlərlə yükləyir. Başqası əksinə hər şeyi MCP alətlərinə sığdırmağa çalışır. Kimisi nəhəng Next.js monoliti qurur. Daha düzgünü hər layın öz məsuliyyət zonasını qəbul etməkdir: UI — göstərmə, MCP — məlumat/axtarış və hərəkətlərə çıxış, agent — orkestrasiya, ACP/Backend — domen invariyantları və pul.

Səhv №5: Arxitekturanın Store‑review və təhlükəsizliyə təsirini kiçiltmək.
Əgər tək bir serveriniz həm MCP endpoint-dir, həm ACP resursudur, həm sirləri saxlayır, həm də hər şeyi “necə varsa” jurnala yazırsa — təhlükəsizlik və məzmun siyasəti üzrə review uzana bilər. Aydın sərhədlər və protokollarla bölünmüş arxitektura gec mərhələlərdə həyatı xeyli asanlaşdırır.