в конечном итоге вопрос о том, лучше или хуже GraphQL, чем Rest API, сводится к вопросу о реализации резолверов первого, т.е. мостов между запросом клиента и источниками данных (базы данных, микросервисы, API). Резолверы, в свою очередь, зависят от конкретного языка и используемой библиотеки. Поэтому вопрос об эффективности запросов в GraphQL для меня так и остается подвешенным. Учитывая также, что на все запросы GraphQL возвращает статус 200 ОК и, кажется, не работает с кэшированием, то и вовсе... преимущества GraphQL для меня сомнительны.
Буду признателен, если меня, полного дилетанта в технологии GraphQL, уважаемая аудитория направит на путь истинный, но первое впечатление от прочтения статья сформировалось такое. Статья представляет собой пособие по синтаксису языка запросов GraphQL, не более того. Главное упущение статьи для меня в том, что как архитектурно реализуется возможность пресловутой "единой конечной точки для всех запросов", за счет чего действительно все решается эффективнее, в статье не объяснено. Соответственно не упомянуты ограничения этой технологии - очевидно, что за "единую конечную точку" придется чем-то платить. В моем понимании, когда куда-то на сервере подкладывается схема GraphQL, описывающая объекты доступные при запросе к "единой конечной точке", формируется тоже самое, что может быть выражено в виде SQL запросов с JOIN-ами, или (тут, по-моему, вообще прямая аналогия) в виде связанных сущностей Java Persistence API и запросов JPQL. Когда в этой, и не только, статье утверждают, что "по сравнению с REST, при котором необходимо выполнять множественные сетевые запросы к каждой конечной точке, с помощью GraphQL можно запрашивать все ресурсы одним вызовом" почему-то не указывают, что множественные сетевые запросы к каждой конечной точке - это не фича REST, а следствие микросервисной архитектуры и реализация её паттерна Database per Service. Сомневаюсь, что в основе GraphQL лежат иная архитектура и шаблоны проектирования. Задаюсь вопросом, значит ли это, что GraphQL обходится без микросервисов. Что нужно для развертывания "сервера GraphQL" также осталось за кадром. В итоге, к сожалению, я не понял ни в чем преимущества этой технологии ни когда её следует использовать.
"Клиентов, приходящих с запросом отсортировать пузырьком лучше, чем у конкурентов, немного." О. мудрый человек, автор сей статьи. Глупость программистов ничуть не меньше, чем глупость политиков при примерно том же уровне самомнения и амбиций. И большинство из собеседующих сами не особо 'секут', а спрашивать что-то ведь надо. Так что решать дурацкие задачки по типу leetCode на собесах придется еще очень долго, пока не изменится сама индустрия и подход к построению it-команд...
Открыл брокерский счет в ВТБ в апреле 2020. Один визит в отделение. Далее все онлайн. Плюс впоследствие еще один для подписания американской формы на налоговый вычет. На мой взгляд, брокерское обслуживание в ВТБ блестящее
в конечном итоге вопрос о том, лучше или хуже GraphQL, чем Rest API, сводится к вопросу о реализации резолверов первого, т.е. мостов между запросом клиента и источниками данных (базы данных, микросервисы, API). Резолверы, в свою очередь, зависят от конкретного языка и используемой библиотеки. Поэтому вопрос об эффективности запросов в GraphQL для меня так и остается подвешенным. Учитывая также, что на все запросы GraphQL возвращает статус 200 ОК и, кажется, не работает с кэшированием, то и вовсе... преимущества GraphQL для меня сомнительны.
Буду признателен, если меня, полного дилетанта в технологии GraphQL, уважаемая аудитория направит на путь истинный, но первое впечатление от прочтения статья сформировалось такое.
Статья представляет собой пособие по синтаксису языка запросов GraphQL, не более того.
Главное упущение статьи для меня в том, что как архитектурно реализуется возможность пресловутой "единой конечной точки для всех запросов", за счет чего действительно все решается эффективнее, в статье не объяснено. Соответственно не упомянуты ограничения этой технологии - очевидно, что за "единую конечную точку" придется чем-то платить.
В моем понимании, когда куда-то на сервере подкладывается схема GraphQL, описывающая объекты доступные при запросе к "единой конечной точке", формируется тоже самое, что может быть выражено в виде SQL запросов с JOIN-ами, или (тут, по-моему, вообще прямая аналогия) в виде связанных сущностей Java Persistence API и запросов JPQL.
Когда в этой, и не только, статье утверждают, что "по сравнению с REST, при котором необходимо выполнять множественные сетевые запросы к каждой конечной точке, с помощью GraphQL можно запрашивать все ресурсы одним вызовом" почему-то не указывают, что множественные сетевые запросы к каждой конечной точке - это не фича REST, а следствие микросервисной архитектуры и реализация её паттерна Database per Service.
Сомневаюсь, что в основе GraphQL лежат иная архитектура и шаблоны проектирования. Задаюсь вопросом, значит ли это, что GraphQL обходится без микросервисов.
Что нужно для развертывания "сервера GraphQL" также осталось за кадром.
В итоге, к сожалению, я не понял ни в чем преимущества этой технологии ни когда её следует использовать.
"Клиентов, приходящих с запросом отсортировать пузырьком лучше, чем у конкурентов, немного." О. мудрый человек, автор сей статьи. Глупость программистов ничуть не меньше, чем глупость политиков при примерно том же уровне самомнения и амбиций. И большинство из собеседующих сами не особо 'секут', а спрашивать что-то ведь надо. Так что решать дурацкие задачки по типу leetCode на собесах придется еще очень долго, пока не изменится сама индустрия и подход к построению it-команд...
На каком основании подлецы в форме полиции могут запретить нахождение на месте обыска адвоката?