Б. Ткаченко

«История движется по спирали», и я думаю, что то же правило применимо к программному обеспечению и особенно к веб-приложениям. На заре Интернета наиболее распространенным способом доставки контента пользователю был статический хостинг HTML-страниц. Затем разработчики начали использовать различные серверные скрипты и фреймворки для генерации HTML-кода для каждого запроса, в зависимости от информации пользователя и запроса пользователя. Такой подход сделал Интернет революционным и доступным для всех - любой может создать веб-сайт с помощью системы управления контентом (CMS), не требующей знания языка программирования. Так в основном все работало в Интернете раньше: вы отправляете запрос, сервер обрабатывает HTML и отправляет его вам, а ваш браузер отображает этот HTML с помощью набора визуальных компонентов.

В 2004 году Google навсегда изменил этот подход. Они представили Gmail - самую популярную сегодня в мире службу электронной почты. Обладая множеством преимуществ перед другими почтовыми службами, Gmail использовал технологию AJAX для динамической загрузки контента без обновления веб-страницы. Для этого уже существовали разные подходы, такие как iframe, но технически это было одно и то же, но у вас могло быть несколько веб-страниц внутри вашей веб-страницы. Забавно то, что Microsoft создала эту технологию в 1999 году для некоторых внутренних нужд в Outlook, но практически никто не использовал ее около пяти лет.

AJAX позволяет загружать базовый HTML-код, JavaScript, а затем динамически загружать отдельные файлы данных. Это положило начало новой эре Web 2.0, когда все пытались создать одностраничные приложения, у которых был совершенно другой подход, чем раньше: теперь сервер «тупой», а клиент «умный», что означает, что вся разметка создается на клиенте, а сервер - только отвечает за доставку контента и за некоторую логику, связанную с безопасностью.

Это 2018 год ... и знаете что? Статические сайты снова в тренде! Нельзя сказать, что они не использовались все это время, но в наши дни они определенно становятся все более популярными. Они не такие, как в начале 00-х - они намного красивее и их намного проще реализовать и поддерживать, они также могут использовать сторонние виджеты для отображения динамического контента или некоторый JavaScript, чтобы сделать ваш сайт более динамичным, но все же это это просто набор HTML-файлов, размещенных на сервере. Каждый день все больше и больше компаний выбирают статические веб-сайты - гораздо проще реализовать индивидуальный и уникальный дизайн. Они намного быстрее, потому что CDN может кэшировать весь ваш веб-сайт, и вам не нужно платить за кластер компьютеров только для размещения веб-сайта. И, наверное, главное преимущество в том, что их невозможно взломать. Что ж, все еще можно взломать множество вещей вокруг них, но не сам веб-сайт, например, можно взломать или DDOS вашего провайдера CDN или взломать провайдера DNS.

Это лишь один из многих примеров того, как старые технологии пересматриваются и сочетаются с новыми технологиями для создания лучших решений для конкретных случаев. Мобильные приложения прошли несколько разных этапов, но всегда можно увидеть, что многие новые технологии - это просто что-то старое, но реализованное с другой точки зрения.

Так в чем проблема?

В doc.ai мы разрабатываем мобильное приложение, которое является частью нашей новой платформы, и мы хотим сделать его настраиваемым и позволить сторонним разработчикам расширять приложение и добавлять новые функции. Наше видение состоит в том, чтобы сделать приложение полностью децентрализованным, чтобы данные не обрабатывались на центральном сервере. Мы упорно работаем над этим, но это займет у нас время, поскольку современные технологии ненадежны. А пока мы должны использовать серверные решения, чтобы предоставить лучший продукт, а затем со временем сделать его децентрализованным.

Итак, как вы можете позволить сторонним разработчикам добавлять новые функции в ваше приложение? Есть несколько возможных подходов:

1. Вы делаете свое приложение с открытым исходным кодом и позволяете разработчикам изменять его. Этот подход хорош, но у него есть несколько ограничений:

  • Разработчик должен знать язык программирования, который вы используете для разработки своего приложения.
  • Чтобы предоставить пользователям обновление, вам необходимо создать новую версию своего приложения, получить разрешение на публикацию его в App Store и Google Play, а затем дождаться, пока все пользователи обновят приложение.
  • Если есть серьезная проблема с функцией, разработанной сторонним разработчиком, у вас есть три способа исправить это:

