Топовые нарративы собирают в 5 раз больше показов и просмотров, чем обычные. Но все зависит от того, насколько нарратив интересен пользователям. Даже нарративы без такого промо могут собрать до 500 тысяч показов и до 60 тысяч просмотров.
Наверное, имеется в виду: «Как убрать из моей ленты Дзена новости»? К сожалению, специальной кнопки про это нет, но можно просто блочить все эти каналы — по дизлайку на карточке появится «сервисное меню», где будет вариант «Заблокировать канал».
И их есть у сообщества!) Например, для node.js — www.apollographql.com/servers — я его использовал в production, очень всё удобно сделано как express middleware.
«автоматическую сериализацию/десериализацию моделей (например, не нужно проверять пришло ли поле с клиента, все проверяется автоматически)» — это в GraphQL из коробки и, в целом, и является одной из основных фишек GraphQL.
«возможность генерации схемы API» — аналогично есть в GraphQL
«генерацию документации на основе схемы» — если под документацией является графическое представление имеющегося API, то это решается инструментами типа github.com/gjtorikian/graphql-docs
«генерацию полностью типизированного SDK для клиента » — есть очень много готовых клиентов для GraphQL на всех популярных платформах, в т.ч. на JS с хорошей интеграцией с React (Apollo или Relay от Facebook). См. github.com/chentsulin/awesome-graphql#lib
В силу того, что GraphQL — это стандартизированная спецификация, существует множество решений «вокруг», которые дают очень большое количество функциональности «на вырост» (типа выемка только тех полей моделей, что были запрошены, подписки на изменения, графическая «песочница» для работы с API (GraphiQL), всевозможные расширения для популярных IDE и т.д.).
Не всегда есть время и ресурсы на все этапы проектирования.
1. Находили ли вы способы сокращения этого цикла? На каких этапах позволительно «срезать углы»?
2. Можно выделить ряд типовых проектов, на которых можно пренебречь некоторыми этапами? (Грубый пример — сайт-визитка, где, кажется, не нужен весь цикл проектирования).
Сложно и дорого добавить полную адаптивность «от десктопа до смартфона» в крупные проекты с большой историей.
В таких проектах часто оправданы затраты ресурсов на создание отдельной версии и её поддержку, чем очень-очень много времени на перелопачивание всей кодовой базы существующего проекта для добавления адаптивности.
В больших сервисах часто делают адаптивность «десктоп — планшет» и отдельная версия для тачей.
Также стоит учитывать большое количество экспериментов, которые постоянно проводятся в больших сервисах, там критически важно уметь проводить «быстрые эксперименты» и точно разделять опыт использования сервиса на различных устройствах.
Тем не менее новые сервисы и промо-сайты Яндекса часто адаптивны, например:
— https://yandexdatafactory.com
— https://music.yandex.ru
— https://afisha.yandex.ru
— https://yandex.ru/blog
— https://yandex.ru/mobilization
Вероятно, вы попадали как раз на отдельные мобильные версии, которые часто отстают по предоставляемым возможностям от настольных, потому что их нередко делают «на сдачу» и «когда будет время».
Асинхронность в php — это не стандарт разработки, в отличие от node.js, где неблокирующее API — стандарт, который в первую очередь описывается во всех мануалах.
node.js хорош именно тем, что «направляет» писать довольно быстрые приложения.
Топовые нарративы собирают в 5 раз больше показов и просмотров, чем обычные. Но все зависит от того, насколько нарратив интересен пользователям. Даже нарративы без такого промо могут собрать до 500 тысяч показов и до 60 тысяч просмотров.
Такая статистика доступна только авторам.
Топовые нарративы тут — zen.yandex.ru/narrative
Ядро, отвечающее за обработку запросов, не зависит от express. Apollo просто его удобно обернули в middleware. А чего вам не хватает в graphql?
А вообще есть не только на JS, вы можете поискать тут по слову server — github.com/chentsulin/awesome-graphql
В силу того, что GraphQL — это стандартизированная спецификация, существует множество решений «вокруг», которые дают очень большое количество функциональности «на вырост» (типа выемка только тех полей моделей, что были запрошены, подписки на изменения, графическая «песочница» для работы с API (GraphiQL), всевозможные расширения для популярных IDE и т.д.).
Подход чем-то похож на GraphQL. К нему не присматривались?
Информация не соответствует действительности.
Какой логической цепочкой вы пользовались, чтобы прийти к такому выводу?
Не всегда есть время и ресурсы на все этапы проектирования.
1. Находили ли вы способы сокращения этого цикла? На каких этапах позволительно «срезать углы»?
2. Можно выделить ряд типовых проектов, на которых можно пренебречь некоторыми этапами? (Грубый пример — сайт-визитка, где, кажется, не нужен весь цикл проектирования).
В таких проектах часто оправданы затраты ресурсов на создание отдельной версии и её поддержку, чем очень-очень много времени на перелопачивание всей кодовой базы существующего проекта для добавления адаптивности.
В больших сервисах часто делают адаптивность «десктоп — планшет» и отдельная версия для тачей.
Также стоит учитывать большое количество экспериментов, которые постоянно проводятся в больших сервисах, там критически важно уметь проводить «быстрые эксперименты» и точно разделять опыт использования сервиса на различных устройствах.
Тем не менее новые сервисы и промо-сайты Яндекса часто адаптивны, например:
— https://yandexdatafactory.com
— https://music.yandex.ru
— https://afisha.yandex.ru
— https://yandex.ru/blog
— https://yandex.ru/mobilization
node.js хорош именно тем, что «направляет» писать довольно быстрые приложения.