Правила валидации хранятся на сервере. В зависимости от того, как часто и с какой скоростью их требуется обновлять, можно держать правила в коде, в БД, в конфигах, во внешних системах и так далее. При этом правила клиентской валидации носят вспомогательный характер и могут значительно отличаться от правил серверной валидации.
В основном, технология пилотируется, но на первый результат уже можно посмотреть – это раздел «Регистрация на Госуслугах» в веб-версии Сбербанк Онлайн.
Да, одна из наших команд работает над оптимизацией входа в приложения (мобильное и веб), и TOTP тоже есть в списке кандидатов. Если сообществу это интересно, можем попросить коллег написать отдельную статью с результатами анализа.
Мы используем JSON, но он слишком громоздкий, поэтому описания даны в формате YAML.
Если вкратце и чуть более погружаясь в технику: в нашем случае JSON – это транспортный уровень протокола, а в статье описана детализация спецификации представительского уровня протокола (согласно сетевой модели OSI).
Соответственно, представительский слой может передаваться посредством любого транспортного слоя – XML, YAML, JSON, plain text. Это вопрос договорённостей и удобства. Для нужд демонстрации было удобно дать описания в YAML просто потому что он проще читается.
В таком случае GraphQL перестаёт отличаться от классического подхода – например, REST, но становится довольно сильно избыточным. По сути, мы передаём полную информацию о запросе, но кроме неё при таких ограничениях ничего передать нельзя. Почему бы тогда не держать соответствие на сервере: путь к HTTP-методу = запрос?
Коллеги, философский вопрос «где заканчивается безопасность и начинается вторжение» – очень интересный, но обсудить с сообществом мы хотели совсем не это. Мы будем очень рады вести дискуссию по теме, а фундаментальные вопросы вселенной можно обсудить отдельно на любой нетехнической площадке.
В архитектуре, где он применим, клиентское и серверное приложение развиваются независимо друг от друга. В такой ситуации необходим абстрактный инструмент для получения данных – именно данных! – который не требует традиционных доработок бэкэнда: обработчика запросов к пути, получения данных из базы, очистки и приведения результата к JSON.
Наша же основная задача состояла в том, чтобы передавать клиентскому приложению кроме данных достаточное количество сопутствующей мета-информации. Ну и, с одной стороны, не слишком перегрузить этим API, а с другой стороны – обеспечить нужную степень управляемости.
Кроме этого GraphQL не даёт возможностей для оптимизации работы под нагрузкой, поскольку нельзя спрогнозировать, какие именно клиентское приложение будет формировать запросы. Напротив, в случае, когда API работает с ограниченным набором данных, можно, например, строить промежуточные слои кэширования и явно прогнозировать нагрузку на разные подсистемы.
Конечно, не надо. Потребность в JS не говорит о том, что с помощью него решают любые задачи – с помощью него удобно решаются задачи, характерные для сегодняшнего дня.
Вы невнимательно читаете, я нигде не утверждаю, что nodejs асинхронный. Да, есть не только в node, но JS-программист сравнительно дешевле, чем, например, программист на Erlang.
Ваша позиция плоха ровно на столько же, насколько та, с которой вы спорите. Всякой задаче свой инструмент — и если nodejs эффективно справляется с асинхронными риалтаймовыми задачами, почему бы не применить его на сервере? Ну да, положим, вы можете написать что-то аналогичное на почти любом другом языке, но зачем, если это дороже?
В Sublime Text 3 есть функция Go To Anything (Ctrl + P), которая в значительной степени реализует ваш функционал.
Поддерживаете ли вы переходы между вкладками по Ctrl + Tab, Ctrl + Shift + Tab, Ctrl + %d? Если да, то как реализована логика перехода, если порядок вкладок постоянно меняется без непосредственного участия пользователя?
Сортируете ли вы как-то прикреплённые вкладки на основании данных использования? Есть ли ручная сортировка?
Я вот тоже долгое время придерживался этого мнения.
А потом неожиданно обнаружил, что программисту нужно образование, которое прививает культуру структурирования и развивает абстрактное мышление. В принципе, этому можно научиться самостоятельно, но, вообще говоря, высшее математическое образование с этим справляется лучше всего. В частности, часто оказывается, что троечник с математического/физического/другого технического факультета лучше воспринимает концепты и пишет более чистый код, чем очень-талантливый-парень-но-совсем-без-вышки.
Мы используем JSON, но он слишком громоздкий, поэтому описания даны в формате YAML.
Если вкратце и чуть более погружаясь в технику: в нашем случае JSON – это транспортный уровень протокола, а в статье описана детализация спецификации представительского уровня протокола (согласно сетевой модели OSI).
Соответственно, представительский слой может передаваться посредством любого транспортного слоя – XML, YAML, JSON, plain text. Это вопрос договорённостей и удобства. Для нужд демонстрации было удобно дать описания в YAML просто потому что он проще читается.
В архитектуре, где он применим, клиентское и серверное приложение развиваются независимо друг от друга. В такой ситуации необходим абстрактный инструмент для получения данных – именно данных! – который не требует традиционных доработок бэкэнда: обработчика запросов к пути, получения данных из базы, очистки и приведения результата к JSON.
Наша же основная задача состояла в том, чтобы передавать клиентскому приложению кроме данных достаточное количество сопутствующей мета-информации. Ну и, с одной стороны, не слишком перегрузить этим API, а с другой стороны – обеспечить нужную степень управляемости.
Кроме этого GraphQL не даёт возможностей для оптимизации работы под нагрузкой, поскольку нельзя спрогнозировать, какие именно клиентское приложение будет формировать запросы. Напротив, в случае, когда API работает с ограниченным набором данных, можно, например, строить промежуточные слои кэширования и явно прогнозировать нагрузку на разные подсистемы.
Вы невнимательно читаете, я нигде не утверждаю, что nodejs асинхронный. Да, есть не только в node, но JS-программист сравнительно дешевле, чем, например, программист на Erlang.
Поддерживаете ли вы переходы между вкладками по Ctrl + Tab, Ctrl + Shift + Tab, Ctrl + %d? Если да, то как реализована логика перехода, если порядок вкладок постоянно меняется без непосредственного участия пользователя?
Сортируете ли вы как-то прикреплённые вкладки на основании данных использования? Есть ли ручная сортировка?
А потом неожиданно обнаружил, что программисту нужно образование, которое прививает культуру структурирования и развивает абстрактное мышление. В принципе, этому можно научиться самостоятельно, но, вообще говоря, высшее математическое образование с этим справляется лучше всего. В частности, часто оказывается, что троечник с математического/физического/другого технического факультета лучше воспринимает концепты и пишет более чистый код, чем очень-талантливый-парень-но-совсем-без-вышки.
Бывают и исключения, но не так часто.
Нашёл для себя в качестве альтернативы Stylus, который:
а) нативный,
б) довольно быстрый,
в) более гибкий.
Рекомендую.