Wpis z mikrobloga

Zadanie rekrutacyjne no. 4 - https://notehub.org/n2wqw
Podołacie Mid Developerzy? ( ͡º ͜ʖ͡º) #webdev #backend. Technologia dowolna, czas nieograniczony.
Na poziomie mida coraz rzadziej firmy dają zadania rekrutacyjne, bo wraz ze wzrostem trudności zwiększa się też czas potrzebny na wykonanie zadania - a czas to pieniądz.

Niestety zadania będą pojawiały się trochę rzadziej ze względu na natłok pracy.

Będę wdzięczny za wszelkie uwagi i sugestie.
Zachęcam do nadsyłania zadań na pw! Pomoże to nam zbudować większą bazę wiedzy :)

Poprzednie zadania:
1. https://notehub.org/9pk10
2. https://notehub.org/r6blk
3. https://notehub.org/unw4x

---------------------
#rekrutacjepstrg - tag z zadaniami rekrutacyjnymi wzorowanymi na realnych zadaniach od polskich firm.
#programowanie
  • 44
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@Izanagi013: czyli np w panelu prosisz o dane to wysylasz subskrypcje do rabbita i potem dostajesz info jak przyjdzie wiadomosc z odpowiedzią na rabbita? a w międzyczasie w panelu wyświetlasz loader? my myślimy o spieciu kilku instancji api graphql przez rabbita i uzycie subskrypcji
  • Odpowiedz
@mirasKo-Kalwario: z tego co wiem, to można bezpośrednio przez websocket z przeglądarki łączyć się z kolejką czy exchange w rabbitcie. Odpalić wtedy klientowi promisa i doklejać zmiany które będzie dostawał na bieżąco. Właśnie w taki sposób działa nasz system, klient widzi na żywo nowe informacje z kilku różnych zewnętrznych serwisów, tyle że mamy dodatkowy serwer socketów, który dopiero łączy się z rabbitem ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@Izanagi013: Jestem ciekaw jakby to mialo dzialac (nie ironicznie, zeby nie bylo) z rabbitmq. Z tego co zrozumialem to microserwis A ma byc serwisem identyfikacyjnym, czyli generujacym token. W jaki sposób byś wchodził na serwis B nie posiadając jeszcze sesji (ciastek do serwisu)? Chyba, że chodziło Ci o autoryzację podczas już otwartej sesji (posiadaniu tokenu użytkownika w ciastku) w microserwisie B - zamiast po http, jak w klasycznym oauth, porozumiewać
  • Odpowiedz
@Matiatakuje: ja to widze tak, bez zadnych sesji czy ciastek, wysylasz request do serwera z kolejką zaczynajac od login.user {login, password}. request leci do mikroA i dostajesz token. Majac token dorzucasz go do kolejnego requesta notes.data.usernote {id}, by dostać info o jakieś notatce, kolejka przekierowuje do mikroB i zwraca dane.
Na mikroA masz autentykacje i kolejke, na mikroB masz notatki, ma mikroC coś innego. Jak masz dużo userów, to możesz
  • Odpowiedz
@Izanagi013: Wydaje mi się, że w tym przypadku dokonujesz couplingu tych systemów, ze względu na to, że masz w wymaganiach by były pod osobnymi adresami (hub i notes). Jasne, oba mogą się odwoływać do pojedynczego serwera, który ma rozdzielacz jak nginx/httpd, ale zastępowanie tego brokerem nie wydaje mi się by przyniosło wielki zysk i prostote ponieważ na poziomie brokera musiałbyś mieć logikę identyfikacji (a raczej jej braku). Bardziej by mi
  • Odpowiedz
@Matiatakuje nie mówię, że to idealne rozwiązanie, raczej pomysł, bez większego przemyślenia, ale planuję się pobawić i zrobić coś takiego, by zobaczyć czy to ma sens czy nie :-D
Wymagania trochę inne, ale wydaje mi się, że w ten sposób można zrobić skalowalny system, nawet kosztem prostoty. Broker po mqtt będzie dużo szybszy niż nginx po http. Ale to po świętach ( ͡º ͜ʖ͡º)
  • Odpowiedz