В 2025 так же была добавлена КОАП 13.52 со штрафами для владельцев впн если он позволяет доступ к запрещенному контенту. Так что свой впн тоже не очень законно.
Вам видится то чего нет. Я писал только о том что кризис в ИТ отсрочился по вполне объективным причинам - это как отсрочка закрытия существующих контрактов (о чем изначально писал), так и, внезапно, помощь государства - у ИТ всегда были преференции по налогам (в т.ч. за счет этого оно и росло), льготная ипотека, и пр.
И вообще, когда вы в качестве причины нынешнего кризиса ИТ в РФ выдвигаете изоляцию - не кажется ли вам такая причина анахронизмом: изоляция началас в 22-м году, а кризис - в 25-м?
Да не, как-то так и есть - после ухода апворка старые контракты стали прямыми, они постепенно завершились, а новых нет и взяться им неоткуда. Очень большую роль тут сыграли санкции - платить становилось всё сложнее и дороже. Бонусом наше валютное законодательство родом из СССР - куча бумажек и местами штрафы до 100%.
Слишком оптимистично. Фриланс в российском вебдеве еще до ковида был при смерти. В то время было неплохо работать на иностранных заказчиков через иностранные биржи, но там тоже все вытеснялись дешевыми индийцами/китайцами, а интересные проекты были по сути фултайм (но без отпусков и прочих плюшек офиса) - т.е. при наличии основной работы мимо. Ну а сейчас на российском рынке остались только совсем мелкие задачи за копейки.
При желании можно сделать 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 до сих пор предлагается всё это делать ручками. Т.е. форкаем библиотеку, добавляем её как-то в проект, редактируем, генерим патч, а потом это всё поддерживать как-то надо. Красотища :(
ЗЫ: Очередной раз за несколько лет понадобилось добавить патч в проект, но снова мне лень ибо генерировать патчи руками это мертворожденный подход, как мне кажется.
В 2025 так же была добавлена КОАП 13.52 со штрафами для владельцев впн если он позволяет доступ к запрещенному контенту. Так что свой впн тоже не очень законно.
Вам видится то чего нет. Я писал только о том что кризис в ИТ отсрочился по вполне объективным причинам - это как отсрочка закрытия существующих контрактов (о чем изначально писал), так и, внезапно, помощь государства - у ИТ всегда были преференции по налогам (в т.ч. за счет этого оно и росло), льготная ипотека, и пр.
Мем где-то из конца 10x, там же рядом 9.5 правил ведения ит бизнеса в России.
Да не, как-то так и есть - после ухода апворка старые контракты стали прямыми, они постепенно завершились, а новых нет и взяться им неоткуда. Очень большую роль тут сыграли санкции - платить становилось всё сложнее и дороже. Бонусом наше валютное законодательство родом из СССР - куча бумажек и местами штрафы до 100%.
Слишком оптимистично. Фриланс в российском вебдеве еще до ковида был при смерти. В то время было неплохо работать на иностранных заказчиков через иностранные биржи, но там тоже все вытеснялись дешевыми индийцами/китайцами, а интересные проекты были по сути фултайм (но без отпусков и прочих плюшек офиса) - т.е. при наличии основной работы мимо. Ну а сейчас на российском рынке остались только совсем мелкие задачи за копейки.
При желании можно сделать 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}