Давайте все согласимся с одной вещью: Писать бэкэнды сложно, и мы отстой.
Да, конечно, мы все отлично в создании нашего Express Server, с нашим MongoDB или MySQL к нему, но что происходит после?
Вы уверены, что ваш специальный сервер готов, когда ваше приложение начнет успешно? Да, вы можете оптимизировать свой сервер, укрепить свой Linux, удалить ненужные пакеты, службы остановки и т. Д. В какой -то момент вам нужно будет увеличить свой сервер, купить более дорогой. Но что, если это нужно только в тот момент, когда на ваш сайт приходит высокий приток пользователей? Вы понижаетесь, чтобы снизить свои бюджеты? Вы продолжаете платить за сервер? Вы даже думали о добавлении балансировщика нагрузки?
Решение очевидно: без сервера и облако !!!! 1! Один!
К сожалению, это не реальность. Почему бы и нет? Потому что это просто больше, чтобы учиться, и это не похоже на изучение новой библиотеки/инструмента, это тонна информации . Вы уже рассматривали свое облако? AWS, Azure, Google Cloud Platform?
Предположим, вы выбрали AWS, вот еще несколько вопросов: вы используете DynamoDB? Или Аврора? Вы знаете, как запросить эти базы данных? Есть ли какие -нибудь ORM для вашего языка+базы данных? Вы развертываете всю эту инфраструктуру вручную? Или вы используете что -то вроде Terraform или Server без сервера? Кстати, насколько вам удобно с Yaml? 😂
Мало того, теперь ваш код выполняется в отдельном функции Анкет Не пробуйте упаковать весь ваш экспресс -сервер. Ну, по крайней мере, если вы цените свой кошелек 😅
Вы уже думали об архитектуре для вашего приложения? Будете ли вы передавать разные части вашего приложения через очередь? Вы будете делать прямые звонки? Вы собираетесь хранить вещи в базе данных напрямую? Или это будет действовать больше как кеш? 🤔
Кроме того, помните, что вы должны создать правильный SDK на фронте, чтобы взаимодействовать с бэкэнд.
ОЙ! Я почти забыл! Вы собираетесь добавить аналитику в свое приложение? Потому что было бы хорошо, если бы вы подумали об этом в этот момент, где вы можете начать собирать данные с самого первого дня.
И как последнее примечание: удачи Поддержание этого Анкет 👌
Вы можете быть одним из тех людей, которые видят текст выше и думают «и в чем проблема со всем этим? Это часть путешествия, я в порядке, проводя 95% своего времени, изучая все это и поддерживая его, я разработчик ».
Извините, но в этом случае вам не хватает много хороших вещей.
Я думаю, что мы все согласны с тем, что возиться с указателями и регистрами — это не что -то с национального ежедневного развития. Конечно, существует этот небольшой процент людей, которые делают это, чтобы оптимизировать скорость своей системы, но это не подавляющее большинство из нас. Почему? Из -за скорости развития.
Использование этих вещей было абстрактно для нас, поэтому мы пишем меньше кода, который не имеет значения, и пишем больше кода, который имеет значение: Тот, который делает наше приложение другим
То же самое с шрифтами, вы не разрабатываете шрифт каждый раз для вашего приложения, а скорее выбираете тот, который подходит лучше всего для использования.
Что, если я скажу вам, что есть способ абстрагировать все эти трудные вещи, касающиеся развития бэкэнд, и просто сосредоточиться на том, что имеет значение в этом коде, который отличает ваше приложение?
Booster — это рамка TypeScript, дистиллированная из многолетнего опыта работы с такими компаниями, как eBay, PayPal, аренда взлетно -посадочной полосы или Zara. Люди в Agile Monkeys Устал постоянно изобретать колесо и создал максимальную бэкэнд -структуру.
Предпосылка проста: Упростить жизнь разработчиков.
Итак, что делает Booster особенным?
Это:
- Не требует предварительных знаний о развитии бэкэнд.
- Освобождает вас от размышлений о серверах.
- Устраняет необходимость настройки базы данных.
- Избегает настройки конечных точек.
- Развертывает в вашем любимом облаке, не прочитав их документы.
- Удаляет любые расходы для вашего развернутого приложения, пока вы не используете его.
- Имеет встроенный сбор данных аналитики для вашего приложения.
- Расширяется с плагинами на случай, если вы Действительно Хочу что -нибудь настроить (мы называем эти ракеты ).
Кроме того, вам не нужно думать в архитектурах, Бустер уже думал, что извлечен из предпринимаемых проектов выше и многих других.
Хорошо, как его использовать?
Я не буду слишком глубоко вдаваться в реальное использование, потому что это не учебник, но я покажу вам достаточно, чтобы увидеть, что происходит, когда вы работаете с Booster.
Когда вы используете бустер, вы много взаимодействуете с повышение CLI инструмент, который идет с ним. У Booster есть крошечный код шаблона, но вы не хотите писать даже этот.
Как настроить их приложение? Это волшебство, ты не делаешь! Единственное, что вам нужно сделать, это написать свое приложение вокруг следующих концепций:
Команды
Команда — это класс с некоторыми полями, которые представляют заказ для вашей системы, а также ручка Метод, который будет проверять эти поля, регистрируя некоторые события (мы поговорим о них в следующем разделе). Примерами команд, как правило, является продолжение предложения «Пользователь может …», например::
- Пользователь может депонировать деньги
- Пользователь может послать сообщение
- Пользователь может Создать чат
Как выглядит команда на практике? Просто код TypeScript, и самое главное, в том, что большая часть его автогенерируется! С командой, как Boost New: Command DepositMoney -Fields AccountId: UUID Сумма: номер Вы получите файл под SRC/Команды со следующим содержимым:
@Command({
authorize: ...
})
export class DepositMoney {
constructor(
readonly accountId: UUID,
readonly amount: number
) {}
public async handle(register: Register): Promise {
register.events(...)
}
}
Теперь вы указали бы, кто может выполнить эту команду во второй строке, напишите свой код проверки внутри ручка метод и зарегистрируйте события. ЭТО ОНО! Никаких методов HTTP, нет конечных точек маршрутизации, глубоких контроллеров или как бы ни был важный код.
События
То же, что и команды, код событий автогенерируется с командой в вашем терминале, они также являются обычным классом TypeScript.
Помните, когда я сказал, что ваше приложение уже объединяет сбор данных для аналитики? Это из -за событий! Вместо изменения вашей базы данных, выполнения запросов и т. Д. Вы просто представляете это изменение как событие. Бустер будет хранить все эти события бесконечно, что означает, что в любое время вы можете проверить, какие шаги сделал пользователь, чтобы вызвать эту ошибку, посмотрите, бросают ли эти пользователи процесс регистрации из -за UX или ошибки, подумайте о том, как это Оптимизируйте новые функции и многое другое!
Примерами событий являются факты, о которых вы можете заявить после команды, многие из них довольно очевидны:
- Депозит выполнен
- Сообщение отправлено
- Комната создана
(Обратите внимание на ed )
Недавно созданное событие Booster выглядит так:
@Event
export class DepositPerformed {
public constructor(
readonly accountId: UUID,
readonly amount: number
) {}
public entityID(): UUID {
return this.accountId
}
}
Сущности
Предприятия являются внутренним состоянием вашего приложения, но вы не изменяете его. Вместо этого Бустер делает что -то вроде Array.reduce В этот бесконечный список событий, которые у вас есть, преобразовать их в осязаемый объект. У сущностей много применений, но наиболее важным является снимок, поэтому ваш бэкэнд Быстро Анкет
Примерами сущностей являются концепции в вашем приложении, такие как:
- банковский счет
- Беседа
- Чат
Вот сущность, которая вычисляет его баланс из Депозитформирован событие, инициализация баланс к 0 В случае, когда учетная запись еще не существует:
@Entity
export class BankAccount {
public constructor(
readonly id: UUID,
readonly balance: number
) {}
@Reduces(DepositPerformed)
public static reduceDepositPerformed(event: DepositPerformed, current?: BankAccount): BankAccount {
const currentBalance = current?.balance ?? 0 // ^-- Note how this is optional, because at the beginning of your app, the account doesnt exist
return new BankAccount(
currentBankAccount.id,
currentBalance + event.amount
)
}
}
Читать модели
Читать модели — это то, как вы подвергаете свои сущности общественности. Читать модели действуют как кэш, чтобы убедиться, что ваше приложение получает данные как можно скорее. Кроме того, они позволяют вам объединять различные сущности и преобразовать данные так, чтобы это имеет смысл для вашего блюда. Опять же, обычный класс TypeScript:
@ReadModel({
authorize: ...,
})
export class AccountReadModel {
public constructor(
public id: UUID,
readonly balanceMessage: string,
) {}
@Projects(BankAccount, 'id')
public static projectBankAccount(entity: BankAccount, current?: AccountReadModel): AccountReadModel {
let message = "Broke"
if (entity.balance > 1000) {
message = "Has sum money here, yo"
} else if (entity.balance > 10000) {
message = "Hey, this person is saving for sumthin'"
} else if (entity.balance > 100000) {
message = "Whoah, they gonna buy a house or what?"
} else if (entity.balance > 1000000) {
message = "They got a shit ton of money, yo!"
}
return new AccountReadModel(entity.id, message)
}
}
Вот и все!
Теперь, чтобы развернуть это, вы просто пишете Boost Deploy -e Производство Анкет
ВОТ И ВСЕ. ПЕРИОД.
Нет конфигурации, нет панелей управления, нет yaml, ничего! Просто нажмите одну чертов кнопку, и у вас есть приложение, развернутое в облаке
Вы правильно настроили свое облако со всеми мерами безопасности, архитектурой, соединением услуг и т. Д.
Booster выплевывает URL, который представляет собой конечную точку GraphQL для вас, и все.
Верно, но как мне подключить это к своему фронталу?
Поскольку это graphql, вы можете идеально использовать библиотеку, подобную Аполлон Чтобы подключить его.
Использование React? Vue? СВОВА? Вяз? Нет проблем, просто используйте адаптер Аполлона для одного из них. Не нужно писать SDK/услуги для разговора с бэкэнд.
Команды могут быть выполнены с помощью мутаций, модели чтения могут быть запрошены или подписаны. Вот и все, нет необходимости кодировать URL -адреса, запомнить заказы параметров, создавать документацию API с Swagger и т. Д. Просто используйте то, что вы кодировали.
Это слишком хорошо, чтобы быть правдой, это должно стоить дорого, верно?
Нет, структура абсолютно бесплатна для использования и открытого исходного кода. Если вы беспокоитесь о затратах на облако, все бустерные проекты имеют право на бесплатный уровень AWS, и даже без него за 40 000 (это сорок тысяч, кстати) за запросы за один месяц, вы заплатите менее одного доллара.
(Нет, команда не получает никакого сокращения от облачных провайдеров, нам просто надоела инструменты, которые создают проблемы вместо того, чтобы решать их 😉)
Если вы достигли до сих пор, поздравляю и спасибо! В настоящее время каркасы появляются каждый день, и люди просто закатывают глаза. Бустер действительно отличается и новатор. Чтобы узнать больше, проверьте Сайт проекта , где вы можете найти ссылки на документацию, демонстрации и многое другое.
Я также рекомендую вам присоединиться к проекту Discord Server и бросить вызов своим идеям, мыслям и вопросам. Проект — это ничто, если он остается в одном месте, и, бросая вызов ему, вы уже помогаете!
Бустер также является частью Hacktoberfest , если вы хотите внести свой вклад подмигиваю; подталкивание Анкет И даже если нет, звезда в нашем GitHub Repo будет много значить.
Следите за обновлениями!
Пусть твой день будет потрясающим, и твои бэксины легко 😉, Ник
Оригинал: «https://dev.to/boostercloud/explaining-the-hype-around-booster-framework-3cf2»