никто не знает, иначе бы они не были дырами :) Но могу сказать, достаточно надёжная система. Главное - самому не накосячить.
Предлагаю следующий урок посвятить серверному рендерингу :)
Николай, да тут смысл в том, чтобы одним запросом к серверу получать сразу все данные. Кстати этот момент хорошо работает и в случае с серверным рендерингом. Мы любые данные можем получить одним запросом и не нужно ничего комбинировать или слать несколько. Поскольку серверный рендеринг работает синхронно это огромное преимущество. Во первых мы не перегружаем локальный сокет петлями, во вторых один запрос (который распараллелить внутри GraphQL) выполняется значительно быстрей, что напримую влияет на первую выдачу HTML в браузер С ошибками Вы точно подметили, один из значимых плюсов!. Стоит тоже в статью добавить )). Примеры отличные !)
Да, Артем, сейчас граф - один из моих основных инструментов и ввел я его уже на нескольких проектах. Очень круто он себя показывает при внедрении на уже готовые проекты. К примеру, не так давно я анонсировал запуск проекта http://troika-gorod.ru/ , который написан полностью на JS, а MODX используется только для проброса и модификации API-запросов. И вот они обратились за доработками, и я решил, что раз функционал растет, то имеет смысл граф ввести, чтобы потом не было мучительно больно. Отмечу, что ввести граф, на самом деле - это совсем не 5 минут (если сайт - не сайт-визитка), во всяком случае у меня. Я руками все пишу. По моим наблюдениям, на среднем проекте только листинг основных запросов составляет строк 500, и это еще при условии использования фрагментов, которые вставлять можно в разные части. На тройке - это 1000 строк. Все это - три десятка АПИ-запросов. http://joxi.ru/bmoY6bGSMdRzpA Так вот, здесь себя граф показывает не только как отличное средство для построения запроса, но и как архитектор АПИ. Вот пара примеров с этой тройкой: Справа - это предоставленная документация. Видно, что вкралась опечатка. А вот еще: А вот пример, почему такое невозможно с графом: А вот наглядный пример, для чего это делается: вот я одним запросом получаю сразу три блока информации http://joxi.ru/bmoY6bGSMdRJpA При чем в своем конечном ответе я получаю именно один конечный многоуровневый JSON. А то, что граф выполнил для сбора этой информации три запроса - так это как раз и демонстрирует то, о чем говорит Артем - возможность работать сразу с несколькими источниками данных. Здесь три запроса выполняется только потому, что на стороне сервера не работает граф и он просто не может вернуть данные одним ответом. А вот на другом моем проекте (и не только на нем), граф крутится и на сервере и в ответе в одном я получаю все нужные мне данные Кстати, в связке с сервером, у меня получилась вообще очень интересная связка: у меня и на сервере, и на клиенте используется единая схема. Это позволяет, во-первых, на сервер в запросе слать не портянку, а просто название операции с параметрами. К примеру, на получение этих данных отправляется вот такой запрос: А во-вторых, я эту же модель, просто с другими обработчиками, использую и на стороне клиента. То есть когда у меня данные подгружены в браузер в хранилища, я могу выполнять структурированные запросы прям в браузере. К примеру, вот так я получаю в браузере данные для карты, со всеми нужными вложенностями, и совершенно без обращения к серверу Короче, про него можно очень много всего рассказывать. И надо отметить, что работа с ним - это не всегда праздник. В том же браузере, из-за того, что он использует промисы, он не рассчитан на множественный вызов (то есть когда во внутренних резолверах выполняешь еще запросы на граф). В случае сотен вызовов в рамках одного запроса, выборка конечная может составить 10 секунд и более :) Но если правильно оптимизировать все, то этот же объем данных будет получен менее чем за секунду.
Николай, вижу мой совет про graphql в первом уроке был принят ))). Благодарю за этот урок, Вы занимаетесь хорошим делом! Хотел бы добавить в преимущества: 1. Структура ответа всегда точно повторяет структуру запроса, все сталкивались с проблемой когда в ресте поменялась структура объекта в ответе и все ломалось. И версионность больше не нужна по этой причине. 2. Возможность работать сразу с несколькими источниками данных. Поскольку по сути graphql это агрегатор, мы можем накрутить работу сразу с несколькими базами и соединять данные в одну выборку. 3. Быстро разворачивается в сравнении с рест. Если написать генератор для моделей, вообще за 5 минут. И за счёт того, что всего 1 эндпоинт мы получаем полнофункциональный вариант по сути, только связи руками накрутить. Ну исключение с мутациями, на них генератор не сделать.
Что-то пошло не так: Консоль запущена... Attempted to set execution time to infinite. Max execution time currently: 30. Тестирование данных перед импортом... Данные из CSV-файла заменят все данные, введённые вручную. Название файла: import-NA-SITE.csv Ошибок не обнаружено. Готовим данные к импорту... Для импорта готовы элементы в количестве: 3. Импортирование... PHP notice: Undefined index: data PHP notice: Undefined variable: object Потом все зависает. Если обновить страницу, появляется 1 ресурс из 3 импортируемых тестовых. В этом ресурсе поле price =0.