Rails - мощная платформа, однако в чистом виде для создания большого количества сложных и навороченных интерфейсов она не подходит.
Я расскажу о том, какой путь мы прошли при создании корпоративной системы: от простого rails-приложения до оригинальной связки rails+extjs. Почему именно extjs на фронтэнде и rails на сервере, какие есть способы "подружить" два разных мира, проблемы и особенности построения архитектуры, аутентификация, авторизация, особенности решаемых задач, возможности применения подхода в других проектах и анализ других вариантов решения проблем корпоративной разработки.
Вполне возможно, что опыт разработки сложных и надежных интерфейсов с использованием минимальных затрат будет интересен не только корпоративных разработчикам, но и при реализации многих других проектов.

В настоящее время любая более-менее уважающая себя компания заинтересована в автоматизации своей деятельности. Рассмотрим сферическую в вакууме компанию, которая достаточно давно (порядка 20 лет) ведет бизнес в быстро меняющихся и не очень хорошо формализованных условиях, обладает достаточными, но не бесконечными, средствами для некоторого развития - то есть типичную среднюю российскую компанию.
На начальном этапе развития в компании внедрялись готовые или разрабатывались собственные двухзвенные решения - «толстый», зачастую чересчур толстый, клиент и много бизнес-логики в хранимых процедурах. Понемногу эти решения пронизывали деятельность предприятия с головы до ног.
Все идет, все меняется, необходимо осваивать новые виды и формы деятельности. Возникает непростая ситуация - имеется некоторая система или набор систем, часто реализованных на устаревших технологиях и, вполне вероятно, совсем не в духе лучших практик, которые уже не позволяют компании решать новые задачи, но избавиться от них невозможно в силу того, что они реализуют большое количество важных и взаимосвязанных бизнес-процессов (Legacy Code).
В компании появляется трехзвенная система в дополнение к имеющимся двухзвенным. Медленно, но верно начинается переход на новую платформу.
Однако требования пользователей к функционалу приложений растут - они видят Google, Yandex, Facebook, ВКонтакте, Одноклассники, также у них есть Excel и различные настольные приложения. Пользователи помимо текстовой и табличной информации хотят видеть графики, карты. А еще хотят удобства работы как в настольных приложениях. Маленький штат разработчиков не позволит одновременно развивать и толстые клиенты, и веб-приложения.
Очень привлекательным является вариант разработки javascript-приложений. Тем более что существуют фреймворки для разработки сложных приложений и интерфейсов.

Итак, начальные условия:
- большая и вездесущая двухзвенная система
- СУБД с большим количеством хранимых процедур, огромным количеством таблиц и данных. Архитектура СУБД изначально «заточена» под двухзвенную систему или отсутствует вообще
- трехзвенная система с очень навороченным фронтом, который не встраивается в экосистему бэка

Стартаперы и те, кто делают все хорошо, презрительно морщатся, но это суровая реальность многих компаний.

Рассмотрим некоторые проблемы.
1. Организация взаимодействия двух платформ - серверного приложения на Rails и клиентских на ExtJs. С одной стороны, ExtJs предоставляет целую платформу для разработки приложений с множеством возможностей. С другой стороны, этих возможностей очень много, они требуют изучения. Также существует множество подводных камней и багов. А еще эта платформа ничего не знает и не хочет знать про сервер. Существуют решения, позволяющие "встроить" ExtJs в экосистему Rails, однако возникают серьезные проблемы при выходе новых мажорных версий ExtJs - 4 версия использовала принцип MVC, 5 и 6 - MVC+MVVM. К тому же не так и много людей используют такую связку. Разработка и поддержка гемов идет достаточно медленно и вяло.
Также платформы используют различную идеологию - ExtJs - Single Page Application. Но клиенты не должны иметь доступа даже к исходному коду тех частей системы, которые им должны быть недоступны, поэтому создание одного приложения для всех пользователей невозможно. Права пользователей достаточно часто меняются, меняются пользователи. С этим связана следующая проблема.

2. Система авторизации. Есть внутренние пользователи, которые управляются LDAP, есть внешние пользователи. В целях безопасности все они используют двухфакторную аутентификацию. Использование какой-либо системы «из коробки» в таких условиях очень затруднительно. Почти все известные решения используют контроллеры для контроля прав. Если много пользователей, групп и интерфейсов, то система, основанная на записи правил в исходном коде, становится крайне громоздкой и трудной.

3. Проблемы производительности. Если клиентское приложение существует независимо от сервера, то все данные получаются AJAX-запросами. При этом есть большое количество данных, которые загружаются при инициализации приложения и впоследствии не изменяются, а часть данных меняется достаточно часто, чтобы не было возможности использовать кэширование.

4. Чем больше исходного кода и выше сложность системы, тем больше затрат приходится нести. Простые на начальных этапах решения становятся очень громоздкими и сложными. Каждая новая доработка начинает приводить к необходимости долгого анализа существующих процессов и кода, чтобы новая фича не поломала уже имеющийся функционал.

5. Тестирование. Рано или поздно, люди приходят к тому, что система должна быть покрыта тестами. С какой стороны подойти к проблеме?