Выставление счетов в Gmail

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

Они проводят большую часть времени в своем почтовом приложении, общаясь со своими клиентами и пытаясь следить за счетами и платежами, жонглируя между множеством приложений. В настоящее время нет ни одного продукта, который предоставлял бы им единый интерфейс, который экономил бы время / деньги и усилия. 55% владельцев малого бизнеса считают, что время успеть - это самая большая проблема. Что, если бы они могли просто выставлять счета / управлять и общаться со своими клиентами из одного приложения, и все это из знакомого им интерфейса электронной почты? А что, если бы это приложение работало на их компьютере и мобильном телефоне одновременно, экономя массу усилий и времени?

Intuit открывает свою платформу для разработчиков и интегрируется с несколькими другими платформами (Amex, Square, Paypal, Stripe и другими). Это была еще одна возможность сотрудничать с лучшими в отрасли, чтобы сэкономить время / силы и деньги для клиентов малого бизнеса. Поэтому мы заключили партнерство с крупнейшим провайдером электронной почты Google, чтобы предоставить очень простой интерфейс выставления счетов из Gmail. Половина клиентов малого бизнеса, использующих Quickbooks в Интернете, уже используют Gmail в качестве поставщика услуг электронной почты. Цель заключалась в том, чтобы позволить продавцам управлять всеми коммуникациями, включая отправку счетов-фактур, проверку статуса оплаты по этим счетам и общаться со своими клиентами, не покидая знакомый интерфейс Gmail в своих браузерах настольных компьютеров И на своих мобильных устройствах. Поскольку Google уже работал над добавлением расширенных дополнительных возможностей в Gmail, это было беспроигрышным вариантом для Small Business Merchants, Intuit и Google. Так родился проект Quickbooks Invoicing For Gmail.

Архитектура, выбранная Google для Gmail, является расширением уже существующей платформы Google App Script. Скрипт приложения Google похож на спецификацию javascript ECMA 3 (подробнее об этом позже).

Вот вещи, которые мы любили из коробки

  1. Полированный интерфейс с четко определенными разделами / карточками / кнопками.
  2. На основе javascript, поэтому обучение практически не требуется. Наше первое доказательство концепции, которое включало вызов экосистемы Intuit и отображение данных в интерфейсе Gmail, было готово всего за несколько часов.
  3. Сценарий приложения автоматически переносится в клиентский и серверный код. Таким образом, весь шаблонный код связи между браузером и сервером полностью исключен! Уже предоставлен набор базовой библиотеки виджетов (текстовые поля, флажки, раскрывающиеся списки, метки, кнопки и т. Д.). Эта библиотека постоянно расширяется за счет частых выпусков с большим количеством виджетов и функций.
  4. Сделайте возможным приложение, которое можно по-настоящему написать и запустить для всех! Просто напишите код один раз, и тот же код будет работать в браузере И в собственных приложениях Gmail для iOS + Android! Не нужно беспокоиться о различных форм-факторах / версии ОС / разрешении.
  5. Обеспечивает очень хорошую реализацию библиотеки OAuth с выделенным хранилищем токенов oauth. Просто сконфигурируйте и используйте, исключает написание стандартного кода для oauth.
  6. Имеет прямой доступ к другим функциям Google (возможность отправлять электронную почту, хранить на диске, получать доступ к GCP и т. Д.).
  7. Предоставляет изолированную среду / IDE на основе браузера с полным кодом для разработки.
  8. Обеспечивает быстрое хранилище / кеш для хранения параметров уровня приложения и уровня сеанса (полезно для безопасного сохранения токенов, настроек, состояния).
  9. Легко выпустить новую версию, которая автоматически распространяется среди всех пользователей.

Помните, как я уже упоминал, сценарий приложения Google основан на Javascript спецификации ECMA 3? Вот где они расходятся ..

  1. Скрипт приложения Google переносится в серверный / клиентский код, поэтому разработчики ограничены в средствах управления пользовательским интерфейсом, предоставляемых Google. Это дополнительно означает, что пользователь не может напрямую манипулировать элементами DOM или даже прослушивать или генерировать события браузера. Все взаимодействие с пользователем осуществляется через предварительно заданные обратные вызовы. Это означает, что как разработчики мы не можем динамически изменять пользовательский интерфейс и предоставлять только проверки / обновления на стороне клиента. Большинство взаимодействий требует отключения сервера.
  2. Скрипт Google App не может отправлять асинхронные HTTP-запросы к какому-либо внешнему API. Все http-вызовы блокируемые и синхронные. Это имеет большое влияние на дизайн кода. В отличие от обычного javascript, разработчики не могут просто запустить событие xhr и обновить результаты при обратном вызове. Все переходы пользовательского интерфейса останавливаются, пока не будут получены результаты.
  3. Все функции, определенные в пакете скриптов приложения Google, являются глобальными, и интервалы между именами отсутствуют.
  4. Поскольку это не чистый javascript, невозможно повторно использовать существующую библиотеку javascript как есть.

