Вы же сами писали, что изобретать свой язык запросов — это зло. Но абзацем ниже предложили именно это - свой язык, основанный на SQL.
Еще один камень преткновения — это то, что вы посылаете запрос как строчку. Строка — это хорошо для человека, но у вас же пользователь не будет писать запрос. Вы его кодом соберёте. А на стороне сервера кодом разберёте. А зачем? Ведь проще послать уже структурированный запрос, как у вас в начале JSON. И ошибок будет меньше, и код проще.
MqExtension - отличная вещь. В git мне её очень не хватает.
Довольно часто хочется иметь локальные изменения для версионных файлов, но не думать при коммите, что там по делу, а что локально для тебя. Так вот все эти вещи у меня в MQ хранились.
В общем вы правы. Но то, что Mercurial хранит весь граф модификаций иногда очень помогает. У меня есть форк проекта с GitHub (https://github.com/foal/gwt-time), структуру (не исходники) которого пришлось значительно изменить. Так вот git не может адекватно накатить изменения с оригинального проекта, а Mercurial легко. И это притом, что история коммитов просто идентична.
Вы абсолютно правильно подметили, что это открытые данные. И из этого вытекает, что их невозможно скомпрометировать. Все эти статьи - "ваш отпечаток могут узнать!" - яйца выеденного не стоят. Просто считайте изначально, что ваш отпечаток известен каждому. И решайте сами пользоваться этим или нет.
Уважаемый, вы все пытаетесь спорить, думая, что вам возражают :)
Что значит - "опасения, что палец сопрут". Нет! Его уже спёрли. И я уверен, что разработчики биометрических систем основываются на этом. А поэтому если вы доверяете конкретному экземпляру такой системы, то пользуйтесь на здоровье. Либо нет.
Но не надо кричать, что система безопасна, пока ваш отпечаток пальца в тайне, а потом беда-беда. Это ложь.
Просто считайте, что ваш отпечаток пальца это open key в ассиметричном шифровании. Никто же не рассуждает о том, что делать в случае компрометации открытого ключа - бред же?
Для непонятливых - отпечаток пальца это открытая всем информация, её невозможно скомпрометировать, ну или считайте, что он изначально скомпрометирован :)
Отвечая на ваш вопрос - ничего делать не буду. Тут вопрос о доверии. И чётком понимании что мой (как и любой другой) отпечаток пальца уже сейчас, как вы говорите "спёрт".
В разных системах (мой ноут, сейф на полке, входной замок, банк) информация о пальце хранится и обрабатывается по-разному. Нельзя украсть палец с входной двери и пройти в банк.
Информация о пальце, даже если она и хранится на стороне сервера вам ничего не даст. Это открытая информация, для её получения не нужно ничего ломать - она есть на каждом стакане, который я трогал - её невозможно скомпрометировать по определению.
Скажем так, я не вижу реальной возможности скомпрометировать палец. Есть уязвимости на уровне железок, но это скорее вопрос к конкретному сервису, а не идее аутентификации по пальцу.
Наверное, потому что не было нужды запускать 30 с лишним копий, чтобы справится с нагрузкой. В странах, где нагрузка меньше вполне хватает 8-15 копий и этой проблемы нет.
Ну вообще-то функциональность Кафки не ограничивается шиной сообщений. Это не "лютая дичь". Например, Kafka Streams превосходно хранят свои состояния внутри самой Кафки. Наши потребности прекрасно укладываются в эту концепцию.
Что бы не причинять вам напрасную боль, могу пояснить, что и Mongo и ES и Redis не играют роль основных источников данных. Для этого у нас есть PostgreSQL. Но он довольно далеко - между ним и монолитом есть RabbitMQ, еще один слой на Java, потом RabbitMQ + еще Java, потом начинаются Mongo и ES и Redis и только потом монолит, о котором я писал :) И это только одна веточка (online), а есть еще B2B, отделения, автоматы (vending machine).
Что касается целостность то у бизнеса нет таких требований и раньше не было. То, что так было реализовано, реально не значит, что это нужно. Скорее это было следствие используемых технологий и большой концентрации данных в одном месте - ведь монолит это не только о коде, но и о данных. При редизайне системы до нас стало доходить, что данные можно разделить на разные независимые потоки с разными требованиями к целостности и сохранности данных.
Я думаю, что для монолита гораздо проще контролировать зависимости между модулями. Если каждый модуль - это отдельный проект, то зависимости между проектами явно прописаны.
Да, так можно делать, я сам для DAO (или сервисов) всегда создавал два модуля, один с интерфейсами, второй с реализацией. На второй зависимость со скопом runtime. Вот только часто вы такие проекты видели? Я нет.
Если у компании несколько автономных команд разработки.
Да, разговор именно о них. Стартапу заморачиваться с микросервисами (если только это не цель их идеи) нет смысла.
Да, вы правы. Очень часто некорректно сравнивают сложность монолита и отдельного микросервиса, в то время как надо сравнивать хотя бы монолит и экосистему всех микросервисов которые выполняют его функции. Вот только потенциал у второй сложной системы намного больше. Я с трудом представляю потенциальный ИИ, который можно прикрутить к управлению монолитом. В случае с микросервисами - легко.
Да! Но не изначально, а она накапливалась там годами, помноженными на количество разработчиков. Ведь тот же кэш надо было делать отдельным Hazelcast кластером, что сняло бы львиную долю нагрузки с сети и решило проблему с источниками данных. Но было сделано, что сделано, тогда это казалось разумным, а текущие требования к нагрузке никто не мог представить.
Вот только монолит не откатить лет на семь назад, чтобы легко поправить это. И таких проблем там не мало. Каждая ошибка (как и хорошее решение) в архитектуре за несколько лет обрастает кодом. И исправить её ой как не просто. А грубой силой исправить (масштабировать) этого монстрика ну очень сложно :)
Я еще добавлю - просмотра относительно статической информации. Плюс некритичной ко скорости обновления. Ваш новый вопрос/ответ может легко появится в общем доступе секунд через 20-30 после его добавления. Не удивлюсь, что и позже — это некритично для этого сервиса.
Хмм... Ну не знаю. У нас заказчики это бизнес, который зарабатывает деньги не на разработке софта. Его модой не приведёшь. Клиентам (B2С) важна бесперебойная работа приложений и отделений. Им пофиг на чем все это едет.
А я про реальный мир. Что касается стоимость поддержки N баз данных и распределенных транзакций, то у нас хорошо ложится Кафка, которая постепенно вытесняет зоопарк из MongoDB, Redis, ES. Да топиков может быть очень много, но проблема одного топика не волнует поддержку если работает вся Кафка. Проблема одного топика ложится на разработчиков. Распределенные транзакции - тут тоже все не плохо. После переосмысления потоков данных выяснилось, что бизнесу они нужны в очень ограниченной области. К тому же эта область не критична ко времени выполнения и поток данных там на порядки меньше (реально тысячи против миллионов). В остальном мы можем позволить себе кратковременно потерять синхронизацию, а то и все данные на уровне микросервиса.
А как для копирование использовать ConEmu?
Вы же сами писали, что изобретать свой язык запросов — это зло. Но абзацем ниже предложили именно это - свой язык, основанный на SQL.
Еще один камень преткновения — это то, что вы посылаете запрос как строчку. Строка — это хорошо для человека, но у вас же пользователь не будет писать запрос. Вы его кодом соберёте. А на стороне сервера кодом разберёте. А зачем? Ведь проще послать уже структурированный запрос, как у вас в начале JSON. И ошибок будет меньше, и код проще.
MqExtension - отличная вещь. В git мне её очень не хватает.
Довольно часто хочется иметь локальные изменения для версионных файлов, но не думать при коммите, что там по делу, а что локально для тебя. Так вот все эти вещи у меня в MQ хранились.
На счет
rerereне знаю - не пробовал. У меня этот проект изначально был в Mercurial. А там все просто работает "из коробки".Сейчас то я в основном с Git работаю - так просто по жизни проще.
В общем вы правы. Но то, что Mercurial хранит весь граф модификаций иногда очень помогает. У меня есть форк проекта с GitHub (https://github.com/foal/gwt-time), структуру (не исходники) которого пришлось значительно изменить. Так вот git не может адекватно накатить изменения с оригинального проекта, а Mercurial легко. И это притом, что история коммитов просто идентична.
Вы абсолютно правильно подметили, что это открытые данные. И из этого вытекает, что их невозможно скомпрометировать. Все эти статьи - "ваш отпечаток могут узнать!" - яйца выеденного не стоят. Просто считайте изначально, что ваш отпечаток известен каждому. И решайте сами пользоваться этим или нет.
Уважаемый, вы все пытаетесь спорить, думая, что вам возражают :)
Что значит - "опасения, что палец сопрут". Нет! Его уже спёрли. И я уверен, что разработчики биометрических систем основываются на этом. А поэтому если вы доверяете конкретному экземпляру такой системы, то пользуйтесь на здоровье. Либо нет.
Но не надо кричать, что система безопасна, пока ваш отпечаток пальца в тайне, а потом беда-беда. Это ложь.
Просто считайте, что ваш отпечаток пальца это open key в ассиметричном шифровании. Никто же не рассуждает о том, что делать в случае компрометации открытого ключа - бред же?
Для непонятливых - отпечаток пальца это открытая всем информация, её невозможно скомпрометировать, ну или считайте, что он изначально скомпрометирован :)
Отвечая на ваш вопрос - ничего делать не буду. Тут вопрос о доверии. И чётком понимании что мой (как и любой другой) отпечаток пальца уже сейчас, как вы говорите "спёрт".
Живите теперь с этим.
Не очень понимаю процесс.
В разных системах (мой ноут, сейф на полке, входной замок, банк) информация о пальце хранится и обрабатывается по-разному. Нельзя украсть палец с входной двери и пройти в банк.
Информация о пальце, даже если она и хранится на стороне сервера вам ничего не даст. Это открытая информация, для её получения не нужно ничего ломать - она есть на каждом стакане, который я трогал - её невозможно скомпрометировать по определению.
Скажем так, я не вижу реальной возможности скомпрометировать палец. Есть уязвимости на уровне железок, но это скорее вопрос к конкретному сервису, а не идее аутентификации по пальцу.
Я вот как подсел на GWT так на нем и еду. Правда я больше по бакенду, поэтому мне Java на клиенте и нравится :)
Вот мне тоже так казалось, а потом я был вынужден вернуться на 10 и тут я понял... Короче, пришлось менять ноут, чтобы вернутся на 11 :)
Наверное, потому что не было нужды запускать 30 с лишним копий, чтобы справится с нагрузкой. В странах, где нагрузка меньше вполне хватает 8-15 копий и этой проблемы нет.
Нет :)
Ну вообще-то функциональность Кафки не ограничивается шиной сообщений. Это не "лютая дичь". Например, Kafka Streams превосходно хранят свои состояния внутри самой Кафки. Наши потребности прекрасно укладываются в эту концепцию.
Что бы не причинять вам напрасную боль, могу пояснить, что и Mongo и ES и Redis не играют роль основных источников данных. Для этого у нас есть PostgreSQL. Но он довольно далеко - между ним и монолитом есть RabbitMQ, еще один слой на Java, потом RabbitMQ + еще Java, потом начинаются Mongo и ES и Redis и только потом монолит, о котором я писал :) И это только одна веточка (online), а есть еще B2B, отделения, автоматы (vending machine).
Что касается целостность то у бизнеса нет таких требований и раньше не было. То, что так было реализовано, реально не значит, что это нужно. Скорее это было следствие используемых технологий и большой концентрации данных в одном месте - ведь монолит это не только о коде, но и о данных. При редизайне системы до нас стало доходить, что данные можно разделить на разные независимые потоки с разными требованиями к целостности и сохранности данных.
Да, так можно делать, я сам для DAO (или сервисов) всегда создавал два модуля, один с интерфейсами, второй с реализацией. На второй зависимость со скопом runtime. Вот только часто вы такие проекты видели? Я нет.
Да, разговор именно о них. Стартапу заморачиваться с микросервисами (если только это не цель их идеи) нет смысла.
Да, вы правы. Очень часто некорректно сравнивают сложность монолита и отдельного микросервиса, в то время как надо сравнивать хотя бы монолит и экосистему всех микросервисов которые выполняют его функции. Вот только потенциал у второй сложной системы намного больше. Я с трудом представляю потенциальный ИИ, который можно прикрутить к управлению монолитом. В случае с микросервисами - легко.
Да! Но не изначально, а она накапливалась там годами, помноженными на количество разработчиков. Ведь тот же кэш надо было делать отдельным Hazelcast кластером, что сняло бы львиную долю нагрузки с сети и решило проблему с источниками данных. Но было сделано, что сделано, тогда это казалось разумным, а текущие требования к нагрузке никто не мог представить.
Вот только монолит не откатить лет на семь назад, чтобы легко поправить это. И таких проблем там не мало. Каждая ошибка (как и хорошее решение) в архитектуре за несколько лет обрастает кодом. И исправить её ой как не просто. А грубой силой исправить (масштабировать) этого монстрика ну очень сложно :)
Я еще добавлю - просмотра относительно статической информации. Плюс некритичной ко скорости обновления. Ваш новый вопрос/ответ может легко появится в общем доступе секунд через 20-30 после его добавления. Не удивлюсь, что и позже — это некритично для этого сервиса.
Хмм... Ну не знаю. У нас заказчики это бизнес, который зарабатывает деньги не на разработке софта. Его модой не приведёшь. Клиентам (B2С) важна бесперебойная работа приложений и отделений. Им пофиг на чем все это едет.
А я про реальный мир. Что касается стоимость поддержки N баз данных и распределенных транзакций, то у нас хорошо ложится Кафка, которая постепенно вытесняет зоопарк из MongoDB, Redis, ES. Да топиков может быть очень много, но проблема одного топика не волнует поддержку если работает вся Кафка. Проблема одного топика ложится на разработчиков. Распределенные транзакции - тут тоже все не плохо. После переосмысления потоков данных выяснилось, что бизнесу они нужны в очень ограниченной области. К тому же эта область не критична ко времени выполнения и поток данных там на порядки меньше (реально тысячи против миллионов). В остальном мы можем позволить себе кратковременно потерять синхронизацию, а то и все данные на уровне микросервиса.