GithubHelp home page GithubHelp logo

boostercloud / booster Goto Github PK

View Code? Open in Web Editor NEW
409.0 18.0 83.0 38.62 MB

Booster Framework

Home Page: https://www.boosterframework.com

License: Apache License 2.0

JavaScript 0.91% Shell 0.10% Batchfile 0.01% TypeScript 90.46% PowerShell 0.01% CSS 0.38% MDX 8.13%
serverless cloud-native booster-framework typescript event-driven event-sourcing cqrs cqrs-es framework aws

booster's Introduction

Booster Framework

Contributor Covenant Build Status oclif License Conventional Commits Integration tests Discord Docs

What is Booster Framework?

Booster Framework is a software development framework designed to create event-driven backend microservices that focus on extreme development productivity. It provides a highly opinionated implementation of the CQRS and Event Sourcing patterns in Typescript, using DDD (Domain-Driven Design) semantics that makes business logic fit naturally within the code. Thanks to Booster, business, product, and technical teams can collaborate, sharing a much closer language.

Booster uses advanced static analysis techniques and takes advantage of the Typescript type system to understand the structure and semantics of your code and minimize the amount of glue code. It’s capable not just of building an entirely functioning GraphQL API for you, but also to build an optimal, production-ready and scalable cloud infrastructure for your application in Azure or AWS.

Combining these features, Booster provides an unprecedented developer experience. On the one hand, it helps you write simpler code, defining your application in terms of commands, events, entities, and read models. On the other hand, you don't have to worry about the tremendous amount of low-level configuration details of conventional tools. You write highly semantic code, and if it compiles, you can run it on the cloud at scale.

Booster is 100% open-source and designed with extensibility in mind. If your desired infrastructure doesn't match the existing implementations, you can easily fork and adapt them or create a new one using your infrastructure-as-code tool of preference. Booster also supports extensions (called “Rockets”) that allow users to implement additional functionalities.

If you want to help us to drive Booster forward or have questions, don't hesitate to ping us on Discord!

Why Booster instead of X?

Booster is designed to maximize developer productivity, and every framework feature is carefully thought out to put your application in production as soon as possible. The CLI helps you to get up and running quickly, and the easy-to-comprehend abstractions and the opinionated architecture make it easy to understand how to organize your code and become productive sooner.

The no-boilerplate politics goes to the extreme, as Booster understands the semantics of your code to create a fully-working GraphQL API for you, as well as an optimal serverless cloud infrastructure and database integrations. And, of course, the API and infrastructure are transparently updated when the application changes.

It would be easier to understand Booster capabilities by listing the things that you won’t need to implement or maintain with Booster:

  • You won’t need to maintain GraphQL schemas
  • You won’t need to implement GraphQL resolvers
  • You won’t have to manage URL paths
  • You won’t have to design the API schemas
  • You won’t have to deserialize or serialize JSON objects
  • You won’t need to use DTOs
  • You won’t need to deal with ORM mappings and/or database queries
  • You won’t need to write infrastructure configuration or deployment scripts
  • You won’t need to build WebSockets for subscriptions

All those things, and more, will be given to you by default and entirely for free, as Booster is open-source and runs in your own cloud account!

Current state and roadmap

The roadmap is community-driven; the core team actively participates in the Booster community, listening to real users and prioritizing those issues and ideas that provide the most value for the majority. So don't hesitate to create issues or leave comments in Discord and tell us about your questions and ideas.

AWS and Azure integrations are thoroughly tested (with unit and integration tests running automatically before every release), and are currently used in production in projects of all-sized organizations, from startups to massive enterprises.

The "Booster Way"

