aimed / slushy Goto Github PK

Prevent leaking of credentials based on https://docs.travis-ci.com/user/environment-variables/#defining-encrypted-variables-in-travisyml

For a response code '200' and the definition '2XX', custom response content-types will not work.

Furthermore response validation will not work.

Use https://github.com/epoberezkin/ajv#assigning-defaults

Ideally we map all errors caused by internal middleware/etc to SlushyErrors that can then be handled by the error handler.

• Support AJV validation error
• Support multer error

Error handling could be provided on a per resource or a per operation basis.

This is similar to GraphQL.
Also consider adding an error parameter so that middleware errors (e.g. validation errors) can be processed in the handler.

Responses currently only support response code 200 for non error responses, otherwise anything supported by custom errors

Supporting other MIME types is a lower priority now, but slushy needs to be able to support different response codes and the appropriate response bodies in a typed manner.

There are a few different approaches to this:

Approach 1:
Request handlers always return an object that includes the status code as well as the payload (and maybe mime type). This can be fully typed, but requires more manual error handling and introduces the concept of response codes to request handlers.

getPets() {
  if (error) {
    return {
     status: 400,
     payload: { message: 'An error ocured' }
    }
  }
  return {
   status: 200,
   payload: []
  }
}

Approach 2:
Generate objects for responses and errors, e.g.

getPets() {
  if (error) { throw new GetPetsBadRequestError() }
  return new GetPetsSuccess([])
}

Approach 3:
Generate errors, but for responses use conventions, e.g. get must be 200, post bust me 201, delete must be 204

getPets() {
  if (error) { throw new GetPetsBadRequestError() }
  return []
}

(see https://swagger.io/docs/specification/describing-request-body/file-upload/)

Ideally this can be a generator, similar to the component schema types generator.
See also #45

Extend the OpenApi schema to support PubSub. Defining PubSub inside of events allows us to generate typed clients that know how to subscribe to events. It furthermore allows to generate typed servers that understand what these events look like and how events can be published. For an example of the schema as well as the generated code see the sections below.

In addition to generating types and handling them in a type safe and validated way, defining the PubSub mechanism inside of the schema would enable deployment pipelines to automatically perform the necessary bootstrapping. E.g. A deployment pipeline could inspect the publishers section and then set up a new AWS Queue.

Requirements:

• Support different PubSub mechanisms (e.g. local, SQS, SNS)

Related work:

• https://www.profit4cloud.nl/blog/async-api-with-api-gateway-and-the-sqs-alternative/
• https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md

Publishing describes how a service publishes events and what shape the events have.
Example publishing:

publishes:
  petShopEvents:
    schema:
        $ref: "#/components/events/PetShopEvent"
    sources:
      SNS:
        arn: {petShopEventsSNSArn}:pet-shop-events
        encoding: application/json
        variables:
          petShopEventsSNSArn:
            type: string

Subscriptions describe how the service connects to publishers. In the case of SNS/SQS a deployment pipeline could create the actual subscription on AWS while Slushy takes care of listening to the events and forwarding them to the appropriate endpoint.
Example subscription:
TODO

subscriptions:
  petShopEvents:
    SQS:
       arn: {petShopEventsSQSArn}:pet-shop-events
       # This references the SNS services this queue is subscribed to. It provides the url and the expected schema.
       SNS:
         # This publisher has write permissions
         permissions: ["SQS:SendMessage"]
         $ref: 'https://my-schemas/petShop/#/publishes/petShopEvents/SNS'

Example code generated:
TODO

https://swagger.io/docs/specification/describing-parameters/#common-for-various-paths

Currently all error handling is done inside of SlushyRouter. This has a few caveats:

• Middleware errors, e.g. parsing, validation (see below), etc. will be not handled correctly.
• If the router handler fails, the error will not be handled correctly.

See also #85.