[a.....n]

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

[k.....e]

@ascalon:

na zachodzie technologie z akapitu wyżej zaczynają być już standardem

Znasz jakieś przykłady publicznie dostępnych api w GraphQL?

[budyn]

Apollo

@ascalon: Co to dokładnie daje, bo nie kumam zbytnio? To jest biblioteka czy usługa? Wyjaśnisz co to robi tak ogólnikowo?

[a.....n]

@kebab-case: here you go https://github.com/APIs-guru/graphql-apis

[k.....e]

@ascalon: Troche mało biorąc pod uwagę, że mówisz, że to zaczyna być standardem

[Zavis]

@ascalon: My w projekcie tego wszystkiego używamy, ale ReactXP bo appka też pod mobilki

[programista5k]

@kebab-case: https://developer.github.com/v4/

[a.....n]

@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.

[a.....n]

@Zavis: Nie słyszałem o ReactXP, czym to po krótce rózni się od React Native?

[Zavis]

@ascalon: Nie siedzę we froncie, żeby ładnie odpowiedzieć, więc po prostu podeślę linka: https://github.com/microsoft/reactxp

[a.....n]

@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.

[budyn]

@ascalon: GraphQL jest fajny, ale moim zdaniem nie nadaję się do większości aplikacji. Daję dowolność, kosztem wydajności. https://www.freecodecamp.org/news/five-common-problems-in-graphql-apps-and-how-to-fix-them-ac74d37a293c/
Te rozwiązania w tym blogu to tak po #!$%@? swoją drogą

[budyn]

@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 ich

[a.....n]

@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.

[techko]

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

[getin]

@ascalon: zamiast zrobić normalnie jquery+php to po co te dziwactwa

[a.....n]

@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 :)

[k.....e]

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

[a.....n]

@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

[WaveCreator]

@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 JS

[a.....n]

@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 że