Witam
W ramach nauki chce stworzyć system do zarządzania sklepami. Każdy sklep działa lokalnie i posiada swoją własną baze danych z asortymentem. Czy moge stworzyć Web API, które będzie komunikować się z tymi sklepami w celu pobierania danych i wyświetlania ich na stronie? W jaki sposób mam połączyć oba serwery które działają w innych sieciach - TCP/IP? 
0
3
Jak sama nazwa WebAPI wskazuje - po http. Jeśli TCP/IP to wtedy nie WebAPI. Jeśli ma znaczenie (moim zdaniem powinno mieć), który towar jest, z którego sklepu to powinieneś do pobranych danych dorzuć jakąś informację.
{
shop: 'Local shop 1',
products: [ ]
}
Pobieranie danych działałoby tak jak na ecommerce, w Web app użytkownik klika w asortymenty/towary/produkty, ty odpytujesz (głównym API) każde WebAPI sklepów, łączysz w jedną listę podzieloną na sklep lub 4 osobne listy w jednym obiekcie i puff, gotowe.
Jest jedna wada tego rozwiązania - główne WebAPI musi znać adresy publiczne każdego WebAPI sklepu. Komunikacja odbywa się GŁÓWNE => SKLEPY i tylko w tym kierunku. Jeśli chcesz po TCP/IP, to tutaj już nie pomogę, ale wiem, że komunikacja mogłaby działać w obie strony - GŁÓWNE <==> SKLEPY, ale wolałbym żeby ktoś mądrzejszy się wypowiedział w tej kwestii....
3
Komunikacja nie-HTTP to np Apache Thrift albo gRPC.
jaros555 napisał(a):
Witam
W ramach nauki chce stworzyć system do zarządzania sklepami. Każdy sklep działa lokalnie i posiada swoją własną baze danych z asortymentem.
W jakim sensie użyłeś słowa "lokalnie" ? W serwerowni, w firmie hostujacej, tylko blokowane prze firewall ?
Wielopoziomowe Web API wprowadza kilka wad
a) niezawodność. Jesli pojedyncze ma 99%, to dwa już 98.
b) do tego by trzeba dać jakiś mądry "bezpiecznik" czyli curcuit breaker
c) opóźnienie, jesli to 100 uS na każdy itd...
Jak być poszukał inspiracji od ludzi z kręgu mikroserwisów, to w pewnym momencie preferuje się asynchroniczne (komunikaty, kolejki) niż synchroniczne (HTTP i podobne)
jaros555 napisał(a):
Czy moge stworzyć Web API, które będzie komunikować się z tymi sklepami w celu pobierania danych i wyświetlania ich na stronie?
Chciałbym wierzyć *), że chcesz coś racjonalnego, tylko nie umiesz "domyśleć" tego do końca. Kto byłby konsumentem tego "nadrzędnego" Web API ? Dlaczego nie może to być normlany wewnętrzny kawałek kodu (in-process), jakiś Proxy, Adapter czy coś w tym stylu ?
*) nawet i to, ze w/w zdanie jest strasznie chropowate, niby coś mówi, ale w gruncie tylko rozmazuje. Ja tu nie czytam żadnego jasnego inżynierskiego planu.
0
Lokalnie mam na myśli to, że każdy sklep posiada swoją własną siec wewnętrzną z serwerem. W sieci lokalnej danego sklepu, pracownicy za pomocą aplikacji dodają i usuwają elementy z bazy (coś jak magazyn). Aplikacja internetowa ma swoją baze danych w której przechowuje dane klientów. Ma ona za zadanie pobrać dane ze wszystkich serwerów i wyświetlić potencjalnemu klientowi asortyment (zdjęcie produktu, podstawowe dane) wraz z ich ilością. Klient za pomocą aplikacji internetowej składałby zamówienie w wybranym przez siebie sklepie na odbiór danego produktu.
Moim planem było:
- Utworzenie Web API dla sklepów lokalnych oraz utworzenie aplikacji webowej do dodawania/usuwania/edytowania produktów (prosty CRUD). To wszystko działa na terenie placówki sklepu (sieć wewnętrzna).
- Utworzenie Web API wraz z aplikacją webową dla klienta. Administrator w bazie danych ustawiałbym adresy publiczne każdego Web API sklepów lokalnych. Klient za pomocą aplikacji wyświetlałby asortyment całej sieci sklepów. W przypadku chęci zakupu jakiegoś produktu, klient mógłby odebrać produkt osobiście w sklepie (stąd potrzebuje dane ze wszystkich sklepów) lub zamówić go sobie kurierem.
Pytanie moje brzmi czy architektura, którą przedstawiłem na obrazku (Web API aplikacji internetowej pobiera dane z kilku Web API sklepów lokalnych. W przypadku zakupu, Web API internetowe wysyłałoby dane do wybranego sklepu w celu rezerwacji produktu [komunikacja obustronna]) ma sens? Może powinienem rozwiązać to w innych sposób? Może czegoś nie uwzględniłem?
Rozwiewając wszelkie wątpliwości. Ja swoją naukę z ASP.NET Web API + React dopiero zaczynam, ale zawsze przy nauce stawiam sobie jakiś realny projekt do realizacji. Kiedyś podczas zakupów w jednej z sieci sklepów widziałem, że pracownicy posiadają osobną aplikacje desktopową do zarządzania lokalnym magazynem. Sieć sklepów posiada również strone internetową w której wyświetla co w danym sklepie jest. Stwierdziłem, że na start to będzie spoko projekt do realizacji tylko za cholere nie wiem jak powinna wyglądać w uproszczeniu taka architektura. Próbowałem znaleźć w internecie jakieś informacje, ale za każdym razem znajdowałem jedynie poradniki jak zrobić Web API + frontend. Ktoś poleca jakieś materiały odnośnie architektury oprogramowania większych systemów w praktyce?
1
Ja bym zamienił wywołania synchroniczne na asynchroniczne. W tej chwili pytając każde API czekasz na odpowiedź i prosta matematyka pokazuje że jeżeli odpowiedź Api1 trwa 2s Api2 1s Api3 3s to czas oczekiwania na dane wyniesie 6s. A co jak się jakieś API posypie?
Dlatego dane z różnych sklepów powinieneś synchronizować poza procesem aplikacji (w tle). Taka usługę działa sobie spokojnie na backendzie, agreguje dane i wrzuca do bazy danych twojej aplikacji. Wtedy robisz prosty SELECT na lokalnej bazie danych co znacząco wpłynie na wydajność i odporność na awarie bo jak któreś API padnie to w bazie danych aplikacji masz kopie danych z tego sklepu, kosztem spójności danych (może się okazać Że przez chwilę będziesz miał niespójne dane dopóki job ich nie zsynchronizuje). Oczywiście sama implementacja takiego joba trywialna już nie jest.
Sam request o rezerwację produktu może już odbywać się synchronicznie poprzez HTTP.
0
markone_dev napisał(a):
Ja bym zamienił wywołania synchroniczne na asynchroniczne. W tej chwili pytając każde API czekasz na odpowiedź i prosta matematyka pokazuje że jeżeli odpowiedź Api1 trwa 2s Api2 1s Api3 3s to czas oczekiwania na dane wyniesie 6s. A co jak się jakieś API posypie?
Dlatego dane z różnych sklepów powinieneś synchronizować poza procesem aplikacji (w tle). Taka usługę działa sobie spokojnie na backendzie, agreguje dane i wrzuca do bazy danych twojej aplikacji. Wtedy robisz prosty SELECT na lokalnej bazie danych co znacząco wpłynie na wydajność i odporność na awarie bo jak któreś API padnie to w bazie danych aplikacji masz kopie danych z tego sklepu, kosztem spójności danych (może się okazać Że przez chwilę będziesz miał niespójne dane dopóki job ich nie zsynchronizuje). Oczywiście sama implementacja takiego joba trywialna już nie jest.
Sam request o rezerwację produktu może już odbywać się synchronicznie poprzez HTTP.
Okej, ma to jak najbardziej sens. Dziękuje! Wiem, że proste to nie będzie, ale chce stopniowo zgłębiać "tajniki magii" i rozwijać się jako programista. Mając z góry wyznaczony cel, łatwiej jest się uczyć.
1
Użyłeś słowa, które wzbudziło we mnie rezonans: agregacja (Użyłeś też cennego słowa: aplikacja)
@jaros555: .
Dlaczego w ogóle to jest pocięte? Jaką rzeczywistość biznesową prezentuje najpierw ciecie, a potem w/w "agregacja"?
Z niedopowiedzeń (i wcale to nie są niedopowiedzenia programistyczne, lecz biznesowo-projektowe) można mniemać o podziale w/g branż towarów, może o firmach córkach w holdingu. Choelra wie.
Z opowieści, tyle ile przekazałeś, wyrabiam sobie pogląd, ze pracownicy ZA DUŻO pracują w sklepie/sklepach webowych, a WCALE nie powiedziałeś o jakiejś aplikacji magazynowo-handlowej+ksiegowość. Ja sobie bez tego NIE UMIEM wyobrazić, ale wiem, ze pracownikom z otoczenia e-sklepu (telefony, składanie paczek) trudno sobie wyobrazić szerzej.
Mam takie swoje testowe pytanie, która wystawia potencjalne problemy: gdzie jest pierwotna karta towarowa, kiedy jest zakładana, gdzie jest prawdziwy (mający znaczenie księgowe) stan
Wg mnie w ERP-ie, i zakładana jest 3 mc wcześniej jak składamy zamówienie do Chin. Ale to szeregowi ludzie nie zawsze widzą problem - natomiast się "nawracają" jak się robi burdel.
1
jaros555 napisał(a):
Witam
W ramach nauki chce stworzyć system do zarządzania sklepami. Każdy sklep działa
Odczytuję, dwie części wypowiedzi: sklepy już są, i na kanwie tego chcesz się nauczyć?
ZrobieDobrze napisał(a):
Z niedopowiedzeń (i wcale to nie są niedopowiedzenia programistyczne, lecz biznesowo-projektowe) można mniemać ...
Bez jasnego, "skazanego na sukces" projektu, to szkoda się nawet tykać kodu. Obecnie, o ile jesteśmy skazani, to na sukces zgoła nie.
0
Te sklepy to wymyślone obiekty w ramach nauki. Lepiej mi będzie uzmysłowić sobie prace i dążyć do celu tworząc system zarządzania dla np sieci sklepów EURO RTV AGD niż jakbym miał czysto klepać kod nieistniejącego bytu. Nie doszukuj się tutaj nie wiadomo jakiego polotu i uwzględnienia 1000 różnych scenariuszy. Pytanie jest proste, czy synchronizacja danych z wielu API za pomocą innego API ma sens i czy takie rozwiązanie się wykorzystuje. To jakie operacje będę dokonywał na tych danych jest już nieistotne. Przecież w przypadku sieci 100 sklepów lepiej jest zrobić jedną strone internetową która pobiera dane ze 100 sklepów, niż tworzyć 100 stron dla 100 sklepów osobno. Kolega wyżej napisał że lepiej będzie to zrobić w sposób asynchroniczny. Usługa będzie pobierać dane z Web API sklepów lokalnych w tle co jakiś określony czas i aktualizować baze."Rozwiewając wszelkie wątpliwości. Ja swoją naukę z ASP.NET Web API + React dopiero zaczynam, ale zawsze przy nauce stawiam sobie jakiś realny projekt do realizacji.""
2
jaros555 napisał(a):
Te sklepy to wymyślone obiekty w ramach nauki. Lepiej mi będzie uzmysłowić sobie prace i dążyć do celu tworząc system zarządzania dla np sieci sklepów EURO RTV AGD niż jakbym miał czysto klepać kod nieistniejącego bytu.
jest dokładnie odwrotnie niż myślisz. Sklep webowy RTV EURO jest jeden, zintegrowany dla całej sieci. Było by to totalnie nieekonomiczne mieć młyn z N sklepami. Jak im zapewnić adminów itd ... jak reagować na selektywne problemy. Tu baza się zapchałą, tam zła paczka Angulara
Wyłącznie JEDEN sklep. On na firmę ogólnokrajowa będzie oczywiście większy, w bardziej złożonej technologii (choćby przez wydajnosć), ale będzie JEDEN i to jedyne racjonalne załozenie.
czasem dla sklepów firm światowych przebije, że po polską skórką ujawni sie zapomniana szwedzka, francuska itd... zwłaszcza dla tych "sklepów" które bardzie służą prezentowaniu towarów niż rzeczywistym transakcjom.
Wiec zaczyna się wyjaśniać, dlaczego taki wydumany projekt
jaros555 napisał(a):
Pytanie jest proste, czy synchronizacja danych z wielu API za pomocą innego API ma sens i czy takie rozwiązanie się wykorzystuje.
W pierwszym pytaniu prezentowałeś coś innego: PRZELOTOWE Web API *)
Tak, wykorzystuje się oczywiście Web API do synchronizacji, z tym ze nikt nie potnie w taki dziecinny sposób, aby to potem sklejać - ale to są zupełnie odmienne zagadnienia.
Przecież w przypadku sieci 100 sklepów lepiej jest zrobić jedną strone internetową która pobiera dane ze 100 sklepów, niż tworzyć 100 stron dla 100 sklepów osobno.
Chore.
Dzielnie walczysz problemami, które sam wygenerowałeś.
*) przynajmniej tak to przestawiłeś - niejasno i w obszarze domysłów. Więc z niejasny projektem ... sorry nie powstanie do tego dobry kod. Sugerowałbym obstukiwać techniki progamistyczne na czymś a) mniejszym b) z wyrazistymi ścisłymi założeniami
3
Przerwę te rozważania bo uważam, że kolega @jaros555 powinien jeszcze uzupełnić troszkę wiedzy zanim zabierze się za to zagadnienie.
Po pierwsze kolega jeszcze nie siedzi twardo w obszarze pojęć podstawowych więc ciężko mu będzie uciągnąć całość . Np z jednej strony mówi o WEB API a z drugiej cały czas pisze o adresach IP. Ustalmy zatem czym mają być API tych lokalnych sklepów, jak mają działać... może należy zacząć od jakiejś dokumentacji a nie od piszmy byle co byle było?
"Prosty CRUD"... nie wiem czy aby wszystko działało jak trzeba to czy on może być taki "prosty".
Pytanie jest proste, czy synchronizacja danych z wielu API za pomocą innego API ma sens
Tak ma. Tylko żeby to zrobić dobrze trzeba mieć już trochę doświadczenia.
Np.
- zapytania do API lokalnych wskazane jest aby były wykonywane równolegle o ile są one na różnych fizycznie maszynach - bo jak na jednej to ta równoległość traci sens - dlaczego? Zastanów się sam.
- po drugie jak zagwarantujesz spójność nazewnictwa kategorii, produktów / ogólnie asortymentu. U jednego będzie kategoria telewizory a u drugiego kina domowe... co wtedy?
Będziesz serwował klientowi końcowemu taki bajzel pojęciowy czy jakoś to poukładasz?
pecież w przypadku sieci 100 sklepów lepiej jest zrobić jedną strone internetową która pobiera dane ze 100 sklepów
O ile umiesz te dane sensownie synchronizować, sortować po cenie itp... Zastanów się nad samym sortowaniem po cenie i stronicowaniem w sytuacji kiedy odpytujesz 100 sklepów jednocześnie...
Żeby to zrobić wydajnie to to nie jest banalna sprawa. Co ma Twoje centralne API zwrócić i jakie ma zadać pytania do tych lokalnych aby wyświetlić 25 stronę wyników posortowaną po cenie malejąco?
Kolega wyżej napisał że lepiej będzie to zrobić w sposób asynchroniczny. Usługa będzie pobierać dane z Web API sklepów lokalnych w tle co jakiś określony czas i aktualizować baze.
W wielu przypadkach takie rozwiązanie może okazać się o wiele skuteczniejsze i szybsze.
Co jakiś czas pełna aktualizacja a na bieżąco jedynie aktualizacja stanów / zmian w kierunku serwery lokalne -> centralny i odwrotnie.
0
To może jeszcze raz na przykładzie owej firmy RTV EURO AGD. Posiadają oni JEDNĄ stronę, która przedstawia ofertę WSZYSTKICH ODDZIAŁÓW w Polsce. Jeśli wybierzesz sobie jakikolwiek produkt, to możesz sprawdzić jego dostępność we wszystkich oddziałach. Każdy z oddziałów posiada swoją aplikacje desktopową do zarządzania sprzedażą w oddziale (sprzedaż produktów, przegląd magazynu sklepu, wystawianie faktur, obsługa dodatkowych urządzeń takich jak terminal, drukarka, czytnik kodów kreskowych itp itd). Jak przychodzi dostawa produktów do sklepu w Będzinie, to oddział w Będzinie do swojej lokalnej bazy danych dodaje owe produkty. Jak przychodzi klient kupić produkt w Warszawie, to oddział w Warszawie korzysta ze swojej lokalnej bazy danych i sprzedaje owy produkt. Rola strony internetowej w tym przypadku jest prosta - wyświetlanie oferty FIRMY, podgląd dostępności produktu w DANYCH ODDZIAŁACH, rezerwacja produktu w DANYCH ODDZIAŁACH. Żeby sprawdzić jaka jest dostępność tych produktów to owa strona internetowa musi jakoś dostać te dane pobrać. JAK?
Jak dokładnie wygląda u nich architektura? Nie mam bladego pojęcia bo tam nie pracuje!
Chce stworzyć kopie tego systemu w ramach nauki. Tak jak napisałem wyżej, nie mam pojęcia jak wygląda dokładana architektura sklepu więc proponuje swoją. Lokalne oddziały posiadają swoją baze danych + WEB API do obsługi aplikacji desktopowej. Ta sama lokalna WEB API komunikuje się z centralną WEB API. Centralna WEB API co jakiś określony czas będzie pobierać dane z tych lokalnych WEB API do swojej bazy, a aplikacja internetowa będzie wyświetlać jej stan. W przypadku dokonania rezerwacji Centralna WEB API będzie komunikować się z określoną lokalną WEB API aby zarezerwować produkt.
Co do nazewnictwa produktów i jego parametrów to zakładam że one będą dokładnie takie same w każdym oddziale (to jest projekt do nauki więc pewne rzeczy sobie upraszczam). Wiadomo, że w prawdziwym życiu może dojść do pomyłki, ale to nie jest celem tej nauki. Wydaje mi się, że aby to obejść wystarczy utworzyć osobną bazę produktów, która będzie dostępna dla wszystkich innych oddziałów, ale to nie jest problem, z którym się teraz mierzę.
Problemem jest to czy podana architektura ma sens. Pytam bo może czegoś nie wiem. Może dane z wielu WEB API jest lepiej przetwarzać za pomocą innego sposobu o którym nie wiem. Tutaj już kolega mi napisał że można pobierać dane z wielu API do jednego API i lepiej robić to w sposób asynchroniczny i aktualizować bazę strony internetowej bo inaczej będę czekał X sekund na pobranie danych.
Prosze pamiętajcie o jednym. Przykład służy mi jedynie do nauki więc problem próbowałem mocno uogólnić.
1
Co do przykładu z Euro RTV AGD to też nie wiem jak to mają zaimplementowane bo sposobów jest kilka. Mogą mieć wszystko (w tym stany magazynowe) w jednej centralnej bazie danych i robić zapytania po id sklepu, id sklepu wybierasz przecież na stronie www. Mogą to mieć w osobnych bazach per sklep i potem dane z lokalnych baz synchronizować do centralnej bazy typu hurtownia danych, która zbiera informacje o sprzedaży i na tej podstawie generowane są raporty Business Inteligence. Wtedy zapytania z www lecą do centralnego API, który pełni funkcję routera czy API Gateway i kieruje zapytanie do odpowiedniego źródła danych (baza/web serwis konkretnego sklepu).
Z mojego punktu widzenia Twoja architektura w której synchronicznie odpytujesz każde API synchronicznie po HTTP, gRPC czy czymkolwiek po kolei, żeby zebrać dane nie ma sensu w rzeczywistym projekcie. Ale teoria teorią a praktyka praktyką i często takie rozwiązania też się stosuje w systemach produkcyjnych bo mogą występować ograniczenia utrudniające robienie takich rzeczy asynchronicznie.
0
markone_dev napisał(a):
Co do przykładu z Euro RTV AGD to też nie wiem jak to mają zaimplementowane bo sposobów jest kilka. Mogą mieć wszystko (w tym stany magazynowe) w jednej centralnej bazie danych i robić zapytania po id sklepu, id sklepu wybierasz przecież na stronie www. Mogą to mieć w osobnych bazach per sklep i potem dane z lokalnych baz synchronizować do centralnej bazy typu hurtownia danych, która zbiera informacje o sprzedaży i na tej podstawie generowane są raporty Business Inteligence. Wtedy zapytania z www lecą do centralnego API, który pełni funkcję routera czy API Gateway i kieruje zapytanie do odpowiedniego źródła danych (baza/web serwis konkretnego sklepu).
Z mojego punktu widzenia Twoja architektura w której synchronicznie odpytujesz każde API synchronicznie po HTTP, gRPC czy czymkolwiek po kolei nie ma sensu w rzeczywistym projekcie. Ale teoria teorią a praktyka praktyką i często takie rozwiązania też się stosuje w systemach produkcyjnych bo mogą występować ograniczenia utrudniające robienie takich rzeczy asynchronicznie.
Co do architektury w której to oddziały łączą się do jednej centralnej bazy istnieje problem, który chce wyeliminować za pomocą swojej architektury. Jeśli centralny serwer przestanie działać to oddziały w całej Polsce nie działają i zatrzymuje to sprzedaż, a na to sklepy sobie nie mogą pozwoli. W przypadku utworzenia lokalnych serwerów w każdym oddziale to do takiej sytuacji nie dojdzie, ale tworzyło to problem z synchronizacją danych. Stąd rodziło się moje pytanie czy mogę synchronizować dane za pomocą jednego API z kilkudziesięciu innych API i potem wyświetlać je na stronie internetowej. Teraz wiem że tak, ale muszę zrobić to w sposób asynchroniczny. Dziękuje za poświęcony czas i pomoc.
3
Jeśli centralny serwer przestanie działać to oddziały w całej Polsce nie działają i zatrzymuje to sprzedaż, a na to sklepy sobie nie mogą pozwoli.
Mogą. Są wzorce i techniki programistyczne, które pozwalają obsłużyć i taką sytuację jak choćby rozproszony cache danych oraz wymiana informacji pomiędzy usługami a stroną www przy pomocy komunikatów i persystentnych kolejek wiadomości. Oczywiście może się okazać, że ktoś wtedy kupi produkt, którego nie ma już na stanie, ale to jest problem biznesowy (co wtedy?) niż techniczny. W taki sposób działa np. Amazon. Nie są w stanie kontrolować w 100% swoich stanów magazynowych i jeżeli zdarzy się taka sytuacja, to wtedy grzecznie przepraszają i dają kupon klientowi z rabatem na kolejne zakupy albo coś w ten deseń. Po prostu policzyli że taniej ich wyjdzie dać komuś rabat na następne zakupy niż inwestować kasę w kuloodporne rozwiązanie które zagwarantuje 100% spójność danych.
2
@markone_dev:
+1
Sądzę, ze na poziomie kolorowej informacji o towarze (jestem pewien) jest centralna struktura, do której lokalne instalacje magazynowo-handlowe sie integrują (w sumie, nie pozterbują tego na stałe, tylko jak fizyczny klient szczególne pyta).
Akurat w sieciówkach nie ma wcale / prawie nie ma (w spożywczych, ale te nie mają weba) niezależnych decyzji o wyborze towaru do oferty. Sklep nie sprzeda spoza oferty przygotowanej przez centralę.
Odnoście realnego życia gospodarczego - na odwrót. To fizyczny sklep ma samodzielność gospodarczą (w wielu sieciówkach każdy jest prawnie innym podmiotem), i NIE MA żadnej możliwości modyfikować mu np stan magazynowy, tylko normalne operacje dostaw. Pracownicy mają odpowiedzialność materialną, jak się stan dużo nie zgadza, trzeba przypadkowy pożar zrobić (podobno, w jednym mieście był w sieciówce)
Zwróć uwagę, jak nieistotną daną jest podana na webie informacja o dostępności w fizycznym sklepie. W perspektywie lat zdarzało się, nawet całkiem niedawno jechałem po switch wieloportowy który teoretycznie wg weba był, ale go nie było.
Akurat mi nie dali kuponu na następne zakupy ;) ale to są te sprawy.
Co innego, jak klient kupuje przez weba, z odbiorem w fizycznym sklepie. Systemy mają kilkanaście sekund, jest czas aby na tym popracować - przy czym nie pracujemy nad kilkutysiecznym asortymentem, a 1-5 (ile w koszyku), w konkretnym rozmiarze buta i kolorze koszulki. Transakcję na 5 asortymentów jest jak zapewnić - na 15tys asortymentu to nigdy nie da się absolutnie spójnie oprogramować.
oczywiście na taki oddział lokalny (desktopowy) program handlwo-magazynowy to nie "mała-firma" z Rzeczpospolitej czy inny za 50zł, ale w takich kontaktach nie ma problemu przygotować dedykowany, ze stosownymi integracjami.
0
Jeżeli rozumiem Twój pomysł to nie jest on do końca poprawny. Serwer stojący lokalnie jest po to, aby działał lokalnie. Zmodyfikowałem nieco Twój obraz:
Jeżeli spróbujesz dostać się do sieci wewnętrznej klienta ze swojego API to Ci się nie uda. Rzadko też spotykam się, aby firma posiadała stały zewnętrzny adres IP.
To sprowadza się do kilku sprawdzonych rozwiązań:
- API klientów powinno być publicznie dostępne, wtedy nie ma z tym problemu. W swojej bazie danych do każdej tabeli dodajesz po prostu
TenantIdreprezentujący klienta
- Drugą opcja jest trzymanie wszystkiego w jednej bazie tj: u siebie, a APi klientów (lub bezpośrednio strona internetowa klienta) komunikuje się z twoim API a nie odwrotnie. jak wyżej dodajesz wtedy
TenantIdreprezentujący klienta. Masz wtedy dostęp do wszystkich danych
- Trzecia opcja, moim zdaniem najgorsza to duplikat bazy danych u Ciebie i klienci będą wysyłać Tobie aktualizacje które wprowadzają u siebie. A zresztą to nie ma sensu, nieważne
0
gswidwa1 napisał(a):
- Trzecia opcja, moim zdaniem najgorsza to duplikat bazy danych u Ciebie i klienci będą wysyłać Tobie aktualizacje które wprowadzają u siebie. A zresztą to nie ma sensu, nieważne
Ta opcja ma sens w pewnych sytuacjach, np. w wypadku gdy ta końcowa apka musi działać w trybie offline. Masa systemów sprzedaży ma do dziś taką architekturę tzn. apka desktopowa z lokalną bazą danych + api do synchronizacji pomiędzy sklepami, tworzenia raportów itd. Rozwiązanie już raczej leciwe, nowych systemów się tak nie projektuje.
0
Zakładam ze każdy sklep lokalny ma swoją wewnętrzną sieć do swojego użytku, ale także mają router odpowiedzialny za dostęp do internetu publicznego. Dlaczego w takim przypadku nie będę mógł się połączyć? Przecież w przypadku łączenia dwóch oddziałów firmy oddalonych o 500km stosuje się rozwiązania takie jak VPN site-to-site, a to z kolei wymaga stałego, zewnętrznego adresu IP. W dzisiejszych czasach praca zdalna jest normalnością i to też wymaga stałego, zewnętrznego adresu IP.
0
Ciężko się dogadać, na jednym oddechu omawiając routing, logikę integracji, zasady biznesowe systemów, obiegi dokuemntów, strukturę bazy danych i wszystko itd.
Jak CHCEMY zintegrować, to i na na dynamicznym adresie by sie dało, byle być w swojej analizie i założeniach rasowym specjalistą.
I na odwrót, super-duper internet nie uratuje źle zaplanowanych systemów (@gswidwa1 - integracja offline wszystkiego i we wszystkie strony)
(co nie znaczy, ze stały IP nie jest rozsądnym wyborem)
0
Zgadzam się. Tak czy siak sporo już się rozjaśniło. Dziękuje każdemu za pomoc