Как я разработал приложение, которое запускается и синхронизируется только на настольных и мобильных платформах

Технические советы по созданию SaaS, который работает и синхронизируется на 5 платформах

Привет, это Такуя. Я единственный разработчик Inkdrop - кроссплатформенного приложения для создания заметок Markdown, поддерживающего macOS, Linux, Windows, Android и iOS. Как вы знаете, сложно заставить ваше приложение поддерживать только эти 5 платформ, но возможно, используя мощные фреймворки. Вы не только полагаетесь на них, но и нуждаетесь в некоторых стратегиях развития, чтобы проект оставался устойчивым. В этой статье я хотел бы поделиться своими достижениями в этом проекте.

Ты не развиваешься в одиночку

Разработка кроссплатформенных приложений обычно связана с множеством невоспроизводимых и непредсказуемых проблем. Функции, нормально работающие в вашей среде, иногда не работают в других средах должным образом. Например, недавно я столкнулся с такой ошибкой, которая заключалась в том, что приложение запускается с пустым экраном. Я заранее тщательно протестировал его с некоторыми бета-версиями, но я не мог знать об этой ошибке. Благодаря их быстрым ответам и отчетам я смог решить эту проблему в течение 24 часов.

Индивидуальные разработчики на самом деле не разрабатывают свои приложения в одиночку, потому что вы всегда можете попросить своих пользователей о помощи. Будьте честны и объясните, над чем вы работаете и что пытаетесь решить. Пользователи, которым нравится ваше приложение, в основном надеются, что ваше приложение также будет успешным, и будут рады вам помочь. Очень важно полагаться на поддержку пользователей, потому что ваш ресурс весьма ограничен. Невозможно было бы развить Inkdrop без поддержки всех пользователей. Поскольку Inkdrop предназначен для программистов, некоторые ребята даже предложили мне пример кода для решения такой проблемы, как этот кейс на форуме. Более того, некоторые пользователи помогли мне решить ошибку, которую я не могу воспроизвести, работая со мной в течение нескольких часов. Такое тесное и интерактивное общение с пользователями будет большим преимуществом, которое позволит вам выделиться на фоне крупных компаний.

CouchDB и PouchDB для бесшовной синхронизации данных с офлайн-поддержкой

Apache CouchDB - это документно-ориентированная база данных (NoSQL), которая имеет JSON API на основе HTTP и поддерживает синхронизацию с несколькими мастерами. Он имеет графический веб-интерфейс под названием Fauxton, который позволяет легко управлять базами данных и документами. PouchDB - это база данных JavaScript, вдохновленная CouchDB, которая может синхронизироваться с ней. Сначала я создал настольную версию и не заботился о мобильных платформах, потому что предполагал, что PouchDB работает и на мобильных устройствах, потому что он написан на JavaScript и, похоже, уже есть некоторые варианты. Если это не сработает, я мог бы создать свой собственный модуль клиентской базы данных, поскольку CouchDB поддерживает RESTful.

Почему я выбрал CouchDB вместо другого PaaS (Platform-as-a-Service), который поддерживает синхронизацию данных между устройствами, например firebase, потому что мне нужна была гибкая поддержка индексирования на стороне клиента. 3 года назад, когда я начал этот проект, firestore еще не был настолько гибок, чтобы его реализовать. PouchDB выглядел многообещающим, поскольку он поддерживает клиентскую MapReduce для построения индексов и имеет модуль полнотекстового поиска. Кроме того, существует DBaaS для CouchDB под названием Cloudant, который может независимо эластично масштабировать пропускную способность и объем хранилища. Поскольку мне не хотелось работать с серверами, я начал использовать Cloudant в первые дни. В настоящее время я использую CouchDB на AWS EC2, так как обнаружил, что нагрузка на сервер в основном стабильна и не так велика, как сервисы BtoC, чем я ожидал, а Cloudant был очень медленным и неудобным для управления в IBM Cloud.

В целом я доволен CouchDB и PouchDB.

Кросс-платформенные фреймворки

