Pluggable auth system based on JWT tokens

In this release, we have extended the auth system to be able to use 3rd party auth providers like Auth0, Cognito, Firebase, or custom implementations using standard Jason Web Tokens (JWT) for authenticating and authorizing Commands and Read Models. In that way, you are not forced to use the Booster internal auth APIs, and it’s easier to integrate Booster services in existing microservice-based systems.

In this version, we have kept the role classes as the way to define application roles, so in order to use a JWT-based auth provider, you must include the expected roles in your ID tokens in the custom:roles claim. To let Booster know how to decode 3rd party provided tokens, you have to configure a tokenVerifier object filling the jwksUri and issuer properties.

The jwksUri is the URI where your auth provider publishes their JWKs (which are used for signing the JWT tokens). The issuer should be provided as well by the auth provider, but it usually matches with the provider domain, so please check provider documentation to find those parameters.

Here is a sample configuration:

Booster.configure('development', (config: BoosterConfig): void => {
  config.appName = 'awesome-app'
  config.provider = AWSProvider
  config.tokenVerifier = { 
    jwksUri: 'https://myauth0app.auth0.com/.well-known/jwks.json', 
    issuer: 'myauth0app.auth0.com'
  }
})

For more information, please refer to our official documentation.

Rockets, Static site deployments, Scheduled commands, and more!

In this release, we introduce important changes that will shape the future of Booster. With the introduction of rockets, we open the door for Booster framework extensibility. This change, along with the upcoming support for JWT tokens will make Booster easier to integrate into existing systems to build the services that can really take advantage of Booster's serverless and event-sourcing characteristics, without requiring the whole application to be written in Booster.

• Booster Rockets for AWS: This feature allows you to build custom plugin packages to extend the underlying AWS infrastructure of your Booster application. This is the first of a series of important changes in the future of the framework as we make it more pluggable and interoperable. Read more in Booster Docs.
• First rocket; Static site deployment: As a demo of the new rockets feature, we’re releasing a static site deployment extension that you can use to deploy static sites or SPAs to AWS. In just a couple of minutes, it will put your static files into an S3 bucket and securely distribute them using Cloudfront.
• Scheduled commands: We’ve introduced the concept @ScheduledCommand to be able to run scheduled actions. It works like a regular @command, but you can describe a CRON-like schedule and the handler will be triggered automatically for you when the time comes. Read more in Booster Docs!
• Improved stability of integration tests: Test has always been #1 citizen in Booster’s development. That's key to provide a framework that can be used in real scenarios and be able to keep evolving it at a good pace with all the necessary checks. In this version, integration tests run more smoothly and faster on top of the actual cloud providers. There’s nothing closer to the real scenario than rehearsing in the real stage!
• Fixed generated file paths to follow TypeScript’s convention of naming files using kebab-case. Kudos to @verogarp for this!
• Lots of improvements and fixes in docs, developer experience, and overall performance. We can’t thank enough @fecony, @verogarp, @jvmazagao, and @AF111 for their great contributions to this release!

We're really excited about this step and the exciting features that are just around the corner, which push us a little bit closer to the first production-ready release! If you try Booster, don't hesitate to join us in Discord and say hello!

Fix: Enable CORS in the auth endpoints for AWS

