PHP je preživio dovoljno ciklusa pomodnih trendova da poduči važnoj lekciji: trajni pozadinski sustavi rijetko se grade oko modernog sintaksnog stila. Grade se oko jasnih granica, predvidivog ponašanja pri neuspjehu i operativnih odluka koje ostaju razumljive kada se tim, promet i zahtjevi promijene.

Zbog toga je PHP koristan okvir za dizajn API-ja. Njegove prednosti nisu tajanstvene: zrelo izvršno okruženje, široka podrška za hosting, sposobni radni okviri, snažne integracije s bazama podataka i nizak prag za čitanje postojećeg koda. No te prednosti postaju otpornost tek kada se aplikacija namjerno raščlani na odgovornosti koje se mogu neovisno razvijati.

Započnite s granicama, a ne krajnjim točkama

API može izgledati dobro dizajnirano, a pritom tiho povezivati HTTP pojedinosti, validaciju, poslovna pravila, perzistenciju i pozive prema trećim stranama unutar jednog kontrolera. Može funkcionirati sve do prve značajne promjene: novog klijenta, vremenskog ograničenja pružatelja plaćanja, upita za izvještavanje ili migracije baze podataka.

Oblik koji se lakše održava odvaja granicu zahtjeva od rada aplikacije. Kontroleri bi trebali prevoditi HTTP u naredbu aplikacije, pozvati slučaj upotrebe i rezultat ponovno prevesti u HTTP. Ne bi trebali odlučivati kako se narudžba određuje cjenovno ni koje se tablice moraju promijeniti.

final class CreateOrderController
{
    public function __construct(private CreateOrder $createOrder) {}

    public function __invoke(Request $request): Response
    {
        $input = CreateOrderInput::fromArray($request->validated());

        $order = $this->createOrder->handle($input);

        return Response::json([
            'id' => $order->id(),
            'status' => $order->status(),
        ], 201);
    }
}

Slučaj upotrebe tada može koordinirati domenska pravila i repozitorije bez znanja o tome je li pozivatelj HTTP klijent, radnik reda ili zadatak naredbenog retka. To nije arhitektura radi arhitekture. Smanjuje trošak promjene jer značajna pravila imaju stabilno mjesto.

Učinite neuspjeh prvoklasnim odgovorom

Većina problema s API-jima pojavljuje se na rubovima: neispravan unos, istekle vjerodajnice, duplikati slanja, nedostupne ovisnosti i spori upiti. Otporan API tretira ih kao uobičajena radna stanja, a ne kao iznimna iznenađenja.

Validacija pripada blizu granice zahtjeva. Vratite dosljednu pogrešku klijenta kada se unos ne može obraditi, a pogreške poslužitelja rezervirajte za neuspjehe koje klijent ne može ispraviti. Jednako je važno da u produkcijskim odgovorima ne izlažete tragove stoga, SQL fragmente ni interne poruke iznimki.

Za operacije koje stvaraju ili mijenjaju stanje, idempotentnost zaslužuje posebnu pažnju. Klijent može pokušati ponovno nakon prekida mreže čak i ako je poslužitelj dovršio izvorni zahtjev. Ako bi dvostruko stvaranje plaćanja ili narudžbe bilo štetno, prihvatite ključ idempotentnosti, pohranite dovršeni rezultat uz taj ključ i vratite isti rezultat za ponovljeni zahtjev.

• Upotrebljavajte jasne statusne kodove koji odražavaju ishod.
• Vratite stabilnu strukturu pogreške koju klijenti mogu raščlaniti.
• Zabilježite identifikator korelacije uz neuspjehe i, prema potrebi, uključite ga u odgovor.
• Postavite vremenska ograničenja za odlazne HTTP, bazne i redne interakcije.
• Ponavljajte samo operacije koje je sigurno ponoviti, uz ograničen broj pokušaja.

Ponovni pokušaj bez vremenskog ograničenja može kratkotrajni problem s ovisnošću pretvoriti u iscrpljeni skup radnika. Ponovni pokušaj bez idempotentnosti može udvostručiti rad. Otpornost nije refleksno „pokušaj ponovno”; ona je promišljen ugovor o tome što se događa kada je prvi pokušaj neizvjestan.

Budite pošteni prema radu s bazom podataka

Baze podataka su mjesto gdje se prividna jednostavnost API-ja susreće sa stvarnom konkurentnošću. PHP aplikacije trebale bi koristiti parametrizirane upite ili ORM-ove mogućnosti sigurnog vezivanja, definirati ograničenja baze podataka za invarijante koje se nikada ne smiju prekršiti te eksplicitno odrediti granice transakcija.

