получается всемирный заговор рантье.. так недалеко и до плоской земли..
И все бизнесы, от мала до велика, вопреки здравому смыслу, эффективности, выгоде, повелись на уловки, этих всемогущих владельцев коммерческой недвижимости..
Хотя может быть заговор кейтеринговых компаний еще рассмотреть, как вариант.. Или клининговых, ведь в офисе не за кем убирать..
Ну ок, считайте, что хендлеров у вас нет, есть только бизнес логика)
О этот мир иллюзий и грез.. Вот вам идея следующей статьи - "мы переименовали X в Y и повысили производительность разработчиков на 5000000000000000000000000%".
что такое еще одни хендлеры? Какая у хендлера задача? принять запрос, свалидировать его, отправить в бизнес логику, принять ответ от бизнес логику, отформатировать ответ и отправить респонс.
Вы где валидируете реквесты? нигде? Вы где форматируете ответ?
Given dispatcher it handles request (both single and batch) and handles errors.
"Хендлером" - является диспатчер, который вы сконфигурировали итерацией по методам класса. Фактически итерацией сделали роутер из вашего примера с фастапи.. То есть класс Users - и есть класс с хендлерами..
То же самое можно в фастапи сделать класс, в него поместить все хендлеры, потом пробежаться по методам класса и router.add_api_route добавить хендлеры в роутер.
Вы реально не видите, что это одно и то же?
Хотя, вероятно, вы следите, как растет количество пользователей от смены реста на json-rpc со своими костылями..
нет, не смотрю в контексте REST. Чаще использую GRPC на проектах, поэтому скорее смотрю через призму GRPC.
И при стурктуризации приложения, как и в ресте, есть слой хендлеров, есть слой бизнес логики, есть логики доступа к данным. И ваш класс Users - это именно слой хендлеров.
Ну и самое главное, как вы формируете "роутер":
@Request.application
def application(request):
users = Users() # класс к которому открываем доступ
method_list = inspect.getmembers(users, predicate=inspect.isfunction)
for method in method_list:
# диспетчер методов {<method_name>: callable}
dispatcher[method[0]] = method[1]
response = JSONRPCResponseManager.handle(
request.data, dispatcher)
Ваши методы из класса users вызываются функцией handle.. Это именно хендлер.. Если вы туда еще и бизнес логику прикладываете, то зря, но зависит от размера сервиса, если на пару хендлеров - то ну и пусть будет, а если на как минимум десять, то точно зря)
Серьезно?? вы увеличили количество клиентов использующих АПИ из-за перехода на json-rpc?? сходите в grpc - еще в 6 раз вырастет..
У вас получилось писать асинхронно и увеличить в 2 раза количество запросов за счет смены rest - json-rpc.. Это прям вау, это достояно доклада по computer science.
Запустили генератор документации на ReactJS.
Тут вообще молодцы, вместо того, чтобы из коробки использовать openapi, написали свое.. Всегда свой костыль ближе и приятнее..
Сократили разворачивание API для новых серверов в 4 раза.
У вас до json-rpc - инженер лично выезжал в дата центр к серверу?
Простите, конечно, я просто вообще не понимаю, как связаны выводы со всем, что описано..
Эммм... Вы пишете, что в Rest "Нужен роутинг для каждого метода", но так и json-rpc нужны. И в своем примере вы итерируясь по методам класса Users, создаете их. а потом в этих хендлерах уже занимаетесь валидаций реквестов и вызовом бизнес логики.
В ресте "Продумываем формат параметров и возвращаемых значений для каждого вызова API". Молю Бога, чтобы вы и json-rpc продумывали, что вы от кого получаете и что кому отдаете.
В ресте "При необходимости управляем кодами ответов HTTP", ну так json-rpc вам нужно будет управлять кодами ответов json-rpc.
и вывод по ресту: "тратим время на разработку не только бизнес-логики, но и на разработку методов для API" - ну так вы делаете все тоже самое, только придумали себе другие названия.
Возможно, в вашем случае json-rpc и хороший выбор, но даже если этот выбор правильный, вы пришли к нему неправильным путем
Кажется, что многие, кто сегодня открыл эту статью сильно больше зарабатывают в час..
Не спорю, любая должна быть озвучена, только так ее будут решать, но непонятно наличие проблемы.. Но тут ведь даже не случай проблемы, кажется автор решил не читать инструкцию, но время на написание гневного отзыва - это всегда пожалуйста.
Никогда не использовал селектел, и скорее всего никогда не буду. Но 600 рублей - это конечно сильно, особенно для заголовка - "Держитесь подальше от холодных хранилищ Selectel".
парсинг sql - возможно самое важное, что нужно в дата платформах, на мой взгляд.. только так можно уберечься от человеческих ошибок..
Интересно, сколько человек задействовано в выкатке витрины и цена этой выкатки в соответствии с ценой, сколько эта витрина приносит пользы.. где в этой истории дата менеджмент? ручной лайнэдж - тоже такая себе затея, с каких пор мы стали доверять людям??
А если нужно будет сменить движок бд, то по старинним российским обычаям это затянется на минимум несколько лет...
И когда начали думать, как его синхронизировать с мастер-веткой PostgreSQL, приняли решение затягивать изменения из PostgreSQL в GreenPlum. Наоборот было бы слишком сложно
Наоборот было бы невозможно. Даже если бы пытались (а пытаются небольшие коммиты), вероятно патчи были бы отклонены (ну и большинство кануло).
Была ночь, возможно я некорректно написал, что имел в виду.
Попробую пояснить.
Есть бесплатный мессенджер, у которого есть бесплатная возможность хранить пересылаемые файлы неограниченно (как по времени, так и по размеру). Для предоставления этой возможности они арендуют сервера, платят деньги… Это прекрасная и удобная фича, но к чему могут привести подобные решения (это мое личное мнение, вполне возможно кто-то считает иначе, не пытаюсь претендовать на истину) — так это то, что эту возможность ограничат, то есть и решение окажется по сути бесполезным, и другим пользователям, которые и не думали использовать его таким образом придется думать, куда пересохранять файлы… А все это (опять же как кажется, опять же исключительно мнение не претендующее на истину) ради того, чтобы съэкономить пару тысяч рублей в месяц, точнее даже не съэкономить в хорошем смысле, а чтобы за тебя заплатил кто-то другой…
Именно это я назвал эксплуатацией чужих решений, именно это я назвал этичностью…
Но опять же вероятно автор статьи и не вкладывал подобный смысл в свое решение, а изыскания исключительно в целях интереса.
Зачем изобретать колесо, с точки зрения, ученика — диаграммы Венна — ясны и понятны, кому это не нужно — останутся с приблизительным пониманием, кто решит углубить свои знания со всем разберется… Не надо изобретать то, что изобретать не надо.
получается всемирный заговор рантье.. так недалеко и до плоской земли..
И все бизнесы, от мала до велика, вопреки здравому смыслу, эффективности, выгоде, повелись на уловки, этих всемогущих владельцев коммерческой недвижимости..
Хотя может быть заговор кейтеринговых компаний еще рассмотреть, как вариант.. Или клининговых, ведь в офисе не за кем убирать..
Ну ок, считайте, что хендлеров у вас нет, есть только бизнес логика)
О этот мир иллюзий и грез.. Вот вам идея следующей статьи - "мы переименовали X в Y и повысили производительность разработчиков на 5000000000000000000000000%".
что такое еще одни хендлеры?
Какая у хендлера задача? принять запрос, свалидировать его, отправить в бизнес логику, принять ответ от бизнес логику, отформатировать ответ и отправить респонс.
Вы где валидируете реквесты? нигде? Вы где форматируете ответ?
"Хендлером" - является диспатчер, который вы сконфигурировали итерацией по методам класса. Фактически итерацией сделали роутер из вашего примера с фастапи.. То есть класс Users - и есть класс с хендлерами..
То же самое можно в фастапи сделать класс, в него поместить все хендлеры, потом пробежаться по методам класса и router.add_api_route добавить хендлеры в роутер.
Вы реально не видите, что это одно и то же?
Хотя, вероятно, вы следите, как растет количество пользователей от смены реста на json-rpc со своими костылями..
нет, не смотрю в контексте REST. Чаще использую GRPC на проектах, поэтому скорее смотрю через призму GRPC.
И при стурктуризации приложения, как и в ресте, есть слой хендлеров, есть слой бизнес логики, есть логики доступа к данным. И ваш класс Users - это именно слой хендлеров.
Ну и самое главное, как вы формируете "роутер":
Ваши методы из класса users вызываются функцией handle.. Это именно хендлер.. Если вы туда еще и бизнес логику прикладываете, то зря, но зависит от размера сервиса, если на пару хендлеров - то ну и пусть будет, а если на как минимум десять, то точно зря)
Блин, я выводы по статье дочитал..
Серьезно?? вы увеличили количество клиентов использующих АПИ из-за перехода на json-rpc?? сходите в grpc - еще в 6 раз вырастет..
У вас получилось писать асинхронно и увеличить в 2 раза количество запросов за счет смены rest - json-rpc.. Это прям вау, это достояно доклада по computer science.
Тут вообще молодцы, вместо того, чтобы из коробки использовать openapi, написали свое.. Всегда свой костыль ближе и приятнее..
У вас до json-rpc - инженер лично выезжал в дата центр к серверу?
Простите, конечно, я просто вообще не понимаю, как связаны выводы со всем, что описано..
Эммм...
Вы пишете, что в Rest "Нужен роутинг для каждого метода", но так и json-rpc нужны. И в своем примере вы итерируясь по методам класса Users, создаете их. а потом в этих хендлерах уже занимаетесь валидаций реквестов и вызовом бизнес логики.
В ресте "Продумываем формат параметров и возвращаемых значений для каждого вызова API". Молю Бога, чтобы вы и json-rpc продумывали, что вы от кого получаете и что кому отдаете.
В ресте "При необходимости управляем кодами ответов HTTP", ну так json-rpc вам нужно будет управлять кодами ответов json-rpc.
и вывод по ресту: "тратим время на разработку не только бизнес-логики, но и на разработку методов для API" - ну так вы делаете все тоже самое, только придумали себе другие названия.
Возможно, в вашем случае json-rpc и хороший выбор, но даже если этот выбор правильный, вы пришли к нему неправильным путем
600 рублей..
Кажется, что многие, кто сегодня открыл эту статью сильно больше зарабатывают в час..
Не спорю, любая должна быть озвучена, только так ее будут решать, но непонятно наличие проблемы.. Но тут ведь даже не случай проблемы, кажется автор решил не читать инструкцию, но время на написание гневного отзыва - это всегда пожалуйста.
Никогда не использовал селектел, и скорее всего никогда не буду. Но 600 рублей - это конечно сильно, особенно для заголовка - "Держитесь подальше от холодных хранилищ Selectel".
"ололо"? в 2024??
если кто-то не стал читать, то вот краткое содержание
парсинг sql - возможно самое важное, что нужно в дата платформах, на мой взгляд.. только так можно уберечься от человеческих ошибок..
Интересно, сколько человек задействовано в выкатке витрины и цена этой выкатки в соответствии с ценой, сколько эта витрина приносит пользы.. где в этой истории дата менеджмент? ручной лайнэдж - тоже такая себе затея, с каких пор мы стали доверять людям??
А если нужно будет сменить движок бд, то по старинним российским обычаям это затянется на минимум несколько лет...
Наоборот было бы невозможно. Даже если бы пытались (а пытаются небольшие коммиты), вероятно патчи были бы отклонены (ну и большинство кануло).
Попробую пояснить.
Есть бесплатный мессенджер, у которого есть бесплатная возможность хранить пересылаемые файлы неограниченно (как по времени, так и по размеру). Для предоставления этой возможности они арендуют сервера, платят деньги… Это прекрасная и удобная фича, но к чему могут привести подобные решения (это мое личное мнение, вполне возможно кто-то считает иначе, не пытаюсь претендовать на истину) — так это то, что эту возможность ограничат, то есть и решение окажется по сути бесполезным, и другим пользователям, которые и не думали использовать его таким образом придется думать, куда пересохранять файлы… А все это (опять же как кажется, опять же исключительно мнение не претендующее на истину) ради того, чтобы съэкономить пару тысяч рублей в месяц, точнее даже не съэкономить в хорошем смысле, а чтобы за тебя заплатил кто-то другой…
Именно это я назвал эксплуатацией чужих решений, именно это я назвал этичностью…
Но опять же вероятно автор статьи и не вкладывал подобный смысл в свое решение, а изыскания исключительно в целях интереса.