Wpis z mikrobloga

Kto używał GraphQL + Apollo + React + Redux? Piszę teraz read-only/get external API (niestety backend dopiero ogarniam i nie umiem into integracja z MongoDB) apkę łączącą wszystkie te technologie i uważam, że to absolutne mistrzostwo świata jesli chodzi o web dev, tak wygląda przyszłość.

Nie widziałem natomiast ofert pracy, w których wykorzystywane są te technologie. Firmy w polsce bazują jeszcze na REST, BackBone (xD), AngularJS (wersja 1 xD), co ciekawe ostatnio dowiedziałem się, że pisanie na Hooksach jest w sumie top tier nowością bardzo pożądaną na rynku, skąd taki stan rzeczy? Domyślam się, że w dużej mierze to utrzymanie już istniejących apek ale na zachodzie technologie z akapitu wyżej zaczynają być już standardem.
W sumie to zapraszam do merytorycznej ( ͡° ͜ʖ ͡°) dyskusji.
#programowanie #webdev #frontend
  • 23
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@kebab-case: głównie chodzi o to że jak stawiasz node server to masz jeden endpoint /graphql zamiast kilkunastu/dziesięciu jak przy normalnym REST. Znacznie redukuje robotę dla backenda i dostajesz dokładnie to co chcesz, czyli np. GET banan - dostajesz banan, w przypadku REST wygląda to tak że masz GET banan - goryl z bananem z którego musisz wyciągać banana.
  • Odpowiedz
@budyn: To jest taki middleware (powiedzmy że pośrednik) między klientem a serverem. Jeśli używałeś Reduxa to używa się go z middleware zazwyczaj to Thunk do zapytań asynchronicznych w celu obsługi stanu aplikacji. Apollo jest czymś podobnym tylko że on łączy server GraphQL z klientem.
  • Odpowiedz
@ascalon: Z drugiej strony aż tak się nie zagłębiałem. Ale jeśli można by było pożenić REST z GraphQL to by było to.
Np definiujesz, że do zapytania o resource X możesz zrobić joina do Y albo Z, wybrać te fieldy co potrzebujesz.
Ale zabronić traversowania/pobierania całego grafu. Pozwolić na joiny w jedną, ale nie w drugą stronę. Np chcesz ostatnie komentarze z danymi użytkownika, ale nie możesz pobrać użytkowników z
  • Odpowiedz
@budyn: bardzo bacznie obseruję technologie robione w open source przez facebooka i myślę że robili GQL też z myślą o enterprise choć tak jak react napewno lepiej się sprawdza przy mniejszych - średnich projektach w połączeni z zewnętrznymi bibliotekami, musiałbym powiercić i poszukać wydajności GQL do REST przy różnego typu zapytaniach.
  • Odpowiedz
Przecie dla backendu to praktycznie tyle samo roboty, bo musisz pisac resolvery pod rozne kejsy (wiec sugerowanie, ze zrobisz pojedyncze resolvery zeby miec to samo co na rescie to zwykle myslenie zyczeniowe, chyba ze robisz jakies pokraki typu pokemon api...). Mam teraz w projekcie graph/apollo/mongo + react na froncie i od strony frontu wydaje sie spoko, ale po przejsciu z resta na takie rozwiazane w kontekscie backendowym to widze troche problemow i
  • Odpowiedz
@techko: z tymi resolverami to w sumie racja. Dla mnie na froncie to bardzo fajna nowość, nie muszę babrać się z wyciąganiem parametrów z obiektów (choć żaden to trud...), natomiast backend jest dla mnie okryty tajemnicą. Express z GQL to moje pierwsze podejście, w sumie wstęp i wydaje się bardzo przyjazne, zobaczymy dalej. Bardzo mnie ciśnie żeby ogarnąć MongoDB :)
  • Odpowiedz
Np definiujesz, że do zapytania o resource X możesz zrobić joina do Y albo Z, wybrać te fieldy co potrzebujesz.


@budyn: No i tak się robi np.

GET /orders/1345?expand=consumer
Zwróciłoby zamówienie o id 1345 i klienta do niego przypisanego
  • Odpowiedz
@getin: bo tak jest fajniej i JSem da się napisać wszystko (nie wiem czy trollujesz ale wytłumaczę), od Native albo jak kolega wyżej napisał RX na mobile po desktop z Electronem. W tej chwili obok Javy, JS to najbardziej elastyczny język z największym community na świecie a PHP trzyma przy życiu tylko gargantuiczna ilość kodu w nim napisana.

Node server ma najlepszą ze wszystkich wydajność pod kątem obsługi ogromnej ilości małych
  • Odpowiedz
@ascalon: Mieliśmy w pracy takiego kolegę, który był wielkim fanem wszystkich nowości w JS i generalnie w temacie JS'a wymiatał. Miał jedną wadę - kod pisał taki, że nie rozumiał go nikt poza nim. Jeśli kiedyś będziesz pracował w większym zespole to nie idź tą drogą. To, że coś jest nowe nie znaczy, że trzeba to od razu pakować wszędzie gdzie się da. I pamiętaj, że był taki czas, że
  • Odpowiedz
@WaveCreator: Zawsze staram się pisać czytelny kod, nie skracam nazw np. gColWid tylko getColumnWidth unikam czegoś w stylu (xD)=>(xD) tylko dobre praktyki tak żeby czytając kod na głos brzmiał jak pisany wierszem ( ͡° ͜ʖ ͡°).
Dla mnie GQL i Apollo to totalna nowość i pierwsze podejście do backendu, zobaczyłem jak to działa i dalej jestem pod wrażeniem. Ale masz rację bo tak mi się spodobało
  • Odpowiedz