Booster Framework follows the next principles:

  • Play nicely: Booster is not here to replace your toolkit but to expand it. Booster's goal is to get along well with your existing auth, queues, databases, and services, providing a modern and swift tool to build new functionalities that take full advantage of the cloud. Booster is still a Node.js application that you can extend with any tool from your Node.js environment.
  • Domain Driven Design first: Software should be designed around business-level concepts to enhance the team's communication. All code in Booster is defined in terms of Commands, Events, Handlers, and Entities, limiting the need for artificial developer-only constructs.
  • CQRS and Event-Sourcing: Booster is designed around the concepts of CQRS and Event-Sourcing. This design has many advantages regarding scalability and data management. It even allows you to travel back in time!
  • The cloud is the machine: We believe that the developers' tools should create infrastructure transparently in the same way that a compiler hides the details of the target processor. We often think about Booster as the "TypeScript-to-Cloud compiler."
  • True Serverless: Serverless is about to stop caring about your servers, but many implementations still require long YAML files to describe your infrastructure, and you need to know what you're doing. True Serverless means that you don't even care about cloud configuration. Booster will figure it out for you based on the code structure you write.
  • Convention over Configuration: We prefer to provide standardized highly-opinionated modules than highly-configurable ones. This helps us to keep your code simple and follow the best practices when deploying your applications to the cloud. Decorating your classes with the provided semantic decorators also helps abstract most of the boilerplate code.
  • Don't Repeat Yourself (Extreme edition): /The only code that matters is the one that makes your application different/. We push the TypeScript structure and type system to the limit to avoid writing repetitive code, like object-to-JSON serializations, API or database schemas, or redundant architecture layers. Boster understands the semantics of your code and connects the dots.
  • Self-documenting APIs We adopted GraphQL because it's a self-documenting standard. You can grab a standard GraphQL client like ApolloClient and start using a Booster backend right away with no complicated integrations.
  • Developer productivity: Software development is fun, and a modern tool should make it even more fun, reducing the need for mundane tasks. Booster provides code generators to help you quickstart new projects and objects, and the framework types and APIs are hand-crafted to help your IDE help you.

Contributing

You can join the conversation and start contributing in any of the following ways:

Please refer to CONTRIBUTING.md for more details. Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

License

The Booster Framework is licensed under the Apache License, Version 2.0. See the LICENSE file for more details.

Resources

booster's People

Contributors

actions-user avatar adrian-lorenzo avatar adriangmweb avatar alvaroloes avatar borjazarco avatar charlietfe avatar davidverdu avatar dependabot[bot] avatar fecony avatar glammers1 avatar gonzalogarciajaubert avatar gonzalojaubert avatar itrion avatar javiertoledo avatar jfsagasti avatar juanjoman avatar jycabello avatar laiaperez88 avatar marcastr0 avatar moneyba avatar myf95 avatar nickseagull avatar otoumas avatar rdiaz82 avatar rdoria1 avatar sanskar-p avatar santigamo avatar tainguyenbui avatar thomas-advantitge avatar verogarp avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

booster's Issues

CLI: Wrong message when deleting stack `boost nuke`

Description
Given that I have a stack deployed

When I delete the stack

Then I should be notified that the stack was deleted

Information:

CLI version: @boostercloud/cli/0.1.4

Current behavior:

booster-ecommerce-application-stack: deployed message displayed when stack successfully undeployed
image

Expected behaviour:

A message that notifies me that the stack has been successfully undeployed

[CLI] flag -h which stands for homepage doesn't work in new:project command

-h flag is duplicated for both help and homepage causing an error when trying to use -h as homepage.

$ boost new:project my-project -h "https://example.com"
create a new project from scratch

USAGE
  $ boost new:project [PROJECTNAME]

OPTIONS
  -a, --author=author                            who is writing this?
  -d, --description=description                  a short description
  -h, --help                                     show CLI help
  -h, --homepage=homepage                        the website of this project
  -l, --license=license                          which license will you use?
  -p, --providerPackageName=providerPackageName  package name implementing the cloud provider integration where the application will be deployed (i.e: "@boostercloud/framework-provider-aws"
  -r, --repository=repository                    the URL of the repository
  -v, --version=version                          the initial version

ExitError: EEXIT: 0
    at Object.exit (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/errors/lib/index.js:18:11)
    at Project.exit (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/command.js:54:23)
    at Project._help (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/command.js:127:21)
    at Object.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/flags.js:37:17)
    at Parser._flags (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/parser/lib/parse.js:149:42)
    at Parser.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/parser/lib/parse.js:117:28)
    at Object.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/parser/lib/index.js:27:27)
    at Project.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/command.js:86:41)
    at Project.runWithErrors (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/dist/commands/new/project.js:14:38)
    at Project.run (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/dist/commands/new/project.js:11:21) {
  oclif: { exit: 0 },
  code: 'EEXIT'
}

The same command using the long version of the flag works:

$ boost new:project my-project --homepage "https://example.com"
? What's your project description? (default: "")