Чтобы он работал на 5 платформах, я использую Electron для настольных ОС (Windows / Linux / macOS) и React Native для мобильных ОС (iOS / Android). Обе версии используют одни и те же фреймворки - ReactJS и Redux. Благодаря этим фреймворкам я мог создавать и то, и другое в основном только с помощью JavaScript, что позволяет приложению совместно использовать большой объем кода между настольными компьютерами и мобильными устройствами.

Учитесь на успешных продуктах

Это был первый раз, когда я создал настольное приложение на основе Electron и ReactJS. Но я хотел развернуть его как можно скорее, чтобы проверить свою идею приложения. Итак, я решил изучить текущие передовые практики по созданию красивого пользовательского интерфейса и расширяемой архитектуры из существующих проектов с открытым исходным кодом, таких как Atom editor и Kitematic. Я обнаружил, что их кодовую базу можно повторно использовать для создания моего приложения, потому что их проектная лицензия не была GPL. Спасибо, GitHub и Docker.

Я начал с форка репозитория Kitematic. Это дало мне много хороших практик и позволило мне заранее избежать многих проблем, но был один недостаток - это также принесло мне некоторый технический долг, который обычно есть у многих других проектов. Например, это зависит от AltJS, который является одной из реализаций архитектуры потока. К сожалению, после того, как я начал работать над Inkdrop, проект быстро стал неактивным. Это помешало мне обновить React до 16 на какое-то время. В конце концов я недавно заменил AltJS на Redux. Однако в принципе невозможно ожидать принятия Kitematic. Вы можете многому научиться из этих проектов. Итак, я бы сделал это снова, если бы я был в той же ситуации.

Я часто заимствовал код Atom для реализации системы плагинов, настроек раскладки клавиатуры, тем и так далее. Я всегда был очарован чтением их кода. Я бы никогда не смог реализовать их в одиночку.

Поделитесь кодовой базой

Поскольку как настольные, так и мобильные приложения созданы с использованием PouchDB, React и Redux, они могут совместно использовать множество кодовых баз, таких как модели данных, некоторые действия redux и редукторы, которые не зависят от собственных слоев или платформ. Это позволяет мне легко поддерживать оба приложения одновременно.

Компоненты пользовательского интерфейса не являются кроссплатформенными

Я создавал пользовательские интерфейсы для настольных компьютеров и мобильных устройств отдельно. С тех пор, как я начал с настольного приложения, меня в первую очередь не волновало, как я создаю мобильное приложение. Кроме того, я считаю, что совместное использование компонентов пользовательского интерфейса между мобильными устройствами и настольными компьютерами - не лучшая стратегия, особенно для Inkdrop. Потому что библиотеки вроде react-native-web в основном ориентированы на мобильные устройства и не ориентированы на настольные компьютеры. Таким образом, он работает только в том случае, если ваше приложение достаточно простое и ориентировано в основном на мобильных пользователей.

Настольное приложение использует Semantic UI, а мобильное приложение использует Native Base для создания красивых компонентов с поддержкой тем. Я подробно рассказал о своем опыте разработки React Native в этой статье:

Взлом PouchDB, чтобы он работал на React Native

PouchDB хорошо работает в браузерах и приложениях Electron. Но когда дело доходит до приложений React Native, было несколько проблем - они не работали с pouchdb-react-native, поскольку использовали AsyncStorage для своего адаптера. Поэтому я создал react-native-sqlite-2 и pouchdb-adapter-react-native-sqlite, чтобы использовать SQLite в качестве адаптера. Другая проблема заключалась в том, что он плохо справлялся с вложениями. Мне пришлось взломать основные модули PouchDB для их поддержки:

Локальный полнотекстовый поиск с SQLite3

Раньше я использовал pouchdb-quick-search для обеспечения полнотекстового поиска, но он был неэффективен, особенно на Android. Поэтому я решил создать свой собственный модуль FTS, используя функцию полнотекстового поиска SQLite на основе pouchdb-quick-search.

Обычно сложно принять решение о том, какой фреймворк вам следует использовать, но не бойтесь пробовать их. Никто даже не знает, какой из них лучше всего подходит для вашего проекта, потому что не существует универсальных решений. Мне пришлось самому создать несколько библиотек для решения проблем, но я думаю, что это также хорошая возможность внести свой вклад в сообщество OSS. По мере роста вашего проекта вы тоже растете. Надеюсь, это поможет :)

Смотрите также