Обсуждение тем по Метеору редко встретишь среди русскоговорящих (судя по каналу в телеге и паблике вк, Хабр). Обмен опытом возможен, но по большей части на официальном форуме метеора.
На Хабре уже давно не было статей по Метеору, поэтому хотелось бы поделиться нашей историей.
Расскажу про наш проект, как мы пришли к Meteor и как на нем летаем. Постараюсь не углубляться в детали или очень специфические вещи — их оставлю на обсуждение, либо отдельную статью.
У нас онлайн школа программирования для детей. PolinaV написала статью про то, как мы делаем это онлайн. В начале 2018 года мы начали активно разрабатывать свою систему — Гену.
Гена был нужен нам по нескольким причинам:
Для первой версии мы выделили ключевой функционал:
Мы посчитали количество пользователей, а так же объем данных, который будет сгенерирован. Эта информация и примерный план развития помогли нам заложить будущую архитектуру Гены.
Я попробовал Метеор в 2016 году, когда нужно было сделать пару простых прототипов. На тот момент у меня были навыки C#(но не ASP), PHP и немного JS.
Хотелось иметь один язык для фронта и бэка, чтобы не усложнять проект и не дублировать логику (возможно, я немного соврал насчет простых прототипов:)). Поэтому решил выбрать только JS, а к нему NodeJS и MongoDB.
Для меня, как и для героя из этой статьи, веб разработка была кучей непонятных названий. А так как опыт разработки уже имелся, я понимал, что есть готовые решения, которые позволяют «просто делать работу», не заморачиваясь об остальном.
Не помню, как был найден Meteor, но он меня подкупил несколькими вещами:
После реализации нескольких прототипов, я начал следить за развитием Метеора, изучать внутренности и пилить мелкие проекты для себя.
И вот настал черед выбора инструмента для реализации Гены. Опущу подробности поиска других инструментов, оставлю доводы в пользу метеора:
Отдельно скажу про Blaze — намеренно взял более простое решение, чтобы не тратить время на изучение более сложных React/Vue (да, не впрыгнули в хайп трейн).
Для ведения задач и документации используем Jira + Confluence. Код поселили в Bitbucket.
В итоге сложилось такое мнение:
После выбора инструмента началась фаза реализации задуманного. Мы не всегда до конца продумываем требования, поэтому порой приходится переделывать фичу несколько раз. Так же у нас очень много идей, и мы стараемся как можно скорее выкатить и потестить их на реальных пользователях.
Структура проекта (структура папок и файлов) помогает избежать вопросов что и где должно лежать. Об этом написано в документации. Писать легко поддерживаемый и расширяемый код проще, когда есть четкое разделение. UI функционал разбит на компоненты, что позволяет изолировать функциональные блоки и переиспользовать их, а при рефакторинге не ломаешь пол проекта:).
Существует много готовых пакетов, которые решают определенные задачи. Например, из коробки Метеор предоставляет аккаунт менеджмент(регистрация, авторизация и т.д.), отправку Email. Сторонние решают другие задачи. Часть из них является прослойкой для npm пакетов, поэтому база готовых решений очень большая.
Моей ошибкой было отказаться от тестов. Решение это было связано с тем, чтобы сэкономить время, ведь «клиенты тесты не видят». Однако наблюдая ситуацию с возникающими багами в Jire понял, что пора менять подход. Вернули тесты и начали писать по TDD. Вдобавок, после попадания кода в develop ветку, начали запускать тесты через CircleCI, чтобы убедиться, что никто ничего не сломал.
Для поддержания Code Style настроили ESLint + prettier. Это позволяет избежать правок по стилю и нелепых ошибок на этапе рассмотрения PR(pull request). А чтобы «плохой» код не дошел до гита, был настроен Husky — инструмент, который умеет выполнять необходимые задачи на этапе коммита (и не только). Таким образом, перед попаданием кода в коммит, он проходит проверку через eslint и prettier.
Стоит отдельно упомянуть про важный минус — скорость сборки проекта. Первый раз сборка занимает примерно 30 секунд, в зависимости от железа. Далее, при изменении кода, процесс занимает примерно 5-10 секунд. На слабом железе числа могут быть больше. Я пользуюсь MacBook pro mid 15, i7, 16gb, мне норм.
Гену решили запустить на Digital Ocean. Причина одна — цена. Официальный хостинг для метеора дорогой. AWS дешевле, но сложнее, чем DO. Есть и другие альтернативы, но остановились на DO.
На данный момент у нас одновременно может быть до 100 пользователей, подключенных к Гене. Это не так много, но и запас прочности у нас большой. Рассчитываем выдержать 1000CCU на текущей конфигурации.
Пока нам хватает двух 10$ серверов + 5$ прокси (для балансировки). Каждый сервер — это nodejs app + MongoDB. Отдельно запущен сервер для мониторинга. Рост трафика у нас прогнозируемый, поэтому развернуть новые сервера успеем (поднять дроплет и дописать строчку в upstream).
Выливать новую версию Гены — одно удовольствие. Для этого был написан небольшой скрипт, который собирает проект в tar (командой meteor build), заливает на сервера, распаковывает, выполняет npm i и запускает демона. Обычно это занимает 1 минуту.
Если опустить подробности, то примерно так (если будет интересно, подготовлю gist):
За Геной наблюдаем через Kadira (картинка в начале поста). Пришлось немного потанцевать с бубном чтобы запустить на своих мощностях, но оно того стоило. Все наглядно и понятно.
Со стабильностью проблем еще не было. Случайных сбоев или утечек памяти не наблюдается.
Гену мы запустили через пол года после старта. Команда выросла, как и Гена. Скорее всего, мы перерастем монолит и появятся микросервисы, очереди, отдельные пакеты и т.д. Но это уже совсем другая история…
Метеор меняется. Тем, кто пробовал его на версии 1.4 и ниже, рекомендую посмотреть список изменений. Надеюсь, вы будете приятно удивлены.
Список полезных материалов по Метеору:
Кто работает с метеором или заинтересован — присоединяйтесь к нашему чатику в телеграмме.
Прошу прощения, если не раскрыл каких-то важных тем, постараюсь ответить в комментариях.
На Хабре уже давно не было статей по Метеору, поэтому хотелось бы поделиться нашей историей.
Расскажу про наш проект, как мы пришли к Meteor и как на нем летаем. Постараюсь не углубляться в детали или очень специфические вещи — их оставлю на обсуждение, либо отдельную статью.
О проекте
У нас онлайн школа программирования для детей. PolinaV написала статью про то, как мы делаем это онлайн. В начале 2018 года мы начали активно разрабатывать свою систему — Гену.
Гена был нужен нам по нескольким причинам:
- большое количество различных инструментов — excel, сервис для ведения расписаний, формы и т.д.;
- работать с инструментами по отдельности было не удобно.
Для первой версии мы выделили ключевой функционал:
- управление расписанием;
- управление учениками / тренерами;
- управление внутренними задачами.
Мы посчитали количество пользователей, а так же объем данных, который будет сгенерирован. Эта информация и примерный план развития помогли нам заложить будущую архитектуру Гены.
Гена и Meteor
Я попробовал Метеор в 2016 году, когда нужно было сделать пару простых прототипов. На тот момент у меня были навыки C#(но не ASP), PHP и немного JS.
Хотелось иметь один язык для фронта и бэка, чтобы не усложнять проект и не дублировать логику (возможно, я немного соврал насчет простых прототипов:)). Поэтому решил выбрать только JS, а к нему NodeJS и MongoDB.
Для меня, как и для героя из этой статьи, веб разработка была кучей непонятных названий. А так как опыт разработки уже имелся, я понимал, что есть готовые решения, которые позволяют «просто делать работу», не заморачиваясь об остальном.
Не помню, как был найден Meteor, но он меня подкупил несколькими вещами:
- простота установки / настройки. Одна команда в консоле — и он твой;
- готовый канал передачи данных (WebSocket + DDP);
- встроенная БД — MongoDB (+minimongo);
- простой инструмент для написания UI — Blaze;
- неплохая документация и статьи/видео по теме.
После реализации нескольких прототипов, я начал следить за развитием Метеора, изучать внутренности и пилить мелкие проекты для себя.
И вот настал черед выбора инструмента для реализации Гены. Опущу подробности поиска других инструментов, оставлю доводы в пользу метеора:
- как писал выше — все в одной коробке;
- можем пожертвовать производительностью и потреблением ресурсов взамен удобству разработки;
- хотим быстро получать новые фичи, чтобы потом их либо улучшить, либо выкинуть;
- можно за небольшой промежуток времени (2-3 дня) подключить JS разработчика к проекту;
- имеется база готовых пакетов.
Отдельно скажу про Blaze — намеренно взял более простое решение, чтобы не тратить время на изучение более сложных React/Vue (да, не впрыгнули в хайп трейн).
Для ведения задач и документации используем Jira + Confluence. Код поселили в Bitbucket.
В итоге сложилось такое мнение:
- если у тебя что-то очень простое, бери сырой JS/CSS/HTML и делай (лендинг, например);
- если есть специфические требования к производительности, ресурсам, функциям — ищи;
- в остальных случаях — бери готовый фреймворк, например, Meteor. Если правильно «готовить», то проблем возникнуть не должно.
Процесс разработки
После выбора инструмента началась фаза реализации задуманного. Мы не всегда до конца продумываем требования, поэтому порой приходится переделывать фичу несколько раз. Так же у нас очень много идей, и мы стараемся как можно скорее выкатить и потестить их на реальных пользователях.
Структура проекта (структура папок и файлов) помогает избежать вопросов что и где должно лежать. Об этом написано в документации. Писать легко поддерживаемый и расширяемый код проще, когда есть четкое разделение. UI функционал разбит на компоненты, что позволяет изолировать функциональные блоки и переиспользовать их, а при рефакторинге не ломаешь пол проекта:).
Существует много готовых пакетов, которые решают определенные задачи. Например, из коробки Метеор предоставляет аккаунт менеджмент(регистрация, авторизация и т.д.), отправку Email. Сторонние решают другие задачи. Часть из них является прослойкой для npm пакетов, поэтому база готовых решений очень большая.
Моей ошибкой было отказаться от тестов. Решение это было связано с тем, чтобы сэкономить время, ведь «клиенты тесты не видят». Однако наблюдая ситуацию с возникающими багами в Jire понял, что пора менять подход. Вернули тесты и начали писать по TDD. Вдобавок, после попадания кода в develop ветку, начали запускать тесты через CircleCI, чтобы убедиться, что никто ничего не сломал.
Для поддержания Code Style настроили ESLint + prettier. Это позволяет избежать правок по стилю и нелепых ошибок на этапе рассмотрения PR(pull request). А чтобы «плохой» код не дошел до гита, был настроен Husky — инструмент, который умеет выполнять необходимые задачи на этапе коммита (и не только). Таким образом, перед попаданием кода в коммит, он проходит проверку через eslint и prettier.
Стоит отдельно упомянуть про важный минус — скорость сборки проекта. Первый раз сборка занимает примерно 30 секунд, в зависимости от железа. Далее, при изменении кода, процесс занимает примерно 5-10 секунд. На слабом железе числа могут быть больше. Я пользуюсь MacBook pro mid 15, i7, 16gb, мне норм.
Гену решили запустить на Digital Ocean. Причина одна — цена. Официальный хостинг для метеора дорогой. AWS дешевле, но сложнее, чем DO. Есть и другие альтернативы, но остановились на DO.
Полет
На данный момент у нас одновременно может быть до 100 пользователей, подключенных к Гене. Это не так много, но и запас прочности у нас большой. Рассчитываем выдержать 1000CCU на текущей конфигурации.
Пока нам хватает двух 10$ серверов + 5$ прокси (для балансировки). Каждый сервер — это nodejs app + MongoDB. Отдельно запущен сервер для мониторинга. Рост трафика у нас прогнозируемый, поэтому развернуть новые сервера успеем (поднять дроплет и дописать строчку в upstream).
Выливать новую версию Гены — одно удовольствие. Для этого был написан небольшой скрипт, который собирает проект в tar (командой meteor build), заливает на сервера, распаковывает, выполняет npm i и запускает демона. Обычно это занимает 1 минуту.
Если опустить подробности, то примерно так (если будет интересно, подготовлю gist):
скриптик
#локально
meteor build --architecture=os.linux.x86_64 --server-only $BUILD_PATH
scp $TAR_FILE_PATH $SERVER_APP_PATH
#на сервере
cd $APP_ROOT
rm -r bundle
tar -xzf $TAR_NAME
cd $APP_ROOT/bundle/programs/server/ && npm i -q
cd $APP_ROOT/bundle
sudo forever-service install $SERVICE_NAME --script $APP_ROOT/bundle/main.js --envVars "$ENV_VARS"
sudo service $SERVICE_NAME start
За Геной наблюдаем через Kadira (картинка в начале поста). Пришлось немного потанцевать с бубном чтобы запустить на своих мощностях, но оно того стоило. Все наглядно и понятно.
Со стабильностью проблем еще не было. Случайных сбоев или утечек памяти не наблюдается.
Заключение
Гену мы запустили через пол года после старта. Команда выросла, как и Гена. Скорее всего, мы перерастем монолит и появятся микросервисы, очереди, отдельные пакеты и т.д. Но это уже совсем другая история…
Метеор меняется. Тем, кто пробовал его на версии 1.4 и ниже, рекомендую посмотреть список изменений. Надеюсь, вы будете приятно удивлены.
Список полезных материалов по Метеору:
Кто работает с метеором или заинтересован — присоединяйтесь к нашему чатику в телеграмме.
Прошу прощения, если не раскрыл каких-то важных тем, постараюсь ответить в комментариях.
