Çfarë janë LISTEN dhe NOTIFY?

Question

Accepted Answer

**`LISTEN`** dhe **`NOTIFY`** ofrojnë një sistem të integruar **publish/subscribe** të mesazheve në PostgreSQL — një sesion mund të dërgojë një noftim në një kanal, dhe sesionet e tjera që dëgjojnë në atë kanal e marrin atë menjëherë. Është një mënyrë e lehtë për të shtyrë ngjarje në kohë reale nga baza e të dhënave pa sondim.

## Mekanizmi themelor

```sql
-- a session SUBSCRIBES to a channel
LISTEN order_created;

-- another session/transaction PUBLISHES a notification (with an optional payload)
NOTIFY order_created, 'order id 123';
-- → all sessions listening on 'order_created' receive the message immediately
```

LISTEN abonohet në një kanal; NOTIFY publikon në të (me një ngarkesë teksti opsionale). Dëgjuesit marrin njoftim në mënyrë asinkrone — nuk ka nevojë për sondim.

## Aktivizimi i NOTIFY automatikisht (një model i zakonshëm)

```sql
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_created', NEW.id::text);   -- notify with the new id
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_notify AFTER INSERT ON orders
  FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
```

Ndërthurja e NOTIFY me një **trigger** lejon bazën e të dhënave të shtyjë ngjarje automatikisht kur të dhënat ndryshojnë (porosi e re, përditësim statusi) — serverët e aplikacionit që dëgjojnë në kanal reagojnë në kohë reale.

## Si e përdorin aplikacionet

```text
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
```

## Kufizimet për të njohur

```text
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
  (no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
  proper broker (RabbitMQ, Kafka) or a queue table.
```

## Pse ka rëndësi

`LISTEN`/`NOTIFY` është një veçori e dobishme, disi më pak e njohur e PostgreSQL që ofron **sisteminë integruese pub/sub të mesazheve**, e vlerëshme për shtimin e **reaktivitetit në kohë reale** në aplikacione pa sondim.

Vlera bazë është mundësimi i bazës së të dhënave të **shtyjë ngjarjet** në sesionet e aplikacionit që dëgjojnë menjëherë kur ndodh diçka (porosi e re, ndryshim statusi) — zakonisht kombinohet me **triggers** në mënyrë që ndryshimet e të dhënave të njoftojnë automatikisht dëgjuesit, të cilëve serverët e aplikacionit u përgjigjen (shtyrje në websockets, pavlefshmëri i cache-jes, përllogaritje e punës në sfond).

Kjo është e vlerëshme sepse ofron sjellje në kohë reale të drejtuar nga ngjarjet pa pasaktësinë e **sondimit** të bazës së të dhënave përsëritje për të kontrolluar ndryshimet (një model i zakonshëm, i dëmshëm që LISTEN/NOTIFY e zëvendëson me elegancë).

Përkuptimi i mekanizmit (LISTEN për të u abonuar, NOTIFY për të publikuar, me triggers për njoftim automatik në ndryshimet e të dhënave) dhe si e përdorin aplikacionet (dëgjim për ngjarje për të drejtuar reaksionet në kohë reale) është e dobishme për ndërtimin e aplikacioneve përgjegjëse dhe të drejtuar nga ngjarjet duke përdorur vetëm PostgreSQL.

Njësoj i rëndësishëm është njohja e **kufizimeve**: njoftimet **nuk ruhen** (humben nëse askush nuk dëgjon — pa garantitë qëndrueshmërie), kanë ngarkesa të vogla, dhe zjarrin vetëm pas përputhjes — pra është i përshtatshëm për sinjalizim të lehtë në kohë reale, *jo* zëvendësim për një broker mesazhi të qëndrueshëm (RabbitMQ, Kafka) kur besueshmëria dhe përqendrueshmëria kanë rëndësi.

Meqenëse reaktiviteti në kohë reale është një nevojë e zakonshme dhe LISTEN/NOTIFY ofron një mënyrë të integruar, pa sondim për të arritur atë për rastet e lehta, kuptimi i tij — mekanizmi pub/sub, modeli i trigger, dhe në mënyrë vendimtare kufizimet e tij (kur mjafton kundrejt kur kërkohet një broker i vërtetë) — është njohuri e dobishme, praktike PostgreSQL për ndërtimin e aplikacioneve të drejtuar nga ngjarjet, një veçori e integruar e dobishme që shpesh injorohet.