При желании можно сделать API почти как REST и без возможности запросить слишком много, это конечно не совсем graphql way, но большую часть недостатков снимает. В REST руками тоже много чего надо прописывать.
Очень не хватает поддержки interface и union для инпутов
Это да, и в целом слишком медленно оно развивается (@oneOf лет пять добавляли?). Хотя для больших старых приложений это даже хорошо наверное. К минусам я бы еще добавил копипасту при работе с интерфейсами (явно что-то очень тяжелое они курили когда так сделали...), тикет с 18 года висит :( Ну и 32 битный int в 2к25 несколько странно выглядит.
Так эта "виртуальная промежуточная БД" и есть наше API, GraphQL просто делает его явным (= не надо копаться в коде чтобы найти как модель конвертируется в json, не надо изобретать велосипеды для документирования этого, и прочее).
Если у вас есть документация для API (есть же?), то это и так все приходится прописывать только в отличии от GraphQL оно часто или никак не синхронизируется с кодом или делается ручками. Я честно как-то пытался подружить laravel c openapi (а до этого была какая-то сторонняя библиотека для генерации документации) - больше этим страдать не буду.
А еще никто не мешает автоматически генерировать типы GraphQL по моделям приложения.
Буквально настолько большой слой работы что как будто нужен отдельный человек .
Зачем? Дробите схему на мелкие части, вроде всё серверное умеет (в том или ином виде) эти части объединять в одну большую схему. Когда-нибудь добавят пространства имен и станет совсем хорошо. Сейчас немного неудобно придумывать названия для мутаций, вложенные мутации отчасти решают проблему, но с ними есть нюансы в очередности выполнения.
то должен ли в фронтер лезть в бэк графа если например бэк на с# ?
А в REST у вас фронтендер как узнает о том какие поля в запросе/форме есть?) В GraphQL это всё совершенно прозрачно , а если чуть доработать то в описания к полям можно добавить, например, требуемый уровень доступа, прописать правила валидации значений (автоматически ессно) - открыл схему и всё, вообще никаких вопросов в бэкэндеру ибо все очевидно из самой схемы. Фронту даже знать не надо на чем оно там внутри работает.
придет json и уже сам возьмёшь поля которые нужны и всё.
Вот только придется доставлять вообще все доступные поля, а там обычно куча данных из связанных таблиц - пустая трата ресурсов. В GraphQL будут выбраны только нужные поля.
Я как-то так же думал пока не распробовал, а теперь REST остался только для скачивания файлов. Огромный плюс GraphQL в том что он одновременно и документация для вашего API - с REST это огромная проблема и решения которые есть (тот же swagger/openapi) имеют чрезвычайно высокий порог входа (на пару порядков выше чем изучить GraphQL) и огромную кучу проблем и интеграцией в существующие проекты. А тут вся схема сразу перед глазами.
Произвольные запросы это даже хорошо - не нужно менять бэкенд на каждый чих. Ограничение нагрузки возможно, но чуть более сложно (обычно реализуется через подсчет стоимости запроса). С кешированием тоже решаемо (но сложнее да). Еще из преимуществ @deprecated из коробки, что позволяет постепенно мигрировать на новое API (и в целом рекомендуется именно этот подход, а не v1, v2 и прочее). Для фронта/клиентов тоже куча преимуществ - можно например генерировать типы и отслеживать опечатки в запросах еще на этапе компиляции. А еще можно автоматически поднять тестовый сервер который будет эмулировать вашу схему.
В целом, несмотря на некоторые недостатки (чуть медленее, сложнее, 32 битный int, до сих пор нету пространств имен, ...), сейчас не вижу никакого смысла использовать что-то другое (за исключением скачивания файлов).
Например, доступ во внутреннюю сеть организации для работы. Или даже самое банальное - попасть на ресурс который запретил доступ из РФ (но сам не запрещен в РФ). Для юрлиц/ип там уже совсем другие штрафы - от 200к (а за повторное от 800к).
Даже интересно стало - а можно ли настроить впн так чтобы он соблюдал запреты? Списки то ведь не публичные, максимум можно проверить конкретные URL. Или вот как быть с ютюбом? Официально никакого запрета на доступ к нему нет.
Странно что все игнорируют новую статью 13.52 которая устанавливается в т.ч. ответственность для владельцев впн за преодоление запрета на доступ к запрещенному контенту. Под неё ведь похоже попадают все кто настроил свой собственный впн? (штраф от 50к)
Статья старая, но всё еще актуальная. Так вот, заголовок не соответствует действительности - совсем не без боли. Как патч то создать? В том же js (patch-package) просто берешь и редактируешь код зависимости, запускаешь команду и у тебя готовый патч (еще и под разные версии той библиотеки что патчим). При этом этап создания патча самый трудоемкий, к сожалению, в PHP до сих пор предлагается всё это делать ручками. Т.е. форкаем библиотеку, добавляем её как-то в проект, редактируем, генерим патч, а потом это всё поддерживать как-то надо. Красотища :(
ЗЫ: Очередной раз за несколько лет понадобилось добавить патч в проект, но снова мне лень ибо генерировать патчи руками это мертворожденный подход, как мне кажется.
GitHub Actions на данный момент не позволяет этого сделать, удерживая уровень вложенности как 2 - то есть только связка вызывающего и вызываемого workflow.
Уже 4 + можно вкладывать их друг в друга, и в матрицы тоже можно, а сами матрицы могут содержать другие матрицы, и т.д.
В РФ обучение на категорию B это ~186 часов из которых 56 часов это практика. При этом минимальный срок обучения в автошколе 2.5 месяца (быстрее маловероятно ибо автошколе прилетит "привет" сверху...). С 56 часами практики всё мухлюют, например считают академическими часами вместо астрономических, за счет чего можно рисовать красивую стоимость. Реальная же цена со всеми затратами (медсправка, пересдачи, допвождения и т.п.) при условии что прав ранее не было и ты не гений будет в районе 60к и от 3х месяцев по времени. Сам экзамен сейчас тоже весьма не прост ибо нарушать ты ничего не можешь и ты на дороге один такой ? + зависит от положения звезд (= проходит в городе, поэтому как повезет, например, пешеход внезапно метнется через пп и пойдешь на пересдачу) и настроения инспектора (у нас например есть несколько перекрестков проехать которые совсем ничего не нарушив сложно, в жизни всем всё равно, а на экзамене это почти сразу пересдача).
См 4 пункт. ЦБ только ещё ничего не определил вроде, а вот в древнем документе оно как раз таки происходило при переводе с транзитного счета. Посмотрим конечно что сейчас будет
При желании можно сделать API почти как REST и без возможности запросить слишком много, это конечно не совсем graphql way, но большую часть недостатков снимает. В REST руками тоже много чего надо прописывать.
Это да, и в целом слишком медленно оно развивается (
@oneOfлет пять добавляли?). Хотя для больших старых приложений это даже хорошо наверное. К минусам я бы еще добавил копипасту при работе с интерфейсами (явно что-то очень тяжелое они курили когда так сделали...), тикет с 18 года висит :( Ну и 32 битныйintв 2к25 несколько странно выглядит.Так эта "виртуальная промежуточная БД" и есть наше API, GraphQL просто делает его явным (= не надо копаться в коде чтобы найти как модель конвертируется в json, не надо изобретать велосипеды для документирования этого, и прочее).
Если у вас есть документация для API (есть же?), то это и так все приходится прописывать только в отличии от GraphQL оно часто или никак не синхронизируется с кодом или делается ручками. Я честно как-то пытался подружить laravel c openapi (а до этого была какая-то сторонняя библиотека для генерации документации) - больше этим страдать не буду.
А еще никто не мешает автоматически генерировать типы GraphQL по моделям приложения.
Зачем? Дробите схему на мелкие части, вроде всё серверное умеет (в том или ином виде) эти части объединять в одну большую схему. Когда-нибудь добавят пространства имен и станет совсем хорошо. Сейчас немного неудобно придумывать названия для мутаций, вложенные мутации отчасти решают проблему, но с ними есть нюансы в очередности выполнения.
А в REST у вас фронтендер как узнает о том какие поля в запросе/форме есть?) В GraphQL это всё совершенно прозрачно , а если чуть доработать то в описания к полям можно добавить, например, требуемый уровень доступа, прописать правила валидации значений (автоматически ессно) - открыл схему и всё, вообще никаких вопросов в бэкэндеру ибо все очевидно из самой схемы. Фронту даже знать не надо на чем оно там внутри работает.
Вот только придется доставлять вообще все доступные поля, а там обычно куча данных из связанных таблиц - пустая трата ресурсов. В GraphQL будут выбраны только нужные поля.
Я как-то так же думал пока не распробовал, а теперь REST остался только для скачивания файлов. Огромный плюс GraphQL в том что он одновременно и документация для вашего API - с REST это огромная проблема и решения которые есть (тот же swagger/openapi) имеют чрезвычайно высокий порог входа (на пару порядков выше чем изучить GraphQL) и огромную кучу проблем и интеграцией в существующие проекты. А тут вся схема сразу перед глазами.
Произвольные запросы это даже хорошо - не нужно менять бэкенд на каждый чих. Ограничение нагрузки возможно, но чуть более сложно (обычно реализуется через подсчет стоимости запроса). С кешированием тоже решаемо (но сложнее да). Еще из преимуществ
@deprecatedиз коробки, что позволяет постепенно мигрировать на новое API (и в целом рекомендуется именно этот подход, а не v1, v2 и прочее). Для фронта/клиентов тоже куча преимуществ - можно например генерировать типы и отслеживать опечатки в запросах еще на этапе компиляции. А еще можно автоматически поднять тестовый сервер который будет эмулировать вашу схему.В целом, несмотря на некоторые недостатки (чуть медленее, сложнее, 32 битный int, до сих пор нету пространств имен, ...), сейчас не вижу никакого смысла использовать что-то другое (за исключением скачивания файлов).
Только что звонили с 0321 и никакой тебе маркировки (билайн поволжье). Надеюсь оно всё же заработает в ближайшее время.
Например, доступ во внутреннюю сеть организации для работы. Или даже самое банальное - попасть на ресурс который запретил доступ из РФ (но сам не запрещен в РФ). Для юрлиц/ип там уже совсем другие штрафы - от 200к (а за повторное от 800к).
Даже интересно стало - а можно ли настроить впн так чтобы он соблюдал запреты? Списки то ведь не публичные, максимум можно проверить конкретные URL. Или вот как быть с ютюбом? Официально никакого запрета на доступ к нему нет.
Странно что все игнорируют новую статью 13.52 которая устанавливается в т.ч. ответственность для владельцев впн за преодоление запрета на доступ к запрещенному контенту. Под неё ведь похоже попадают все кто настроил свой собственный впн? (штраф от 50к)
Или как более универсальный вариант прогнать скриптом из https://habr.com/ru/articles/847886/comments/#comment_27381100 (ссылка в самом конце) (нашел рабочий конфиг через этот скрипт)
С позавчерашнего вечера они (билайн, поволжье) похоже что-то подкрутили и GoodbyeDPI более не помогает от "замедления" ютюба (всё остальное работает).
Wireguard был полностью забанен еще до бана ютюба (поволжье, билайн).
К сожалению была удалена в v17 и сигналы должны быть иммутабельны (https://github.com/angular/angular/issues/52735).
Статья старая, но всё еще актуальная. Так вот, заголовок не соответствует действительности - совсем не без боли. Как патч то создать? В том же js (
patch-package) просто берешь и редактируешь код зависимости, запускаешь команду и у тебя готовый патч (еще и под разные версии той библиотеки что патчим). При этом этап создания патча самый трудоемкий, к сожалению, в PHP до сих пор предлагается всё это делать ручками. Т.е. форкаем библиотеку, добавляем её как-то в проект, редактируем, генерим патч, а потом это всё поддерживать как-то надо. Красотища :(ЗЫ: Очередной раз за несколько лет понадобилось добавить патч в проект, но снова мне лень ибо генерировать патчи руками это мертворожденный подход, как мне кажется.
Ну и вон тиккеты есть https://github.com/actions/runner/issues/1489 можно проголосовать)
Можно ссылаться локально если они лежат в одном репо
./.github/workflows/{filename}Уже 4 + можно вкладывать их друг в друга, и в матрицы тоже можно, а сами матрицы могут содержать другие матрицы, и т.д.
В РФ обучение на категорию B это ~186 часов из которых 56 часов это практика. При этом минимальный срок обучения в автошколе 2.5 месяца (быстрее маловероятно ибо автошколе прилетит "привет" сверху...). С 56 часами практики всё мухлюют, например считают академическими часами вместо астрономических, за счет чего можно рисовать красивую стоимость. Реальная же цена со всеми затратами (медсправка, пересдачи, допвождения и т.п.) при условии что прав ранее не было и ты не гений будет в районе 60к и от 3х месяцев по времени. Сам экзамен сейчас тоже весьма не прост ибо нарушать ты ничего не можешь и ты на дороге один такой ? + зависит от положения звезд (= проходит в городе, поэтому как повезет, например, пешеход внезапно метнется через пп и пойдешь на пересдачу) и настроения инспектора (у нас например есть несколько перекрестков проехать которые совсем ничего не нарушив сложно, в жизни всем всё равно, а на экзамене это почти сразу пересдача).
См 4 пункт. ЦБ только ещё ничего не определил вроде, а вот в древнем документе оно как раз таки происходило при переводе с транзитного счета. Посмотрим конечно что сейчас будет
Уже есть информация как оно происходить будет? Напишу ка я наверное в банк...
Так оно теперь как-то так скорее всего будет:
ваш банк автоматически конвертирует 80% в рубли например при переводе с транзитного счета и только после этого вы сможете совершить
которую уже придется докупать за полученные рубли.