Запуск власного стартапу, технічна складова, виклики та не технічні особливості

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Вітаю, спільното DOU.

Мене звати Роман (www.linkedin.com/in/romanmalko). Я засновник mmeet.app. У цій статті хочу поділитись технічними викликами, як реалізував проєкт, та нетехнічними, з чим стикнувся.

(happy path відео є на сайті mmeet.app)

Ідея

Усі знайомства починаються однаково: матч → чат → «привіт, як справи» → через три тижні нічого. Я хотів інакше: ніяких чатів. Сподобалась людина — відразу пропонуєш, де і коли зустрітись. Вона погоджується або пропонує своє. Мета — від матчу до реальної зустрічі за 5 хвилин.

Основа проєкту — mmeet-video: замість набору фото кожен записує короткі відповіді на кілька питань; проєкт склеює їх в одне безперервне відео. Дивишся — і відразу бачиш живу людину, а не відфільтровану картинку.

Цю статтю я писав, щоб показати, як усе вкладено під капот і на чому я спотикався.

Репо — монорепо з кількома частинами:

• мобільний застосунок — React Native Expo
• сайт — Next.js лендінг
• основний бекенд — Spring Boot + GraphQL, єдина публічна точка входу
• воркер для склейки відео — Spring Boot сервіс без HTTP
• photo-validation — окремий сервіс, який перевіряє фото користувача через Gemini
• video-validation — окремий сервіс, який перевіряє записане відео через Gemini

Плюс Nginx спереду і docker-compose для прод-розгортання.

Схема трафіку проста:

Мобілка і сайт ніколи не йдуть напряму в базу, Redis чи S3. Тільки через основний бекенд. Це економить купу нервів — один вхід, одне місце для логіки, один шар безпеки.

Авторизація — чому я пішов від Firebase Auth

Спочатку логін був через Firebase Auth. Зручно, але кожна дрібниця — через їхню чорну скриньку. Я виніс auth на бекенд:

• Email + пароль — BCrypt на бекенді, при першому логіні автоматично реєструється користувач. Невідомий email і неправильний пароль повертають однаковий 401 — щоб не можна було вгадувати, хто зареєстрований.
• Google — мобілка тягне idToken через Google SDK, надсилає на бекенд. Бекенд перевіряє підпис через Google-верифікатор, дістає email з claims.
• Apple — те саме через Apple JWKS.

Після будь-якого з трьох варіантів я видаю свій JWT на 30 днів. Firebase Admin залишив тільки для push-нотифікацій, там він незамінний.

Чому так краще: контроль над тим, як ведуться сесії, що записується в лог, і не треба гуглити «firebase auth custom claim» щотижня.

GraphQL і кодоген — контракт, який сам себе оновлює

У мене одна схема на бекенді. Мобілка запускає yarn codegen — і з цієї схеми генерується типізована обгортка для Apollo. Тобто хуки для мутацій, запитів і типи всіх полів — усе автоматом.

Підводний камінь тут один, але великий: якщо забув запустити codegen після зміни схеми, типи стають застарілими, і TypeScript тобі не скаже. Тому правило: змінив бекенд → yarn codegen на мобілці. Записав, щоб не забувалося.

Як працює головна фіча — домовитись про зустріч

Весь флоу крутиться навколо об’єкта «зустріч». У нього три слоти адреси:

• адреса, яку запропонував ініціатор
• адреса, яку запропонувала інша сторона (якщо контрпропозиція)
• узгоджена адреса, якщо дійшли згоди

Послідовність:

1. Користувач А через Google Places вибирає місце і час. Я зберігаю не що завгодно, а тільки координати і адресу, які віддав сам Google — мобілка не може підсунути вигадану адресу.
2. Бекенд записує пропозицію і шле push користувачу Б.
3. Б тисне «Accept». Бекенд переносить пропозицію в статус узгодженої, шле push А.

mmeet-video: склейка через чергу

Це найцікавіша частина технічно. Користувач записує відповіді на питання — кожна відповідь як окремий mp4, мобілка шле їх на основний бекенд, той кладе файли в S3. Після кожної відповіді треба склеїти всі відеофайли в єдине відео.

Тільки от склейка через ffmpeg — довга, і на основному бекенді її робити не можна (забив потік — інші користувачі чекають, або взагалі сервер падає із-за нехватки пам’яті). Тому:

