Ну если лично у вас таких проблем не было, это не значит, что их не существует. Это лишь говорит о том, что вы с ними не сталкивались. А я сталкивался и докер эту проблему отлично решает. И ещё много других. Не стоит судить от полезности инструмента только лишь по применимости или не применимости именно в вашей работе. Это как минимум не репрезентативно. Если для вас это избыточная абстракция - замечательно. Но для тех, кто его использует для решения своих задач - это полезный рабочий инструмент.
Докер унифицирует среду выполнения и процесс сборки и запуска в ней. Это значительно исключает ситуацию бага и разработчика, у которого "все работает локально, ничего не знаю", а там оказывается версии библиотеки в ОС у разраба и на сервере разные. Так что зря вы на докер катите. Это одна из хороших практик и необходимость, нежели переусложнение. Вдобавок докер изолирует все зависимости от системы, и у вас исключается ситуация, когда один проект требует одну версию интерпретатора/компилятора и версии библиотек в системе, а другой -другие, а третий - третьи. И как вы все это будете устанавливать и обслуживать на одной машине без изоляции - большой вопрос и отдельная очень "интересная" тема.
Версии то есть в апи, только вот если у вас много внешних потребителей этого апи, на которых вам сложно повлиять, то заставить их переползти на новую версию может быть очень не быстро. Ибо доп. затраты для компании-партнёра, а профит не очевиден, итак же все работает. Так что с версиями надо быть аккуратнее и делать по возможности без них, либо с минимальным из количеством. А то может случиться, что поддерживать их придётся если не вечно, то очень долго.
Этого вполне можно добиться, если конфигурация проекта локально отличается от конфигурации на сервере. Например, фиче-флаги выставлены по-другому. С этим надо быть аккуратнее))
Это вы меня извините) На моей практике изменение именно апи слоя не вызывало каких-то серьезных затрат. Значительное время обычно занимала как раз изменение логики работы с апи и подготовки данных запроса и ответа. Поэтому название статьи интерпретировал не так, как вы задумыаали.
Я вам про Ивана, вы мне про ... Мы не обсуждаем, что и куда утекло. У вас в статье написано
Некоторые из них прибегают к автогенерации кода на основе схем Swagger, другие переписывают код вручную. Однако эти подходы требуют значительных ресурсов и времени, а также часто приводят к избыточному коду, который растет в объеме вместе с количеством задействованных в коде методов API. В данной статье я хочу поделиться методом, который позволяет избежать этих сложностей.
Как при измерении апи в моем примере ваш подход избавляет от сложностей, о которых вы сами написали, если все равно приходится менять логику запроса?
Тогда резюмируя все вышесказанное при существенном изменении API придется менять не только слой апи и вот эти вот интерфейсы, но и логику получения данных независимо от того, где она находится. Вот поэтому я и не понял, как ваш подход избавляет от этого.
Вы забыли, что надо ещё поменять логику запроса этих данных. Ранее одного запроса было достаточно, теперь надо делать два. Причем может случиться так, что нагрузка запроса тоже поменялась. Тут простым изменением интерфейса тайпскрипта не обойтись. Придется менять логику получения данных и их обработку. Если все это инкапсулировать в отдельный класс/объект/модуль, то это модуль в любом случае придется постоянно переписывать при таких изменениях.
Статью я прочитал, но видимо не понял всех плюсов решения. Давайте разберём реальный кейс. Допустим, у нас была логика: запрашиваем URL url1/common1, возвращается структура
{
"key1":"val1",
"key2":"val2"
}
API поменялось, теперь надо запрашивать 2 URL'а: url/entity2 и url/entity3, возвращается соответственно
{
"key1": {
"key3": "val1"
}
}
и
{
"key4": "val2"
}
Какой должен быть интерфейс старого API и как мне нужно его поменять на стороне клиента, чтобы адаптировать под новый API?
Вместо поддержки слоя API вы предлагаете поддерживать слой прокси. Апи может так поменяться, что никакой прокси слой не спасет. Ну и потом, не весь бэк на ноде пишется и не везде на бэке используется тайпскрипт. Все это как мёртвому припарка.
Макось вполне способна ворочаться на 8гб . Учитывая, что это air, а не про, ЦА этой модели не компилирует мегабайты кода и не монтирует гигабайты видео на этом. Если этого не делать,с 8гб и с быстрым свопом рядовой пользователь дискомфорта ощущать не будет. Браузер, просмотр видео, работа с документами, редактирование фотографий, подготовка отчётов, презентаций, проведение конференций - вот под эти задачи вполне хватит. Зачем переплачивать за 16гб? Кому надо, тот добавит в конструкторе на сайте эппла и закажет кастомизированную версию. Мой жене вполне 8гб с головой хватит
Вы не учитываете, что затраты (временные и финансовые), которые необходимо потратить на это, непропорционально велики по сравнению с прибылью, которую компания сможет извлечь из этого. Вдобавок, рост потребности в ресурсах стимулирует рынок железа. Все в выгоде. И как вообще продавать эту вашу оптимизацию - непонятно. Я вот прям представляю, как маркетологи говорят "наша ос стала в 2 раза быстрее по сравнению с предыдущей версией", а рядовому потребителю мягко говоря все равно. Ибо он уже давно купил достаточно мощное железо, чтобы на замечать разницы между условно 1.и 0.5 секундами задержки. А те, кто сидит на старом железе, новую ос не факт что могут поставить, ибо набор команд процессора может уже не поддерживаться, нет secure boot и прочих улучшений, без которых винда ну никак не запустится) Вы мыслите с точки зрения потребителя и только в целях экономии железа, а интересы компании совсем не рассматриваете.
Вот поэтому js и "не любят". Потому что там есть вещи, которые выглядят, как надёжные, но работают мягко говоря не надежно, и которые, как оказывается, "никто не использует", но они зачем-то есть. Обо что часто и спотыкаются новички. Ибо эти сакральные знания приходят с опытом.
В СНГ итак неопределённостей в жизни у людей хватает, а работа по контракту добавляет ещё одну (увольнение одним днём, работа на 6 месяцев, а потом опять искать). С финансовыми обязательствами вроде кредитов и ипотеки, где нужны постоянные выплаты, так работать не очень приятно.
Вообще, есть ИП и гражданский трудовой договор, что в принципе и есть по сути работа по контракту.
Хром для Линукса умеет из коробки выносить сайт в отдельный ярлык. Запускается при этом в отдельном окне без меню браузера и выглядит вполне себе как отдельное приложение. Я жене ватсап так вынес. Не уверен, что другие браузеры так могут, но вот если пользуетесь хромом, можно без сторонних приложений этого добиться.
Ну если лично у вас таких проблем не было, это не значит, что их не существует. Это лишь говорит о том, что вы с ними не сталкивались. А я сталкивался и докер эту проблему отлично решает. И ещё много других. Не стоит судить от полезности инструмента только лишь по применимости или не применимости именно в вашей работе. Это как минимум не репрезентативно. Если для вас это избыточная абстракция - замечательно. Но для тех, кто его использует для решения своих задач - это полезный рабочий инструмент.
Докер унифицирует среду выполнения и процесс сборки и запуска в ней. Это значительно исключает ситуацию бага и разработчика, у которого "все работает локально, ничего не знаю", а там оказывается версии библиотеки в ОС у разраба и на сервере разные. Так что зря вы на докер катите. Это одна из хороших практик и необходимость, нежели переусложнение. Вдобавок докер изолирует все зависимости от системы, и у вас исключается ситуация, когда один проект требует одну версию интерпретатора/компилятора и версии библиотек в системе, а другой -другие, а третий - третьи. И как вы все это будете устанавливать и обслуживать на одной машине без изоляции - большой вопрос и отдельная очень "интересная" тема.
Версии то есть в апи, только вот если у вас много внешних потребителей этого апи, на которых вам сложно повлиять, то заставить их переползти на новую версию может быть очень не быстро. Ибо доп. затраты для компании-партнёра, а профит не очевиден, итак же все работает. Так что с версиями надо быть аккуратнее и делать по возможности без них, либо с минимальным из количеством. А то может случиться, что поддерживать их придётся если не вечно, то очень долго.
Этого вполне можно добиться, если конфигурация проекта локально отличается от конфигурации на сервере. Например, фиче-флаги выставлены по-другому. С этим надо быть аккуратнее))
Это вы меня извините) На моей практике изменение именно апи слоя не вызывало каких-то серьезных затрат. Значительное время обычно занимала как раз изменение логики работы с апи и подготовки данных запроса и ответа. Поэтому название статьи интерпретировал не так, как вы задумыаали.
Я вам про Ивана, вы мне про ... Мы не обсуждаем, что и куда утекло. У вас в статье написано
Как при измерении апи в моем примере ваш подход избавляет от сложностей, о которых вы сами написали, если все равно приходится менять логику запроса?
Тогда резюмируя все вышесказанное при существенном изменении API придется менять не только слой апи и вот эти вот интерфейсы, но и логику получения данных независимо от того, где она находится. Вот поэтому я и не понял, как ваш подход избавляет от этого.
Вы забыли, что надо ещё поменять логику запроса этих данных. Ранее одного запроса было достаточно, теперь надо делать два. Причем может случиться так, что нагрузка запроса тоже поменялась. Тут простым изменением интерфейса тайпскрипта не обойтись. Придется менять логику получения данных и их обработку. Если все это инкапсулировать в отдельный класс/объект/модуль, то это модуль в любом случае придется постоянно переписывать при таких изменениях.
Статью я прочитал, но видимо не понял всех плюсов решения. Давайте разберём реальный кейс. Допустим, у нас была логика: запрашиваем URL url1/common1, возвращается структура
API поменялось, теперь надо запрашивать 2 URL'а: url/entity2 и url/entity3, возвращается соответственно
и
Какой должен быть интерфейс старого API и как мне нужно его поменять на стороне клиента, чтобы адаптировать под новый API?
Вместо поддержки слоя API вы предлагаете поддерживать слой прокси. Апи может так поменяться, что никакой прокси слой не спасет. Ну и потом, не весь бэк на ноде пишется и не везде на бэке используется тайпскрипт. Все это как мёртвому припарка.
Макось вполне способна ворочаться на 8гб . Учитывая, что это air, а не про, ЦА этой модели не компилирует мегабайты кода и не монтирует гигабайты видео на этом. Если этого не делать,с 8гб и с быстрым свопом рядовой пользователь дискомфорта ощущать не будет. Браузер, просмотр видео, работа с документами, редактирование фотографий, подготовка отчётов, презентаций, проведение конференций - вот под эти задачи вполне хватит. Зачем переплачивать за 16гб? Кому надо, тот добавит в конструкторе на сайте эппла и закажет кастомизированную версию. Мой жене вполне 8гб с головой хватит
Вы не учитываете, что затраты (временные и финансовые), которые необходимо потратить на это, непропорционально велики по сравнению с прибылью, которую компания сможет извлечь из этого. Вдобавок, рост потребности в ресурсах стимулирует рынок железа. Все в выгоде. И как вообще продавать эту вашу оптимизацию - непонятно. Я вот прям представляю, как маркетологи говорят "наша ос стала в 2 раза быстрее по сравнению с предыдущей версией", а рядовому потребителю мягко говоря все равно. Ибо он уже давно купил достаточно мощное железо, чтобы на замечать разницы между условно 1.и 0.5 секундами задержки. А те, кто сидит на старом железе, новую ос не факт что могут поставить, ибо набор команд процессора может уже не поддерживаться, нет secure boot и прочих улучшений, без которых винда ну никак не запустится) Вы мыслите с точки зрения потребителя и только в целях экономии железа, а интересы компании совсем не рассматриваете.
Правильное поведение - это когда тип конвертируется всегда одинаково. Но в примере выше что-то пошло не так) И это далеко не правильное поведение.
Вот поэтому js и "не любят". Потому что там есть вещи, которые выглядят, как надёжные, но работают мягко говоря не надежно, и которые, как оказывается, "никто не использует", но они зачем-то есть. Обо что часто и спотыкаются новички. Ибо эти сакральные знания приходят с опытом.
Чтобы не объедались, компания заботится о весе сотрудников)
Что характерно, одно время ваши сотрудники всё-таки пользовались сканером, потом перешли на мобилки.
Тут часто время зависит от того, какую библиотеку вы для этого использовали. Стандартная медленная, попробуйте https://github.com/ijl/orjson.
Мултитаскинг - это миф
В СНГ итак неопределённостей в жизни у людей хватает, а работа по контракту добавляет ещё одну (увольнение одним днём, работа на 6 месяцев, а потом опять искать). С финансовыми обязательствами вроде кредитов и ипотеки, где нужны постоянные выплаты, так работать не очень приятно.
Вообще, есть ИП и гражданский трудовой договор, что в принципе и есть по сути работа по контракту.
Хром для Линукса умеет из коробки выносить сайт в отдельный ярлык. Запускается при этом в отдельном окне без меню браузера и выглядит вполне себе как отдельное приложение. Я жене ватсап так вынес. Не уверен, что другие браузеры так могут, но вот если пользуетесь хромом, можно без сторонних приложений этого добиться.