Implement GraphQL interface for Socket for Kubernetes provider

In this task, we are covering the second part of the graphQL implementation with all the stuff related to subscriptions and WebSockets. In this task, we will need to implement some additional methods from the provider interface, and also we will need to implement some mechanism to tracks the socket sessions.,Acceptance criteria

Implement GraphQL interface for REST for Kubernetes provider

In this task, we are covering the first provider functions implementation. We are going to implement some rawToEnvelope functions and the functions to save the information into the event store and perform searches in the event store. ,Acceptance criteria

Implement GraphQL interface for REST for Kubernetes provider

In this task, we are covering the first provider functions implementation. We are going to implement some rawToEnvelope functions and the functions to save the information into the event store and perform searches in the event store. ,Acceptance criteria

Create a CLI command like "boost info" to get information about the current deployed project

Right now, when we deploy a booster application, important information such us the ,baseRESTURL, or ,clientID, is shown. But after that, it is impossible to retrieve that information again (unless you go the the AWS console and dig into the resources),The command ,boost info, will fill that hole, but with the idea to be much more useful.,Ideally, ,boost info, should work to show local information (information about the current version of the code inside the root folder this command was executed) and remote information (information both general and provider-specific, about the current ,deployed) ,app.,Draft of the information it should include:,$ boost info:local -e

  • App name: "my-app"
    Information about the local version of the application

    Commands: ...
    Entities: ...
    Events: ...
    ReadModels: ...
    Roles: ...
    Migrations: ...

    GraphQL schema: ...

$ boost info:deployed -e
(The same data structure as in info:local but using the deployed app information,
plus the following:)

baseRESTURL: ...
baseWebsocketURL: ...
AWS.clientID: ...
(Any extra information we consider, we can keep adding things later)
,Why differentiating between local and deployed applications? Because they can be different, and it is very useful to see the changes your local version contain VS de deployed version. Also, during development, it is also useful to know how your changes are materialized in the GraphQL schema, for example.,This ticket can be really long so it is encouraged to be split into sub tickets, ,working on the most important information first, which is:, knowing the ,baseRESTURL,, ,baseWebsocketURL,, and ,AWS.clientID, of the ,deployed application.

Create a CLI command like "boost info" to get information about the current deployed project

Right now, when we deploy a booster application, important information such us the ,baseRESTURL, or ,clientID, is shown. But after that, it is impossible to retrieve that information again (unless you go the the AWS console and dig into the resources),The command ,boost info, will fill that hole, but with the idea to be much more useful.,Ideally, ,boost info, should work to show local information (information about the current version of the code inside the root folder this command was executed) and remote information (information both general and provider-specific, about the current ,deployed) ,app.,Draft of the information it should include:,$ boost info:local -e

  • App name: "my-app"
    Information about the local version of the application

    Commands: ...
    Entities: ...
    Events: ...
    ReadModels: ...
    Roles: ...
    Migrations: ...

    GraphQL schema: ...

$ boost info:deployed -e
(The same data structure as in info:local but using the deployed app information,
plus the following:)

baseRESTURL: ...
baseWebsocketURL: ...
AWS.clientID: ...
(Any extra information we consider, we can keep adding things later)
,Why differentiating between local and deployed applications? Because they can be different, and it is very useful to see the changes your local version contain VS de deployed version. Also, during development, it is also useful to know how your changes are materialized in the GraphQL schema, for example.,This ticket can be really long so it is encouraged to be split into sub tickets, ,working on the most important information first, which is:, knowing the ,baseRESTURL,, ,baseWebsocketURL,, and ,AWS.clientID, of the ,deployed application.

Invalid token in aws/credentials file report: "Unable to determine default account and/or region"

Environment
➜ booster_projects nvm use node
Now using node v13.3.0 (npm v6.13.1)
➜ booster_projects npm install -u -g @theagilemonkeys/booster-cli
/Users/gonzalogarcia/.nvm/versions/node/v13.3.0/bin/boost -> /Users/gonzalogarcia/.nvm/versions/node/v13.3.0/lib/node_modules/@theagilemonkeys/booster-cli/bin/run

  • @theagilemonkeys/[email protected]
    updated 10 packages in 31.947s
    ➜ booster_projects boost -v
    @theagilemonkeys/booster-cli/0.0.43 darwin-x64 node-v13.3.0

