главная сложность это собственно создание непротиворечивого стандарта правил
Эти правила уже есть: REST API, Swagger/OpenAPI. Это уже набор непротиворечивых правил, которые очень хорошо поддерживаются всеми инфраструктурами (проксирование, балансировка по различным правилам, кеширование и даже условновность). Есть хорошее разделение на действие (метод), сущность (путь и параметры) и контекст (заголовки и query). Всё это прекрасно описывается схемой OpenAPI. До какого-то момента, я даже не видел смысла переходить на 3 версию.
потом убеждение всех ему следовать
Вот здесь соглашусь - вообще люди очень упёртые по натуре, уверены, что делают как проще, но по факту любят всё усложнять. Дисциплина вообще самая сложная часть в любой организации. Но не зависит вообще никак от выбранного стандарта. Поэтому чем вам точно следует гордиться, что приучили хоть к какому-то стандарту людей, пусть даже я не одобряю выбор.
Статические валидаторы, хотя их и ненавидят, очень помогают поддерживать дисциплину. Общий плюс для gql и openapi - возможность использовать принцип Schema First. Это хорошо.
потом исправление незамеченных ошибок
Поэтому хорошо, когда есть помимо стандарта, ещё и какие-то полезные работающие валидаторы. Лично мне инструментарий OpenAPI нравится тем, что я могу разработать схему инфраструктуры, сгенирировать базовый код и наполнить его бизнес-логикой на практически любом ЯП.
Я пошёл дальше и сделал с командой автогенерацию UI на основе схемы. Опять же, gql такого не позволит сделать. Но здесь видна разница в наших с вами подходах: мне интереснее как можно реже обращаться к фронтендерам и получить максимум логики из бэка, а вы с точностью наоборот рассуждаете. Начинает вырисовываться тенденция: фронтендерам больше нравится самим выбирать как работать с данными, даже в ущерб производительности, а бэкендерам нравится больше статический подход, где строгая валидация, высокая скорость за счёт оптимизаций и безопасность.
Я пишу это не ради спора. Просто надеюсь, что наш с вами диалог будет полезен тем, кто будет в будущем выбирать архитектуру и стандарт. К сожалению, лично я нахожу, что GraphQL вносит иллюзию порядка, но на деле потом вносит больше хаоса и проблем. Пока что, не нашёл ничего лучше классического HTTP Rest API и автогененерируемой схемы Swagger/OpenAPI.
При этом все это апи создавалось достаточно хаотично, кому как хотелось тот так и делал.
В этом предложении вы сами говорите, что не использовали никакой спецификации, полностью забили на стандартизацию и вообще на организацию, при этом считаете что виноват в этом REST API. Нее, ну логично, конечно.
Стали внедрять GraphQL.
А могли просто ввести спецификацию OpenAPI и привести REST API в порядок. Работы заняло бы меньше на переделку, и получили бы ещё удобный Swagger UI для интеграции и отладки запросов с документацией.
Структуру держали максимально приближенную в бд.
А что мешало это делать изначально в API? Вот, например, PostgREST делает это прекрасно настолько, что вообще не нужны бэкендеры (DBA только).
Вот об этом и речь, что формат схемы не решает проблемы организации. Только наличие спецификации и стандартизации могут в этом помочь. Какая будет при этом использоваться схема - вообще пофиг! Переписывание REST API на gql это просто смена локации кроватей.
И это я ещё тему ACL и доступа к данным не поднимал. Там вообще мрак...
Да никто и не говорит "невозможно". Просто KISS приучает делать всё как можно проще. Зачем усложнять себе жизнь ради 10-20% прироста в сериализации, если 80% времени это запрос в БД (к примеру).
С HTTP легко можно работать в cURL и отладить запрос даже с чайника. Сделать то же самое с gRPC довольно большой геморрой. Вопрос именно в этом, о чём и речь.
TLS - gRPC без сертификата в принципе боль. Локальная разработка превращается в цирк с конями на ровном месте.
Remote debugging - не всегда клиент и сервер для дебага можно разместить в одной сети. А если сервис на чём-то безгуёвом и в облаке, то боль умножается на 2. MitM частично решают, но не умеют в gRPC.
Вот поэтому многие и используют HTTP - на нём банально инструментарий богатый на все случаи жизни и отладки. Не говоря уже о важном факторе: схему надо знать. Без схемы не будет интеграции. Если сервер не подконтрольный, то с ним дружить не получится.
Больше похоже, что вы привыкли к определённому звуку. Я наоборот не могу слушать ни на форточках, ни на маках как ни старался настроить. Но я звук вывожу на микшер по USB, а там затачиваю уже как мне нравится.
Я не знаю какой браузер использовали, но я бы рекомендовал попробовать с репозитория хрома брать пакеты. Уже давно наблюдаю, что они много чего в своих билдах допиливают, по сравнению с Хромиумом, что сказывается на качестве звука и картинки.
Вы не просто один адрес хотите использовать, но и один порт тогда уж.
Даже с учётом что вы себе сами этим геморрой придумали на ровном месте, возьмите haproxy. Там где traefik захлебнется на 100 соединений в 4 vCPU, haproxy легко прожуёт это всё на одном ядре в десятикратном размере с меньшими задержками.
Traefik очень удобный, когда у вас дофигаллион разных источников для сервисов (не самих сервисов), например, кубер+docker swarm+какая-то кастомная БД+ещё какой-то HTTP-сервис. И вам нужно централизовано управлять не только подключениями, но и сертификатами, middleware и т.п.
В вашем примере с таким же успехом можно было Istio использовать. Но зачем?
Поэтому с учётом придуманной проблемы с портами (безопасники, будь у вас наоборот всё на разных нестандартных портах, обрадовались бы), хотя бы посмотрите в сторону более адекватных инструментов для маршрутизации типа haproxy.
Ну и не забудьте протюнить ядро по сетевому стеку, буферам и файловым дескрипторам, чтоб не удивиться потом. Но рано или поздно всё равно в сеть упрётесь.
вместе с Metallb Вы сможете конечно выдать IP из какого-нибудь локального пула адресов
А можно не из локального, BGP'шного. Так, кстати, внешний адрес трушно балансируется по нодам.
мы решали задачку, когда доступ нужно получить из глобальной сети Интернет к нескольким СУБД по одному и тому-же белому IP адресу.
Если прям нужно один адрес, то можно использовать аннотацию:
metallb.universe.tf/allow-shared-ip: "true"
С другой стороны, вы же как-то уже на прокси разные балансите трафик. Тут либо nodeport, либо Klipper, либо что-то вроде metallb. Ну либо calico в одной сети с NAT-маршрутизатором.
Просто для такой простой задачи разные прокси просто избыточны и часто добавляют только задержку. Если уж брать, то лучше haproxy хотя бы.
Капец как сложно. Я в kubuntu 22.04 просто запустил бинарь и всё поставил через гуй, хотя с линуксом на "бро". Правда драйвер от Nvidia уже стоял. С ним просто в kdenlive быстрее видео рендерилось.
Вот тест timeit. Результаты теста о советах подобного типа говорят сами за себя.
# python3.10 -m timeit 'result = []' 'for i in range(10):' ' result.append(i)'
500000 loops, best of 5: 676 nsec per loop
# python3.10 -m timeit 'result = [0] * 10' 'for i in range(10):' ' result[i] = i'
500000 loops, best of 5: 545 nsec per loop
# python3.12 -m timeit 'result = []' 'for i in range(10):' ' result.append(i)'
1000000 loops, best of 5: 352 nsec per loop
# python3.12 -m timeit 'result = [0] * 10' 'for i in range(10):' ' result[i] = i'
1000000 loops, best of 5: 354 nsec per loop
Использование map и filter
Вот прям очень говорящий пример, почему статья в минусах:
# python3.10 -m timeit -s 'numbers = [1, 2, 3, 4]' 'list(filter(lambda x: x % 2 == 0, numbers))'
500000 loops, best of 5: 616 nsec per loop
# python3.10 -m timeit -s 'numbers = [1, 2, 3, 4]' '[x for x in numbers if x % 2 == 0]'
1000000 loops, best of 5: 365 nsec per loop
# python3.12 -m timeit -s 'numbers = [1, 2, 3, 4]' 'list(filter(lambda x: x % 2 == 0, numbers))'
500000 loops, best of 5: 598 nsec per loop
# python3.12 -m timeit -s 'numbers = [1, 2, 3, 4]' '[x for x in numbers if x % 2 == 0]'
1000000 loops, best of 5: 200 nsec per loop
Так себе совет, потому что COPY сделает слой с колёсами, которые нужны только при установке. Правильнее будет сделать через mount, но тогда задействуется buildkit. Хотя это не проблема для большинства ситуаций, я считаю.
Т.е. тут реально кто-то обсуждает, что в блоге OTUS'а "замыкания" перевели как "закрытия", но никто не оценил совершенство очепятки kокальная переменная, которая настолько идеально передаёт качество самого материала?
Эти правила уже есть: REST API, Swagger/OpenAPI. Это уже набор непротиворечивых правил, которые очень хорошо поддерживаются всеми инфраструктурами (проксирование, балансировка по различным правилам, кеширование и даже условновность). Есть хорошее разделение на действие (метод), сущность (путь и параметры) и контекст (заголовки и query). Всё это прекрасно описывается схемой OpenAPI. До какого-то момента, я даже не видел смысла переходить на 3 версию.
Вот здесь соглашусь - вообще люди очень упёртые по натуре, уверены, что делают как проще, но по факту любят всё усложнять. Дисциплина вообще самая сложная часть в любой организации. Но не зависит вообще никак от выбранного стандарта. Поэтому чем вам точно следует гордиться, что приучили хоть к какому-то стандарту людей, пусть даже я не одобряю выбор.
Статические валидаторы, хотя их и ненавидят, очень помогают поддерживать дисциплину. Общий плюс для gql и openapi - возможность использовать принцип Schema First. Это хорошо.
Поэтому хорошо, когда есть помимо стандарта, ещё и какие-то полезные работающие валидаторы. Лично мне инструментарий OpenAPI нравится тем, что я могу разработать схему инфраструктуры, сгенирировать базовый код и наполнить его бизнес-логикой на практически любом ЯП.
Я пошёл дальше и сделал с командой автогенерацию UI на основе схемы. Опять же, gql такого не позволит сделать. Но здесь видна разница в наших с вами подходах: мне интереснее как можно реже обращаться к фронтендерам и получить максимум логики из бэка, а вы с точностью наоборот рассуждаете. Начинает вырисовываться тенденция: фронтендерам больше нравится самим выбирать как работать с данными, даже в ущерб производительности, а бэкендерам нравится больше статический подход, где строгая валидация, высокая скорость за счёт оптимизаций и безопасность.
Я пишу это не ради спора. Просто надеюсь, что наш с вами диалог будет полезен тем, кто будет в будущем выбирать архитектуру и стандарт. К сожалению, лично я нахожу, что GraphQL вносит иллюзию порядка, но на деле потом вносит больше хаоса и проблем. Пока что, не нашёл ничего лучше классического HTTP Rest API и автогененерируемой схемы Swagger/OpenAPI.
В этом предложении вы сами говорите, что не использовали никакой спецификации, полностью забили на стандартизацию и вообще на организацию, при этом считаете что виноват в этом REST API. Нее, ну логично, конечно.
А могли просто ввести спецификацию OpenAPI и привести REST API в порядок. Работы заняло бы меньше на переделку, и получили бы ещё удобный Swagger UI для интеграции и отладки запросов с документацией.
А что мешало это делать изначально в API? Вот, например, PostgREST делает это прекрасно настолько, что вообще не нужны бэкендеры (DBA только).
Вот об этом и речь, что формат схемы не решает проблемы организации. Только наличие спецификации и стандартизации могут в этом помочь. Какая будет при этом использоваться схема - вообще пофиг! Переписывание REST API на gql это просто смена локации кроватей.
И это я ещё тему ACL и доступа к данным не поднимал. Там вообще мрак...
Пожалуйста, пишите новости. У вас получается лучше.
Простите, но вы описали какой-то мир розовых пони, где бэкенд не надо реализовывать совсем. Даже posgrest не может таким похвастаться.
С graphql возникает очень интересный вопрос с http-кешированием. Так что мониторинг это прям вообще 10ый вопрос.
REST API со схемой тоже позволяет брать данных столько, сколько нужно. Не вижу вообще никаких преимуществ у gql в этом.
Сколько не общаюсь с адептами gql, никак не могу получить внятный ответ на вопрос "чем это лучше restapi+openapi?"
Вопрос без подвоха и стёба. Мне правда интересно.
Я вот как-то этот момент упустил. А где он заблокирован? У меня сайт на HTTP3 вроде исправно работает.
Вы учились тоже на данных из общественного достояния. Можно ли сказать, что всё что вы сделаете тоже должно быть общественным достоянием?
А если вы программировать научились на книгах издательства, то ваши программы тоже им принадлежать должны?
Вы бы тоже не согласились бесплатно работать, думаю.
А можно просто Rancher. Он ещё и сделан по интерфейсу так, чтоб с ним могли работать прям далёкие от кубера люди, например, разработчики.
Блин, ну я тоже так пишу. Это основы оформления письменных работ. Может я программа и забыл об этом...
Да никто и не говорит "невозможно". Просто KISS приучает делать всё как можно проще. Зачем усложнять себе жизнь ради 10-20% прироста в сериализации, если 80% времени это запрос в БД (к примеру).
С HTTP легко можно работать в cURL и отладить запрос даже с чайника. Сделать то же самое с gRPC довольно большой геморрой. Вопрос именно в этом, о чём и речь.
Проблемы тут сразу две:
TLS - gRPC без сертификата в принципе боль. Локальная разработка превращается в цирк с конями на ровном месте.
Remote debugging - не всегда клиент и сервер для дебага можно разместить в одной сети. А если сервис на чём-то безгуёвом и в облаке, то боль умножается на 2. MitM частично решают, но не умеют в gRPC.
Вот поэтому многие и используют HTTP - на нём банально инструментарий богатый на все случаи жизни и отладки. Не говоря уже о важном факторе: схему надо знать. Без схемы не будет интеграции. Если сервер не подконтрольный, то с ним дружить не получится.
Больше похоже, что вы привыкли к определённому звуку. Я наоборот не могу слушать ни на форточках, ни на маках как ни старался настроить. Но я звук вывожу на микшер по USB, а там затачиваю уже как мне нравится.
Я не знаю какой браузер использовали, но я бы рекомендовал попробовать с репозитория хрома брать пакеты. Уже давно наблюдаю, что они много чего в своих билдах допиливают, по сравнению с Хромиумом, что сказывается на качестве звука и картинки.
Вы не просто один адрес хотите использовать, но и один порт тогда уж.
Даже с учётом что вы себе сами этим геморрой придумали на ровном месте, возьмите haproxy. Там где traefik захлебнется на 100 соединений в 4 vCPU, haproxy легко прожуёт это всё на одном ядре в десятикратном размере с меньшими задержками.
Traefik очень удобный, когда у вас дофигаллион разных источников для сервисов (не самих сервисов), например, кубер+docker swarm+какая-то кастомная БД+ещё какой-то HTTP-сервис. И вам нужно централизовано управлять не только подключениями, но и сертификатами, middleware и т.п.
В вашем примере с таким же успехом можно было Istio использовать. Но зачем?
Поэтому с учётом придуманной проблемы с портами (безопасники, будь у вас наоборот всё на разных нестандартных портах, обрадовались бы), хотя бы посмотрите в сторону более адекватных инструментов для маршрутизации типа haproxy.
Ну и не забудьте протюнить ядро по сетевому стеку, буферам и файловым дескрипторам, чтоб не удивиться потом. Но рано или поздно всё равно в сеть упрётесь.
Вам бы матчасть подтянуть...
А можно не из локального, BGP'шного. Так, кстати, внешний адрес трушно балансируется по нодам.
Если прям нужно один адрес, то можно использовать аннотацию:
С другой стороны, вы же как-то уже на прокси разные балансите трафик. Тут либо nodeport, либо Klipper, либо что-то вроде metallb. Ну либо calico в одной сети с NAT-маршрутизатором.
Просто для такой простой задачи разные прокси просто избыточны и часто добавляют только задержку. Если уж брать, то лучше haproxy хотя бы.
А можно просто Service и Metallb (если не облачный кубер). А если облачный, то скорее всего просто Service.
Капец как сложно. Я в kubuntu 22.04 просто запустил бинарь и всё поставил через гуй, хотя с линуксом на "бро". Правда драйвер от Nvidia уже стоял. С ним просто в kdenlive быстрее видео рендерилось.
Вот тест timeit. Результаты теста о советах подобного типа говорят сами за себя.
Вот прям очень говорящий пример, почему статья в минусах:
Так себе совет, потому что COPY сделает слой с колёсами, которые нужны только при установке. Правильнее будет сделать через mount, но тогда задействуется buildkit. Хотя это не проблема для большинства ситуаций, я считаю.
Т.е. тут реально кто-то обсуждает, что в блоге OTUS'а "замыкания" перевели как "закрытия", но никто не оценил совершенство очепятки
kокальная переменная, которая настолько идеально передаёт качество самого материала?Thorium продолжает поддерживать семёрку. Хотя я на кубунте на нём, но репы под семёрку ещё есть.