LINUX.ORG.RU

GraphQL создает свою OpenSource foundation

 , ,


0

2

GraphQL, data-ориентированный язык запросов для Web-сервисов (REST-сервисов), который был разработан в компании Facebook, создает свою open-source foundation и переходит под ее управление. GraphQL Foundation будет находиться и хоститься под эгидой Linux Foundation.

>>> Детали

— Кто на ком стоял? - Крикнул Филипп Филиппович, - потрудитесь излагать ваши мысли яснее.

Язык запросов создаёт свою open-source foundation но будет под эгидой другой open-source foundation?

Знаю мормона Мацумото, Гвидона ван Россума, Ларри Уолла, Иеруcалимски, но а кто такой «Язык запросов»?

Bruce_Lee ★★ ()
Последнее исправление: Bruce_Lee (всего исправлений: 2)

Новость про фонд поддержки малоизвестного языка.

Это, конечно, хорошо. Но нельзя ли написать про сам язык — язык запросов к чему? На что он похож?

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

Как раз новость для того, что если кто-то не слышал до этого, да узнает :) на самом деле сейчас довольно трендовая вещь и как ни странно удобная. Переписывать вики смысла нет, но вкратце: теперь ты не пишешь апи экшн на каждый новый чих, а задаёшь то что тебе надо получить в самом запросе. Это очень примитивное объяснение, конечно. Но это удобно использовать, например, в том же vue и react. Ты сразу задаёшь те поля которые ожидаешь. И не тащишь огромные объекты в виде джейсонов

GreenBag ★★ ()
Ответ на: комментарий от WitcherGeralt

В статье полтора абзаца и ННП.

новый NIH-велосипед от морда-книги. теперь толпы леммингов опять ломануться внедрять это чудо велосипедостроения в свои сайтики. ну, ладно морда-книга, которая решает свои специфические проблемы, отказываясь от удобства и распространенности/известности инструмента ради прироста производительности, который им жизненно необходим. но толпам леммингов кажется, что это - прогресс и они в него ломятся!

вот недавно только, вытягивал проект из полной жопы. хипстеры начитались где-то про falcon (веб-фреймворк есть такой, нихрена не умеет, но делает это очень быстро). я их спрашиваю: «какого х не на django rest framework???» а они: «falcon - впереди планеты. его там тот-то использует». «а у вас уже проблемы с производительностью появились или команда как у того-то, чтобы все самим писать???».

anonymous ()
Ответ на: комментарий от tailgunner

Речь о том, что ты отправил человека читать пустую статью в Википедии, лучше бы сразу эту ссылку дал.

Мне не очень интересно, и слегка в теме, но сходил и прочёл. Мотивацию понял, но смысла в упор не увидел.

WitcherGeralt ()
Ответ на: комментарий от GreenBag

апи экшн

в том же vue и react

Ну вот теперь стало понятно, что это что-то для веб-разработки. Впрочем, tailgunner уже поправил текст новости так, что это теперь можно понять и из самой новости.

// Ушёл читать статью по ссылке из комментариев.

P.S. tailgunner: Ещё можно было бы web-development в теги добавить. Из тех, которые проставлены сейчас, он был бы самым информативным. :)

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 4)
Ответ на: комментарий от anonymous

вот недавно только, вытягивал проект из полной жопы. хипстеры начитались где-то про django (веб-фреймворк есть такой, дохера умеет, но делает это очень плохо). я их спрашиваю: «какого х не на flask, pyramid и GraphQL ???» а они: «django - впереди планеты. его там тот-то использует». «а у вас уже потребность в функционале из коробки появилась или команда как у того-то, чтобы каждый запрос самим писать???».

anonymous ()
Ответ на: комментарий от anonymous

Про леммингов соглашусь, но не полностью. Графкуэль облегчает жизнь обезьянкам-«программистам», которые осилили react/vue/any modern frontend shit и строгают на нём интерфейсы ко всему подряд, от лэндингов до мобильных приложений. И это норма, ибо спрос на разработчиков растёт, рынок и потребности постоянно меняются, просто не остаётся другого выбора, как упрощать и удешевлять разработку. И тут можно сказать графкуэлю только спасибо, ибо без него бы студенты-фронтендеры такой bullshit нам в браузеры отправляли, что мама не горюй...

GT ()
Ответ на: комментарий от WitcherGeralt

Ну в статье выше там это описано. На примере того как писался мобильный клиент для сервисов Facebook. Без Graohql приходилось постоянно следить за веб версией и править api.

GreenBag ★★ ()
Ответ на: комментарий от GT

Обычно такой понос как написал ты пишут студенты немного знающие ассемблер, плюсы и системное API. Что ничуть не лучше веб программерства.

anonymous ()
Ответ на: комментарий от WitcherGeralt

Я объяснял принцип совсем на пальцах. Не такие глупые в Facebook чтобы выполнять запросы с клиента как SQL. Все работает более грамотно. Со схемами и тп. но чтобы понять лучше таки почитать datasheet.

GreenBag ★★ ()
Ответ на: комментарий от GreenBag

Причём тут инъекции, если с клиента поступает уже готовый запрос?

Я про то, что sql может быть точно так же разобран на бекенде как и сабж. Разница только в том, что sql-запросом нельзя определить структуру.

WitcherGeralt ()
Ответ на: комментарий от tailgunner

Не важно. Принцип тот же: клиент сам решает, какие данные ему нужны, а на сервере некое универсальное двигло, обрабатывающее некий универсальный язык запросов.

dimgel ()
Ответ на: комментарий от dimgel

Не знаю как в других проектах, но у фейсбука и apollo, на сервере граф из вложенных друг в друга функций-обработчиков, которые, при каждом запросе, начинают невобразно вызываться. Каждая, ясное дело, дергает БД

Я не совсем понял как заоптимизировать этот граф в один sql-запрос. Но фейсбуг кажется предлагает решать эту проблему кешируя данные в отдельном nodejs микросервисе (проект dataloader)

spoonbob ()

Покопался в инете по теме ГрафКЛ , нашел интересное обсуждение https://habr.com/post/335158/

Вот цитата оттуда:

Когда вы делаете GraphQL запрос, вы вольны делать что угодно. Но опять же в случае какого либо RPC (как выше назвали этот подход), это позволяет контроллировать все аспекты взаимодействия. И т.о. даже если клиент генерирует вредоносные для сервера запросы, сервер может их просто игнорировать используя простые правила фильтрации.
В случае GraphQL, эта спецификация дает бесконечное множество путей получения данных.
И мой вопрос состоит в том, каким образом это множество можно ограничить до разумных пределов, чтобы контроллировать производительность сервера и «хорошие намерения» клиента.

anonymous ()
Ответ на: комментарий от WitcherGeralt

очень сильно упрощает бекенд. это почти что прямой доступ фронтенда в базу данных твоего приложения (ограничения на доступ конечно ты можешь задать, какие хочешь)

anonymous ()
Ответ на: комментарий от ritsufag

apollo server/client самые «production-ready» решения на данный момент, что там в энтерпрайзных сишарпах не знаю, наверное ребята еще не слышали про новую революцию graphql, в скале есть sangria

umren ★★★★★ ()