•  

    pokaż komentarz

    Napisze ktoś do czego służy ta aplikacja? Po komentarzach widać tylko pochwały jaki to kod jest wspaniały a jaki to zleceniodawca zły

    •  

      pokaż komentarz

      @kidi1: Pełna aplikacja (zarówno frontend i backend), napisana z użyciem technologii które są ostatnio najbardziej sexy (React Native, NodeJS, GraphQL, Apollo), w której użytkownicy dostają benefity w zamian za opłacanie rachunków za jej pośrednictwem, zamiast za pomocą przelewu bankowego ( "an app where users receive benefits for paying their rent through the platform as opposed to check or bank transfer").

    •  

      pokaż komentarz

      technologii które są ostatnio najbardziej sexy

      @noarch: serio? ( ͡º ͜ʖ͡º)

      źródło: img.izismile.com

    •  

      pokaż komentarz

      @getin: Wziomby się za prawdziwom robote, a nie fiku miku na internetach, tak to i mój synku potrofi. Ostatnio nawet LOLA jakiego zrobił.

      źródło: _T5k9kqTURBXy9hYjM4ZmMyODk0NmYwOTg2M2QwNDUzZGVmZTBhNGQ5Yy5qcGVnkpUDACjNB4DNBDiTBc0HgM0EOIGhMAE.jpg

    •  

      pokaż komentarz

      @noarch: Ostatnio duzo slysze o GraphQL i tak sie zastanawiam czy ludzie tego uzywaja dlatego, ze ma to faktycznie sens czy po prostu fajnie miec to w cv. Sklaniam sie troche ku temu drugiemu...

    •  

      pokaż komentarz

      @Scandalous: Próg wejścia w GraphQL jest wyższy niż w RESTa, natomiast sama idea jest mega ciekawa, gdyż upraszcza sposób definiowania API i odwraca sposób myślenia o komunikacji klient-serwer. W klasycznym REST serwer decyduje, jakie zapytania klient może wykonać do serwera, co przekłada się na dokładanie kolejnych endpointów wraz z kolejnymi potrzebami na frontendzie, natomiast przy GraphQL to klient definiuje strukturę zapytania i zasobów o które chce odpytać serwer.

    •  

      pokaż komentarz

      @noarch: czyli... Wymyslil 'punkty PayBack'.... No k@%@a brawo

    •  

      pokaż komentarz

      @noarch:

      Czyli teoretycznie o wiele latwiej jest polozyc serwer zapytaniami niz w rescie?

      Sam osobiscie nie wskakuje jeszcze na ten wagonik hype'u nazwany GraphQL. Jak do wszystkiego co pochodzi ze swiata JS, podchodze do tego ostroznie. Teraz jest 'cool' a za 2 lata jak juz aplikcaje przejda przez fazy gaszenia pozarow przez GraphQL to wtedy cool bedzie co innego (pewnie SOAP wroci do lask XD).

    •  

      pokaż komentarz

      @Scandalous: Jest cholernie wygodne gdy pracujesz z frontendowcami, w porównaniu z REST nie trzeba bawić się w pierdyliard ścieżek, dodatkowo masz zagnieżdżanie zapytań więc zmniejsza liczbę wywołań, następna sprawa to walidacja typów, obowiązkowa, jak prześlesz inta w miejsce stringa to odejdziesz z kwitkiem, w REST masz walidację jak sobie zaimplementujesz, najczęściej kończy się to jednak na sprawdzeniu czy wartość jest pusta, bo implementacji RESTa z pełną walidacją typów to ze świecą szukać.

    •  

      pokaż komentarz

      Próg wejścia w GraphQL jest wyższy niż w RESTa,

      @Scandalous: u nas zastosowaliśmy GraphQL gdy rozszerzaliśmy weba o mobilna apkę. W sumie ciekawy case study można by napisać, bo nie wszystko poszło tak jak oczekiwaliśmy.

    •  

      pokaż komentarz

      najczęściej kończy się to jednak na sprawdzeniu czy wartość jest pusta, bo implementacji RESTa z pełną walidacją typów to ze świecą szukać.

      @sciana: Yy...kazdy endpoint napisany w silnie typowanym jezyku bedzie miec walidacje typow od kopa ;) A jak uzywasz jezyka z dynamicznym typowaniem...to sam sobie jestes winny :D

    •  

      pokaż komentarz

      @yuio chętnie poczytam, dobry artykuł pod medium. wołaj ;)

    •  

      pokaż komentarz

      @yuio: Również chętnie poczytałbym case study z większego projektu z GQL

    •  

      pokaż komentarz

      @Lump139: samce alfa kodu ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @sciana: przecież to front-endowiec powinien wprowadzać walidację do każdego pola.

    •  

      pokaż komentarz

      @yuio: Opiszesz, niedlugo bede robil api i myslalem o graphql bo klienta oczekiwani sa nie sprecyzowane, i z rozmow wynika ze bedzie to prawie idealne rozwiqzanie

    •  

      pokaż komentarz

      @noarch: Lepiej być testerem, niż bawić się w programowanie na dłuższą metę. Zarobki trochę niższe, ale nie trzeba się uczyć 24/7. Co roku aktualizacje + nowe technologie. Męczące to jest.

    •  

      pokaż komentarz

      @Herron: ta, jakbym ufał frontendowcom to bym teraz bez ręki chodził.

    •  

      pokaż komentarz

      @noarch: dla mnie to dziwna rzecz wlasnie przeciez ludzie chcieli zeby klient mial ograniczenia, zeby to wszystko bylo bezpieczne, a teraz kazdy informatyk po technikum bedzie mogl sobie robic zmodyfikowane zapytania i bedzie ok, no i ciekawe jak sie zabezpieczyc przed tym ukryc hasla i inne wrazliwsze dane, w prostym przypadku to wydaje sie wygodne ale przy wiekszych wymaganiach to wydaje sie byc koszmar

    •  
      d......o

      -34

      pokaż komentarz

      napisana z użyciem technologii które są ostatnio najbardziej sexy

      @noarch: beka z tych programistow15k co z tego ze kase ma jak dziewczyna/zona takiego delikwenta to najczesciej odpad, który chad by nie dotknal (max 5-6/10). Niestety mowie z doswiadczenia

    •  

      pokaż komentarz

      @sciana: Tylko dokłada kolejne newralgiczne punkty gdzie można zrobić luke bezpieczeństwa. W zwykłej komunikacji Rest można bardzo silnie dbać o to. A przy graphql jest z pilnowaniem ciężej.

    •  

      pokaż komentarz

      @sciana: przecież to front-endowiec powinien wprowadzać walidację do każdego pola.

      @Herron: wyłącz JS lub zrób zapytanie czymś innym niż przeglądarka.

      backend bez walidacji:

      źródło: i.kym-cdn.com

    •  

      pokaż komentarz

      @WydajnaJednostkaIndywidualna: React native jest do aplikacji mobilnych i o takim środowisku była mowa. Oczywiście web to co innego i masz rację.

    •  

      pokaż komentarz

      @Scandalous: @skowron-line: graphql od strony devów frontowych jest super, od strony backendu i bazy to jest to mordęga i wyrywanie włosów z głowy

      dla tych którzy nie rozumieją czym jest graphql, jest to uproszczenie, graphql ma swoją składnię itd. ale ogólnie wygląda to tak
      - front pyta api zwróć mi strukturę danych taką i taką, serwer generuje to i odpowiada dokładnie taką strukturą nie zwracając żadnych innych nadmiarowych danych
      - działa to w nieskończonym zagnieżdżeniu
      - jest opcja by zwrócić wszystkie dane
      - opcja paginacji
      - opcja filtrowania po dowolnej danej

      jaki z tym jest problem:
      - jest to bardzo elastyczne i pomaga frontowi w pierwszych etapach szybko wdrażać ale, ostatecznie zabija wydajność bo takie generowanie jest kosztowne, tj nie ma z tego co wiem dobrych automatów które generują zapytania na podstawie GraphQL do bazy tak by było to wydajne, najczęściej jest więc to bardzo BARDZO nie wydajne
      - samo takie generowanie to narzut na backend
      - od strony backendu nie wiesz do końca jakich pytań się spodziewać, chodzi o to że masz API normalne i masz 90 możliwych requestów, to bazodanowiec, programista może przejść te casey i je zoptymalizować bo widzi co jest zrobione, i może pod te rzeczy pisać zoptymalizowane query
      - w graphql, o ile nie masz agregacji zapytań i narzędzi do analizy co tam przychodzi, to masz dość rozmyte pojęcie jakie zapytania dostajesz
      - oczywiście też możesz optymalizować ale to jest trudniejsze, bo musisz wykrywać że dla zapytania o parametrach musisz zastosować customowe query i odpowiednio to optymalizować
      - taka optymalizacja na graphql jest podatna na regresję, przykład: zrobiono optymalizację dla jakiegoś query graphql, i działa to wydajnie, front zmodyfikował, puścił na produkcję, zapytania było trochę inne od tego zoptymalizowanego i użyty został nieefektywny mechanizm, strona została położona i trzeba było cofać zmiany
      - lub regers typu że optymalizacja zadziałała ale jakiś parametr został zignorowany,
      - bezpieczeństwo - skoro to frontend generuje zapytania, to ktoś może spreparować zapytanie tak by otrzymać jakąś niepubliczną informację i trochę ciężko się jest przed tym zabezpieczyć jak masz teoretycznie nieskończoną liczbę możliwości ataku, przez to imo graphql się średnio nadaje do danych niepublicznych, ktoś taki uniwersalny elastyczny mechanizm może jakoś przechytrzyć
      - backend developer musi napisać jakiś uniwersalny mechanizm, który zwróci dowolną informację, w dowolnej strukturze, dowolnie zagnieżdżoną, z paginacją lub bez, praktycznie więc developer musi napisać interfejs bazodanowy który przyjmuje graphql i odpowiednio to przetwarza by uzyskać dowolne informacje, wg mnie ciężkie do zrobienia i poza zasięgiem mniejszych projektów / małych zespołów

      jak na razie nie ma automatycznych narzędzi i bibliotek które generują odpowiednie zapytania do bazy danych, umożliwiają łatwą optymalizację, i dbają o bezpieczeństwo

      jedynie jakie biblioteki które znalazłem to robią dwie rzeczy:
      - dla każdego zapytania biorą i zbierają wszystkie informacje w jednej dużej tablicy, i w backendzie pętlami to filtrują i na tym robią cache
      - są takie które próbują używać ORMów, i robić joiny, ale zwykle padają przy bardziej skomplikowanych zapytaniach typu count na group by, cokolwiek z having itd.

      Jak dla mnie przy małych średnich projektach jest ok zrobić dużą tablicę, i filtrować to w backendzie w początkowej fazie projektu by szybko wprowadzać zmiany, zbierać informację co jest potrzebne itd, ale na pewnym etapie trzeba to zastąpić normalnymi, statycznymi endpointami które da się lepiej zoptymalizować i kontrolować.

    •  

      pokaż komentarz

      @WydajnaJednostkaIndywidualna: React native jest do aplikacji mobilnych i o takim środowisku była mowa. Oczywiście web to co innego i masz rację.

      @Herron: ale wiesz, że ta twoja apka mobilna robi zapytania do serwera, które widać chociażby w Fiddlerze i to nie problem odpytać serwer poza apką mobilną?

    •  

      pokaż komentarz

      @Herron: xD pewnie, najlepiej w htmlu określić ze e-mail i przecież komu się będzie chciało wejść w konsole i usunąć pare znaków żeby oszukać. Walidacja powinna odbywać się PRZEDE WSZYSTKIM przy przesłaniu requesta, a później jeszcze raz przed samym zapisem do bazy. Ta we froncie to najwyżej może ułatwić użytkownikowi niektóre kroki

    •  

      pokaż komentarz

      @WydajnaJednostkaIndywidualna: Tak, to nie jest problem, ale większość twoich uzytkowników będzie używała apki, a szkoda obciążać niepotrzebnie serwer setkami zbędnych zapytań. W przypadku kiedy masz z kilkaset tysięcy aktywnych użytkowników takie coś się przydaje. Oczywiście, zawsze dobrze mieć dodatkowe zabezbieczenie na serwerze.

    •  

      pokaż komentarz

      , a szkoda obciążać niepotrzebnie serwer setkami zbędnych zapytań.

      @Herron: przecież przy walidacji to nie jest żadne zapytanie, a sprawdzenia typów, zakresów i ew. regex - parę ifów.

      Walidacja ma być ZAWSZE też po stronie serwera. To, że Twój zwykły użytkownik użyje telefonu to nic.
      To, że potencjalny atakujący, na pewno nie użyje telefonu, a wspomoże się emulatorem to jest wazne.

    •  

      pokaż komentarz

      @adakar: napisal aplikace do analogiczneho systemu.

    •  

      pokaż komentarz

      @neizd: no ale niczego 'nowego', nie wymyslil...

    •  

      pokaż komentarz

      @Jaslanin:
      To o czym piszesz to automatyczne generowane zapytań dla GraphQL. Tego nikt rozsądny nie robi.
      Samodzielnie kontrolujesz agregowanie (dataloader).
      Dodatkowo możesz zablokować zbyt skomplikowane zapytania (query complexity check).
      Sprawdzenie złożoności zapytań jest wymagane jeśli bezmyślnie odwzorowujesz schemat bazy danych na schemat GraphQL. Generalnie opisujesz swoje schematy tak aby unikać cykli i wtedy jest ok. Podobnie jak REST jest reprezentacją stanów zasobu tak w GraphQL dajesz wygodny interfejs do odpytywania, nie udostępniasz wprost schematu swojej bazy danych

    •  

      pokaż komentarz

      Lepiej być testerem, niż bawić się w programowanie na dłuższą metę. Zarobki trochę niższe, ale nie trzeba się uczyć 24/7. Co roku aktualizacje + nowe technologie.

      @Herron: Lepiej zostać sprzątaczką, raz 5 lat upgrade mopa, raz na 10 upgrade odkurzacza.

    •  

      pokaż komentarz

      Lepiej być testerem, niż bawić się w programowanie na dłuższą metę. Zarobki trochę niższe, ale nie trzeba się uczyć 24/7.

      @Herron: lol

    •  

      pokaż komentarz

      @Jaslanin: poniekąd masz rację, mnie osobiście najbardziej denerwuje fakt że musisz mieć taka prisme odpalana jakos osobma instancja, czyli jak odpalisz sama apke w nodzie, to i tak musisz do niej mieć prisme odpalona. Nie wiem jak przy dużych projektach, przy małych mi sie sprawdzało, ale skoro Facebook coś takiego wprowadza, to do dużych też się nada, tylko trzeba mieć odpowiednią wiedzę.

    •  

      pokaż komentarz

      @Kiel_basa: być może moje use case jak do tej pory były nie kompatybilne z graphQL, w większości projektów i use casów potrzebuję by dane były świeże,

      dodatkowo dochodzi fakt że nie da się nie trzymać kilku TB danych na potrzeby graphQL w cache lub RAMie, muszę te dane mieć w bazie danych, nosql, document storage zależnie od konkretnego przeznaczenia, tzn jakąś część bym mógł, ale wtedy bym musiał obsługiwać dwie ścieżki, jedną z graphQL, drugą zwyczajną, ale nie widzę tu zalet, poza 4 razy większym nakładem pracy, który mógłby być wykorzystany do zrobienia czegoś co zarabia pieniądze.

      z tego co rozumiem to co opisujesz agregowaniem / dataloader, to jest to po prostu wyciągnij dane z bazy i innych źródeł do jakiejś dużej tablicy i trzymaj w niej, a filtrowaniem zajmuje się program który po tych danych skacze

      czyli tak naprawdę musisz napisać taki swój mechanizm jak Elastic Search, chyba nawet elastic search wspiera graphQL, ale takie coś się nie sprawdza jeżeli masz dane świeże

      np nie widzę możliwości wygenerowania na podstawie graphQL żadnego raportu np na potrzeby księgowe przy takim podejściu, bo z tego co wiem takie systemy jak elastic nie gwarantują żadnej transakcyjności

      dodatkowo są problemy z obsługą takich scenariuszy jak, wyszukaj coś, zmodyfikuj coś na podstawie wyników, i znowu coś wyszukaj żeby dane w kolejnym graphql już się znajdowały zmiany, wtedy to nie działa bo albo musisz regenerować cache, co powoduje obciążenie zwłaszcza jak jest dużo danych, albo mieć drugą ścieżkę poza graphql która obsługuje jakoś inaczej operacje na aktualizowanych danych, ale to jest wtedy dwa razy więcej roboty

      wiem że alternatywą dla regenerowania całościowego takiego cache, jest atomowa aktualizacja bezpośrednio na cache, ale tutaj z kolei dochodzimy do problemów transakcyjności, atomowości operacji itd. które musimy rozwiązywać, a które normalnie robi nam baza danych

      ja rozumiem że graphql nadaje się do danych które są rzadko modyfikowane, a często wyszukiwane, oraz jest akceptowalna pewna ich nieświeżość / poślizg aktualizacji, jak np trzymanie bazy produktowej sklepu w elastic search, i robienie query przy użyciu graph QL

    •  

      pokaż komentarz

      @Kiel_basa: ale nie bardzo widzę taki mechanizm działający na elastic od strony backendu, przynajmniej nie w małych i średnich projektach, ja rozumiem że np. w facebooku się to może udać zrobić, i jest to zasadne bo jak to zrobią, to każdy ich system może sobie łatwo pobrać dowolne dane i różni ludzie mogą dzięki temu szybko różne rzeczy analizować, ale jeżeli nie masz dużych zasobów by taki dobry mechanizm backendowy dla graphql zrobić, a z tego co widzę to dobrych open sourcowych nie ma, jest to problematyczne. Jedyny produkcyjne jakie widziałem dla małych średnich projektów bez zasobów facebooka, czy google. To wdrożenie graphql poprzez ładowanie danych do elastic search. Elastic Search je ramu jak krowa, ale ma te swoje shardy i fajnie się to skaluje. I jest w miarę tanie.

      Wiem że poza tym są narzędzia żeby to wdrożyć, które mają różne tooling ale to wszystko kosztuje pieniądze, i płaci się od liczby queries np. https://www.apollographql.com/plans , ta i temu podobne firmy oferują różne narzędzia typu śledzenie wywołań, agregację zapytań, analizę wolnych zapytań, ale to wszystko kosztuje spore pieniądze i jak dla mnie jest ryzykowne. Bo do końca nie wiem jak wygląda to z jakością działania tego wszystkiego. Bo może być tak że wdrożę to w swojej firmie, wydam pieniądze i utopię na to kasę.

      I tak analizując to wszystko to wyszło mi tak, że w moim konkretnym przypadku wydawanie na to kasy jest bez sensu. Bo ostatecznie wszystko sprowadza się do pytania jeżeli wprowadzę graphql i wydam kasę to ile na tym zarobię? jakie jest tego ryzyko? czy mnie na to stać? czy mam programistów w firmie którzy mi takie coś dowiozą :-).

      I wychodzi mi na to że:
      - to samo mogę wykonać tańszymi technologiami
      - kasy mało zaoszczędze bo wdrożenie tego jest kompleksowe
      - ryzyko jest duże bo mało programistów ma w tym doświadczenie, a nie mam takiego budżetu R&D jak google czy facebook, żeby móc taką ryzykowną implementację przeprowadzić. Tzn ja rozumiem że jak to zrobię to po paru iteracjach i wydaniu sporej kasy jakoś to będzie działało na graphql, ale nie widzę jak taki wydatek mi się zwróci

      tzn rozumiem że w kontekście facebooka, netflixa, google, ubera im się to opłaca, bo każdy w firmie może później wyciągnąć sobie przez to dane, zasilać sobie sztuczną inteligencję różnymi danymi, robić analizy data science w prosty i łatwy sposób jak uda im się to wdrożyć (i widzę jak dzięki temu te firmy zarobią na tym $$$) - i spoko jak pracujesz dla takiej firmy to jak najbardziej graphql to dobry pomysł.

      ale w małym średnim projekcie, to nie widzę by w graphql kasa się zwróciła, być może jak to dojrzeje i pojawi się dobry tooling to tak.

      niemniej jednak na początku projektu, gdy szybko się implementuje jakiś MVP, proof of concept, jakiś szkielet to graphql jest dobrym narzędziem, programista szybko stawia elastic, ładuje tam dane z bazy, potem frontendowiec sobie wyciąga dane, jest szybki loop że front nie musi czekać na backa aż mu zrobi endpointy albo wszystko mockować, ale na pewnym etapie to się przestaje sprawdzać jak potrzebujesz by jakiś endpoint się skalował itd. wtedy o wiele trudniej już to zrobić, tak samo o wiele trudniej zachować transakcyjność, atomowość operacji, świeżość danych itd. itd.

    •  

      pokaż komentarz

      @Lump139 sexy to ostatnio słowo hit w korpo. Każda oferta jest sexy. Szkolenia są sexy.

      Wcześniej modne było słowo mega

    •  

      pokaż komentarz

      @Jaslanin:

      Wydaje mi się, że nie do końca rozumiesz o co w tym GraphQL chodzi.
      Sam GraphQL to po prostu język.
      Możesz mieć w jednym backendzie zarówno REST i GraphQL, to jest spoko - to jest tylko twoje API.
      Modele/serwisy wywołujesz zarówno w controlerach RESTowych jak i w resolverach GraphQL.
      Jeśli masz jakiś endpoint w REST analogiczny możesz mieć w GraphQL.

      Na czym cały hype polega:
      Zamiast wiele razy pytać REST API o dane np. o książce:
      /Author/2/Books (tutaj dostaniemy id + tytuł)
      /Books/1 (tutaj wiemy jakie są komentarze do książki)
      /Books/2 (tutaj wiemy jakie są komentarze do książki)
      ...
      Itd.

      W GraphQL masz jedno zadanie do API. Może to być jedyna zaleta wobec REST, ale możesz też zoptymalizować zapytania.

      I tutaj wracamy do dataloader-a i batchowania, zamiast kilka razy odpytywać swoją bazę danych możesz zgrupować zapytania (np. prosty where in).
      Tutaj nie ma żadnej magii, dataloder jedynie zgrupuje wywołania twoim zadaniem jest implementacja jak pobrać takie dane dla grupy.

      Nie potrzeba do tego żadnego Elasticsearch etc.
      Jeśli korzystanie z GraphQL się nie opłaca to go nie stosujemy, serio. Jednak to jest obecnie tak proste i dobrze wspierane rozwiązanie, że trudno sobie wyobrazić żeby benefity, które daję były mniejsze od kosztów (narzut opisywania typów, nauka nowej technologii).
      Z własnego doświadczenia polecam wykorzystać GraphQL w jakiejś prostej funkcjonalności/mikro serwisie i samemu wyrobić sobie zdanie czy warto.

    •  

      pokaż komentarz

      Na czym cały hype polega:
      Zamiast wiele razy pytać REST API o dane np. o książce:
      /Author/2/Books (tutaj dostaniemy id + tytuł)
      /Books/1 (tutaj wiemy jakie są komentarze do książki)
      /Books/2 (tutaj wiemy jakie są komentarze do książki)

      @Kiel_basa: Jeśli wiesz, że na froncie będziesz potrzebował razem danych o książkach danego autora + o komentarzach do każdej z nich to po prostu przygotowujesz jeden endpoint, który ci to zwraca. Nie wiem skąd tu 3 zapytania ( ͡° ͜ʖ ͡°)

      GraphQL ma przewagę jedynie wtedy, gdy nie wiemy z góry o co będzie pytać front, więc chcemy przygotować maksymalnie elastyczne API.

    •  

      pokaż komentarz

      @WaveCreator:
      Później okazuje się że na froncie czasem potrzebujesz innego zestawu danych i masz endpointy:
      /BooksWithAuthorComments
      /BooksWithReviews
      Itd.

      Albo backendowca szlak trafia i zwraca zawsze wszystko i zwrotka waży 5MB ( ͡° ͜ʖ ͡°).

      Innym razem jednach chciałbyś korzystać z nagłówków do cachowania informacji o książce ale jak w zwrotce będziesz miał informacje o komentarzach do książki to o cache możesz zapomnieć.

    •  

      pokaż komentarz

      Później okazuje się że na froncie czasem potrzebujesz innego zestawu danych
      @Kiel_basa: A takie rzeczy to nie powinny się okazywać na etapie tworzenia specyfikacji projektu, jeszcze zanim powstanie pierwsza linijka kodu? ( ͡° ͜ʖ ͡°)
      Jeśli z góry wiemy, że po powstaniu pierwszej wersji api będzie dynamicznie ewoluować i obsługiwać coraz więcej coraz bardziej zróżnicowanych zapytań z różnych źródeł - to owszem, tutaj moim zdaniem GraphQL wydaje się rozsądniejszym wyborem niż REST.

      Ale trochę przeraża mnie to, że w artykułach opisujących GraphQL nie jest on przedstawiany jako alternatywa, tylko "REST umarł, niech żyje GraphQL". Hypetrain.exe ( ͡° ͜ʖ ͡°)

      Albo backendowca szlak trafia i zwraca zawsze wszystko i zwrotka waży 5MB ( ͡° ͜ʖ ͡°).
      Albo go szlag trafia jak musi przygotować schemę GraphQL dostosowaną do różnych poziomów uprawnień użytkowników i/lub aplikacji odpytujących API. Ale w sumie nas to nie interesuje - bo za to mu płacą, nie? ( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      @WaveCreator

      A takie rzeczy to nie powinny się okazywać na etapie tworzenia specyfikacji projektu, jeszcze zanim powstanie pierwsza linijka kodu
      Szanuję( ͡° ͜ʖ ͡°)

    •  

      pokaż komentarz

      Później okazuje się że na froncie czasem potrzebujesz innego zestawu danych i masz endpointy:
      /BooksWithAuthorComments
      /BooksWithReviews
      Itd.


      Albo backendowca szlak trafia i zwraca zawsze wszystko i zwrotka waży 5MB ( ͡° ͜ʖ ͡°).

      @Kiel_basa: no i tu pięknie pokazałeś przykład gdzie jest to przydatne! Właśnie o to chodzi! Natomiast pakowanie tego wszędzie, w szczególności jako API w aplikacjach gdzie nie ma mowy o reużywalności tego typu API (backend do większości tego typu aplikacji), gdzie frontent i backend robi ten sam team (albo ta sama osoba xD) gdzie w zasadzie gównie operujemy na zdarzeniach / komendach a nie zasobach no to jest zwykły Hype Driven Development albo CV Driven Development ;)

      pokaż spoiler to samo w sumie dotyczy HATEOASa

    •  

      pokaż komentarz

      @getin: Jaki ty jesteś p!?#$#@niety! Śmiejesz się z chłopaka, samouka, który na zachodzie jest doceniony przez olbrzymie korporacje i mógłby ciebie kupić razem z cała twoją wioską !

  •  

    pokaż komentarz

    Koleś użył floatów do obsługi transakcji finansowych. Sam bym mu nie zapłacił za takie gówno.

  •  

    pokaż komentarz

    Wow! 9 tysięcy gwiazdek, ponad tysiąc głosów i 200 komentarzy.
    Się obłowił xD

  •  

    pokaż komentarz

    wykopalisko z płomieniem i tylko 6 komentarzy
    meh zawszę liczę że poczytam sobie jakieś fajne dyskusje a tutaj zawód niestety

  •  

    pokaż komentarz

    Przecież tu nie ma czego wykopywać. Ta apka niewiele w sumie robi trochę wygląda jak lekko rozbudowane example z tutoriali, nic więcej... a wypopki łykają jak pelikany i news juz trafił na główną z płomieniem.
    beka!

    źródło: i.wpimg.pl