Обзор

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

  • Я предпочитаю использовать один язык программирования. В моем случае ответом является JavaScript (TypeScript также будет работать в этом же стеке).
  • Я хочу создавать клиенты для нескольких платформ (например, для Интернета, мобильных устройств, компьютеров), но у меня нет времени или желания создавать каждый из них в виде отдельного проекта.
  • Я не хочу тратить бесчисленное количество часов на создание компонентов пользовательского интерфейса.
  • Я хочу использовать преимущество PaaS с низкими или бесплатными затратами во время разработки и на ранних этапах моего проекта.
  • Мне нужна возможность автоматического развертывания всего стека, когда я нажимаю коммиты кода.

Платформа как услуга 🔥

Я использую Firebase (созданный на основе Google Cloud Platform), который предоставляет услуги веб-хостинга, аутентификации, базы данных (NoSQL и Realtime), хранения файлов, бессерверных функции, ведение журнала, аналитика, push-уведомления и многое другое!

Firebase — очень жизнеспособная платформа для стартапов…

У меня есть одно приложение с ~ 500 пользователями, и я ничего не плачу в месяц. У меня есть другие приложения с меньшим количеством пользователей, и в целом я плачу около 0,30 доллара в месяц. Очевидно, что затраты относительны и могут быстро увеличиваться в зависимости от популярности приложения, независимо от платформы. Я считаю, что Firebase — очень жизнеспособная платформа для стартапов с точки зрения затрат (и функциональности).

Клиент 👩‍💼

Что касается клиента (клиентов), мне нравится Quasar Framework (построенный на Vue.js), главным образом потому, что я могу собрать всех клиентов из одного кодовая база (например, SPA, PWA, SSR, собственный iOS, собственный Android, собственный Windows, собственный macOS, родной Linux, расширения для браузера…). Quasar также предоставляет фантастическую встроенную библиотеку компонентов пользовательского интерфейса и множество других полезных подключаемых модулей, расширений и вспомогательных функций.

Сборки веб-клиента развертываются в службе Firebase Hosting. Я размещаю свой код на GitHub и использую GitHub Actions для автоматизации развертывания в Firebase.

Собственные клиентские сборки развертываются в соответствующем магазине приложений с использованием собственного процесса каждого магазина (например, я развертываю приложения iOS с помощью XCode). Quasar делает процесс сборки относительно простым благодаря встроенной поддержке Cordova, Capacitor и Electron.

Все, кто хочет узнать больше о Quasar Framework, могут посмотреть это обучающее видео от любимца сообщества Создание приложений с Дэнни:

Маркетинг (www) 🌐

Если применимо, я создаю маркетинговый сайт в отдельном проекте Quasar и создаю его как рендеринг на стороне сервера (SSR), чтобы получить преимущества SEO; однако чаще всего я просто включаю эти страницы как часть своего приложения и позволяю пользователям «запускать» приложение с помощью кнопки призыва к действию.

Я создаю общедоступные маршруты, макеты и страницы для создания анонимного контента, когда пользователи посещают «https://www.myappdomain.app».

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

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

Документация 📖

Я могу создать документацию, встроенную в мой клиент (используя Quasar расширение приложения QMarkdown); однако, поскольку я могу развертывать обновления отдельно, я обычно создаю отдельный проект документации, используя либо другой проект Quasar, либо что-то вроде VuePress.

При использовании отдельного проекта документации я обычно развертываю его на GitHub Pages, используя собственный поддомен, например https://docs.myappdomain.app.

Сервер 🌀

Я создаю серверный проект, используя Node/Express и Firebase Admin SDK. Развертывание сервера в Firebase Functions дает мне возможность создавать REST API, триггеры публикации/подписки, триггеры обновления базы данных и запланированные триггеры.

ПРИМЕЧАНИЕ. Для тех из вас, кто знаком с Firebase SDK, ведутся споры о том, лучше ли делать вызовы Firebase напрямую из клиента или чтобы сервер выполнял вызовы Firebase и предоставлял клиенту RESTful API. Для того и другого есть веские причины, и, скорее всего, вам понадобится смесь. Я использовал оба подхода в проектах и ​​предпочитаю использовать сервер, когда это возможно, и делать вызовы непосредственно к Firebase с клиента только в случае крайней необходимости.

Примеры случаев, когда необходимо использовать клиентский SDK Firebase:
1) вход с использованием методов аутентификации Firebase, таких как Google или Facebook
2) загрузка файлов в хранилище Firebase
3) использование Firebase Analytics для захвата клиентского трафика

Структура проекта

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

MyProject
  L client           // Quasar project
    L src            // Quasar code (for all platforms)
    L src-*          // auto-created when platforms added
    L ...            // other platforms added
    L dist
      L *            // Web client builds
    L quasar.conf.js // Quasar configuration
    L package.json   // scripts to run, build, deploy client(s)
  L docs           // Quasar or VuePress project
    L src          // Document markdown files
    L package.json // scripts to run, build, deploy docs
  L server
    L functions    // Node/Express project
      L index.js   // code starts here
    L package.json // scripts to run, build, deploy server
  L .git         // local "monolythic" repo
  L .github      // GitHub actions
  L package.json // scripts to run, build, deploy all

Заключение

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

У всех опытных full-stack разработчиков есть свое мнение. Каждый подходит к этому с разных точек зрения и уникальных ограничений.

Для меня этот «самоуверенный» технологический стек стал результатом множества проб и ошибок и до сих пор не подводил меня. По крайней мере, это стоит исследовать, когда вы пытаетесь найти свой собственный «утвержденный» технологический стек! Удачи! 👍

Надеюсь это поможет! Я с нетерпением жду ваших комментариев!