Názory k článku Použití message brokeru NATS

Jenom drobné upřesnění 3. kapitoly, v Go se jako odkaz na balík (nats.Publish()) nepoužívá poslední část cesty z importu, ale samotný název cílového balíku. Podle konvence se v naprosté většině tyto názvy shodují, ale jsou i výjimky. Jednou z nich je i NATS klient, který má cestu "github.com/nats-io/go-nats", ale název balíku je jen "nats". Z tohoto důvodu je použití aliasu "nats" zbytečné a naopak při použití odkazu go-nats by se balík nenašel.

jj to jsem napsal nesrozumitelně, opravím to, aby to bylo jasnější. Díky za upozornění.

opraveno

Omlouvám se autorovi, ale po opětovném přečtení bych ještě přidal jednu poznámku. Podle mne se trochu v příkladech ztratily dvě skutečnosti.

1. Standardní conn vytvořený přes nats.Connect(...) umí zasílat jen pole bytů. Nad ním lze vytvořit EncodedConnection, kterému se jako parametr předá typ zakódování zprávy (typicky třeba JSON nebo Protocol Buffers) a spojení je automaticky serializováno a deserializováno, přičemž lze oba dva typy spojení na klientu a serveru libovolně kombinovat, pokud zajistíte potřebnou odpovídající serializaci/de­serializaci.

2. Příjemce zpráv může zprávy zpracovávat asynchronně nebo synchronně. V uvedeném příkladu přes callback se jedná o asynchronní zpracování, u synchronního si sami vyzvedáváte novou zprávu. V tomto případě je udržována fronta zpráv, kde můžete zjišťovat (případně nastavovat) její délku. V tomto ohledu je zpracování přes kanál synchronní.

To je naprosto v pořádku a já naopak moc děkuji za doplnění. K bodu 1 bude příště několik příkladů, především klasický Protocol Buffers (to je velmi užitečná věc, dobrá alternativa asi ke třem pokusům o "binární JSON")