Skip to main content

Specifikace backendové služby

Interní otevření WebUI (režim Unix Socket)

Spustitelný soubor backendu je nainstalován v:

/usr/local/<app_id>/bin/<binary_name>

Backend musí vytvořit a naslouchat na Unix Socketu:

/var/api/<app_id>.sock

Požadavky:

  1. Pokud /var/api neexistuje, musí být automaticky vytvořen.
  2. Staré soubory socketu musí být před spuštěním vyčištěny.
  3. Oprávnění souboru socketu musí umožňovat přístup platformového proxy.
  4. Protokol rozhraní backendu je HTTP přes Unix Socket.
  5. Backend by měl řádně zpracovávat SIGTERM pro zastavení služby systemd.

Specifikace standardních logů:

Úroveň loguPoužití
ERRORSelhání služby, chyby při spuštění, poškození dat
WARNZastaralé funkce, obnovitelné chyby, problémy s konfigurací
INFOUdálosti životního cyklu služby (spuštění/ukončení), informace o verzi, načtená konfigurace
DEBUGPodrobné diagnostické informace — logy úrovně DEBUG musí být v produkčním prostředí zakázány, používají se pouze při vývoji a ladění

Standardní formát výstupu:

[YYYY-MM-DD HH:MM:SS] [LEVEL] [component] message

Příklad:

[2026-05-11 16:30:00] [INFO] [main] Service started on port 8686

U služeb spravovaných systémem systemd upřednostňujte výstup logů na stdout/stderr — systemd journal automaticky zachytává obojí.

Omezení automatického restartu při pádu služby
  • Maximální počet pokusů o restart: 5krát během 60 sekund
  • Po překročení limitu přejde služba do stavu selhání
  • App Center po překročení limitu restartu zobrazí službu jako „Abnormal" (nenormální)
  • Parametry StartLimitBurst=5 a StartLimitIntervalSec=60 musí být výslovně nakonfigurovány v souboru služby systemd.

Externí otevření WebUI (režim HTTP port)

Spustitelný soubor backendu je nainstalován v:

/usr/local/<app_id>/bin/<binary_name>

Backend přímo naslouchá na <listen_port> a poskytuje HTTP rozhraní.

Požadavky:

  1. Přímo naslouchat na <listen_port>.
  2. Obsluhovat statickou domovskou stránku WebUI.
  3. Poskytovat endpoint pro kontrolu stavu (health check).
  4. Poskytovat trasy obchodní logiky API; konkrétní obchodní logiku definuje aplikace.
  5. Řádně zpracovávat SIGTERM a SIGINT.

Doporučené pevné trasy:

GET /
GET /health

Doporučené pojmenování obchodních API:

/api/<resource>

Pro kompatibilitu se systémovým vstupním bodem lze současně podporovat také:

/<app_id>/api/<resource>
/v2/proxy/<app_id>/<resource>
/v2/proxy/<app_id>/api/<resource>