Это не совсем рантайм, там, скорее всего, сравнивается просто время выполнения http запросов, которые под капотом работают на libuv или чём-то подобном. Если добавить какую-то логику обработки запросов, то мало чего останется от бенчмарков
Архитектура в software engineering и архитектура зданий это абсолютно разные вещи. Во втором случае к вам не придут после заложенного фундамента и не скажут, что дом то должен быть на самом деле круглый, а не квадратный. После десяти построенных этажей вам не скажут, что надо сейчас сделать пять, а верхние пока отрезать. Или сделать так, чтоб каждый чётный этаж пока что не был виден жильцам и тд
Первый тоже спорный, т.к. часто закрывается тестировщиками, на которых часто экономят и перекладывают всю ответственность за тестирование на разработчиков. По крайней мере, для презентации то можно было отполировать, это не работа продукта в проде под нагрузкой.
Думаю вы понимаете, что станет с зарплатами и конкуренцией в ИТ и если 80% работы будут делать ИИ?
По сравнению со временами перфокарт или даже ассемблеров, сейчас 80 процентов за меня делают более высокоуровневый язык, IDE, фреймворки, stackoverflow, но работы меньше не стало
Большинство компаний регулярно сталкиваются с проблемой постоянной модификации слоя API в своих веб-приложениях в ответ на изменения API сервера
Получается, что вы меняете слой API практически также, как и в реализации без прокси. Также, был упомянут вариант с кодогенерацией по спеке openapi, в котором как раз вообще ничего не меняется в слое API (ну как, пока генератор нормально генерирует, потому что там тоже даже для популярнейшего тайпскрипта периодически всплывают баги даже в самых популярных генераторах).В общем, я не понял, чем ваш вариант лучше существующих и решает ли он вообще проблему.
Большинство компаний регулярно сталкиваются с проблемой постоянной модификации слоя API в своих веб-приложениях в ответ на изменения API сервера
Если честно, я не очень понял, как этот метод спасает от изменения API на бэке. Если часть каких-то данных переместили в другой эндпоинт? Или разбили логику на несколько эндпоинтов? Или поменялся content type? А как это работает с вложенными эндпоинтами, напр., item/{id}/nested_item ? Для чего писать в начале методы, если у нас уже есть соглашение в рамках RESTfull API?
Почитав комменты выше автолюбителей, пришел к такому же мнению. Сделать некоторое количество кнопок кастомизируемыми, чтоб можно было маппить крутилки экрана на крутилки и кнопки физические. Или, как вариант, сделать доп кнопку, которая переключает режимы всего блока. Условно, сейчас блок физических кнопок настроен на радио, переключаем один раз и блок теперь управляет климат контролем, переключаем ещё раз - чем-то другим и тд.
Я понимаю, что эти фантазии имеют место быть, но на мой взгляд эти оба кейса это дикость, т.к. в джанге многое завязано на модели как они есть. Взять те же class based views из самой джанги или из DRF, модуль аутентификации с user model, а сколько разных батареек ждёт джанговскую модель... Я не вижу особой разницы между этим вариантом и переписыванием с нуля хоть на другом фреймворке, хоть на другом вообще стеке. Второй вариант тоже выглядит весьма сомнительным, так как мы вместо уменьшения связности идём наоборот в сторону её увеличения. У нас оба фреймворка предназначены практически для одной и той же задачи, с разницей лишь в нюансах и мы из каких-то мутных побуждений берём их оба и строим франкенштейна (ну тут просто удачи, что сказать). Помимо того, что у нас в коде переплетены 2 фреймворка, так у нас ещё значительно вырастает количество зависимостей, за которыми надо следить, у нас увеличивается сложность поддержки проекта, увеличиваем требования к экспертизе разработчиков в команде. В таком случае проще выделять из Django что-то в отдельные независимые сервисы на fastapi, если есть в этом необходимость и уменьшать связность.
В чем смысл пилить в джанге репозитории, когда джанго орм уже и так представляет из себя достаточную абстракцию над несколькими субд? Там же много всего завязано на модели джанго орм.
И не особо игра
Раз уж оборудовали такие лабиринты, то может добавить сюда "шлагбаум" для людей?
Это не совсем рантайм, там, скорее всего, сравнивается просто время выполнения http запросов, которые под капотом работают на libuv или чём-то подобном. Если добавить какую-то логику обработки запросов, то мало чего останется от бенчмарков
В firefox они давным-давно есть
Есть у кого-то успешный опыт использования? И успешный опыт перехода на большом проекте?
Да и на УСН тоже имеет значение, там избежание двойного налогообложения не работает
https://habr.com/ru/news/770676/
Архитектура в software engineering и архитектура зданий это абсолютно разные вещи. Во втором случае к вам не придут после заложенного фундамента и не скажут, что дом то должен быть на самом деле круглый, а не квадратный. После десяти построенных этажей вам не скажут, что надо сейчас сделать пять, а верхние пока отрезать. Или сделать так, чтоб каждый чётный этаж пока что не был виден жильцам и тд
Первый тоже спорный, т.к. часто закрывается тестировщиками, на которых часто экономят и перекладывают всю ответственность за тестирование на разработчиков. По крайней мере, для презентации то можно было отполировать, это не работа продукта в проде под нагрузкой.
Подобные перспективы возлагали и на фарму, но волшебных nzt до сих пор нет
По сравнению со временами перфокарт или даже ассемблеров, сейчас 80 процентов за меня делают более высокоуровневый язык, IDE, фреймворки, stackoverflow, но работы меньше не стало
Спасибо за статью
Получается, что вы меняете слой API практически также, как и в реализации без прокси. Также, был упомянут вариант с кодогенерацией по спеке openapi, в котором как раз вообще ничего не меняется в слое API (ну как, пока генератор нормально генерирует, потому что там тоже даже для популярнейшего тайпскрипта периодически всплывают баги даже в самых популярных генераторах).В общем, я не понял, чем ваш вариант лучше существующих и решает ли он вообще проблему.
By the way
Если честно, я не очень понял, как этот метод спасает от изменения API на бэке. Если часть каких-то данных переместили в другой эндпоинт? Или разбили логику на несколько эндпоинтов? Или поменялся content type? А как это работает с вложенными эндпоинтами, напр., item/{id}/nested_item ? Для чего писать в начале методы, если у нас уже есть соглашение в рамках RESTfull API?
Почитав комменты выше автолюбителей, пришел к такому же мнению. Сделать некоторое количество кнопок кастомизируемыми, чтоб можно было маппить крутилки экрана на крутилки и кнопки физические. Или, как вариант, сделать доп кнопку, которая переключает режимы всего блока. Условно, сейчас блок физических кнопок настроен на радио, переключаем один раз и блок теперь управляет климат контролем, переключаем ещё раз - чем-то другим и тд.
Глубокое заблуждение
Я понимаю, что эти фантазии имеют место быть, но на мой взгляд эти оба кейса это дикость, т.к. в джанге многое завязано на модели как они есть. Взять те же class based views из самой джанги или из DRF, модуль аутентификации с user model, а сколько разных батареек ждёт джанговскую модель... Я не вижу особой разницы между этим вариантом и переписыванием с нуля хоть на другом фреймворке, хоть на другом вообще стеке.
Второй вариант тоже выглядит весьма сомнительным, так как мы вместо уменьшения связности идём наоборот в сторону её увеличения. У нас оба фреймворка предназначены практически для одной и той же задачи, с разницей лишь в нюансах и мы из каких-то мутных побуждений берём их оба и строим франкенштейна (ну тут просто удачи, что сказать). Помимо того, что у нас в коде переплетены 2 фреймворка, так у нас ещё значительно вырастает количество зависимостей, за которыми надо следить, у нас увеличивается сложность поддержки проекта, увеличиваем требования к экспертизе разработчиков в команде. В таком случае проще выделять из Django что-то в отдельные независимые сервисы на fastapi, если есть в этом необходимость и уменьшать связность.
В чем смысл пилить в джанге репозитории, когда джанго орм уже и так представляет из себя достаточную абстракцию над несколькими субд? Там же много всего завязано на модели джанго орм.
Будет ли работать это решение, но посмотрим