Předání dat mezi serverama

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Webster.K
Člen | 212
+
0
-

Zdravím všechny, řeším předávání dat mezi dvěma serverama (na obou nette a MySQL DB). Potřebuju na jednom serveru vytvořit formulář, který má dva selectboxy, ten druhý závislý na výběru toho prvního… každopádně do obou potřebuji dostat data z databáze na druhém serveru. Jde to nějak jednoduše udělat? Nechce se mi totiž mít několik identických tabulek ve dvou databázích, protože když v jedné něco měním, budu to muset měnit i na druhém a mohlo by mi dojít k tomu, že nebudu mít stejné výchozí data :/ napadá někoho jak toho docílit?

johnnie
Člen | 54
+
0
-

imho, jedine ze si spravis nejake API a ktore ti vrati napr. JSON s polozkami ktore pojdu do selectu

igor.pocta
Člen | 100
+
0
-

Můžeš si vytvořit REST API :)

Asi záleží na situaci. Např. na nekritické aplikaci bych to řešil tak, že bych druhou tabulku synchronizoval, např. nočním cronem, protože druhý server nemusí být vždy dostupný :)

Editoval igor.pocta (2. 8. 2017 15:26)

Webster.K
Člen | 212
+
0
-

Ta tabulka synchronizovat by asi šla :) problém je v tom, že formulář který to bude, bude mít na starosti několik dalších věcí, mimo jiné i zápis do předchozího serveru do jedné z tabulek. Popřípadě nápad jak to odeslat na jiný server? Napadlo mě metodou GET/POST a pak si to parsovat, nicméně se tak musí stát napozadí a zpětně když se vše uloží zpět ukázat že je vše ok :/ Problém je že oba systémy si v hodně věcech jsou podobné, mají stejné části ale nemohou běžet společně. Problém je v tom, že nechci klienty z jedné domény směřovat jinam, budou se přihlašovat už takhle na tomto webu, zase na druhou stranu „zaměstnanci“ mají oddělený portál kde se řeší objednávky a dalších X věcí najednou… a já potřebuju z té části pro klienty, když vytvoří objednávku to dostat do druhého systému aby o tom „zaměstnanci“ věděli :/ takže realtime komunikace v ideálním případě, když to bude třeba o 5 minut později, problém to také není.

igor.pocta
Člen | 100
+
0
-

Webster.K napsal(a):

Ta tabulka synchronizovat by asi šla :) problém je v tom, že formulář který to bude, bude mít na starosti několik dalších věcí, mimo jiné i zápis do předchozího serveru do jedné z tabulek. Popřípadě nápad jak to odeslat na jiný server? Napadlo mě metodou GET/POST a pak si to parsovat, nicméně se tak musí stát napozadí a zpětně když se vše uloží zpět ukázat že je vše ok :/ Problém je že oba systémy si v hodně věcech jsou podobné, mají stejné části ale nemohou běžet společně. Problém je v tom, že nechci klienty z jedné domény směřovat jinam, budou se přihlašovat už takhle na tomto webu, zase na druhou stranu „zaměstnanci“ mají oddělený portál kde se řeší objednávky a dalších X věcí najednou… a já potřebuju z té části pro klienty, když vytvoří objednávku to dostat do druhého systému aby o tom „zaměstnanci“ věděli :/ takže realtime komunikace v ideálním případě, když to bude třeba o 5 minut později, problém to také není.

Něco podobného v současné době taky začínám řešit. Administraci mám na interním serveru kvůli citlivým údajům ale na webhostingu mám portál pro veřejnost (budoucí zaměstnanci).

Připravil jsem si na to RESTí API a když uložím v interní administraci zaměstnance, tak se to zároveň přenese na webhosting a naopak.
**V poslední době si ale říkám, co když to spojení spadne a na každém serveru budou rozdílná data ?!? ** Nemá s tím někdo zkušenosti?

Webster.K
Člen | 212
+
0
-

To já teprve REST API začal Googlit :D každopádně to vypadá jako přesně to, co potřebuji… otázka je co se stane v případě, že server na který se odesílá POST bude nedostupný, jasně, klientovy by se to mělo dát vědět, ale při delším výpadku to člověk víckrát vyplňovat chtít nebude a pak nastane problém :/

iguana007
Člen | 970
+
0
-

Webster.K napsal(a):

To já teprve REST API začal Googlit :D každopádně to vypadá jako přesně to, co potřebuji… otázka je co se stane v případě, že server na který se odesílá POST bude nedostupný, jasně, klientovy by se to mělo dát vědět, ale při delším výpadku to člověk víckrát vyplňovat chtít nebude a pak nastane problém :/

Ukladej si to do te lokalni databaze s nejakym privlastkem, treba is_sent 1 nebo 0, podle toho, zda-li se to povede odeslat nebo ne. Nasledne nezpracovane udaje muzes ad hoc odeslat treba cronem jednou denne vecer.

Rob Bob
Člen | 60
+
+2
-

A proč si prostě nevytvoříš druhé přímé připojení k té druhé databázi?

Webster.K
Člen | 212
+
0
-

Protože se k tý databázi dá přistoupit jen přes localhost, není veřejná a navíc nechci aby ten druhý systém měl přístup k celé databázi ale jen ke třem tabulkám max… a protože každá má svou registraci tedy své uživatele kteří přistupují k věcem jen a pouze v tom daném systému

matopeto
Člen | 395
+
0
-

A co pouzit klasicku replikaciu databaze (master/slave) … viac info na googlu podla vaseho databazoveho serveru.

EDIT: tak citam vyssie, ze ta druha databaza nie je dostupna, tak to asi nepojde… jedine ze pretunelovat :)

Pri reste nezabudnut na dobre zabezpecenie, aby nikto kto ten rest odchyti vedel pridavat do vasej databaze :)

Editoval matopeto (4. 8. 2017 10:59)

Webster.K
Člen | 212
+
0
-

Obě ty databáze běží na webhostingu (wedos), myslím že mi nepovolí se jim pošťourat v nastavení :D :D :D :D :D proto to nepůjde :/ a koukám na to REST API – nemá někdo návod jak to co nejjednodušeji dát dohromady aby to odesílalo požadavky? Našel jsem pro nette nějaký plugin (drahak/Restful) ale přijde mi zbytečně složitý… mimo to jsem našel někde nějaký článek kde celé řešení je přes sendResponse() viz: https://blog.venca-x.cz/…st-api-json/

Vypadá to jednoduše, ale nevím jak zaručím, že to bude alespoň trochu zabezpečené, ty POST věci co chci odeslat (skupina čísel a datetime), musím nějak zabezpečit, aby si vesele nemohl přidávat každý, nicméně jak vyřešit když někdo zachytí tu post žádost? To pak si může přidávat dle libosti ne?

matopeto
Člen | 395
+
+1
-

zabezpecit mozes napriklad tak, ze na jednom serveru podpises data privatnym klucom a na druhom ich pomocou public klucu overis. Pokial ti nikto neukradne privatny kluc tak si v suchu…

Editoval matopeto (4. 8. 2017 16:04)