Steps to reproduce it:

  1. Create a new project
  2. Update the credentials file with an invalid token

Expected result

A meaningful message like this one:
`➜ testing serverless deploy
Serverless: Packaging service...

Serverless Error ---------------------------------------

ServerlessError: The security token included in the request is invalid.`

Result

Booster error message about the default account is fine but Serverless message points me to the token issue which is the main issue:

➜ issues boost deploy ℹ boost deploy 🚀 ✖ Unable to determine default account and/or region

Suggestions for improvements (especially in docs)

Hey everyone! I'm just starting with the framework, but I'm loving it so far. Congrats! 😊

When first using Booster, I thought I could just note down any kind of friction/bug/suggestion I could see. Hopefully, something of this will be useful for you. Please, take in mind these notes were taken a week ago (in case something has changed since).

  1. Getting started doesn't include installation requirements (e.g. It seems like we need NPM. What Node+NPM versions are supported?)

  2. Once everything's installed, the list of links to further follow is OK. But it would be better in my opinion to suggest a recommended next step (I'd personally link to the Cart example).

  3. Installing dependencies takes some time and there's no feedback. I'd feel safer knowing what it's installing.

  4. In Github's README step 7 for cart demo. Comments are longer than what the plugin shows in a 1080p resolution. We could just shorten those.

  5. Cart entity ID field is not set as readonly by default when generated. Is this expected?

  6. Samples show 'Projects' but that doesn't exist. Maybe it's reduces what it means?

  7. Why not adding the imports in the samples? It seems like saving a few lines really makes it more difficult to know where some calls come from when implementing it on your own.

  8. CartItem used in ReadModel, but defined as a private inner interface in Cart entity (can't be used directly)

  9. "And thanks to the serverless foundation Booster is based on, you won't be paying anything if it is not used." <-- Is this right? I think that having some AWS resources set up will have like an idle cost, like Kinesis.

  10. Deploy booster doesn't work because I didn't have AWS credentials set up. But the tool doesn't let you know that. Actually, I had to go through all the documentation to find out I had to create a ~/.aws/credentials file. Again, this should probably be at the beginning of a get started tutorial, including what's required to do your first app.

  11. Error when deploying: cart-demo already exists. We need to define a different unique name for it. What about randomizing the appname? Feels like something the tool could do on its own.

  12. When showing the request examples in the docs, the way URLs are explained is difficult to follow. E.g.

You need to do a GET request to the above URL followed by the readmodels/CartReadModel segment.

What's the above URL? One would think it's the last URL formed, but it meant the root app URL. It'd be much simpler to just show exactly how the request would look like and stop cross-referencing.

Implement Authentication for the Kubernetes provider

Investigate about the authentication implementation in Kubernetes and implement it. With Dapr we are able to implement some Oauth providers and also we have the possibility to implement token authentication. Define the best authentication model for our provider and implement it inside the cluster. ,Acceptance criteria

BOOST NUKE: Failing to perform `boost nuke` when event code has changed

Description
Given that I am a user with a Booster project deployed
When I modify one of my events
Then I should still be able to nuke my application
Current behavior:

When I change the directory of my event
And I try to nuke my application
Then an error is returned
✖ Error registering reducer: The event CartChanged was already registered to be reduced by method projectCartChanged in the entity Cart.
Solution to problem

  1. Remove dist folder
  2. execute boost nuke

Expected behavior:

The application can be deleted without having to remove dist folder.

Prepare a new integration test suite for kubernetes

In order to achieve a stable project, we need to create an integration suite specific to the Kubernetes provider. This is a task with a high research component because we need to define how to run all the tests on a CI/CD environment.,Acceptance criteria

[CLI] `boost new:project` never ends on Windows

When creating a new project on Windows, the installing dependencies never ends.

If we kill boost with Ctrl + C, we cannot perform an npm install inside the project, because npm is waiting for another npm instance to end.

Taking a look closely, a node process still appears on the Task Manager. This process is unkillable, as when executing

# Forcefully kill all node.exe, including their children
taskkill /f /im node.exe /t

The command fails saying that the node process is attached to a parent process (the one we killed), and the only solution is to reboot in order to unlock npm and kill those node processes.

I suspect that we are doing something wrong when spawning the npm process. It'd be helpful to have #156 in order to debug this easier.

Create `boost` command to allow creating/deleting/modifying users

Right now, there is no way to create a user that has a role with the flag allowSelfSignUp to true.

Initially, we thought that a good way to create a user with those roles (or add those roles to an existing user) can be done with a CLI boost command.

Think if this is still a good approach and implement it.

Related issues
#284 #290

Implement GraphQL interface for REST for Kubernetes provider

In this task, we are covering the first provider functions implementation. We are going to implement some rawToEnvelope functions and the functions to save the information into the event store and perform searches in the event store. ,Acceptance criteria

[CLI] Remove stack trace from CLI's stdout messages

Environment

@boostercloud/cli/0.3.3 darwin-x64 node-v12.16.3

Steps to reproduce it:

You just need to generate an error executing a CLI command, for instance, having on purpose a wrong AWS credentials configuration.

Expected result

Stack trace could be removed from those messages because it doesn't help much the user. In fact, in previous versions like 0.2.1, there was no stack trace:

$ boost deploy -e production
ℹ boost deploy [production] 🚀
ℹ Bootstrapping the following environment: {"name":"Default environment","account":"155431809731","region":"us-east-1"}
✖ The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. (You can see the full error logs in ./errors.log)

Result

$ boost deploy -e production
ℹ boost deploy [production] 🚀
ℹ Bootstraping the following environment: {"name":"Default environment","account":"155431809731","region":"us-east-1"}
✖ SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
    at Request.extractError (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/protocol/query.js:50:29)
    at Request.callListeners (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
    at Request.emit (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
    at Request.emit (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/request.js:683:14)
    at Request.transition (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/state_machine.js:14:12)
    at /Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/request.js:685:12)
    at Request.callListeners (/Users/glammers/development/theam/my-first-booster-project/node_modules/@boostercloud/framework-provider-aws-infrastructure/node_modules/aws-sdk/lib/sequential_executor.js:116:18)

Error while deploying

I had an issue while trying to deploy (boost deploy -e production). This is a completely brand new project, by the way.
I had never seen this kind of error and the IDE does not show any

✖ TypeError: Cannot read property 'name' of undefined at 
/Users/carlosperez/PROYECTOS/mayday_booster/node_modules/@boostercloud/framework-core/dist/decorators/entity.js:30:36 at 
DecorateProperty (/Users/carlosperez/PROYECTOS/mayday_booster/node_modules/reflect-metadata/Reflect.js:553:33) at 
Object.decorate (/Users/carlosperez/PROYECTOS/mayday_booster/node_modules/reflect-metadata/Reflect.js:123:24) at 
Object.__decorate (/Users/carlosperez/PROYECTOS/mayday_booster/node_modules/tslib/tslib.js:96:96) at 
/Users/carlosperez/PROYECTOS/mayday_booster/dist/entities/Message.js:21:13 at 
Object.<anonymous> (/Users/carlosperez/PROYECTOS/mayday_booster/dist/entities/Message.js:35:3) at
 Module._compile (internal/modules/cjs/loader.js:1147:30) at 
Object.Module._extensions..js (internal/modules/cjs/loader.js:1167:10) at 
Module.load (internal/modules/cjs/loader.js:996:32) at 
Function.Module._load (internal/modules/cjs/loader.js:896:14)

Message entity:

import { Entity, Reduces } from "@boostercloud/framework-core";
import {UUID} from "@boostercloud/framework-types";
import {MessageCreated} from "../events/MessageCreated";
@Entity
export class Message {
    public constructor(
        public id: UUID,
        readonly body: String,
        readonly author: UUID,
        readonly createdAt: String
    ) {
    }
    @Reduces(MessageCreated)
    public static create(event: MessageCreated): Message {
        return event.message;
    }
}

MessageCreated event:

import { Event } from "@boostercloud/framework-core";
import { UUID } from "@boostercloud/framework-types";
import {Message} from "../entities/Message";
@Event
export class MessageCreated {
    public constructor(
        readonly message: Message
    ) {}
    public entityID(): UUID {
        return this.message.id;
    }
}

Fix project template lint configuration

Description
Given that I am a user that has just created a Booster project from template

When I run the linter

Then I get an error

Steps to reproduce:

  1. Create a booster project from template
  2. run npm run lint

Steps to fix it:

  1. Add an eslint configuration file, e.g. .eslintrc.js
  2. Update the following dependencies:
"@typescript-eslint/eslint-plugin"
"@typescript-eslint/parser" 

Fix project template tests

Description
Given I am a user that has created a Booster project

When I run tests

Then I should be returned my test results

Current behavior:

Tests are missing some key dev dependencies

  • mocha
  • ts-node

Steps to reproduce:

  1. Create a booster project from template
  2. run npm run test

Steps to fix:

  1. add mocha dev dependency
  2. add ts-node dev dependency
  3. run npm run test

Notes:

It is possible that this does not occur of you have mocha and ts-node installed as global dependencies

Find automation between Jira and GitHub

We need a better organization between the project in Jira and in Github.,We need Jira to have everything in just one place but we want to publish issues in GitHub to create community. ,Let's find automation to make the following process:,Resources:

Add basic observability capabilities to a Booster app

Design a way to:

  • List the booster applications in an AWS account
  • List all the deployments for a specific booster application in an AWS account, seeing the mappings with their corresponding environments (production, staging, etc)

This could be a new CLI command, an API exposed by booster apps, or both.

[CLI] Check whether the environment passed to "-e" option does exist

Given that I am a user with a Booster with different environments configured (for production, local, stage, etc)

When I deploy with the command
boost deploy -e "unknownEnvironment"

Then I should get an error message saying that the environment is not recognized

Current behavior:

When I deploy my booster application in an unknown environment, the applications crashes unexpectedly after a while.
image

Solution to problem
Check whether the environment specified exists before deploying the application

Expected behavior
Get an error message saying that the environment is not recognized

Rename lint scripts in package.json files

Lint scripts were changed to be lint:check and lint:fix in the package.json template for projects created by Booster. It may make sense to have the same for the Booster project. As Tai said, those changes may also require refactoring some pipeline steps.

Terminal spinner behaves differently for a deploy and nuke commands

I realized that the terminal spinner we are using from ,ora, has different behavior for the action deploy and nuke. While for a deploy the spinner disappears as soon as the sentence ,Bootstraping the following environment: ..., is logged. While executing a nuke the spinner is shown until the action is completed (it sometimes gets frozen though).,Let's see with an example:,Deploy:,Nuke:,Based on Ora's documentation, every time a .info is executed, the spinner behaves as follows:,That's why there is no more spinner for the deploy action once we log the sentence aforementioned. If we take a look at the code, we see that between the start and the end (succeed) of the spinner, there might be some actions that may lead to write some info messages. That the case of the deploy:,Script.logger.start(message)
await action(ctx)
Script.logger.succeed(message),Example of an action:,deployer(config).forEach((next): void => {
logger.info(next)
}),Deploy workflow:,observer.next('Bootstraping the following environment: ' + JSON.stringify(env)),This ticket aims to make a decision in order to have the same behavior for all the CLI commands no matter if a log.info is executed in between. In other words, ,do we want the spinner to be there from the beginning until the command is done? If so, we have to change our code because it’s not happening as long as we have a log.info as part of the stdout steps.

[CLI] help display for boost sometimes shows an error

Example of command without errors:

$ boost -h            
CLI of the Booster Cloud Framework, the next level of abstraction for cloud-native applications

VERSION
  @boostercloud/cli/0.4.1 darwin-x64 node-v12.16.3

USAGE
  $ boost [COMMAND]

COMMANDS
  deploy  Deploy the current application as configured in your `index.ts` file.
  help    display help for boost
  new     generate new resource, write 'boost new' to see options
  nuke    Remove all resources used by the current application as configured in your `index.ts` file.
  run     Run the current application locally, as configured in your configuration files.

Example of a command with errors:

$ boost new:command -h
generate new resource, write 'boost new' to see options

USAGE
  $ boost new:command [COMMANDNAME]

OPTIONS
  -f, --fields=fields  field that this command will contain
  -h, --help           show CLI help

ExitError: EEXIT: 0
    at Object.exit (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/errors/lib/index.js:18:11)
    at Command.exit (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/command.js:54:23)
    at Command._help (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/command.js:127:21)
    at Object.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/flags.js:37:17)
    at Parser._flags (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/parser/lib/parse.js:149:42)
    at Parser.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/parser/lib/parse.js:117:28)
    at Object.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/parser/lib/index.js:27:27)
    at Command.parse (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/node_modules/@oclif/command/lib/command.js:86:41)
    at Command.runWithErrors (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/dist/commands/new/command.js:16:38)
    at Command.run (/Users/glammers/.nvm/versions/node/v12.16.3/lib/node_modules/@boostercloud/cli/dist/commands/new/command.js:13:21) {
  oclif: { exit: 0 },
  code: 'EEXIT'
}

