В списке требований на визу часто есть договор аренды жилья. Как вообще можно заключить договор аренды, не находясь в стране? Получается, вы сначала должны приехать по тур. визе, заключить договор, а потом подавать на визу кочевника?
Можно вопрос на отвлеченную тему? Я хоть не занимаюсь VR, но пробежался по статье по диагонали. Кажется, математика школьная, но объем статьи большой, хорошая графика. Это косвенное свидетельство, что вы накопили значительный и целостный опыт в решение ваших задач.
А вот сколько времени уходит на подготовку такого специалиста? Допустим, если взять за основу среднего программиста с бекграундом технического вуза.
Сегодня посетил VR-атраккцион. Настроился очароваться HDMI и 90fps (помню провальную попытку 90-x годов). Думал, будет как в IMAX.
Как же разочаровался в итоге. Видна пиксельная сетка, в динамичных сценах наступает тошнота. Об этом уже писали, например в статье на geektimes.
С таким качеством картинки не приходится говорить о проникновении VR в жизнь. Вперед шагнули контроллеры. Система быстро и точно реагирует на изменение положения рук, головы, тела. Теперь слово за устройствами графического вывода.
Доступность информации ведет не к прозрению, а к постановке новых вопросов. Процесс бесконечный. С каждым ответом повышается вероятность пойти по ложному пути. В конечном счете ложь будет не отличить от правды, а правду легко выставить ложью.
Дополненная реальность станет невероятным прорывом во всех сферах жизни.
Смартфон стал популярен отчасти потому, что сократил время на обслуживание информационных потребностей — карта под рукой, расписание с собой. Я могу прийти на байдарке на остров посреди озера и вдруг решить купить билет на поезд вечером и тут же это сделать.
AR еще больше сокращает время на поиск информации. Для путешествий в незнакомых местах это крайне востребовано. Перед вами такой-то собор, а за ним кафе, в котором ваш любимый десерт стоит столько-то.
Врач делает операцию в очках и видит все метрики пациента. Механик ремонтирует автомобиль и знает, с каким моментом затянуть гайку.
И конечно, военных не могут не интересовать очки, в которых солдат видит данные о дислокации противника, полученные с дрона. Так что финансовая поддержка технологии на гос. уровне гарантирована.
Интересный взгляд, но противоречивый. С одной стороны утверждается, что социальный организм (СО) ставит целью комфортное пребывание в нем участников, с другой – условием обозначается некое насильственное действие. Выводы делаю из таких деклараций:
> 1.2. Доносить… и мотивировать участников искренне их разделять;
Мотивировать — да. Но влиять на искренность или конформизм участников — это вторгаться в личное пространство. Ответная агрессия весьма предсказуема.
> 1.1.1. Адаптировать новых участников к среде обитания;
Вроде, верно. Но напоминает «мы сделаем вас счастливыми». За этим чувствуется некая фальш. Хорошо передано в недавнем фильме «Сфера».
> 1.5.2. Определять культурные нормы в среде;
Они отличаются от общепринятых культурных норм?
> 2.2. Подавлять конфликты в среде…
Может быть неудачная формулировака? Но подавление не коррелирует с комфортным пребыванием.
И вот это:
> 3.1.2. Обеспечить социальную защиту от внешних угроз для участников;
Это стандартная юридически обусловленная функция самой организации. СО тут ни при чем.
Среагировал на фразу. Вообще Яндекс тоже не во всем Яндекс ) Их успех заложен в 2000-х годах. И с тех пор они мало полезного дали миру разработки, в отличии от того же Фейсбук. Хотя попытки были, да.
Мне больше интересен взгляд соискателя. Так вышло, что профессионально проходить собеседования научился раньше, чем стал разработчиком. Вы и сами знаете, что хитрые задачки не ставят целью получить правильные ответы. Банальное «оценить способность к рассуждению» часто является целью.
Но бывают наниматели, которые меряют соискателей по себе. Имею в виду технических лидов. Причем, подготовившись и зная ответы на свои хитрые вопросы, они оценивают соискателя на предмет «достоин ли предстать их светлы очи».
Пусть они умны, но такие ожидания, имхо, от недостатка жизненного опыта. Ты берешь человека, и скорее всего, будешь растить спеца под свои специфические потребности. То есть тебе нужна способная заготовка. Или тебе нужен универсальный специалист? Тогда при чем тут хитрая задача? Поменяйтесь местами с соискателем, и он задаст две подобных задачи, на которых у нанимателя не будет ответа.
Справедливости ради, я не часто встречал такое отношение, и оно не раздражает в случаях, если:
— вижу, что на позицию действительно требуются специфически подготовленные по теме люди. Например, это могли бы быть исследования в части поиска Яндекса, или тестирование безопасности у Касперского.
— компания столь шикарна, что за дверями очередь супер-профи соискателей. Но HR любой топ-компании скажет, что такой очереди нет.
— Хороший тимлид ищет человека, очень совместимого с ним. Позицию не разделяю, но понимаю.
В остальных случаях скорее сочту, что менеджмент в компании гниловат, и, вероятно, досрочно закончу собеседование (соискателя никто не лишал такого права).
C JS пятый год. Бывает позыв бросить, перейти на какой-нибудь C(#++). Но JS тут ни при чем.
Скорее тяготит безмерности спектра применений JS.
Мозг не справится постичь, осилить все прикладные области, все тулзы и либы. Пять лет в состоянии цейтнота. Верно подметил автор, чтение концептуальных статей отнимает уйму времени.
Есть еще момент. Если нужно что-то разработать, в первую очередь думаешь не об алгоритме, а о том, есть ли подходящий npm-пакет.
Но все это реально настолько увлекательно. Не знаю, как сейчас в других языках, но в мир JS можно уйти так глубоко, насколько хватит ментальных возможностей.
Вот и думаешь иногда, метнуться на какой-нибудь C(#++), может даже вспомнить Assembler, на котором писал когда-то драйверы. Сидеть себе копаться в однотипных задачах. Развлекать мозг алгоритмами, а не поиском npm-пакетов.
Но потом понимаешь, будет скучно без ощущения вечного ренессанса, без камасутры react/redux/apollo/immutable/draft/jest/eslint/node/npm/sass/webpack/babel/uglify/pm2. И не можешь никуда деться. Все симтомы болезни налицо )
фронт потихоньку хочет стать драйвером всей разработки
Вы проницательны и частично правы. Но такое стремление фронта не от желания захватить мир.
Если свести дуализм проблемы REST–GQL к одной фразе, то эта фраза будет о том, кто лучше готовит view-оринтированные данные.
Любой API – это этап на пути трансформации данных во view-оринтированный формат. Отправная точка — БД. В ней данные разбиты на информационные сущности и, что важно, нормализованы и индексированы ради оптимального расходования места и скорости доступа (если говорить про реляционную БД). Замечу, ни у кого не вызывает сомнения необходимость нормализации ради компактности.
Но такие данные вряд ли годятся для визуализации. Потому API является не просто шлюзом к данным, но как-то трансформирует их под ту или иную задачу фронта. Поскольку задач у фронта много и они возникают иногда с пугающей скоростью, беку просто не угнаться за подготовкой данных под каждую задачу.
Все приходит к тому, что бек говорит, мол мы же дали вам два массива связанных данных, соберите из них, что вам конкретно нужно. И фронт каждый раз собирает. Каким бы мудрым не был API очень редко ответ сервер не требует дополнительного процессинга на фронте.
И тут появляется GraphQL, а вместе с ним возможность декларативно объявить и получить именно те данные, которые нужны компоненту. Конечно, такая плюшка притягательна для фронта. Представляет, сколько строк кода можно сэкономить повсеместно? Причем для бека сложность поддержки GQL вряд ли больше, чем поддержки REST. Поэтому фронт, как конечный потребитель данных, хочет быть услышан
Это и прекрасно! Считаю, никакая новая технология не должна пойти в массы, не пройдя сопротивление легасевых (читай, традиционных) технологий. Естественный отбор. И любая легасевая технология живет, пока есть хоть один ее адепт.
Но и сводить достоинства GQL к экономии трафика не совсем верно. У него гораздо больше плюсов. Да, их получаю в основном фронтенд-разработчики. При правильной организации, плюсы получит сервис в целом (надеюсь). Непосредственно со стороны бекенд-разработчика, возможно, плюсов не так много.
Десяток лишних полей — не страшно, но и не нужно. Однако я встречал API, где речь шла не о десятках полей, а десятках лишних килобайтов, причем дублирующейся информации.
Мне кажется, лучше изначально применить архитектуру, исключающую избыточность, чем каждый раз ломать голову над дизайном моделей и коллекций, потом долго оптимизировать, подхачивая модели по месту.
Не отрицаю, можно построить великолепный RESTful API, снабдить его отличным свагером. Но так получается, что есть одно слабое место – избыточная выгрузка, другое – жестко заданные модели, которые не всегда легко подстроить под меняющиеся потребности, третье – версионность. В сумме это повышает вероятность зашить в API неисправимые дефекты, которые потом станут сакральными багами. Встречали такие? Это когда благодаря багу все более-мене работает на фронте. Стоит его пофиксить, и все развалится. Не отсюда ли пословица «работает — не трогай!» :)
Почему GQL встречает такое сопротивление? Объяснение приходит, когда смотришь на зависимость членов команды друг от друга.
Фронтендер зависит от бекендера, чего не скажешь об обратном. По этой причине фронтендер так или иначе вникает в проблемы бека, но не всегда бывает наоборот.
Если бекендер вложил массу времени и сил в изучение архитектурных подходов REST, а затем свел руки вместе, поднял над собой и сказал: «Я в домике», – то фронтендеру остается с грустным видом удалиться, волоча на шнурке какой-нибудь GraphQL.
Но если смотреть на сервис как на конечный продукт и понимать проблемы фронтенда (к слову, современный фронтенд вряд ли уступает по сложности бекенду), то GraphQL будет выглядеть незаменимым инструментом для решения многих проблем:
1. Уменьшение количества запросов и пейлоада, о чем говорилось в статье.
2. Обновление состояния приложения на сообщениях от сервера на основе subscriptions.
3. Оптимальное кеширование. Оба популярных клиентских фреймворка – Relay и Apoll реализуют его из коробки.
4. Проблема начального этапа разработки, когда отсутствие эндпоинтов вынуждает мокать данные, писать обертки в коде. Вместо этого фронтенд может воспользоваться BaaS-сервисами типа graph.cool и scaphold для быстрого и бесплатного прототипирования, а когда будет готов свой бекенд, – просто поменять адрес сервера.
5. Декларативность кода. Лично у меня давно возникает диссонанс от необходимости писать модуль fetch с retry, создавать словари для разных ресурсов и HTTP-методов. По сравнению с подходом того же Redux, это кажется громоздким, бессмысленным, ибо повторяется из проекта в проект, не соответствующем времени.
GraphQL не только язык. Как бывает с удачными подходами — они вдохновляют на создание целой экосистемы инструментов, решающих основную и сопутствующие проблемы. Такими инструментами являются упомянутые клиентские фреймворки Relay и Apollo. Да, их применение требует изменить многое на бекенде, и тут могут быть сложности.
Но сложность связана с новизной, с необходимостью бекен-разработчика изучать новые подходы, когда он столько сил потратил на изучение старых. Это понятно и оправдано. Но в конечном счете, общее дело делаем. И вы правда считаете REST вершиной эволюции? Уверены, что через 10 лет кто-то будет вспоминать про REST? Как бы не оказаться в хвосте очереди
Что мешает создать endpoint на бэкенде, который будет возращать только нужную информацию?
Типичный ответ бекенд-разработчика: «Мне что пилить новую модель под каждую потребность?» И последующие объяснения, что наследование хоть и хорошо, но поддерживать большое количество моделей труднее, или надо их хачить в каждом отдельном сервисе и т.д. и т.п.
Проблему перевыгрузки данных это не решает. Данные придут в соответствии с моделью, заданной на сервере. Получается, хотели узнать возраст персоны, а до кучи получили результаты анализов.
Вынужден слегка поправить ваш вопрос. С моей стороны нет каких-либо предложений, но GQL, как известно, используется для записи.
Мне кажется, вы видите проблему в том, что запись не может быть столь же произвольно безграничной, как получение данных. Блокировки–транзакции–индексирование на уровне БД ограничивают попытки менять данные произвольным образом. Все ради поддержания целостности и доступности данных.
Но GQL не дает абсолютной свободы ни в запросах, ни в мутации. Это только кажется, что любой путь в графе доступен. Представление данных в виде графа позволяет делать крутые оптимизации на фронте. Но на беке, чтобы путь в графе был доступен, он должен быть разрешен схемой.
Некоторые сервисы, например graph.cool, имеют два варианта API — упрощенный и полнофункциональный. В упрощенном API для всех типов данных неявно создаются разрешения на доступ к их полям, а если какое-то поле связано с другим типом, то и к узлам этого типа. В полном API ситуация строже — нужно самостоятельно определить разрешенные для чтения пути.
С мутациями все еще строже. Нет никакой произвольности. В схеме должны определять доступные мутации. Каждая мутация – это функция, которая может проверить входные данные и сделать нужные запросы к БД. Клиенту доступна та или иная мутация, он может вызывать ее с разными параметрами, но он не может через GQL менять любые данные в графе, как заблагорассудится.
PS. На мое знание GQL пока нельзя полагаться – только недавно стал изучать GQL и больше со стороны фронта.
В этом случае сложность бэкенда перекроет все плюсы
Какую дополнительную сложность приносит GraphQL в подобной ситуации?
Мне кажется, не сильно усложняет, может и не усложняет вовсе. Но я не бекендер, мне не видно
Со стороны фронта, кончено, упрощение встретят «на ура». Но причина не в лени.
Какой проект не возьми, везде свои решения для запроса данных, кеширования, асинхронных уведомлений от сервера. Каждый раз думаешь, когда мы слезем с велосипеда в этой части?
И тягу к идеальному нельзя задвинуть. Оптимизация запросов на клиенте, отсутствие избыточного пейлоада, повышение отзывчивости – это хорошо, это правильно.
И к слову, чтобы все это применить на клиенте, тоже надо руки приложить. Особенно такой фреймворк,
как Relay Modern. По меньшей мере придется как следует разобраться с вебпаком, чтобы применить правильный лоадер для graphql-схемы, поставить плагин в бабель, изучить React, понять что есть HOC. Не скажу, что GraphQL это прямо подарок лентяю.
Как я понимаю (сам только начал изучать), логика запроса данных – в функциях-резолверах. Они связаны с полями и являются частью схемы GraphQL. Прочая бизнес-логика – в event-driven келбеках.
Например, на graph.cool для этих целей предлагается использовать функции. Они позволяют сделать что-то на разных этапах обработки запроса. На скриншоте показан выбор этапа при создании функции.
Сами функции могут хоститься на облачных сервисах типа AWS Lambda.
Если пишете свой GraphQL бекенд, то используете какую-то библиотеку. Она, наверняка, будет предлагать аналогичный механизм келбеков.
В списке требований на визу часто есть договор аренды жилья.
Как вообще можно заключить договор аренды, не находясь в стране?
Получается, вы сначала должны приехать по тур. визе, заключить договор, а потом подавать на визу кочевника?
А вот сколько времени уходит на подготовку такого специалиста? Допустим, если взять за основу среднего программиста с бекграундом технического вуза.
Сегодня посетил VR-атраккцион. Настроился очароваться HDMI и 90fps (помню провальную попытку 90-x годов). Думал, будет как в IMAX.
Как же разочаровался в итоге. Видна пиксельная сетка, в динамичных сценах наступает тошнота. Об этом уже писали, например в статье на geektimes.
С таким качеством картинки не приходится говорить о проникновении VR в жизнь. Вперед шагнули контроллеры. Система быстро и точно реагирует на изменение положения рук, головы, тела. Теперь слово за устройствами графического вывода.
Доступность информации ведет не к прозрению, а к постановке новых вопросов. Процесс бесконечный. С каждым ответом повышается вероятность пойти по ложному пути. В конечном счете ложь будет не отличить от правды, а правду легко выставить ложью.
Смартфон стал популярен отчасти потому, что сократил время на обслуживание информационных потребностей — карта под рукой, расписание с собой. Я могу прийти на байдарке на остров посреди озера и вдруг решить купить билет на поезд вечером и тут же это сделать.
AR еще больше сокращает время на поиск информации. Для путешествий в незнакомых местах это крайне востребовано. Перед вами такой-то собор, а за ним кафе, в котором ваш любимый десерт стоит столько-то.
Врач делает операцию в очках и видит все метрики пациента. Механик ремонтирует автомобиль и знает, с каким моментом затянуть гайку.
И конечно, военных не могут не интересовать очки, в которых солдат видит данные о дислокации противника, полученные с дрона. Так что финансовая поддержка технологии на гос. уровне гарантирована.
> 1.2. Доносить… и мотивировать участников искренне их разделять;
Мотивировать — да. Но влиять на искренность или конформизм участников — это вторгаться в личное пространство. Ответная агрессия весьма предсказуема.
> 1.1.1. Адаптировать новых участников к среде обитания;
Вроде, верно. Но напоминает «мы сделаем вас счастливыми». За этим чувствуется некая фальш. Хорошо передано в недавнем фильме «Сфера».
> 1.5.2. Определять культурные нормы в среде;
Они отличаются от общепринятых культурных норм?
> 2.2. Подавлять конфликты в среде…
Может быть неудачная формулировака? Но подавление не коррелирует с комфортным пребыванием.
И вот это:
> 3.1.2. Обеспечить социальную защиту от внешних угроз для участников;
Это стандартная юридически обусловленная функция самой организации. СО тут ни при чем.
За них не волнуйтесь — алмаз в пыли не заваляется )
Среагировал на фразу. Вообще Яндекс тоже не во всем Яндекс ) Их успех заложен в 2000-х годах. И с тех пор они мало полезного дали миру разработки, в отличии от того же Фейсбук. Хотя попытки были, да.
Мне больше интересен взгляд соискателя. Так вышло, что профессионально проходить собеседования научился раньше, чем стал разработчиком. Вы и сами знаете, что хитрые задачки не ставят целью получить правильные ответы. Банальное «оценить способность к рассуждению» часто является целью.
Но бывают наниматели, которые меряют соискателей по себе. Имею в виду технических лидов. Причем, подготовившись и зная ответы на свои хитрые вопросы, они оценивают соискателя на предмет «достоин ли предстать их светлы очи».
Пусть они умны, но такие ожидания, имхо, от недостатка жизненного опыта. Ты берешь человека, и скорее всего, будешь растить спеца под свои специфические потребности. То есть тебе нужна способная заготовка. Или тебе нужен универсальный специалист? Тогда при чем тут хитрая задача? Поменяйтесь местами с соискателем, и он задаст две подобных задачи, на которых у нанимателя не будет ответа.
Справедливости ради, я не часто встречал такое отношение, и оно не раздражает в случаях, если:
— вижу, что на позицию действительно требуются специфически подготовленные по теме люди. Например, это могли бы быть исследования в части поиска Яндекса, или тестирование безопасности у Касперского.
— компания столь шикарна, что за дверями очередь супер-профи соискателей. Но HR любой топ-компании скажет, что такой очереди нет.
— Хороший тимлид ищет человека, очень совместимого с ним. Позицию не разделяю, но понимаю.
В остальных случаях скорее сочту, что менеджмент в компании гниловат, и, вероятно, досрочно закончу собеседование (соискателя никто не лишал такого права).
C JS пятый год. Бывает позыв бросить, перейти на какой-нибудь C(#++). Но JS тут ни при чем.
Скорее тяготит безмерности спектра применений JS.
Мозг не справится постичь, осилить все прикладные области, все тулзы и либы. Пять лет в состоянии цейтнота. Верно подметил автор, чтение концептуальных статей отнимает уйму времени.
Есть еще момент. Если нужно что-то разработать, в первую очередь думаешь не об алгоритме, а о том, есть ли подходящий npm-пакет.
Но все это реально настолько увлекательно. Не знаю, как сейчас в других языках, но в мир JS можно уйти так глубоко, насколько хватит ментальных возможностей.
Вот и думаешь иногда, метнуться на какой-нибудь C(#++), может даже вспомнить Assembler, на котором писал когда-то драйверы. Сидеть себе копаться в однотипных задачах. Развлекать мозг алгоритмами, а не поиском npm-пакетов.
Но потом понимаешь, будет скучно без ощущения вечного ренессанса, без камасутры react/redux/apollo/immutable/draft/jest/eslint/node/npm/sass/webpack/babel/uglify/pm2. И не можешь никуда деться. Все симтомы болезни налицо )
Вы проницательны и частично правы. Но такое стремление фронта не от желания захватить мир.
Если свести дуализм проблемы REST–GQL к одной фразе, то эта фраза будет о том, кто лучше готовит view-оринтированные данные.
Любой API – это этап на пути трансформации данных во view-оринтированный формат. Отправная точка — БД. В ней данные разбиты на информационные сущности и, что важно, нормализованы и индексированы ради оптимального расходования места и скорости доступа (если говорить про реляционную БД). Замечу, ни у кого не вызывает сомнения необходимость нормализации ради компактности.
Но такие данные вряд ли годятся для визуализации. Потому API является не просто шлюзом к данным, но как-то трансформирует их под ту или иную задачу фронта. Поскольку задач у фронта много и они возникают иногда с пугающей скоростью, беку просто не угнаться за подготовкой данных под каждую задачу.
Все приходит к тому, что бек говорит, мол мы же дали вам два массива связанных данных, соберите из них, что вам конкретно нужно. И фронт каждый раз собирает. Каким бы мудрым не был API очень редко ответ сервер не требует дополнительного процессинга на фронте.
И тут появляется GraphQL, а вместе с ним возможность декларативно объявить и получить именно те данные, которые нужны компоненту. Конечно, такая плюшка притягательна для фронта. Представляет, сколько строк кода можно сэкономить повсеместно? Причем для бека сложность поддержки GQL вряд ли больше, чем поддержки REST. Поэтому фронт, как конечный потребитель данных, хочет быть услышан
Но и сводить достоинства GQL к экономии трафика не совсем верно. У него гораздо больше плюсов. Да, их получаю в основном фронтенд-разработчики. При правильной организации, плюсы получит сервис в целом (надеюсь). Непосредственно со стороны бекенд-разработчика, возможно, плюсов не так много.
Мне кажется, лучше изначально применить архитектуру, исключающую избыточность, чем каждый раз ломать голову над дизайном моделей и коллекций, потом долго оптимизировать, подхачивая модели по месту.
Не отрицаю, можно построить великолепный RESTful API, снабдить его отличным свагером. Но так получается, что есть одно слабое место – избыточная выгрузка, другое – жестко заданные модели, которые не всегда легко подстроить под меняющиеся потребности, третье – версионность. В сумме это повышает вероятность зашить в API неисправимые дефекты, которые потом станут сакральными багами. Встречали такие? Это когда благодаря багу все более-мене работает на фронте. Стоит его пофиксить, и все развалится. Не отсюда ли пословица «работает — не трогай!» :)
Фронтендер зависит от бекендера, чего не скажешь об обратном. По этой причине фронтендер так или иначе вникает в проблемы бека, но не всегда бывает наоборот.
Если бекендер вложил массу времени и сил в изучение архитектурных подходов REST, а затем свел руки вместе, поднял над собой и сказал: «Я в домике», – то фронтендеру остается с грустным видом удалиться, волоча на шнурке какой-нибудь GraphQL.
Но если смотреть на сервис как на конечный продукт и понимать проблемы фронтенда (к слову, современный фронтенд вряд ли уступает по сложности бекенду), то GraphQL будет выглядеть незаменимым инструментом для решения многих проблем:
1. Уменьшение количества запросов и пейлоада, о чем говорилось в статье.
2. Обновление состояния приложения на сообщениях от сервера на основе subscriptions.
3. Оптимальное кеширование. Оба популярных клиентских фреймворка – Relay и Apoll реализуют его из коробки.
4. Проблема начального этапа разработки, когда отсутствие эндпоинтов вынуждает мокать данные, писать обертки в коде. Вместо этого фронтенд может воспользоваться BaaS-сервисами типа graph.cool и scaphold для быстрого и бесплатного прототипирования, а когда будет готов свой бекенд, – просто поменять адрес сервера.
5. Декларативность кода. Лично у меня давно возникает диссонанс от необходимости писать модуль fetch с retry, создавать словари для разных ресурсов и HTTP-методов. По сравнению с подходом того же Redux, это кажется громоздким, бессмысленным, ибо повторяется из проекта в проект, не соответствующем времени.
GraphQL не только язык. Как бывает с удачными подходами — они вдохновляют на создание целой экосистемы инструментов, решающих основную и сопутствующие проблемы. Такими инструментами являются упомянутые клиентские фреймворки Relay и Apollo. Да, их применение требует изменить многое на бекенде, и тут могут быть сложности.
Но сложность связана с новизной, с необходимостью бекен-разработчика изучать новые подходы, когда он столько сил потратил на изучение старых. Это понятно и оправдано. Но в конечном счете, общее дело делаем. И вы правда считаете REST вершиной эволюции? Уверены, что через 10 лет кто-то будет вспоминать про REST? Как бы не оказаться в хвосте очереди
Типичный ответ бекенд-разработчика: «Мне что пилить новую модель под каждую потребность?» И последующие объяснения, что наследование хоть и хорошо, но поддерживать большое количество моделей труднее, или надо их хачить в каждом отдельном сервисе и т.д. и т.п.
Мне кажется, вы видите проблему в том, что запись не может быть столь же произвольно безграничной, как получение данных. Блокировки–транзакции–индексирование на уровне БД ограничивают попытки менять данные произвольным образом. Все ради поддержания целостности и доступности данных.
Но GQL не дает абсолютной свободы ни в запросах, ни в мутации. Это только кажется, что любой путь в графе доступен. Представление данных в виде графа позволяет делать крутые оптимизации на фронте. Но на беке, чтобы путь в графе был доступен, он должен быть разрешен схемой.
Некоторые сервисы, например graph.cool, имеют два варианта API — упрощенный и полнофункциональный. В упрощенном API для всех типов данных неявно создаются разрешения на доступ к их полям, а если какое-то поле связано с другим типом, то и к узлам этого типа. В полном API ситуация строже — нужно самостоятельно определить разрешенные для чтения пути.
С мутациями все еще строже. Нет никакой произвольности. В схеме должны определять доступные мутации. Каждая мутация – это функция, которая может проверить входные данные и сделать нужные запросы к БД. Клиенту доступна та или иная мутация, он может вызывать ее с разными параметрами, но он не может через GQL менять любые данные в графе, как заблагорассудится.
PS. На мое знание GQL пока нельзя полагаться – только недавно стал изучать GQL и больше со стороны фронта.
Какую дополнительную сложность приносит GraphQL в подобной ситуации?
Мне кажется, не сильно усложняет, может и не усложняет вовсе. Но я не бекендер, мне не видно
Со стороны фронта, кончено, упрощение встретят «на ура». Но причина не в лени.
Какой проект не возьми, везде свои решения для запроса данных, кеширования, асинхронных уведомлений от сервера. Каждый раз думаешь, когда мы слезем с велосипеда в этой части?
И тягу к идеальному нельзя задвинуть. Оптимизация запросов на клиенте, отсутствие избыточного пейлоада, повышение отзывчивости – это хорошо, это правильно.
И к слову, чтобы все это применить на клиенте, тоже надо руки приложить. Особенно такой фреймворк,
как Relay Modern. По меньшей мере придется как следует разобраться с вебпаком, чтобы применить правильный лоадер для graphql-схемы, поставить плагин в бабель, изучить React, понять что есть HOC. Не скажу, что GraphQL это прямо подарок лентяю.
Например, на graph.cool для этих целей предлагается использовать функции. Они позволяют сделать что-то на разных этапах обработки запроса. На скриншоте показан выбор этапа при создании функции.
Сами функции могут хоститься на облачных сервисах типа AWS Lambda.
Если пишете свой GraphQL бекенд, то используете какую-то библиотеку. Она, наверняка, будет предлагать аналогичный механизм келбеков.