
Nie dostał zapłaty za wykonany projekt - więc udostępnił go... za darmo
Po aferze z nieuczciwym klientem kod źródłowy aplikacji został upubliczniony przez jego twórcę, a sam projekt stał się mega popularny na GitHubie - zebrał do tej pory niemal 9 tysięcy gwiazdek, a sama historia Jasona Wernera na Reddicie otrzymała już ponad tysiąc głosów i 200 komentarzy.
+378
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
+555
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").
+156
pokaż komentarz
@noarch dzięki
-653
pokaż komentarz
technologii które są ostatnio najbardziej sexy
@noarch: serio? ( ͡º ͜ʖ͡º)
źródło: img.izismile.com
+353
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
+34
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...
+68
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.
+69
pokaż komentarz
@noarch: czyli... Wymyslil 'punkty PayBack'.... No k@%@a brawo
+40
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).
+8
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ć.
+13
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.
+45
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
+3
pokaż komentarz
@yuio a tak to;dr co poszło nie tak?
+1
pokaż komentarz
@yuio chętnie poczytam, dobry artykuł pod medium. wołaj ;)
-11
pokaż komentarz
@noarch: "sexy" XDDDDDDD
+7
pokaż komentarz
@yuio: Również chętnie poczytałbym case study z większego projektu z GQL
+1
pokaż komentarz
@Lump139: samce alfa kodu ( ͡° ͜ʖ ͡°)
-26
pokaż komentarz
@sciana: przecież to front-endowiec powinien wprowadzać walidację do każdego pola.
0
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
-15
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.
+10
pokaż komentarz
@Herron: lepiej smażyć burgery.
+46
pokaż komentarz
@Herron: ta, jakbym ufał frontendowcom to bym teraz bez ręki chodził.
-6
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
-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
0
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.
0
pokaż komentarz
@noarch: trendy to jest Rust
+97
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
0
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ę.
+52
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ć.
+3
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ą?
+10
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
-4
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.
+23
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.
0
pokaż komentarz
@adakar: napisal aplikace do analogiczneho systemu.
-2
pokaż komentarz
@neizd: no ale niczego 'nowego', nie wymyslil...
0
pokaż komentarz
@Scandalous dlive.io wykorzystuje GraphQL
+4
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
+8
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.
+4
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
0
pokaż komentarz
@yuio: Wolaj :)
0
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ę.
+1
pokaż komentarz
@depresso: własnego? Iks de
+3
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
+1
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.
0
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
0
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.
0
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.
+1
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ć.
+2
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? ( ͡° ͜ʖ ͡°)
+1
pokaż komentarz
@WaveCreator
A takie rzeczy to nie powinny się okazywać na etapie tworzenia specyfikacji projektu, jeszcze zanim powstanie pierwsza linijka kodu
Szanuję( ͡° ͜ʖ ͡°)
+1
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
0
pokaż komentarz
@swagerstom facebook tez
0
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ą !
+448
pokaż komentarz
Koleś użył floatów do obsługi transakcji finansowych. Sam bym mu nie zapłacił za takie gówno.
-150
pokaż komentarz
@resource_1337: A co jest zlego z Floatami czy Doublami do transakcji finansowych? Brak precyzji czy niedokladne odwzorowanie to problem do rozwiazania.
http://vanillajava.blogspot.com/2011/08/double-your-money-again.html?m=1
+130
pokaż komentarz
@resource_1337: dokładnie tak samo. Takie błędy robić. Za projekt nie płacić a wykopalisko zakopać
+27
pokaż komentarz
@PrettyMuchDeadAlready: co jest złego ... Może zamiast jak w tym artykule poprawiać błędy to najlepiej ich unikac? Nie chcesz big decimala bo wolny i nie umiesz używać to użyj longa i mnoz i dziel przez 100. A tak naprawdę to prędkość ram nie są teraz problem... Problemem jest czytelność kodu , nawal korekcji lub mnożenia 100 to na pewno kolejni którzy tego dotknął będą happy...
-121
pokaż komentarz
@resource_1337: a co ma css to do transakcji finansowych? jak lubi niech używa floatów, bo np. flex nie działa pod IE9
+217
pokaż komentarz
@resource_1337: Tak, to jest błąd w sztuce. Do operacji księgowych używamy Decimala. W kazdym razie problem wystepuje wyłącznie przy dlugotrwałej akumulacji dużych kwot i wprowadza blad rzedu 0,00001% średniej kwoty przelewu. W przypadku tej aplikacji jest to dopuszczalny trade-off, szczególnie jeśli nie ma tam akumulacji stanu konta. Tym bardziej, jeśli wlaściciel platformy i tak skubie sobie z tego jakiś procent, a użytkownicy się na to skubanie zgadzają.
+23
pokaż komentarz
a co ma css to do transakcji finansowych? jak lubi niech używa floatów, bo np. flex nie działa pod IE9
@yraras: ------>>>>> https://www.dobreprogramy.pl/slepciu/Dlaczego-w-MySQLu-nie-stosowac-typu-FLOAT,30401.html
-119
pokaż komentarz
@Instynkt: ale na backendzie on nie używa programu Microsoft MYSQL tylko Node.js
-102
pokaż komentarz
Komentarz usunięty przez moderatora
+87
pokaż komentarz
@yraras: Co ma Microsoft do MySQL, co ma MySQL do node.js?
-77
pokaż komentarz
@Aysorth: lol, mnie pytasz? pytaj kolegę Instynkt który podesłał link
+30
pokaż komentarz
@yraras: xD
+2
pokaż komentarz
@tamtokontojuzusunalem Dlaczego decimal a nie float? Kiedy taki błąd może wystąpić? Jakieś źródło? Bardzo mnie to interesuje.
+35
pokaż komentarz
@graffer bo float nie jest dokładny a jedynie pewnym przybliżeniem (zwłaszcza dla niektórych ulamkow). Jak będziesz cały czas wykonywał operacje na liczbach obarczonych błędem to ten błąd będzie się kumulował.
Poczytaj na Wiki o liczbach zmiennoprzecinkowych i jak są one zapisywane w komputerze
+26
pokaż komentarz
@graffer: juz samo 0.1 nie dasz rady zreprezentowac w systemie binarnym bez zaokrąglen, albo np. 11* 0.1 wyjdzie ci inaczej niz jakbys w petli +=0.1 robił 11 razy bo wtedy blad sie poteguje i wyjdzie ci inna liczba dlatego tez nie porownuje sie znakiem rowna (==) sie liczb zmiennoprzecinkowych. No i dodatkowo w double/floatach nie masz żadnej kontroli nad tym jaka jest precyzja, mniejsza lub wieksza i jak sie powinno zachowywac zaokraglanie przy obliczeniach bo są różne metody zaokraglania
+34
pokaż komentarz
@resource_1337: dzien dobry - programista 15k z tej strony. do obslugi kwot w transakcjach finansowych uzywamy int-ow a w kodzie owijamy je value-objectami. dziekuje ze moglem pomoc. pozdrawiam!
+26
pokaż komentarz
Ja jebie, gdzie wy się uczyliscie programować że nie więcej jak działają liczby zmiennoprzecinkowe
https://floating-point-gui.de/
+6
pokaż komentarz
@graffer: zdefiniuj sobie dwie zmienne typu float, przypisz im wartości 0.1 i 0.2 i je dodaj.
+8
pokaż komentarz
@misieg8 Java ma wrapper w postaci klasy Money do rozwiązywania takich drogich problemow.
Z drugiej strony integrowalem się już z systemem jednej z polskich firm IT na C, gdzie api wymagało przesyłania kasy w double.
+45
pokaż komentarz
Żeby trzeba było tłumaczyć programistom, że float nie nadaje się do operacji finansowych bo w kursie "js w 15 min" nie było o tym. kurła kiedyś to było
0
pokaż komentarz
@graffer: Dlatego że liczby rzeczywiste działają w niżej opisany sposób. Liczba jest reprezentowana jako ułamek * 2 ^ przesunięcie. Ułamek jest w przedziale [1,2) więc między każdą kolejną potęga 2 jest tyle samo liczb, czyli tylko tyle ile na to pozwala ułamek. Oraz sama dokładność reprezentacji jest ograniczona do długości mantysy. Czyli jeśli twoja liczba jest dłuższa w zapisie 2kowym od mantysy będzie jakiś błąd.
+14
pokaż komentarz
@graffer: Dla floata jest to tylko ok 7 cyfr dla systemu 10tkowego więc to nie jest niezwykle duża liczba np. program :
#include<stdio.h>
int main() {
float x=1000000.11;
printf("%f",x);
}
Wyświetli 1000000.12
Dodatkowo ten błąd powiększa się z każdą operacją zgodnie z nią i w operacjach finansowych szybko ci się mocno akumuluje.
+1
pokaż komentarz
@graffer: https://pl.wikipedia.org/wiki/Epsilon_maszynowy
+12
pokaż komentarz
@resource_1337: A czemu by do takich operacji nie używać po prostu liczb całkowitych i przechowywać liczbę groszy w pamięci? Wtedy błąd jest zerowy, a i 64-bitowa liczba powinna wystarczyć.
-3
pokaż komentarz
@Instynkt: znajdz jeszcze artykuł dlaczego w ogóle używać do czegokolwiek mysqla xD
+13
pokaż komentarz
@nastarkill:
co jest złego ... Może zamiast jak w tym artykule poprawiać błędy to najlepiej ich unikac? Nie chcesz big decimala bo wolny i nie umiesz używać to użyj longa i mnoz i dziel przez 100. A tak naprawdę to prędkość ram nie są teraz problem... Problemem jest czytelność kodu , nawal korekcji lub mnożenia 100 to na pewno kolejni którzy tego dotknął będą happy...
A może po prostu zamiast wynajdować koło na nowo bierzesz klasę Money z dowolnego frameworka, gdzie ktoś już przemyślał, zaimplementował, przetestował i sprawdził w boju?
-1
pokaż komentarz
@anuar2k: można ale czasami trzeba wykonać kilka działań i w taki sposób byś stracił sporo dokładności np mnożąc 1.20001 a później dzieląc ponownie (przewalutowanie)
0
pokaż komentarz
@IvanBarazniew: mhm szczególnie ze wszystkie ormy obsługują wszystkie klasy stworzone przez społeczność (y)
-1
pokaż komentarz
@resource_1337: ja tam się nie znam (rok klepania w javie here), ale w Node nie ma jakiegoś odpowiednika javowego Money? Albo chociaż decimal?
0
pokaż komentarz
@PrettyMuchDeadAlready: A o decimalu pan słyszał?
+18
pokaż komentarz
@tamtokontojuzusunalem:
problem wystepuje wyłącznie przy dlugotrwałej akumulacji dużych kwot
Nie prawda, występuje nawet przy dodaniu 2 małych wartości:
`
class Program
{
static void Main(string[] args)
{
double x = 0.1;
double y = 0.2;
double z = 0.3; // x + y
double xPlusY = x + y;
Console.WriteLine(xPlusY); // 0.3
Console.WriteLine(xPlusY - z); // 5.55111512312578E-17
Console.WriteLine(xPlusY == z); // false
}
}
`
Porównywanie czy 2 zmienne typu float/double, mają taką samą wartość jest niewiarygodne. Stosuje się porównanie z uwzględnieniem dokładności:
if(Math.Abs(a - b) < epsilon) {...}
+3
pokaż komentarz
@yraras: powiedz typie że nie zarabiasz na życie kodując... Błagam.
Chodzi o typ danych, nie o css xD
+4
pokaż komentarz
@IvanBarazniew: bigdecimal wolny xD ciekawe ile razy padło takie stwierdzenie po porządnym profilowaniu kodu a ile razy jakiś wannabe specjalista uznał, ze pora na optymalizacje bo tak
0
pokaż komentarz
@IvanBarazniew: nadal nie uzywasz doubla albo floata prawda ?;)
0
pokaż komentarz
@edgar_k:
bigdecimal wolny xD ciekawe ile razy padło takie stwierdzenie po porządnym profilowaniu kodu a ile razy jakiś wannabe specjalista uznał, ze pora na optymalizacje bo tak
A gdzie ja coś takiego napisałem?
+2
pokaż komentarz
@boskizigolo:
mhm szczególnie ze wszystkie ormy obsługują wszystkie klasy stworzone przez społeczność (y)
A co ma piernik do wiatraka?
Napisanie własnego typu / mapera pod orm to żaden wyczyn. Jak kod opublikujesz to ci jeszcze społeczność pomoże.
0
pokaż komentarz
@nastarkill: Raczej gotowej klasy do obliczeń na pieniądzach, która np uwzględnia też walutę. W środku jest typ całkowity w bazie danych też. Używanie zmiennoprzecinkowych typów do operacji walutowych jest obarczone błędem.
Oczywiście wszystko zależy od tego co robisz i liczysz - zapewnię w niektórych zastosowaniach float, czy double jest ok.
0
pokaż komentarz
@tamtokontojuzusunalem: niestety nie jest to prawda, poprawiałem taki błąd w aplikacji ubezpieczeniowej gdzie nie ma jakieś "długotrwałej akumulacji" To co się wyliczy u klienta w przeglądarce jest oczywiście potem weryifkowane w backendzie i co chwila była różnica
+1
pokaż komentarz
@yuim: zwłaszcza że każda szanująca się uczelnia uczy metod numerycznych gdzie między innymi teoria błędów jest omawiana
0
pokaż komentarz
@resource_1337 z takich ciekawostek to Hybris czyli jedna z większych platform ecommerce używa double'a do operacji na cenach ᕙ(⇀‸↼‶)ᕗ
+2
pokaż komentarz
@edgar_k zapnij ORMa do projektu, narzekaj że BigDecimal jest wolny. Jap%$%!%@e xD
+9
pokaż komentarz
A co jest zlego z Floatami czy Doublami do transakcji finansowych?
najzabawniej z floatem jest w C++: ( ͡° ͜ʖ ͡°)
zadanie: liczbę 2 dodać 20 mln razy. Nie ma ułamków!
int main() {
const int N = 20000000;
const float C = 2;
// sumowanie
float sum = 0;
for (int i=0; i<N; i++)
sum+=C;
cout << "sum = " << sum << endl;
cout << "C*N = " << C*N << endl;
cout << "diff = " << C*N - sum << endl;
}
błąd wynosi 6 milionów przy wyniku prawidłowym 40 milionów. ( ͡° ͜ʖ ͡°) z liczbami ułamkowymi nie lepiej.
wołam wszystkich, też tych co się znają, dla ciekawostki :>
@tamtokontojuzusunalem: @PrettyMuchDeadAlready: @graffer @krasnoludkolo @niko444 @misieg8 @yuim @nuklear @ChilledMimosa @DudaChudeUda @MAti_gca @DonTom @9Mn3bsRvWlWjP9W8JbgL @resource_1337
0
pokaż komentarz
@animuss: to też jest ciekawsze :)
#include <stdio.h>
int main()
{
float x = 100000000.0;
while(x <= 100000000.1){
++x;
}
printf("Skończone");
return 0;
}
0
pokaż komentarz
@MAti_gca: dobre :>
-1
pokaż komentarz
Nie prawda, występuje nawet przy dodaniu 2 małych wartości:
@9Mn3bsRvWlWjP9W8JbgL: Tak, występuje błąd na poziomie 5E-17. Nawet nie jesteś w stanie wypowiedzieć tej wartości. Jeśli zaokranglanie przy rzutowaniu na centy czy grosze jest obustronny, to będzie działać.
+2
pokaż komentarz
@misieg8: dzień dobry, programista 1200 na rękę here. W JavaScripcie nie ma intów. ( ͡° ͜ʖ ͡°)
+153
pokaż komentarz
Wow! 9 tysięcy gwiazdek, ponad tysiąc głosów i 200 komentarzy.
Się obłowił xD
+203
pokaż komentarz
@Striker009: Procesor Intel! Dysk tysionc!
-13
pokaż komentarz
@Striker009: no jakby nie patrzeć otworzył sobie drogę na świat a i klientowi który nie zapłacił może dokopać.
-6
pokaż komentarz
@Striker009: vikop power
+17
pokaż komentarz
@Striker009: Te 9 tysięcy gwiazdek to może nic nie znaczy, ale pojawienie się na głównej wykopu to dopiero zaszczyt i sława ( ͡° ͜ʖ ͡°) Będzie dzieciom o tym opowiadał
+55
pokaż komentarz
wykopalisko z płomieniem i tylko 6 komentarzy
meh zawszę liczę że poczytam sobie jakieś fajne dyskusje a tutaj zawód niestety
+21
pokaż komentarz
@ArseneWengerTheAnimatedSeries: Możesz popatrzeć w kod ( ͡° ͜ʖ ͡°)
+21
pokaż komentarz
@ArseneWengerTheAnimatedSeries: programiści 15k to raczej małomówne nerdy - czego Ty oczekujesz ( ͡º ͜ʖ͡º)
0
pokaż komentarz
@ArseneWengerTheAnimatedSeries: @Da_R_ecky: Ale to raczej nie chodzi o to. Nie wiem jak wy, ale ja od pewnego czasu widzę, że coraz mniej użytkowników komentuje wpisy. Może mi się wydaje może nie, ale takie mam wrażenie ( ͡° ͜ʖ ͡°)
+5
pokaż komentarz
@Linuksiarz1: bo w tego typu znaleziskach nie da się rzucić łatwym, populistycznym hasłem, które dostanie pierdyliard plusów.
+2
pokaż komentarz
@ArseneWengerTheAnimatedSeries: Daj im chwilę, myślisz, że tak łatwo politykę albo żydów do takich wątków wkręcić? Może łatwiej byłoby coś lewica/prawica, z tym wyzyskiem zleceniodawcy, ale też ciężko.
-1
pokaż komentarz
@Da_R_ecky: pewnie zamiast gadać bez sensu zarabiają w tym czasie
0
pokaż komentarz
@ArseneWengerTheAnimatedSeries: poszła dyskusja wyżej jakby co ( ͡° ͜ʖ ͡°)
+70
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
-4
pokaż komentarz
@FantaZy: no i pewnie napisałbyś lepszą w lepszej technologi, ale szkoda ci czasu
+2
pokaż komentarz
@YerbajTo: Co w tym dziwnego, skoro w Polsce jest tylu dobrych programistów, a większość siedzi na wykopie? I nie piszę tego z sarkazmem. Z osób, które wykopały te znalezisko, znalazłbyś pewnie z 50, które napisałyby to lepiej.
-1
pokaż komentarz
@FantaZy: Przecież tu sami programiści15k, więc pewnie za bardzo wczuli się w sytuację, bo każdy z nich miał taki przypadek, gdzie zrobił super mega odjechany projekt, a klient go zlał i nie zapłacił za robotę ( ͡° ͜ʖ ͡°)
+1
pokaż komentarz
@FantaZy: No ale przecież nie zapłacił! ( ͡° ͜ʖ ͡°)ノ⌐■-■
-2
pokaż komentarz
@Murasame: W Polsce jest tylu programistów 15 000+, ze większość siedzi na Wykopie bez pracy (a mniejszość w pracy na FB).