Это должно быть заложено на этапе разработки. Просто запустить несколько инстансов, которые указывают на разные базы, не получится, т.к. запросы будут идти на случайный инстанс. Либо "умный" роутинг запросов на лоад балансере, но это, как мне кажется, крайняя и сложная мера.
Если брать полный стейтлесс монолит, то он будет идентичен микросервисам в плане цены масштабирования только при условии, что хранилище данных масштабируется независимо.
Однако нагруженные микросервисы можно вынести на отдельные базы, если они допускают определенную несогласованность данных. Монолит так масштабировать обычно нельзя, т.к. некоторые части должны все-таки работать с согласованным хранилищем.
Плюс (тут я не уверен, чисто как идея) — не будет ли проблем при запуске на одной машине нагрузки разных типов — множества быстрых запросов или маленького количества медленных, либо грузящих диск, или процессор.
Если монолит — полный stateless и содержит в себе только обработчики запросов — то разницы нету.
Если монолит содержит в себе какое-то состояние — явное или неявное (кеши, сессии в памяти, восстановленные CQRS агрегаты ), или поведение — задачи по расписанию и т.п. — то разница есть, и значительная.
О преимуществах микросервисов стоит судить не с точки зрения "модули, которые общаються по хттп вместо in-process call, зачем?", а с точки зрения облачного развертывания. Это скорее набор микро-приложений (а не модулей), которые друг с другом взаимодействуют мало и редко.
Представьте банковские сервисы: сервис курсов валют запрашивают миллион раз в день, сервис свифт-переводов — тысячу раз. В облаке дешевле отмасштабировать только нагруженный сервис — деплой и контейнер дешевые (бесплатные), плюс автомасштабирование от облачного вендора будет дешевле.
Это пример синтетический, потому что аналогичный код на джаваскрипте работает так же, как и тайпскриптовый, и выдает ошибку в том же месте. Если бы джаваскрипт падал там же, где выдает ошибку флоу, тогда можно было бы говорить, что поведение тайпскрипта некорректно.
Флоу пытается изменить сущность джаваскрипта, тайпскрипт — только привнести опциональные аннотации типов. В этом их разница.
Вы, собственно, подтверждаете мои слова: целевая аудитория TypeScript это огромная когорта C# программистов, которым легче принять что-то промежуточное между JavaScript и C#, чем чистый JavaScript сам по себе.
А применимо к контексту это означает, что неплохо было бы размять мозги и принять JavaScript таким, каков он есть, не полагаясь на внешние костыли.
Ага, то-то джаваскрипт обзавелся извращением под названием jsdoc, который, помимо комментирования, еще и пытается добавлять информацию о типах.
На мой взгляд, у typescript поведение более логичное для динамического языка.
Отсутствие ковариантности для массивов хорошо в синтетических примерах, но не в реальном коде, где у сторонних библиотек может в массиве лежать все подряд и вперемешку.
Кроме этого, нужно помнить, что типы в тайпскрипте — это не всегда настоящие типы, а часто лишь декларации — как и в джаваскрипте.
Structural typing (типы одинаковые, если у них одинаковые поля и методы) сделан намеренно. Если бы сделали nominal typing — про нормальное взаимодействие с javascript-кодом можно было бы забыть.
В тайпскрипте очень крутой advanced typing — mapped types, union/intersection, и т.д.
С препроцессором можно тянуть части (модули) бутстрапа. Единственное, что нужно вытягивать и зависимости используемых модулей, которые не всегда очевидны.
В Ангуляре тоже есть проверка, только немного другая. Упрощенно можно сказать, что в Ангуляре сравниваются данные, в Реакте — сравнивается виртуальный DOM (однако можно вмешаться и сделать проверку данных).
Ещё более высокой степени сокращения длины сообщения при сохранении смысла можно добиться отбрасывая гласные и часть пробелов: “Пздрвл тб, Шрк, т блбс!”
Думаю, здесь имеет место не сжатие, а хэширование, т.к. однозначно восстановить фразу человеку, не смотревшему "Простоквашино", будет невозможно.
Оценки можно и убрать, их роль — служить формальным показателем уровня знаний — все-равно не выполняется. Однако отбор по уровню знаний никуда не денется, просто приобретет другие формы: тестирование, опрос и т.п.
Другое дело, что отбор будет работать только там, где он нужен — при поступлении в вуз, на работу и т.п. По сути, мотивация на получение знаний не уйдет, уйдет сублимация этой мотивации мотивацией на получение оценок. Что хорошо и здорОво, в отличие от восточных 100 баллов по ЕГЭ.
С другой стороны, человек, который не хочет или не может получать знания, будет избавлен от 10 лет давления и унижения.
Это должно быть заложено на этапе разработки. Просто запустить несколько инстансов, которые указывают на разные базы, не получится, т.к. запросы будут идти на случайный инстанс. Либо "умный" роутинг запросов на лоад балансере, но это, как мне кажется, крайняя и сложная мера.
Если брать полный стейтлесс монолит, то он будет идентичен микросервисам в плане цены масштабирования только при условии, что хранилище данных масштабируется независимо.
Однако нагруженные микросервисы можно вынести на отдельные базы, если они допускают определенную несогласованность данных. Монолит так масштабировать обычно нельзя, т.к. некоторые части должны все-таки работать с согласованным хранилищем.
Плюс (тут я не уверен, чисто как идея) — не будет ли проблем при запуске на одной машине нагрузки разных типов — множества быстрых запросов или маленького количества медленных, либо грузящих диск, или процессор.
Если монолит — полный stateless и содержит в себе только обработчики запросов — то разницы нету.
Если монолит содержит в себе какое-то состояние — явное или неявное (кеши, сессии в памяти, восстановленные CQRS агрегаты ), или поведение — задачи по расписанию и т.п. — то разница есть, и значительная.
О преимуществах микросервисов стоит судить не с точки зрения "модули, которые общаються по хттп вместо in-process call, зачем?", а с точки зрения облачного развертывания. Это скорее набор микро-приложений (а не модулей), которые друг с другом взаимодействуют мало и редко.
Представьте банковские сервисы: сервис курсов валют запрашивают миллион раз в день, сервис свифт-переводов — тысячу раз. В облаке дешевле отмасштабировать только нагруженный сервис — деплой и контейнер дешевые (бесплатные), плюс автомасштабирование от облачного вендора будет дешевле.
Появились средства контейнеризации, облака — и достали из закромов старый прием и назвали по-новому.
Мы все еще про тайпскрипт говорим? Там тоже
типизацияаннотация типами опциональная. О каком принуждении идет речь?Подозреваю, что вы тайпскрипт не знаете, а думаете, что это нечто типа Java, только компилируется в джаваскрипт.
Это пример синтетический, потому что аналогичный код на джаваскрипте работает так же, как и тайпскриптовый, и выдает ошибку в том же месте. Если бы джаваскрипт падал там же, где выдает ошибку флоу, тогда можно было бы говорить, что поведение тайпскрипта некорректно.
Флоу пытается изменить сущность джаваскрипта, тайпскрипт — только привнести опциональные аннотации типов. В этом их разница.
Ага, то-то джаваскрипт обзавелся извращением под названием jsdoc, который, помимо комментирования, еще и пытается добавлять информацию о типах.
Спасибо. И отдельно — за поддержку Linq2Db.
Ну в тайпскрипте тоже со структурной типизацией и отсутствием номинальной проблем не возникает.
На мой взгляд, у typescript поведение более логичное для динамического языка.
Отсутствие ковариантности для массивов хорошо в синтетических примерах, но не в реальном коде, где у сторонних библиотек может в массиве лежать все подряд и вперемешку.
Кроме этого, нужно помнить, что типы в тайпскрипте — это не всегда настоящие типы, а часто лишь декларации — как и в джаваскрипте.
Structural typing (типы одинаковые, если у них одинаковые поля и методы) сделан намеренно. Если бы сделали nominal typing — про нормальное взаимодействие с javascript-кодом можно было бы забыть.
В тайпскрипте очень крутой advanced typing — mapped types, union/intersection, и т.д.
С препроцессором можно тянуть части (модули) бутстрапа. Единственное, что нужно вытягивать и зависимости используемых модулей, которые не всегда очевидны.
Вообще-то суть меняется радикально.
В Ангуляре тоже есть проверка, только немного другая. Упрощенно можно сказать, что в Ангуляре сравниваются данные, в Реакте — сравнивается виртуальный DOM (однако можно вмешаться и сделать проверку данных).
Думаю, здесь имеет место не сжатие, а хэширование, т.к. однозначно восстановить фразу человеку, не смотревшему "Простоквашино", будет невозможно.
Для аналога LINQ нужны не лямбды, а Expressions, которые компилятором преобразуются в дерево выражений.
А в новом Delphi разве не .net?
Оценки можно и убрать, их роль — служить формальным показателем уровня знаний — все-равно не выполняется. Однако отбор по уровню знаний никуда не денется, просто приобретет другие формы: тестирование, опрос и т.п.
Другое дело, что отбор будет работать только там, где он нужен — при поступлении в вуз, на работу и т.п. По сути, мотивация на получение знаний не уйдет, уйдет сублимация этой мотивации мотивацией на получение оценок. Что хорошо и здорОво, в отличие от восточных 100 баллов по ЕГЭ.
С другой стороны, человек, который не хочет или не может получать знания, будет избавлен от 10 лет давления и унижения.
Запрет на двойки действовал еще во времена моего обучения. Никого из школы с двойкой не выпустили.