Find automation between Jira and GitHub

We need a better organization between the project in Jira and in Github.,We need Jira to have everything in just one place but we want to publish issues in GitHub to create community. ,Let's find automation to make the following process:,Resources:

Implement GraphQL interface for REST for Kubernetes provider

In this task, we are covering the first provider functions implementation. We are going to implement some rawToEnvelope functions and the functions to save the information into the event store and perform searches in the event store. ,Acceptance criteria

Terminal spinner behaves differently for a deploy and nuke commands

I realized that the terminal spinner we are using from ,ora, has different behavior for the action deploy and nuke. While for a deploy the spinner disappears as soon as the sentence ,Bootstraping the following environment: ..., is logged. While executing a nuke the spinner is shown until the action is completed (it sometimes gets frozen though).,Let's see with an example:,Deploy:,Nuke:,Based on Ora's documentation, every time a .info is executed, the spinner behaves as follows:,That's why there is no more spinner for the deploy action once we log the sentence aforementioned. If we take a look at the code, we see that between the start and the end (succeed) of the spinner, there might be some actions that may lead to write some info messages. That the case of the deploy:,Script.logger.start(message)
await action(ctx)
Script.logger.succeed(message),Example of an action:,deployer(config).forEach((next): void => {
logger.info(next)
}),Deploy workflow:,observer.next('Bootstraping the following environment: ' + JSON.stringify(env)),This ticket aims to make a decision in order to have the same behavior for all the CLI commands no matter if a log.info is executed in between. In other words, ,do we want the spinner to be there from the beginning until the command is done? If so, we have to change our code because it’s not happening as long as we have a log.info as part of the stdout steps.

