10 июля 2018 г.

Я давно хотел разработать приложение для Electron. Однако не просто любое приложение — доказательство концепции для смягчения некоторых известных недостатков работы с Electron:

  • Производительность: работа с ресурсоемким ресурсом Electron.
  • Конфиденциальность:обход неспособности Electron скрыть исходный код.
  • Универсальность: отделение бизнес-логики от архитектуры Electron.

Принятие компромисса в производительности

Начав свою карьеру в качестве нативного настольного разработчика, я не ожидал, что Electron будет соответствовать нативной производительности.

Я ожидал, что Electron будет более ресурсоемким — особенно в части памяти. Видите ли, Electron порождает процессы Chrome для запуска во время выполнения, занимая значительный объем памяти даже в режиме ожидания.

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

Принятие компромисса — важный шаг к принятию Electron в качестве жизнеспособного варианта для производства. Как разработчики, мы склонны забывать, что конечные пользователи меньше всего хотят испытывать проблемы с производительностью. Большая часть мира не работает на Macbook Pro и 16 ГБ ОЗУ, поэтому нам следует быть особенно осторожными с жизненно важными ресурсами.

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

Работа с конфиденциальностью

Приложения Electron объединяются с использованием формата архивации, похожего на tar, который называется asar.

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

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

Снижение ожиданий

Назовите меня чудаком, но я всегда сталкиваюсь с таким ходом мыслей: «Что, если Электрон исчезнет, ​​а у меня останется весь этот вчерашний код?» Да, Электрон вряд ли исчезнет, ​​но что, если появится что-то получше? Насколько переносимым может быть мой код для попытки возможного перехода?

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

Наконец, мысль

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

Go казался идеальным вариантом. Я мог использовать его функции кросс-компиляции для работы со всеми основными операционными системами. Я бы объединил их в виде распакованных файлов в Electron и предоставил функциональность через традиционный веб-API.

Я пошел еще дальше: что, если бы у меня был отдельный SPA и мой автономный двоичный файл, живущий внутри приложения Electron? Я могу отделить свой уровень представления от моей бизнес-логики, при этом все это будет объединено в исполняемый файл Electron.

Затем я смог решить большинство первоначальных проблем, которые меня беспокоили:

  • Производительность: в зависимости от варианта использования и выхода за рамки дебатов Go vs Node; Go значительно лучше справляется с вычислениями, связанными с процессором.
  • Конфиденциальность. Я бы скрыл бизнес-логику, распространяя ее в виде машинного кода, что является шагом вперед по сравнению с запутыванием.
  • Универсальность.Наличие всей бизнес-логики в одном бинарном файле означает переносимость. Кроме того, наличие Vue для управления пользовательским интерфейсом означает, что автономный SPA может быть создан в любое время.

Другие возможные преимущества:

  • Двоичный файл может обрабатывать большую часть того, что делает Electron API в отношении ввода-вывода.
  • Комбинация Go x Vue может быть перемещена в облако и перепрофилирована в качестве веб-клиента.
  • CLI можно было встроить в бинарный файл Go и использовать в другом месте.

Звучит неплохо, есть что показать?

Да, на самом деле, я делаю. Я пошел дальше и создал RepoCMD — приложение для управления GitHub в качестве доказательства концепции.

Найдите приложение Electron здесь: github.com/repocmd-desktop.

А приложение Go здесь: github.com/repocmd

Я буду работать над частью 2 этой серии, где я перейду к техническому пошаговому руководству, объясняющему, как все эти компоненты работают вместе.

А пока вы можете следить за обновлениями в моем твиттере: @_ef2k.

Первоначально опубликовано на eddieflores.com.