Как раз такие мелочи вроде операторов ?? Или <=> плюс типы в том числе и возвращаемых значений когда их накопиться достаточно много и создают эффект изменения стилистики.
Язык все ещё развиваться пусть и не такими ударными темпами как раньше.
Вы меня уделали. Совсем забыл об этих особенностях хотя guzzle довольно часто использую. Но сути это особо не меняет. Почему-то все относятся к php как будто он застрял на версии 5.3 и да, тогда он действительно был не самым лучшим языком. Но с php 5.4 и выше это уже вполне серьезный язык со всем что должно быть в серьезном скриптовом языке для web. Даже несмотря на то что js в данный момент дико популярен мне в нем действительно не хватает многих вещей которые есть в php из коробки.
строгая типизация уже есть, замыкания не хуже чем в js, чистые функции — да пожалуйста, единственно параллельного выполнения нет, но для языка который создан работать в один поток и умереть это не особо и нужно.
могу предположить все что is_object($var) — а где пригодиться?
пока думаю только прокси объекты — которым важно что через них был передан какой-либо объект, лишь бы только объект
Что касается массива — думаю объекты описывающие интерфейсы массива все-таки пройдут
В случае если использовать изоморфные приложения как у вас тогда все просто и понятно, но как эксперимент — попробуйте представить, просто представить что backend у вас не ваш любимый node.js а на java или например как в моем случае php.
Попробуйте описать 2 раза типы мутации и запросы ручками для клиента на том-же Apollo и следом за этим описать эти-же типы запросы и мутации на сервере используя например
php = laravel + folklore/graphql
java = Spring + graphql-java
я бы посмотрел на это =)
P.S
используйте GraphQL только если у вас изоморфное приложение на платформе node.js
А бизнес логика как и положено лежит бизнес слое который собственно и инжектируется через DI в типы мутации и запросы, слава DDD при желании можно переписать все на REST тупо генерированием тех же REST ресурсов для каждого объекта логики.
1) Я не говорю что сам протокол graphql плох
2) Имхо для описание одного REST ресурса потребуется чуть меньше времени чем на описание 1 типа 3 мутаций и 2 запросов и единственный два плюса в graphql против REST это возможность выбрать список полей (включая условные выборки) и простая выборка полей связанных объектов — собственно для чего мне он и нужен — из 25 объектов 22 можно вытянуть по зависимостям имея на руках любой из них.
3) Для использования graphql нужен отдельный сервер relay/meteor а для бэка остальных платформ кроме node.js остается только использовать Apollo клиент а эти ребята полны сюрпризов я скажу — например могут внезапно выпилить поддержку Redux в новой версии и одновременно закрыть доки на старую, плюс не допилить доки на новую в итоге документацию приходиться вытаскивать их кэша гугла.
4) Для REST есть куча готовых генераторов которые позволят автоматизировать занудное создание ресурсов а для graphql мне пришлось писать такой генератор самому — причем аж 2 раза — первый для сервера а второй для клиента.
И так на backend находятся 25 таблиц в postgres причем 4 из них содержат jsonb поля с произвольным содержанием.
А теперь головные боли:
1) backend
Для того чтобы graphql заработал нужно описать запросы типы и мутации.
В коробке с graphql идет целая куча примитивных типов — вроде числа, строки, boolean и т.д
Далее идут структурные типы вроде объектов — причем для описания своего объекта необходимо описать ВСЕ поля объекта на основе существующих полей. в итоге 25 объектов в среднем с 8-10 полями — это ОЧЕНЬ много описаний. Но это еще не все внезапно нет готового типа для произвольного json — типы должны быть точно описаны. Но добавить свой тип в принципе возможно — пришлось добавить тип json самостоятельно. Связи указываются как поле которое ссылается на другой тип.
Хорошо у нас есть типы объектов но сами по себе они бесполезны! необходимы запросы к объектам на основе эти типов. предположим я желаю 2 типа запросов на каждый объект первый — показать по id или по другому ключевому полю и второй — показать все по каком-либо набору критерию. В итоге мы уже описываем аргументы. В итоге по 2-5 аргументов на каждую сущность в каждом запросе по два на сущность — и это опять достаточно много описаний.
Далее мутации — если взять 3 мутации (удалить, добавить, изменить) то опять описываем аргументы, для мутаций уже те самые 8-10 полей и это опять куча аргументов + еще правила валидации для каждого поля в каждой мутации.
Смотрим видим что необходимо создать просто огромное количество кода для описания graphql для CRUD+list для 25 объектов.
В итоге рвем на голове волосы от чисто объема кода и пишем некий генератор который используя рефлексию и немного doctrine/dbal шерстит наши таблицы и генерирует поля для наших типов и аргументы для наших запросов и мутаций. Сам генератор принимает список объектов и какие поля/аргументы не надо генерировать.
Все это месяц работы.
2) фронт
Здесь нам опять необходимо описать наши 50 запросов и 150 мутаций — хорошо есть генератор из php который выдаст нам схему и мы определим хитрый Higher-Order Component (HOC) который будет принимать конфиг из серии
Объект
поля
запросы
аргументы запроса
поля запроса
мутации
аргументы мутации
поля мутации
После чего генерирует код наших запросов/мутаций (graphql-tag), и прописывает их в props нашего объекта.
Хорошо — теперь бы нам пробросить наши запросы в props наших объектов.
Для этого внезапно Apollo предлагает свои HOC который принимают graphql-tag и пробрасывают свойства в объект. И для контроля выполнения запросов еще один HOC.
В итоге получаем эдакий толстый бургер где наши 2 HOC это 2 булки — один для предоставления и генерации запросов, второй для того чтобы упростить вызов этих запросов а между ними уже лежит начинка в виде HOC для каждого запроса/мутации.
После чего строим 25 data-table оборачиваем их в наш HOC с разными конфигами и радуемся.
Все это звучит понятно просто и легко но по факту это достаточно сложная работа.
Итог:
Если у вас более 5 объектов в системе и вы не хотите её делать год одному и 3 месяца одной командой из 5 человек — не используйте graphql.
если вы не используете специальный saas/baas или другой софт который использует graphql из коробки и умеет генерировать запросы/мутации на основе типов — не используйте graphql.
если у вас не graphqlCool фреймворк например meteor не используйте graphql
В основном возникла проблема со сборкой доков — у меня целая куча папок с md файлами, собирал я все это через MkDocs. Постепенно размер каждого файла вырос и редактировать их стало адово сложно.
reStructuredText позволяет же тупо сделать include одного файла в другой, что позволило разбить исходники доков по одному на модуль — при сборке они будут одним документом,
rst может автоматом создает оглавление на основе заголовков
(yml в MkDocs надо забивать руками) и приятные мелочи вроде создания таблицы из csv меня и подкупили.
В прошлой компании где я работал у меня был личный кабинет — довольно просторная комната, шкаф, пара столов и тумбочка. После недели работы в одиночестве мне стало очень не комфортно.
Был и в openspace с кучей народа все они говорят и шумят что не дает сконцентрироваться.
Самым адекватным вариантом оказался кабинет для отдела — в кабинете 4-6 человек из одной команды, если шумим то все вместе, если работаем то все молча.
Markdown на самом деле довольно шикарный формат когда нужно сделать например описание проекта на том-же github. Но постепенно создавая доки я обнаружил что мне не хватает некоторых фичей, тогда я открыл для себя reStructuredText (rst) и он еще более шикарен.
С недавних пор начал копать React и эти ES6 штучки настолько удобны, что когда возвращаешься рефакторить старые проекты с jQuery без зависимостей, модулей, стрелочных функций, let и const начинаешь плакать кровавыми слезами, хотя еще пол года кивал над словами коллеги — нафиг все эти сложности — jQuery рулит.
Иногда есть проблемы которые с наскока не решить, например у меня было два таких случая — в первом я месяц бился над решением задачи и в итоге когда уже совсем отчаялся — тупо лег спать и увидел решение во сне, утром я сразу попробовал реализовать его и оно как не странно сработало.
Второй случай похож, в общем я неделю загонялся по одной таске но потом в офис пришел корпоратив, я наклюкался в дрова и набыдлокодил непонятно что — после на трезвую голову я понял что решил это, отрефакторил код, вылил на прод и уже как 3 года он работает.
Да типовые задачи должны решаться на раз, желательно подключением готовой и отлаженной профессионалами библиотеки, но иногда есть проблемы для которых нет готовых решений, вот тут и надо немного удачи и вдохновения и тонны тяжелого труда.
php меня кормит уже 4 года. Начинал с древнего php 5.3 сейчас активно использую 7.1 для реальных проектов. У нас команда из двух верстальщиков, двух студентов, двух мидлов и двух менеджеров что тоже пишут на php. Рядом еще отдел java с похожим составом.
Новый php в связки с laravel хорош, да есть еще легаси на 5.4 от которого стынет в жилах кровь. Только вот в плане фронта далеко на чистом php и старой доброй jquery далеко не уедешь. Angular/React/Vue быть и это полезные технологии которые позволяют очень многое. В данный момент разбираюсь с redux и делаю фановые штуки на React.
К сожалению сама по себе node.js не такая на мой взгляд платформа на которой стоит делать "серьезный" backend. Так что возможно работать в связке node+php где простые stateless компоненты взаимодействуют с более "серьезным" api на том же php. Проблема правда в том что для backend вместо php спокойно можно ставить java/go/python где серьезные вещи можно будет сделать проще на них.
Итог — если вы хотите чуть больше чем костыли на jq — node.js вам понадобиться, php — не сложный бэк и в этом он реально хорош, для кошмарных вещей лучше использовать java, для кучи мелких но быстрых go.
Пусть даже и ограничивает, одной активной вкладки с майнером и 5-и которые в фоне "приторможенные" один фиг могут посадить батарею, а обычный юзверь может открыть и все 20-50 вкладок (видел у жены брата и у своей матери).
Фанатам лиса даже на мобиле (вроде меня, подкупили режим чтения — он ИМХО удобен даже для хабра) походу точно придется страдать — и так не держу больше 10 вкладок а если с майнингом то вообще полный лисец будет.
Еще интересно как на этот майнер отреагируют старые устройства с устаревшим хромом или вообще стоковым webview который не хром (как на моей старой ZTE) учитывая что они бывают даже при звонках виснут уже.
Тихий ужас для мобильников и планшетов, ладно десктопы и ноуты где можно поставить блокировщики,NoScript, прописать список dns в старом добром bind на роутере или в /etc/hosts.
На мобилке мало адекватных блокировщиков, без рута фиг настроишь iptables и dns, о майнинге узнаешь только тогда, когда батарея кончиться, посмотреть что напихал сайт в твой мобильный хром или лису сложновато без кое-каких инструментов. Так что ждем веселье для бедных пользователей смартфонов когда лагать будет даже оболочка.
Дизайн вк хорош, но вот с музыкой на мобиле все-таки напортачили.
Когда я отрываю музыку из плеера в фоне и нажимаю свернуть — я надеюсь что он меня вернет в вк но вместо этого плеер тупо сворачиваться. Сама музыка имеет странную особенность лагать даже при нормальном интернете особенно при переключении между треками. В итоге пришлось таки поставить этот ваш boom — там нет лагов при переключении между треками и сами треки загружаться нормально хотя-бы, и не оставляют меня без музыки в наушниках.
Как раз такие мелочи вроде операторов ?? Или <=> плюс типы в том числе и возвращаемых значений когда их накопиться достаточно много и создают эффект изменения стилистики.
Язык все ещё развиваться пусть и не такими ударными темпами как раньше.
Вы меня уделали. Совсем забыл об этих особенностях хотя guzzle довольно часто использую. Но сути это особо не меняет. Почему-то все относятся к php как будто он застрял на версии 5.3 и да, тогда он действительно был не самым лучшим языком. Но с php 5.4 и выше это уже вполне серьезный язык со всем что должно быть в серьезном скриптовом языке для web. Даже несмотря на то что js в данный момент дико популярен мне в нем действительно не хватает многих вещей которые есть в php из коробки.
А что плохого в php 7.x ?
строгая типизация уже есть, замыкания не хуже чем в js, чистые функции — да пожалуйста, единственно параллельного выполнения нет, но для языка который создан работать в один поток и умереть это не особо и нужно.
могу предположить все что is_object($var) — а где пригодиться?
пока думаю только прокси объекты — которым важно что через них был передан какой-либо объект, лишь бы только объект
Что касается массива — думаю объекты описывающие интерфейсы массива все-таки пройдут
В случае если использовать изоморфные приложения как у вас тогда все просто и понятно, но как эксперимент — попробуйте представить, просто представить что backend у вас не ваш любимый node.js а на java или например как в моем случае php.
Попробуйте описать 2 раза типы мутации и запросы ручками для клиента на том-же Apollo и следом за этим описать эти-же типы запросы и мутации на сервере используя например
я бы посмотрел на это =)
P.S
используйте GraphQL только если у вас изоморфное приложение на платформе node.js
Собственно мне и пришлось реализовать подобные генераторы для graphql с костылями в велосипедами ибо ручками такой объем кода не потяну физически.
А бизнес логика как и положено лежит бизнес слое который собственно и инжектируется через DI в типы мутации и запросы, слава DDD при желании можно переписать все на REST тупо генерированием тех же REST ресурсов для каждого объекта логики.
1) Я не говорю что сам протокол graphql плох
2) Имхо для описание одного REST ресурса потребуется чуть меньше времени чем на описание 1 типа 3 мутаций и 2 запросов и единственный два плюса в graphql против REST это возможность выбрать список полей (включая условные выборки) и простая выборка полей связанных объектов — собственно для чего мне он и нужен — из 25 объектов 22 можно вытянуть по зависимостям имея на руках любой из них.
3) Для использования graphql нужен отдельный сервер relay/meteor а для бэка остальных платформ кроме node.js остается только использовать Apollo клиент а эти ребята полны сюрпризов я скажу — например могут внезапно выпилить поддержку Redux в новой версии и одновременно закрыть доки на старую, плюс не допилить доки на новую в итоге документацию приходиться вытаскивать их кэша гугла.
4) Для REST есть куча готовых генераторов которые позволят автоматизировать занудное создание ресурсов а для graphql мне пришлось писать такой генератор самому — причем аж 2 раза — первый для сервера а второй для клиента.
Внезапно в данный как раз занимаюсь одним бизнес приложением с использованием этой технологии и могу много чего интересного рассказать.
На бэке стоит внезапно php и laravel для подключения используется единственная более-менее адекватный коннектор который по сути обертка над этой либой
На фронте используется React + Apollo
И так на backend находятся 25 таблиц в postgres причем 4 из них содержат jsonb поля с произвольным содержанием.
А теперь головные боли:
1) backend
Для того чтобы graphql заработал нужно описать запросы типы и мутации.
В коробке с graphql идет целая куча примитивных типов — вроде числа, строки, boolean и т.д
Далее идут структурные типы вроде объектов — причем для описания своего объекта необходимо описать ВСЕ поля объекта на основе существующих полей. в итоге 25 объектов в среднем с 8-10 полями — это ОЧЕНЬ много описаний. Но это еще не все внезапно нет готового типа для произвольного json — типы должны быть точно описаны. Но добавить свой тип в принципе возможно — пришлось добавить тип json самостоятельно. Связи указываются как поле которое ссылается на другой тип.
Хорошо у нас есть типы объектов но сами по себе они бесполезны! необходимы запросы к объектам на основе эти типов. предположим я желаю 2 типа запросов на каждый объект первый — показать по id или по другому ключевому полю и второй — показать все по каком-либо набору критерию. В итоге мы уже описываем аргументы. В итоге по 2-5 аргументов на каждую сущность в каждом запросе по два на сущность — и это опять достаточно много описаний.
Далее мутации — если взять 3 мутации (удалить, добавить, изменить) то опять описываем аргументы, для мутаций уже те самые 8-10 полей и это опять куча аргументов + еще правила валидации для каждого поля в каждой мутации.
Смотрим видим что необходимо создать просто огромное количество кода для описания graphql для CRUD+list для 25 объектов.
В итоге рвем на голове волосы от чисто объема кода и пишем некий генератор который используя рефлексию и немного doctrine/dbal шерстит наши таблицы и генерирует поля для наших типов и аргументы для наших запросов и мутаций. Сам генератор принимает список объектов и какие поля/аргументы не надо генерировать.
Все это месяц работы.
2) фронт
Здесь нам опять необходимо описать наши 50 запросов и 150 мутаций — хорошо есть генератор из php который выдаст нам схему и мы определим хитрый Higher-Order Component (HOC) который будет принимать конфиг из серии
Объект
После чего генерирует код наших запросов/мутаций (graphql-tag), и прописывает их в props нашего объекта.
Хорошо — теперь бы нам пробросить наши запросы в props наших объектов.
Для этого внезапно Apollo предлагает свои HOC который принимают graphql-tag и пробрасывают свойства в объект. И для контроля выполнения запросов еще один HOC.
В итоге получаем эдакий толстый бургер где наши 2 HOC это 2 булки — один для предоставления и генерации запросов, второй для того чтобы упростить вызов этих запросов а между ними уже лежит начинка в виде HOC для каждого запроса/мутации.
После чего строим 25 data-table оборачиваем их в наш HOC с разными конфигами и радуемся.
Все это звучит понятно просто и легко но по факту это достаточно сложная работа.
Итог:
Обычно я собираю его в html или в odt и все найс.
В основном возникла проблема со сборкой доков — у меня целая куча папок с md файлами, собирал я все это через MkDocs. Постепенно размер каждого файла вырос и редактировать их стало адово сложно.
reStructuredText позволяет же тупо сделать include одного файла в другой, что позволило разбить исходники доков по одному на модуль — при сборке они будут одним документом,
rst может автоматом создает оглавление на основе заголовков
(yml в MkDocs надо забивать руками) и приятные мелочи вроде создания таблицы из csv меня и подкупили.
В прошлой компании где я работал у меня был личный кабинет — довольно просторная комната, шкаф, пара столов и тумбочка. После недели работы в одиночестве мне стало очень не комфортно.
Был и в openspace с кучей народа все они говорят и шумят что не дает сконцентрироваться.
Самым адекватным вариантом оказался кабинет для отдела — в кабинете 4-6 человек из одной команды, если шумим то все вместе, если работаем то все молча.
Markdown на самом деле довольно шикарный формат когда нужно сделать например описание проекта на том-же github. Но постепенно создавая доки я обнаружил что мне не хватает некоторых фичей, тогда я открыл для себя reStructuredText (rst) и он еще более шикарен.
С недавних пор начал копать React и эти ES6 штучки настолько удобны, что когда возвращаешься рефакторить старые проекты с jQuery без зависимостей, модулей, стрелочных функций, let и const начинаешь плакать кровавыми слезами, хотя еще пол года кивал над словами коллеги — нафиг все эти сложности — jQuery рулит.
Иногда есть проблемы которые с наскока не решить, например у меня было два таких случая — в первом я месяц бился над решением задачи и в итоге когда уже совсем отчаялся — тупо лег спать и увидел решение во сне, утром я сразу попробовал реализовать его и оно как не странно сработало.
Второй случай похож, в общем я неделю загонялся по одной таске но потом в офис пришел корпоратив, я наклюкался в дрова и набыдлокодил непонятно что — после на трезвую голову я понял что решил это, отрефакторил код, вылил на прод и уже как 3 года он работает.
Да типовые задачи должны решаться на раз, желательно подключением готовой и отлаженной профессионалами библиотеки, но иногда есть проблемы для которых нет готовых решений, вот тут и надо немного удачи и вдохновения и тонны тяжелого труда.
DotEnv есть даже на php так что ничего нового
php меня кормит уже 4 года. Начинал с древнего php 5.3 сейчас активно использую 7.1 для реальных проектов. У нас команда из двух верстальщиков, двух студентов, двух мидлов и двух менеджеров что тоже пишут на php. Рядом еще отдел java с похожим составом.
Новый php в связки с laravel хорош, да есть еще легаси на 5.4 от которого стынет в жилах кровь. Только вот в плане фронта далеко на чистом php и старой доброй jquery далеко не уедешь. Angular/React/Vue быть и это полезные технологии которые позволяют очень многое. В данный момент разбираюсь с redux и делаю фановые штуки на React.
К сожалению сама по себе node.js не такая на мой взгляд платформа на которой стоит делать "серьезный" backend. Так что возможно работать в связке node+php где простые stateless компоненты взаимодействуют с более "серьезным" api на том же php. Проблема правда в том что для backend вместо php спокойно можно ставить java/go/python где серьезные вещи можно будет сделать проще на них.
Итог — если вы хотите чуть больше чем костыли на jq — node.js вам понадобиться, php — не сложный бэк и в этом он реально хорош, для кошмарных вещей лучше использовать java, для кучи мелких но быстрых go.
Пусть даже и ограничивает, одной активной вкладки с майнером и 5-и которые в фоне "приторможенные" один фиг могут посадить батарею, а обычный юзверь может открыть и все 20-50 вкладок (видел у жены брата и у своей матери).
Фанатам лиса даже на мобиле (вроде меня, подкупили режим чтения — он ИМХО удобен даже для хабра) походу точно придется страдать — и так не держу больше 10 вкладок а если с майнингом то вообще полный лисец будет.
Еще интересно как на этот майнер отреагируют старые устройства с устаревшим хромом или вообще стоковым webview который не хром (как на моей старой ZTE) учитывая что они бывают даже при звонках виснут уже.
Тихий ужас для мобильников и планшетов, ладно десктопы и ноуты где можно поставить блокировщики,NoScript, прописать список dns в старом добром bind на роутере или в /etc/hosts.
На мобилке мало адекватных блокировщиков, без рута фиг настроишь iptables и dns, о майнинге узнаешь только тогда, когда батарея кончиться, посмотреть что напихал сайт в твой мобильный хром или лису сложновато без кое-каких инструментов. Так что ждем веселье для бедных пользователей смартфонов когда лагать будет даже оболочка.
Дизайн вк хорош, но вот с музыкой на мобиле все-таки напортачили.
Когда я отрываю музыку из плеера в фоне и нажимаю свернуть — я надеюсь что он меня вернет в вк но вместо этого плеер тупо сворачиваться. Сама музыка имеет странную особенность лагать даже при нормальном интернете особенно при переключении между треками. В итоге пришлось таки поставить этот ваш boom — там нет лагов при переключении между треками и сами треки загружаться нормально хотя-бы, и не оставляют меня без музыки в наушниках.