Require the environment parameter in the CLI using oclif `required` flag

In the current implementation of most CLI commands that require an ,environment, parameter to work, like ,boost deploy,, ,boost nuke, or ,boost start,, we’re detecting when a user has missed the required environment parameter with an if like this:,if (!flags.environment) {
console.log('Error: no environment name provided. Usage: boost start -e <environment>.')
return
},In ,this comment,, , proposed to replace this check by the native ,required, flag from the ,oclif, library that we’re using to parse the options.,In this task, we should review the commands implementations to detect where we’re doing checks as the one explained before, enable the corresponding option in the command flags, and fix the tests to make sure that we’re still requiring the option.

[CLI] Allow a parameter to run the new:project command with default values

It would be great to have a parameter like -y in the project:new command so when we run

boost project:new my-boosted-project -y

The CLI doesn't ask the user for inputs and everything is created with default values

Current behavior

> boost new:project my-boosted-project
? What's your project description? (default: "") 
> Intro
? What's the first version? (default: 0.1.0) 
> Intro
? Who's the author? (default: "") 
> Intro
? What's the website? (default: "") 
> Intro
? What license will you be publishing this under? (default: MIT) 
> Intro
? What's the URL of the repository? (default: "") 
> Intro
? What's the package name of your provider infrastructure library?
> Intro
(AWS)
ℹ boost new 🚧
✔ Creating project root
✔ Generating config files
✔ Installing dependencies
ℹ Project generated!

expected behavior

> boost new:project my-boosted-project -y
ℹ boost new 🚧
✔ Creating project root
✔ Generating config files
✔ Installing dependencies
ℹ Project generated!

I propose -y because that's kind of standard in CLIs for yes to all

Require the environment parameter in the CLI using oclif `required` flag

In the current implementation of most CLI commands that require an ,environment, parameter to work, like ,boost deploy,, ,boost nuke, or ,boost start,, we’re detecting when a user has missed the required environment parameter with an if like this:,if (!flags.environment) {
console.log('Error: no environment name provided. Usage: boost start -e <environment>.')
return
},In ,this comment,, , proposed to replace this check by the native ,required, flag from the ,oclif, library that we’re using to parse the options.,In this task, we should review the commands implementations to detect where we’re doing checks as the one explained before, enable the corresponding option in the command flags, and fix the tests to make sure that we’re still requiring the option.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.