@noarch dzięki

technologii które są ostatnio najbardziej sexy

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

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

@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

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

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

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

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

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.

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

@yuio a tak to;dr co poszło nie tak?

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

@noarch: "sexy" XDDDDDDD

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

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

@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

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

@Herron: lepiej smażyć burgery.

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

@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

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

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

@noarch: trendy to jest Rust

@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

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

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

@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ą?

@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

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

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

@adakar: napisal aplikace do analogiczneho systemu.

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

@Scandalous dlive.io wykorzystuje GraphQL

@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

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.

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

@yuio: Wolaj :)

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

@depresso: własnego? Iks de

@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

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

@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

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

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.

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

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? ( ͡° ͜ʖ ͡°)

@WaveCreator

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

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


@swagerstom facebook tez

@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ą !

@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

@resource_1337: dokładnie tak samo. Takie błędy robić. Za projekt nie płacić a wykopalisko zakopać

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

@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

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

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

@Instynkt: ale na backendzie on nie używa programu Microsoft MYSQL tylko Node.js

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

@resource_1337: No gupek, powinien użyć drainerów i destroyerów i opakować to w podwójną ciągłą na zapętleniu przez command conquer na airlinerze.

@yraras: Co ma Microsoft do MySQL, co ma MySQL do node.js?

@Aysorth: lol, mnie pytasz? pytaj kolegę Instynkt który podesłał link

@yraras: xD

@tamtokontojuzusunalem Dlaczego decimal a nie float? Kiedy taki błąd może wystąpić? Jakieś źródło? Bardzo mnie to interesuje.

@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

@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

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

Ja jebie, gdzie wy się uczyliscie programować że nie więcej jak działają liczby zmiennoprzecinkowe

https://floating-point-gui.de/

@graffer: zdefiniuj sobie dwie zmienne typu float, przypisz im wartości 0.1 i 0.2 i je dodaj.

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

Ż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

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

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

@graffer: https://pl.wikipedia.org/wiki/Epsilon_maszynowy

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

@Instynkt: znajdz jeszcze artykuł dlaczego w ogóle używać do czegokolwiek mysqla xD

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

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

@IvanBarazniew: mhm szczególnie ze wszystkie ormy obsługują wszystkie klasy stworzone przez społeczność (y)

@resource_1337: ja tam się nie znam (rok klepania w javie here), ale w Node nie ma jakiegoś odpowiednika javowego Money? Albo chociaż decimal?

@PrettyMuchDeadAlready: A o decimalu pan słyszał?

@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) {...}

@yraras: powiedz typie że nie zarabiasz na życie kodując... Błagam.

Chodzi o typ danych, nie o css xD

@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

@IvanBarazniew: nadal nie uzywasz doubla albo floata prawda ?;)

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

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

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

@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

@yuim: zwłaszcza że każda szanująca się uczelnia uczy metod numerycznych gdzie między innymi teoria błędów jest omawiana

@resource_1337 z takich ciekawostek to Hybris czyli jedna z większych platform ecommerce używa double'a do operacji na cenach ᕙ(⇀‸↼‶)ᕗ

@edgar_k zapnij ORMa do projektu, narzekaj że BigDecimal jest wolny. Jap%$%!%@e xD

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

@animuss: to też jest ciekawsze :)

#include <stdio.h>

int main()
{
float x = 100000000.0;
while(x <= 100000000.1){
++x;
}
printf("Skończone");

return 0;


}

@MAti_gca: dobre :>

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

@misieg8: dzień dobry, programista 1200 na rękę here. W JavaScripcie nie ma intów. ( ͡° ͜ʖ ͡°)

@Striker009: Procesor Intel! Dysk tysionc!

@Striker009: no jakby nie patrzeć otworzył sobie drogę na świat a i klientowi który nie zapłacił może dokopać.

@Striker009: vikop power

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

@ArseneWengerTheAnimatedSeries: Możesz popatrzeć w kod ( ͡° ͜ʖ ͡°)

@ArseneWengerTheAnimatedSeries: programiści 15k to raczej małomówne nerdy - czego Ty oczekujesz ( ͡º ͜ʖ͡º)

@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 ( ͡° ͜ʖ ͡°)

@Linuksiarz1: bo w tego typu znaleziskach nie da się rzucić łatwym, populistycznym hasłem, które dostanie pierdyliard plusów.

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

@Da_R_ecky: pewnie zamiast gadać bez sensu zarabiają w tym czasie

@ArseneWengerTheAnimatedSeries: poszła dyskusja wyżej jakby co ( ͡° ͜ʖ ͡°)

@FantaZy: no i pewnie napisałbyś lepszą w lepszej technologi, ale szkoda ci czasu

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

@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ę ( ͡° ͜ʖ ͡°)

@FantaZy: No ale przecież nie zapłacił! ( ͡° ͜ʖ ͡°)ﾉ⌐■-■

@Murasame: W Polsce jest tylu programistów 15 000+, ze większość siedzi na Wykopie bez pracy (a mniejszość w pracy na FB).