The Auth Stack now generates the auth API with preflight support (accept OPTIONS requests) for the auth/sign-up, auth/sign-in ,and auth/sign-out endpoints. Also, the corresponding POST methods return the `Access-Control-Allow-Origin: *' header.

Skip actions or delete read models from projections!

With this release, we introduce more flexibility when developing projections from read models. Users can now delete, skip the action or return a read model from their projections!! Feel free to give it a try 😉

Improvements

Now projections return the ProjectionResult<MyReadModel> type:

type ProjectionResult<TReadModel> = TReadModel | ReadModelAction
enum ReadModelAction {
  Delete,
  Nothing,
}

This means that you have now three different options to return in your projections:

• A normal read model as it was before
• Skip the action, so you will keep the read model untouch
• Delete the read model: There are some cases where users may want to delete read models, so they don’t get printed when querying (for example, when triggering a DeleteUser command)
  Of course, all different options are optional depending on your specific use case!

Before

@ReadModel
export class UserReadModel {
  public constructor(readonly username: string, /* ...(other interesting fields from users)... */) {}
  @Projects(User, ‘id’)
  public static projectUser(entity: User, current?: UserReadModel): UserReadModel  {
    return new UserReadModel(...)
  }

After

@ReadModel
export class UserReadModel {
  public constructor(readonly username: string, /* ...(other interesting fields from users)... */) {}
  @Projects(User, ‘id’)
  public static projectUser(entity: User, current?: UserReadModel): ProjectionResult<UserReadModel>  {
    if (current?.deleted) {
      return ReadModelAction.Delete
    } else if (!current?.modified) {
      return ReadModelAction.Nothing
    }
    return new UserReadModel(...)
  }

2x faster GraphQL requests, Authentication improvements, and more!

This release contains a lot of additions, huge improvements in usability, performance, and stability, so we encourage you to update right away. There are some breaking changes, but they are easily addressable (minor syntax changes)

⚠ Breaking Changes

• Command handlers are now static methods that receive the command data in the first parameter. If you are upgrading form a previous Booster version, you will get a compilation error. To fix it, you need to change the command handler signature:
  If we have the following command:

@Command(...)
export class CreatePost {
  public constructor(
    readonly postId: UUID
  ) {}

  public async handle(register: Register): Promise<void> {
    if(this.postId) {
      ...
    }
  }
}

Then we need to make the handle method static, receive the command data as the first parameter, and change any usages of this by the name of the first parameters:

  public static async handle(command: CreatePost, register: Register): Promise<void> {
    if(command.postId) {
      ...
    }

• If you use roles, they have some changes in the attributes they accept. allowSelfSignup is no longer used and was replaced by the property auth, which is an object with some new options. For more information, go to this section of the documentation. If you want to strictly fix the syntax while keeping the exact same behavior, then replace roles with allowSelfSignUp: false like this:

@Role({
  allowSelfSignUp: false,
})
export class Admin {}

By this:

@Role({
  auth: {
    signUpMethods: [],
  },
})
export class Admin {}

And roles with allowSelfSignUp: true like this:

@Role({
  allowSelfSignUp: true,
})
export class User {}

By this:

@Role({
  auth: {
    signUpMethods: ['email']
  },
})
export class User {}

• Finally, you would get a compilation error in the index.tx file after upgrading, saying that boosterRequestAuthorizer doesn't exist. Just remove that export, it ware refactored out.
  

🔥 New

• Authorization gets better!
  • You can specify now that some roles are allowed to signup by phone. Everything will be handled and they will be sent an SMS, instead of an email, for confirmation.
  • You can configure a role to skip the confirmation step

🚀 Improvements

• Removed the need for an authorizer function, meaning that the GraphQL requests are now almost 2x faster!
• You can now call the new auth API method /refresh-token to refresh expired access tokens
• GraphQL now supports the standard authentication mechanism, both in HTTP calls and in WebSocket calls. This means that you can now correctly authorize any request using the standard GraphQL client of your choice (Android, iOS, etc.)
• Added and improved a lot of documentation!

🩹 Fixes

• Improved integration tests and make them execute in parallel, reducing tremendously the time you need to wait for them.
• Fix how auth related errors were returned after a GraphQL request. Now they properly follow the standard ({errors: [...]})

Full support for GraphQL Apollo Client, Documentation, and Stabilization

Full support for GraphQL Apollo Client

Booster now adheres to the "GraphQL over WebSocket Protocol" so you can now use the Apollo client for your client language to do queries, mutations, and subscriptions. All the connection details are managed for you.

Documentation

We have been working really hard on the documentation. It is still not finished yet, but we are almost there! The structure and the content are of much better quality now.

Fixes and Stabilization

We continue adding more and more integration tests to ensure everything works as expected. Along the way, many bugs were found and fixed.

Static file deployments and the AWS provider resources are all eligible for the free-tier

New features & improvements

• Static file deployments: Now you can put any file in the public/ folder of your application and they will get deployed along with your code. This is really useful for creating your front end application and deploy it along with your backend.
• AWS free-tier: The infrastructure created with the AWS provider has been restructured so that it doesn't need Kinesis Streams, the only services that had a fixed cost even if you didn't use your application. Now, any Booster application won't have any cost if it is not used and will be eligible for the free-tier (so it would cost you nothing!)
• We have improved the boost command line app so that it now gives you more information and it is easier to use

Fixes and docs

We've put A LOT of effort into testing, as we are reaching the milestone that will make Booster safe for production environments.
We've added integration tests, improved the continuous integration system so that tests are run before merging pull requests into master and before releasing any new version, etc.

Also, we have been working hard on documentation. It is still not completely finished, but expect great improvements in that area.

Happy Boostering!

GraphQL Subscriptions and kick-off the stabilization phase

This release finishes the GraphQL functionality that was still missing: support for subscription operations.

Now you can subscribe to any of your read models, specifying any filter you want. After that, whenever you update that read model through any event, you will be notified with the updated version of the read model if it matches the filters you specified.
It works similarly to GraphQL live queries.

With this missing piece, Booster is now suitable for real-time apps!

As always, there were a lot of bugs fixed.

The project now starts a new phase where we focus less on adding features and more on stabilizing the public API, fixing bus and polishing any rough edge

Multi-environment support, GraphQL, EventHandlers, and Local provider!

This release contains a bunch of new exciting features that makes Booster easier to use and more powerful:

New features

• Added support for GraphQL
  The idea is to move towards GraphQL where:
  • Commands are submitted through mutations
  • ReadModels read requests are submitted through queries
  • You can subscribe to ReadModels changes through subscriptions
    Right now, the GraphQL schema is generated automatically based on your Commands and ReadModel types and you can submit mutations and queries using the endpoint /graphql. Subscriptions will come in a future release
• Event handlers: Now you can execute additional logic as a reaction to any event in your system, which in turn, can generate new events. This extends substantially the kind of application you can build.
• Multiple environments: Now, when you configure your Booster application in the config.ts file, you specify the name of the environment you are configuring. This way, for example, you can have a "production" environment that uses the AWS provider and a "development" environment that uses the local provider (see below)
• Local provider: There is a new provider available: 'framework-provider-local`. Its purpose is to allow you to execute Booster locally so that you can test and debug the application before sending it to production. Right now, only authentication and submitting commands are supported. We will keep working on it to make it support all Booster features

Bugfixes

There were so many bugs fixed that writing them here will take too long. I'd rather spend that time fixing more bugs! 😄

Normalize projection decorator

This release changes the "@Projection" decorator to "@Projects" to be consistent with other decortators.

Note: This is a breaking change. Your projects will stop compiling. Luckily, the solution is simple enough: just change the @Projection decorators by @Projects