Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL
Насколько я понимаю, доступа к коду как раз и нет. У него же нет другой точки входа с описанными схемами или доступа к БД напрямую. Поэтому и пришлось юзать что дали. Или есть? )
И одна из них webonyx/graphql-php взята за основу для Railt
Зацепил меня данный комментарий. Думал после видео что-нибудь кто-нибудь ответит, но нет)
Я ещё первое до конца не досмотрел. А второе вообще 3 часа. ))
Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека.
Я имел ввиду немного другое. Конечно не надо менять стеки. Я хотел сказать, что нет особой необходимости использовать GraphQL для PHP разработчиков. Если только у тебя не мега сервис с могущим API, как говорит Кирилл Несмеянов.Т.е.PHP разработчику вполне хватит REST-а.
А вот если посмотреть со стороны фронт разработчика, то ему GraphQL даёт больше плюшек. Он не знает ни схем, ни связей объектов в отличие от PHP разработчика (и любого другого бекэндера). И GraphQL даёт ему возможность самому строить запросы не зная этого.
Попробую пояснить мысль. Представим, что MODX — это сервис с API, как это изначально планировалось сделать в MODX3 — использовать Slim в качестве ядра и работать через API. Тогда можно подключать любую админку. Как мне кажется (!), тут GraphQL в качестве обёртки не нужен. Вполне хватит обычного REST-а.
П.С. Возможно, я говорю глупости. Просто ещё не до конца вкурил эту тему. :)
Посмотрел. Заинтересовало. Но… GraphQL — это как бы альтернатива REST-у. Придумана фронтэндерами. Удобно. Но в экосистеме MODX я не встречал даже какой-то толковой наработки по RESTful. Поэтому GraphQL вряд ли будет востребован разработчиками, использующими MODX. И это не удивительно. Могу ошибаться, но скорее всего и в WP, Joomla и т.п. CMS такого тоже не увидишь. Это другой уровень.
В свете сказанного, GraphQL выглядит немного неуместно для PHP. Как и для любого другого серверного языка. А вот для JS самое оно. Фронтэндеру не нужно разбираться в связях и типах. Всё прописано в схемах.
Но это, как требует говорить Николай, чисто моё мнение.
Ты не понял. В js это «возможности», а в php — беда. )
Всё это субъективно. Меня эти «возможности» немного раздражают, но это не значит, что js отстой. В обычных языках тоже свои особенности. Но они как есть, так и будут.
Не часто, но бывает. Я мыслю по другому. я так программирую, что мне достаточно isset и isEmpty. И я не припомню случая, когда мне нужно было бы проверять на undefined. А вот в js это частенько приходилось делать. Это потому что я плохой программист или просто подход к языкам разный?
3 и 4 аналоги тоже есть в php, но я ими очень редко пользовался. В js повсеместно использую
Честно говоря непонятно, что ты этим хотел подчеркнуть. Ибо понять это можно как минус.
А я, например, часто пользуюсь функциями isInt, isArray и т.п. Не пойму, чем мы мериемся.
П.С. какая же это боль писать комменты с телефона.
Например, тип строки (Hello world) не совпадает с типом нового объекта String (new String('Hello world')). Это порой приводит к нежелательным последствиям, которые могут сбить с толку.
Вообще всё-таки некорректно сравнивать эти языки. У них разная история и предназначение. Если задаться целью, то ровно также можно найти миллион отличий между javascript и java, js и go, php и pyton. Только вот зачем? Js — уникальный скриптовый язык, который на данный момент невозможно ничем заменить в отличие от серверных, где альтернатив много. Но от этого он не становиться идеальным. Как раз наоборот
Столько этих «особенностей» нет ни в одном другом языке.
Возможно. Никогда не говори никогда. Но сейчас я не понимаю, почему описанные выше и ещё в тысячах статей выкрутасы в js это просто прикольные мелочи, а в php всё просто ужасно. Поэтому хочется пояснений, раскрывающих преимущества js. Ответ — когда-нибудь поймёшь, говорит только о субъективности. Никаких объективных причин нет.
Просто для меня это заявление звучит противоречиво.
Говориться, что на JS приходится более внимательно работать с типами и условиями. Т.е. он менее требователен и типизирован. Что в дальнейшем может приводить к ошибкам. И следом идет
Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…
Еще интересен такой момент. Ты уже год не кодишь на php. Подзабывать начал или всё чётко? Это я к вопросу об использовании разных технологий для разных задач.
Хотя сам Кирилл её не хвалит )
Я имел ввиду немного другое. Конечно не надо менять стеки. Я хотел сказать, что нет особой необходимости использовать GraphQL для PHP разработчиков. Если только у тебя не мега сервис с могущим API, как говорит Кирилл Несмеянов.Т.е.PHP разработчику вполне хватит REST-а.
А вот если посмотреть со стороны фронт разработчика, то ему GraphQL даёт больше плюшек. Он не знает ни схем, ни связей объектов в отличие от PHP разработчика (и любого другого бекэндера). И GraphQL даёт ему возможность самому строить запросы не зная этого.
Попробую пояснить мысль. Представим, что MODX — это сервис с API, как это изначально планировалось сделать в MODX3 — использовать Slim в качестве ядра и работать через API. Тогда можно подключать любую админку. Как мне кажется (!), тут GraphQL в качестве обёртки не нужен. Вполне хватит обычного REST-а.
П.С. Возможно, я говорю глупости. Просто ещё не до конца вкурил эту тему. :)
В свете сказанного, GraphQL выглядит немного неуместно для PHP. Как и для любого другого серверного языка. А вот для JS самое оно. Фронтэндеру не нужно разбираться в связях и типах. Всё прописано в схемах.
Но это, как требует говорить Николай, чисто моё мнение.
Я — гениальный человек!
А то что ничего не создал…
Так я был занят и болел.
(ещё пирожков)
П.С. Извини, но мимо тёщиного дома… ))
Всё это субъективно. Меня эти «возможности» немного раздражают, но это не значит, что js отстой. В обычных языках тоже свои особенности. Но они как есть, так и будут.
История javascript .
А я, например, часто пользуюсь функциями isInt, isArray и т.п. Не пойму, чем мы мериемся.
П.С. какая же это боль писать комменты с телефона.
Вообще всё-таки некорректно сравнивать эти языки. У них разная история и предназначение. Если задаться целью, то ровно также можно найти миллион отличий между javascript и java, js и go, php и pyton. Только вот зачем? Js — уникальный скриптовый язык, который на данный момент невозможно ничем заменить в отличие от серверных, где альтернатив много. Но от этого он не становиться идеальным. Как раз наоборот
Столько этих «особенностей» нет ни в одном другом языке.
Говориться, что на JS приходится более внимательно работать с типами и условиями. Т.е. он менее требователен и типизирован. Что в дальнейшем может приводить к ошибкам. И следом идет
Т.е. всё наоборот.
Поэтому и просил уточнить.
П.С. А TS — это typescript?
А почему для генерации html нужна нода? Удобнее?