Как любой хороший инженер, мы любим сложные задачи, и этот проект дал им много.

  1. Повторное использование. В Intuit у нас есть несколько библиотек, обрабатывающих сложную бизнес-логику, которые мы повторно используем в проектах. И мы хотели использовать некоторые из них и в этом проекте. Однако все эти библиотеки основаны на ES5 / 6 и по умолчанию не совместимы с Google App Script. Чтобы избежать переписывания и постоянного наверстывания при выпуске новой версии этих библиотек, команда придумала инновационный способ решения проблемы. На первом этапе эти библиотеки проходят через babel для преобразования в ES3, а затем через rollup для экспорта всех функций в глобальное пространство имен. Это упростило нам прямое повторное использование этих библиотек.
  2. Контроль версий / Быстрое развертывание - Google предоставляет изолированную среду на основе браузера для разработки. Изменения происходят мгновенно по мере изменения кода. Однако не существует заранее определенного способа развития на местном уровне. Отсутствие локальной разработки означает отсутствие преимуществ полного управления исходным кодом (ветвление, слияние, перехватчики сборки, запросы на вытягивание, обзоры и т. Д.). Чтобы обойти эту проблему, мы решили разработать локально в среде IDE и использовать репозиторий Intuit на github. Однако это по-прежнему означало, что нам нужно будет вручную скопировать код вставки в песочницу Google, чтобы иметь возможность запускать его и проверять поведение. Теперь подумайте обо всех различных средах (qa, e2e, stage) и умножьте эти ручные усилия во много раз. Не похоже, чтобы продуктивное время использовалось правильно. Так что еще одна прекрасная возможность автоматизировать. Команда нашла пакет узла, который развертывает код на серверах скриптов приложений Google и интегрируется как скрипт npm. Теперь команда могла свободно разрабатывать на локальной машине, запускать тесты и напрямую развертывать на серверах Google с помощью простых команд npm в разных средах. Чтобы упростить работу (зачем тратить несколько секунд на запуск npm, если нам это не нужно), мы добавили наблюдатель файлов, который запускал сценарий развертывания, как только любой файл в исходной папке был сохранен. Тот же сценарий npm использовался для развертывания через jenkins.
  3. Модульное тестирование. Поскольку скрипт приложения Google загружает все функции javascript в едином общедоступном пространстве имен (что несовместимо с подходом node.js, где модуль представляет собой строго один файл, а содержимое является частным, default), нам нужен был новый способ написания модульных тестов при использовании инфраструктуры узлов. Для этой команды попался gas-local, который загружает все функции в едином контексте. Эта библиотека также предоставляла возможность насмешек.
  4. Автоматизация. Для автоматизации процесса развертывания мы хотели следовать стандартной практике выполнения модульных тестов и развертывать их на серверах Google только в том случае, если они проходят успешно. Использование сценариев npm упростило задачу. Прежде чем развертывание начнется, наш сценарий npm сначала запускает сценарии модульного тестирования и отправляет их на серверы Google, если они проходят.
  5. Регистрация ошибок - в Intuit мы всегда опережаем ошибки. Мы хотим иметь возможность исправлять проблемы до того, как клиенты сообщат о проблеме. Однако прямого способа получить журналы на серверах Intuit не было. По умолчанию скрипт Google App предоставляет журналы только последнего сеанса. Мы могли бы использовать конечную точку HTTP для журналов splunk и post с помощью HTTP, но это привело бы к снижению производительности приложения (помните, что в сценарии Google App все HTTP-вызовы синхронны) .Чтобы решить эту проблему, изначально мы думали о хранении журналов в хранилище сеанса и использовании таймера (который запускает async) для чтения и отправки журналов на серверы Intuit. Однако даже этот вариант не был оптимальным, поскольку было ограничение на количество символов в хранилище сеанса, а api таймера планировалось исключить. Наконец, мы смогли установить путь от скрипта Google App к Stackdriver (облачная платформа ведения журналов Google) и оттуда к серверам pub / sub Google и извлекать журналы на наши splunk-серверы из очередей Pub / Sub. Путь к получению журналов на наш сервер был долгим, но он решил нашу проблему асинхронной отправки журналов на серверы Intuit. Плюс дополнительный бонус в том, что мы можем агрегировать журналы из нескольких учетных записей предварительной подготовки в одну очередь публикации / подписки и устанавливать только один канал между серверами Intuit splunk и подпрограммой Google pub.
  6. Отслеживание использования. Не только ошибки, мы фанатично собираем совокупные показатели использования нашего приложения и отслеживаем потенциальные точки прерывания или шаги, на которых пользователь застревает. Опять же, не было прямого способа отправить эти данные из сценария приложения на наши аналитические серверы. Для этого мы следовали шаблону журнала. Наше приложение отправляет специально отформатированное сообщение в stackdriver, которое направляет его в отдельную очередь pub / sub. Затем мы развернули специальную облачную функцию Google, которая прослушивает очередь и отправляет ее на наши аналитические серверы.

Последние мысли

Этот проект бросал вызов уникальным задачам, в которых наших традиционных корпоративных инструментов CI / CD было недостаточно. Не только команде нужно было создать продукт, но и создать инструменты для создания и развертывания продукта. За очень короткое время команда собрала набор инструментов, чтобы добавить недостающую функциональность и утроить продуктивность разработчика.

Я надеюсь, что этот пост в блоге будет полезен любой команде, начинающей разработку скрипта Google App. Хотелось бы узнать, столкнулись ли вы с подобными проблемами и как вы их решили.

Если вам интересно, как выглядит приложение, приложение QuickBooks Invoicing уже доступно в магазине приложений Google. Дайте ему вращение.

С помощью: Джона Каллахана