Razmotrite rezervaciju zaliha. Čitanje dostupne zalihe, njezino smanjenje i stvaranje rezervacije moraju ili uspjeti zajedno ili propasti zajedno. Transakcija je nužna, ali nije dovoljna ako dva zahtjeva mogu oba pročitati istu dostupnu količinu prije nego što bilo koji od njih upiše promjenu. Dizajn može zahtijevati zaključavanje redaka, atomsko uvjetno ažuriranje ili optimističku konkurentnost sa stupcem verzije.

UPDATE inventory
SET available = available - :quantity
WHERE product_id = :product_id
  AND available >= :quantity;

Ako je broj zahvaćenih redaka nula, aplikacija može prijaviti da zaliha nije dostupna. Ovaj pristup izražava poslovni uvjet u samoj operaciji, izbjegavajući krhki slijed čitanja pa pisanja.

Transakcije bi također trebale biti kratke. Nemojte držati transakciju baze podataka otvorenom dok pozivate udaljenu uslugu ili generirate veliko izvješće. Potvrdite lokalno stanje, a zatim predajte nekritični naknadni rad putem trajnog reda ili eksplicitnog obrasca izlaznog spremnika. Točan mehanizam varira, ali načelo ostaje: lokalna dosljednost i udaljena isporuka različiti su problemi.

Dizajnirajte za implementaciju, a ne samo za razvoj

Docker može olakšati dosljedno pokretanje PHP usluge, ali samo kada slika odražava produkcijsku stvarnost. Ovisnosti za izgradnju trebale bi se, kada je praktično, odvojiti od izvršnog okruženja, konfiguracija bi trebala dolaziti kroz okruženje ili upravljani sustav konfiguracije, a zapisivi direktoriji tijekom izvršavanja trebali bi biti namjerni.

Kontejnerizacija aplikacije ne uklanja potrebu za operativnom disciplinom. Procesu su potrebni strukturirani zapisnici, provjere zdravlja koje odražavaju njegovu sposobnost posluživanja smislenog prometa i uredno ponašanje pri gašenju. Potrošačima reda potrebna je strategija za dovršavanje ili oslobađanje rada u tijeku kada spremnik primi signal za prekid.

Konfiguracija zaslužuje jednaku pažnju kao i kod. Držite tajne izvan kontrole izvornog koda i izvan slika spremnika. Validirajte obaveznu konfiguraciju pri pokretanju kako bi nedostajući URL baze podataka ili ključ za šifriranje jasno zakazao, umjesto da pri prvom zahtjevu proizvede zbunjujuće pogreške.

Mjerite prije „optimiziranja”

Rad na performansama PHP-a najkorisniji je kada započne putanjom zahtjeva i dokazima. Spore krajnje točke najčešće proizlaze iz nepotrebnih povratnih putovanja do baze podataka, nedostajućih indeksa, prevelikih korisnih tereta, ponovljenih udaljenih poziva ili rada koji bi se trebao odvijati asinkrono. Zamjena čitljivog koda domišljatim kodom rijetko rješava stvarno usko grlo.

Profilirajte reprezentativna radna opterećenja, pregledajte broj i trajanje upita te uspostavite proračun latencije za važne krajnje točke. Zatim poboljšajte skupi dio. Predmemoriranje može pomoći, ali uvodi pitanja invalidacije, dosljednosti i kapaciteta. Predmemorirajte podatke s jasnim vlasnikom, definiranim vijekom trajanja i sigurnim zamjenskim rješenjem kada predmemorija nije dostupna.

U mnogim sustavima najbolje poboljšanje performansi jest uklanjanje rada: vratite samo potrebna polja, stranicite kolekcije, izbjegavajte učitavanje neiskorištenih odnosa i premjestite neinteraktivnu obradu iz putanje zahtjeva.

Učinite bazu koda lakom za sigurnu promjenu

Održivost je značajka API-ja, čak i ako je nijedan klijent ne vidi izravno. Tim koji može sigurno razumjeti i mijenjati uslugu može odgovoriti na sigurnosne probleme, potrebe kupaca i operativne neuspjehe bez pretvaranja svakog izdanja u kockanje.

Koristite tipove tamo gdje prenose namjeru, imenujte operacije prema poslovnim radnjama i zadržite konvencije radnog okvira u vanjskom sloju, umjesto da dopustite da definiraju svaki dio domene. Testovi bi se trebali posebno usredotočiti na odluke s posljedicama: autorizaciju, određivanje cijena, prijelaze stanja, validaciju i rukovanje neuspjesima. Integracijski testovi trebali bi provjeriti slažu li se aplikacija i baza podataka oko važnih ograničenja.

Trajna vrijednost PHP-a nije u tome što izbjegava složenost. Ona je u tome što timovima omogućuje postupno rješavanje složenosti. Gradite API-je s malim, eksplicitnim spojevima; učinite neuspjehe predvidivima; zaštitite podatke stvarnim ograničenjima; i mjerite putanje o kojima korisnici ovise. Trendovi će proći. Sustav dizajniran na ovaj način i dalje će biti razumljiv kada se to dogodi.