Я прошу стороннего разработчика исправить это

II. Исправьте это самостоятельно или

III. просто отключите эту функцию

Все эти параметры требуют, чтобы вы опубликовали новую версию своего приложения, а это означает, что пользователю может потребоваться около трех дней, чтобы получить новую версию. И не все будут его обновлять - вы получите много жалоб, а некоторые пользователи просто удалят ваше приложение, потому что оно не работает.

Слишком сложно поддерживать монолитное приложение, созданное основной командой и десятками сторонних разработчиков.

2. У вас есть основная часть вашего приложения в виде нативного приложения и у вас есть определенные разделы в виде веб-страницы. Это довольно популярный подход, и он работает довольно хорошо, но у него есть существенные недостатки:

  • Это ужасно медленно - ваши пользователи будут ненавидеть вас за приложение, которое каждый раз зависает. Это медленно, потому что WebView работает медленно, и требуется гораздо больше времени для визуализации веб-страницы, а затем для визуализации собственного компонента, особенно если на странице много элементов.
  • Вы должны поддерживать стили своего приложения вместе со стилями своего веб-приложения и следить за тем, чтобы они совпадали и ваше приложение выглядело хорошо.
  • Хотите использовать какую-то аппаратную функцию или что-то специфичное для ОС? Ну, ты не можешь. Иногда вы можете потратить много ресурсов на поддержку большого количества дополнительного кода для этого, но обычно это не вариант.
  • Ваше приложение полностью работает как веб-страница. То же, что и предыдущее, но даже немного медленнее, но в качестве преимущества вам не нужно поддерживать две версии стилей.

Лучшее решение?

В doc.ai мы используем комбинацию №1 и №2, но с некоторыми изменениями. У нас есть собственное приложение с плагинами, которые также используют собственные компоненты, но разработчики могут динамически добавлять их, используя язык разметки, и отправлять их в мобильное приложение с сервера. Для разработчика создание новой страницы (мы называем их внутренними представлениями) в нашем приложении так же просто, как создание HTML-файла. Мы используем React Native, который позволяет нам иметь одинаковую базу кода для iOS и Android, и мы позволяем разработчикам также использовать упрощенную версию JSX. Мы называем этот подход «Серверный рендеринг React Native». А поскольку он отображает собственные компоненты, он работает очень быстро. Это по-прежнему требует дополнительных знаний языка разметки, но писать HTML-подобный код намного проще, чем писать код Objective-C или Swift. Вот как может выглядеть простой View:

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

Этот подход также позволяет разработчикам легко создавать представления, которые идеально подходят для интерфейса нашего приложения, потому что мы тщательно разрабатываем и адаптируем каждый компонент, доступный для разработчика.

Как это работает внутри?

Что ж, наша серверная часть довольно проста: мы просто генерируем код разметки из шаблона для каждого запроса и отправляем его обратно пользователю. Мы также выполняем кеширование на сервере и на клиенте, чтобы пользователь мог получить контент как можно скорее, но на стороне сервера это очень просто.

Настоящая магия начинается с клиента, когда мы хотим визуализировать представление из разметки. У нас есть специальный модуль, который принимает разметку JSX и строит абстрактное синтаксическое дерево, а затем создает собственный компонент для каждого узла в этом дереве и помещает его прямо на экран. Некоторые компоненты также могут иметь некоторый базовый код JavaScript внутри атрибутов, аналогичный шаблонам Angular, поэтому как разработчик вы можете добавить некоторую логику к компонентам, например, вы можете открыть модальное окно при нажатии на какой-либо элемент.

Более подробную информацию вы найдете в исходном коде этого проекта, когда мы опубликуем его в открытом доступе.

Но подождите, вы обещали сделать его децентрализованным!

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

Нашу первую встречу разработчиков будут проводить и организовывать наши инженеры и специалисты по искусственному интеллекту, а также главный научный сотрудник Джереми Ховард.
Когда: среда, 21 марта с 18 до 20:30 < br /> Где: Оцинковка ул. Техама, 44. CA 94105, Сан-Франциско

ЗАРЕГИСТРИРУЙТЕСЬ ЗДЕСЬ (или [email protected] для регистрации в последнюю минуту)
Еда и напитки предоставляются