Разве не хорошо, что на modx.pro начали появляться публикации любой направленности? Помоему, это круто! Правда я считаю, что надо побольше технических деталей. Хотя мне ли говорить подобное, у самого есть такие посты…
В курсе, а ещё на куче других языков. Но в данном же случае обсуждается твой вариант реализации (на JS) и вариант Андрея (на PHP).
Тут вопрос спорный. Уже довольно много средств есть для генерации всего и вся, в том числе резолверов. К примеру, на той же призме, достаточно описать схему и запустить деплой, будет не только структура БД создана, но и сгенерированы CRUD-резолверы, включая условия поиска, сортировки и т.п.
То есть, на примере ИМ, можно просто описать схему запросов и мутаций для msCategory, msProduct, msOrder и т.п. и оно поедет?
рассчитывая, что ответ придет в соответствии с документацией
тогда-то и посыпались ошибки
примерно это я и здесь буду сейчас это проходить
Смею возразить, что не «это» и даже не «примерно». Ведь когда тебе разработчик с того конца даёт доку, то ты рассчитываешь, что в ней отражены все нюансы и тонкости, если нет — это плохой тон. В данном случае автор т.н. API, которое мы фактически парсим, ничего нам не должен и в любой момент может поменять любой тип данных от чего GraphQL начнёт ругаться.
К слову, я вообще по себе заметил, что работая с JS я стал более внимательным к типам данных и условиям
Вот это неоспоримый факт! Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…
7. modstore.pro и modx.pro судя по всему — это абсолютно разные сайты со своими отдельными базами данных.
Это смотря для каких целей.
— Если тупо всю необходимую инфу получать и выводить о товарах, то RESTful подойдёт, он же проще ставится и работает только на PHP, на котором и сам MODX крутится.
— Если же нужна универсальность API, для какого-то мобильного приложения или SPA, то GraphQL будет предпочтительнее. Правда работы изначально придётся провести довольно много, чтобы прописать всё взаимодействие (запросы, мутации, подписки) в резолверы.
Может показаться, что все кто молчит, согласны с наездами, поэтому отпишусь.
Я не согласен! Человек захотел написать об этом заметку, почему нет? Сообщество итак редко пополняется, а часто бывают заметки, которые просто трудно читать из-за корявого форматирования. А тут вам и оформление, и гифка — читать приятно, короче. К тому-же, если это мотивирует Баху, то блин, пусть хоть каждую неделю пишет!
P.S. Если взять за основу психологическую модель «Треугольник Карпмана», то оч забавно наблюдать, как притеснители, высказывая своё недовольство и получив жёсткий ответ, становятся в роль жертвы…
Да + будут проблемы (большие) с производительностью, если использовать связку, описанную в данной статье (mSearch2 + SeoFilter), и дело не в том, что они в связке дают такой эффект, но и отдельно mSearch2 на большом кол-ве товаров и опций в фильтре будет тормозить.
Я сомневаюсь, что Яндекс узнает об этих страницах, только если через код Яндекс Метрики. Но вы можете вручную на страницах сайта указывать ссылки на эти страницы + можно поизвращаться и создать отдельный сайтмап из таблиц этого компонента.
Как-то ради интереса сгенерил около 1 млн ресурсов на голом сайте. Создавал через runProcessor, чтобы эксперимент был близок к реальности. Так каждый последующий ресурс создавался дольше предыдущего. При чём ближе к цели сохранение ресурса (а точнее сброс и создание кеша) доходило до нескольких секунд. Я уже не говорю о том, что дерево ресурсов просто подвисло (считай, админка перестала функционировать).
В общем, на ресурсах с такими объёмами далеко не уедешь. Тут либо создавать свою альтернативу ресурсам, либо использовать другие технологии вообще.
То есть, на примере ИМ, можно просто описать схему запросов и мутаций для msCategory, msProduct, msOrder и т.п. и оно поедет?
Вот это неоспоримый факт! Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…
Так и есть, Василий ни раз об этом говорил.
— Если тупо всю необходимую инфу получать и выводить о товарах, то RESTful подойдёт, он же проще ставится и работает только на PHP, на котором и сам MODX крутится.
— Если же нужна универсальность API, для какого-то мобильного приложения или SPA, то GraphQL будет предпочтительнее. Правда работы изначально придётся провести довольно много, чтобы прописать всё взаимодействие (запросы, мутации, подписки) в резолверы.
Согласен. Мне тоже нравится Sharp.
Я не согласен! Человек захотел написать об этом заметку, почему нет? Сообщество итак редко пополняется, а часто бывают заметки, которые просто трудно читать из-за корявого форматирования. А тут вам и оформление, и гифка — читать приятно, короче. К тому-же, если это мотивирует Баху, то блин, пусть хоть каждую неделю пишет!
P.S. Если взять за основу психологическую модель «Треугольник Карпмана», то оч забавно наблюдать, как притеснители, высказывая своё недовольство и получив жёсткий ответ, становятся в роль жертвы…
Я сомневаюсь, что Яндекс узнает об этих страницах, только если через код Яндекс Метрики. Но вы можете вручную на страницах сайта указывать ссылки на эти страницы + можно поизвращаться и создать отдельный сайтмап из таблиц этого компонента.
В общем, на ресурсах с такими объёмами далеко не уедешь. Тут либо создавать свою альтернативу ресурсам, либо использовать другие технологии вообще.
Нет такого. Можете в коде default.js добавить самостоятельно.
P.S. Вопросы по приобретённому компоненту задавайте в техподдержку Modstore.
Отменить нельзя — не пойму смысла.