GraphQL Patrzę sobie w źródła strony, która korzysta z GraphQL (którą to jest https://en.zalando.de) i po raz kolejny nie mogę wyjść z podziwu, kto wpadł na pomysł, by stworzyć równie pokraczne dziadostwo, produkujące na wyjściu taki śmietnik w kodzie. No bo przecież to świetny pomysł i porządna inżynieria aby w JSON-ie kluczem w danych był kolejny JSON. Strona embeduje zatem potworny kawał JavaScriptu, który to ma z kilka tysięcy linii po sformatowaniu i oczywiście n poziomów zagnieżdżeń, żeby się go czasem zbyt łatwo nie zanalizowało, w którym to tkwią klucz w rodzaju:
"{\"id\":\"cb96571222c2df7160e55fd1765c7044a48026b6d47f61e99f9bdd6afffbe9f8\",\"variables\":{\"keys\":[\"product.flag.earlyaccess.plus\",\"pdp.plus.earlyaccess.reminder.confirmation.headline\",\"pdp.plus.earlyaccess.reminder.confirmation.subheadline\",\"pdp.plus.earlyaccess.reminder.confirmation.body\",\"pdp.plus.earlyaccess.reminder.confirmation.body.wishlist\",\"pdp.plus.earlyaccess.reminder.error\",\"max.order.limit.notification.pdp\",\"max.customer.limit.notification.pdp\",\"max.customer.limit.notification.wardrobe.web\",\"brand.follow.notification\",\"wishlist.add.notification\"],\"host\":\"en.zalando.de\"}}"
I z takich oto bohomazów można wydłubywac różne dane.
>>> pprint.pprint(json_data["graphqlCache"]["{\"id\":\"cb96571222c2df7160e55fd1765c7044a48026b6d47f61e99f9bdd6afffbe9f8\",\"variables\":{\"keys\":[\"product.flag.earlyaccess.plus\",\"pdp.plus.earlyaccess.reminder.confirmation.headline\",\"pdp.plus.earlyaccess.reminder.confirmation.subheadline\",\"pdp.plus.earlyaccess.reminder.confirmation.body\",\"pdp.plus.earlyaccess.reminder.confirmation.body.wishlist\",\"pdp.plus.earlyaccess.reminder.error\",\"max.order.limit.notification.pdp\",\"max.customer.limit.notification.pdp\",\"max.customer.limit.notification.wardrobe.web\",\"brand.follow.notification\",\"wishlist.add.notification\"],\"host\":\"en.zalando.de\"}}"]["data"]["translations"])
{'brand.follow.notification': 'Following! Find more brands or adjust your list '
'anytime in your account.',
'max.customer.limit.notification.pdp': 'You’ve already purchased this product '
'and reached the max limit as a '
'customer.',
'max.customer.limit.notification.wardrobe.web': 'Looks like you’ve already '
'ordered the max amount of '
'this item.',
'max.order.limit.notification.pdp': 'It looks like you already purchased the '
'maximum limit of exclusive items.',
'pdp.plus.earlyaccess.reminder.confirmation.body': 'We’ll send you an email '
'when this item drops.',
'pdp.plus.earlyaccess.reminder.confirmation.body.wishlist': 'For now, we’ve '
'added this to '
'your liked items '
'so you can find '
'it again.',
'pdp.plus.earlyaccess.reminder.confirmation.headline': 'All set!',
'pdp.plus.earlyaccess.reminder.confirmation.subheadline': 'You’ll be first to '
'know',
'pdp.plus.earlyaccess.reminder.error': 'We hit a snag! Try setting the '
'reminder again.',
'product.flag.earlyaccess.plus': 'Early Access',
'wishlist.add.notification': 'The item was added to your wish list.'}
Jak ktoś korzysta z bibliotek i frameworków, które chowają przed nim całą tę cudaczną złożoność to może i uważa, że GraphQL to fajny gadżet i przyszłość web developerki, ja jednak, zaglądając pod maskę czuję tylko paskudny swąd strasznego partactwa. Coś chyba pospolitego w pociesznym świecie frontów, że by tylko przypomnieć pocieszny wpis How it feels to learn JavaScript in 2016, czy node.js z ich cudacznym środowiskiem i śmietnikiem jaki się wciąga przy każdej próbie spakowania wszystkiego do kupy (bo x polega na y, które polega na z, które wciąga niesławne is-even, bo developer co to pisał najwyraźniej nie wiedział jak to się sprawdza).
Wy tak żyjecie?
node.js z ich cudacznym środowiskiem i śmietnikiem jaki się wciąga przy każdej próbie spakowania wszystkiego do kupy (bo x polega na y, które polega na z, które wciąga niesławne is-even Czy takie przechodnie zależności są zawsze problemem czy tylko jak trzeba optymalizować wielkość wynikowej paczki? Np dla Haskella są dwie biblioteki do testów wydajnościowych criterion i gauge. Mają to samo api a główną zaletą gauge jest to że ma tylko 12 zależności a criterion ma - 63. Za to główną zaletą criteriona jest to że jest pobłogosławiony przez twórców Haskella (nie wiem na czym to błogosławieństwo polega konkretnie, ale repo criteriona jest w organizacji haskell na githubie
Pytanie jeszcze czy motywacja twojej krytyki sa jakies kwestie czysto optymalizacyjne czy po prostu to jak to wyglada wizualnie w JSON-ie? Bo GraphQL nie sluszy do ogladania w JSON-ie...
wydłubywać dane z HTML-a ale w HTMLu sa divy i inne spany a nie JSONy i nie GraphQL, lol
Nie scrapuję API tylko bezpośrednio stronę. A JSON-y i inne GraphQL-owe śmieci są w tagach <script>, potem przeglądarka to składa do kupy.
I uprzedzając pytanie: mogę jak człowiek iść do API, wpis tyczy się tego jaki tworzy się śmietnik w źródłach za plecami użytkowników, bo JSON będący kluczem w JSON-ie to jednak dla mnie pewien ewenement ;)
żadnych plusów nie było z tego, a minusy w postaci niewygodnych zapytań, klepania schematów
Straszne ogolniki rzuciles, trudno nawet to zakwestionowac no bo nie wiadomo o co Ci chodzi :p
klepania schematów Masz na mysli "schema"? To w Calibanie np. same sie klepia
był se kiedyś SOAP i komu to przeszkadzało :(