Мы расскажем, зачем разработчики добивались максимально быстрого отклика приложения и чем заменили отвлекающие визуальные оповещения. А также почему мы планируем сделать систему полностью автономной и работающей оффлайн, несмотря на то, что на складе сотни роутеров.
"Разработка сразу пошла быстрее, чем на Java. По субъективным ощущениям — примерно в 1,5–2 раза." - откровенная брехня.
Да синтаксис Kotlin более краток, есть своя реализация стримов. Но 70% времени разработчик тратит на понимание того, как его решение повлияет на работу системы, дизайн, чтение кода, понимание зависимостей, тестирования и т.д.
"Для этого подойдет протокол JSON-RPC Over HTTP." - вообще непонятно для чего такое тут писать. Транспорт в системе в обещем случае должен быть абстрагирован и что там гоняется под капотом интересовать должно максимум архитектора.
"Возможность автономной работы сканера снижает важность стабильной интернет-связи.
"По сути хороший сигнал нужен только в ключевых точках, а не по всему складу." А почему бы не натыкать вай фай точек? они же не стоят как-то дорого.
Конечно оффлайн работа нужна, но этому подходу 100 лет в обед.
даже в пиковых нагрузках как 500*5=2500 запросов в секунду, не такая уж и большая цифра. Тем более, что средняя скорее всего будет сильно меньше.
200 000 товаров, если по каждому товару отправляется даже по 100 сообщений(что завышено скорее всего на порядок), то пик как раз и будет в ~2500 в секунду, реально с 200к товаров, апдейтов наверное 2-3млн.
Вся система in-house, клиенту можно выставить любой дубовый gateway, а внутри заиспользовать бинарные протоколы, которые вполне переваривают такие данные.
Кроме того оперативных данных не так много и заказы сделанные даже пол года назад, можно сложить в архив и забыть про них.