1. Основний бекенд пише в Redis свіжий timestamp для користувача.
2. Кидає повідомлення в RabbitMQ з цим самим timestamp.
3. Воркер склейки (окремий сервіс, без HTTP взагалі) забирає повідомлення.
4. Перед склейкою звіряє: «мій timestamp == той, що в Redis?»
5. Якщо так — качає всі відповіді з S3, запускає ffmpeg, заливає результат назад в S3, пушить мобілку.
6. Якщо ні — мовчки викидає повідомлення.

Навіщо ця перевірка? Якщо користувач перезаписав відповідь, поки йшла стара склейка, — стара вже неактуальна. Простий порівняльний timestamp у Redis робить дедуплікацію без блокувань і без складних стейтів.

Контракт повідомлення живе в двох місцях — на стороні продюсера (основний бекенд) і на стороні консюмера (воркер). Змінив, з одного боку, забув, з іншого — відео просто перестає склеюватися. Тому я окремо записав попередження про те, щоб тримати їх синхронно. Також сервіс по склейці можна масштабувати, бо він підключається до брокерів і працює асинхронно.

Валідація фото і відео через Gemini

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

Я зробив два окремі сервіси — photo-validation і video-validation. Логіка однакова:

1. Основний бекенд після завантаження файлу кидає задачу в чергу.
2. Відповідний сервіс забирає файл з S3, надсилає його в Gemini з промптом.
3. Gemini віддає структуровану відповідь: валідно / невалідно + причина.
4. Сервіс пише результат назад, і бекенд знає — показувати цю фотку/відео іншим чи просити перезняти.

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

Що я наламав і як полагодив

Фото, які вбивали сервер

Спершу мобілка заливала фото «як є» — якість 1.0, без обмеження розмірів. 8-мегапіксельна селфі з iPhone — це 4–6 МБ.

Виправлення на дві сторони:

• Мобілка: якість стиснення 0,8, максимальна сторона 1080 пікселів. Типове фото тепер 150–300 КБ.
• Бекенд: ліміт 2 МБ, плюс перевірка magic-байтів. Тобто недостатньо сказати в Content-Type «я jpeg» — сервер читає перші байти файлу і дивиться, чи це реально JPEG/PNG/WebP. Інакше будь-хто міг би завантажити .exe з підробленим заголовком.

Maestro e2e — як дістати код верифікації з Redis

E2E-тести зроблені на Maestro. Дуже зручна робота з сценаріями. Detox не завівся.

JDK 24 зламав Android білд

Одного ранку Android перестав збиратися з restricted method in java.lang.System. Виявилося — одна з RN-бібліотек використовує CMake-плагін, який падає на JDK 24. Лікування: поставити Temurin 17 і виставити JAVA_HOME на нього. RN поки не дружить з найновішою Java.

Підсумок

Головні уроки, які я для себе виніс:

1. Один вхід робить життя простим. Всі запити йдуть через нього.
2. GraphQL + codegen економить купу часу, але вимагає дисципліни запускати codegen.
3. Фонова робота — в чергу. Склейка відео і валідація через чергу набагато стійкіші, ніж крутити це в веб-потоці.
4. Валідуй на обох сторонах. Мобілка стискає фото, бекенд перевіряє розмір і магічні байти. Жодна зі сторін не довіряє іншій.
5. Не бійся відмовитися від хайпового SDK. Firebase Auth — класний, але свій JWT простіший і під контролем.

Про нетехнічну сторону

Я зрозумів, що робота над своїм стартапом — це насправді робота над собою, над своїм перфекціонізмом, який змушує вичищати усе до пікселя, і при цьому треба балансувати з продуктивністю і рухатись вперед.

Стартап як дитина.

Є ще одна частина цього досвіду, про яку хочеться сказати окремо — не технічна, а людська.

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

Це внутрішній перехід, який технічно описати важко, але він реальний. Ти можеш нескінченно переписувати той самий екран, міняти відтінок оранжевого на чекмарку, додавати ще один edge case у валідації — і все це під приводом ще не готово. Насправді ж готовність — це не стан продукту, це твоя згода відпустити.

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

У випадку mmeet це означає серйозно ставитися до модерації, до приватності, до того, як саме люди представлені одне одному, до того, які сигнали підсилює алгоритм, а які ні. Це не додаткова фіча — це фундамент. Технології тут інструмент, а не мета. Мета — простір, у якому людям добре бути собою.

Що далі

Зараз фокус на налаштуванні моніторингу через Grafana, покращенні video-merger pipeline (паралельна обробка) і експериментах з AI для автоматичної модерації відео.

Застосунок проходить перевірку в маркетах Apple App Store та Google Play.