Одна кодова база для кабінету і мобільного додатка

Більшість інтернет-провайдерів приходять до одного й того самого. Є вебкабінет, де абонент дивиться баланс, написаний кілька років тому під наявний білінг. Потім замовляють мобільний додаток — зазвичай в іншого підрядника, — і той поступово формує власне уявлення про те, що таке зміна тарифу. Дві кодові бази, два цикли релізів, і кожна нова функція узгоджується двічі.

Дорого коштують не продубльовані екрани. Дорого коштує продубльоване розуміння білінгу під ними.

Де насправді починається розбіжність

Кабінет абонента постійно спілкується з білінгом: баланс, тарифи, обіцяний платіж, призупинення послуги, сповіщення про аварії. Це не просто читання даних. Обіцяний платіж має правила: коли його можна взяти, як часто і що відбувається, коли він не закривається вчасно. Ці правила живуть у білінгу, а не в інтерфейсі.

Коли два клієнти реалізують їх окремо, вони розходяться. Додаток дозволяє обіцяний платіж, який кабінет не дає. У підтримку приходить звернення, що відтворюється лише на одній платформі, і кожна розмова починається з питання «а де саме ви це бачили?».

Що змінює спільна кодова база

З React Native Web, Next.js та Expo на одній кодовій базі правила описані один раз. Екрани відрізняються там, де платформи справді відрізняються — навігація, сповіщення, біометрія, — і збігаються там, де мають збігатися, бо це той самий код.

На практиці це означає:

Функція виходить у вебі, на iOS та Android однією зміною, а не трьома задачами.
Інтеграція з білінгом має одну реалізацію, тож виправлення діє скрізь.
Це може підтримувати одна людина — і для провайдера з десятками тисяч абонентів саме це зазвичай і є справжнім обмеженням.

Це не безкоштовно. Спільний код вимагає дисципліни: що належить до спільного шару, а що справді специфічне для платформи. І відповідь змінюється, поки продукт росте.

Чого це не вирішує

Це не виправляє білінг. Якщо API потребує трьох запитів, щоб відповісти «скільки абонент винен», ви тепер робите три запити з одного місця замість шести з двох. Це виграш у підтримці, а не в архітектурі — і зазвичай саме з цього варто починати наступний крок.