They should be loaded & available within in your stack config. To make them available in your lambda’s you would need to add them using the environment param on the function or use app.setDefaultFunctionProps({ environment: { … } })

This will be addressed with the new process reuse work but wanted to document an issue: Prisma spawns an rust executable to do connection management with the db. Right now every time a function is invoked it spawns another one. This shouldn't be a problem but for some reason when the node process exits the rust binary sticks around. Restarting sst kills them all and I have to do this periodically as my db connections get exhausted. Wonder why it's not exiting with the node process

A question on monorepos when using the sst/live lambda approach: It seems one would do a

npx create-serverless-stack@latest <microservice name>

in the parent folder for each microservice in the monorepo? Or, one could also do the

npx create-serverless-stack

once, and then put the microservices in each of their own directories under

src

. And then, in

lib

create one stack per microservice, each with the API, Lambda, DynamoDB table(s) and whatever other serverless pieces and deploy a stack per microservice.

Is anybody doing e2e test of SST apps?

trying my hand with live lambda/sst using typescript, and getting the following error. Any way to configure where the

tsconfig.json

should be referenced?:

Resolve error: ENOENT: no such file or directory, stat './tsconfig.json'

I've added a bucket to an existing SST app but it's not getting created when I run

sst deploy

. I don't need to have any notifications attached to it. It's just going to be used to write data as a result of a call to an endpoint (also defined in SST) Is there anything I need to other than this:

export default class SomeStack extends sst.Stack {
  constructor(scope: <http://sst.App|sst.App>, id: string, props?: sst.StackProps) {
    super(scope, id, props);

    const statsCsvBucket = new Bucket(this, process.env.REBOOK_STATS_BUCKET);
  }
}

I think there may be some incompatibility with Node 16. I had some low level error with the runtime that is spawned when a lambda is invoked and downgrading to Node 15 fixed. I'll try to recreate to get the exact error

Getting the error:

Error: There is already a Construct with name 'SingersApi' in SingersStack [dev-karaoke-singers]

in the following sst/cdk Stack class:

import { RemovalPolicy } from '@aws-cdk/core';
import * as sst from '@serverless-stack/resources';

export default class SingersStack extends sst.Stack {
    constructor(scope: <http://sst.App|sst.App>, id: string, props?: sst.StackProps) {
        super(scope, id, props);

        const singersTable = new sst.Table(this, "singers", {
            fields: {
                singer_id: sst.TableFieldType.STRING,
            },
            primaryIndex: { partitionKey: 'singer_id'},
            dynamodbTable: {
                removalPolicy: RemovalPolicy.DESTROY
            }
        });

        const singersApi = new sst.Api(this, 'SingersApi', {
            defaultFunctionProps: {
                environment: {
                    singersTable: singersTable.dynamodbTable.tableName,
                },
            },
        });

        singersApi.addRoutes(this, {
            'POST /karaoke/singers': 'src/services/singers/functions/KAR_SNG_create_singer.handler',
            'GET /karaoke/singers/{singerId}': 'src/services/singers/functions/KAR_SNG_get_singer.handler',
            'GET /karaoke/singers': 'src/services/singers/functions/KAR_SNG_get_all_singers.handler',
            'PUT /karaoke/singers/{singerId}': 'src/services/singers/functions/KAR_SNG_update_singer.handler',
            'DELETE /karaoke/singers/{singerId}': 'src/services/singers/functions/KAR_SNG_delete_singer.handler', 
        });

        singersApi.attachPermissions([singersTable]);

        this.addOutputs({
            'SingersApi': {
                value: singersApi.url,
                exportName: scope.logicalPrefixedName('SingersApi'),
            }
        });
    }
}

It seems having 'SingersApi' in both

const singersApi = new sst.Api(this, 'SingersApi', {

and

this.addOutputs({
            'SingersApi': {
                value: singersApi.url,
                exportName: scope.logicalPrefixedName('SingersApi'),
            }
        });

is a no-go. These seem like similar, yet different context meanings of the api parameter. The later is the Key and ExportName in CFN. But what is the same parameter in the

sst.Api

constructor?

And there you have it. A monorepo, karaoke-backend-sst, with 3 microservices thrown together in less than 24 hours: • super easy to learn - the constructs are quite intuitive, the lerna/monorepo thing was new but, easy enough. • had a few typos in my code, like mis-spelled fieldnames in my dynamodb mappings - no problem. Fixed the typos with Live Lambda running, hit send on Postman again, and done. • I'm still not sold, though. I kind of miss the hours and hours I spent messing with serverless.yml, serverless plugins and getting dynamodb local to work in conjunction with deploy and cdk. Don't know what I'm going to do with my life anymore...

Question on security with Cognito UserPools: If we're doing a monorepo, and we anticipate sharing said UserPool across multiple microservices, then it's likely a common pattern to use cross-stack references?

What’s the preferred way to run a script after a deploy? We need to register the (generated) URLs as webhooks with some external API

It looks like --increase-timeout is on by default. I’m not sure if thats the intention given it’s a command option?

Hey – is there a way to import an existing AppSync API to SST that was created via Cloudformation (by way of serverless framework)? I noticed the docs only show such for AppSync created by CDK.

Got my app ported from elixir to serverless finally. Next step is refactoring postgres for dynamo. Realizing I'm not sure how to run my jest tests anymore since they need dynamo access. How are people doing this?

Morning, we're currently setting up AppSync auth with an existing user pool and running into some issues. We've tried as follows with no deployment issues but run into 500s when querying in the AppSync console. We can't seem to track down useful logs either. Any thoughts/suggestions?

const userPool = cognito.UserPool.fromUserPoolArn(
      this,
      // does this id matter?
      'dev-user-pool',
      process.env.AWS_USER_POOL_ARN,
    )

    const api = new sst.AppSyncApi(this, 'v2', {
      graphqlApi: {
        schema: 'src/schema/schema.graphql',
        authorizationConfig: {
          defaultAuthorization: {
            authorizationType: appsync.AuthorizationType.USER_POOL,
            userPoolConfig: {
              userPool: userPool,
            },
          },
        },
        logConfig: {
          excludeVerboseContent: false,
          fieldLogLevel: appsync.FieldLogLevel.ALL,
        },
      },
      resolvers: {
        'Query    projects': 'src/get-projects.main',
        'Mutation    createProject': 'src/create-project.main',
      },
    })

A question regarding Domain-Driven Design (DDD) and architectural design that I suspect is likely common to many, if not most microservice apps. So, I'm wondering how people might approach this as a common design pattern. The idea is, that as a user of the system, a person is a different type of entity in different sub-domains: • In Cognito, a person is a "User" who signs up, logs in, forgets and resets passwords, etc. Authentication and authorization-related stuff. • In a banking app, a person is a "Customer". They check account balances, transfer money between accounts, etc. In my karaoke backend app, a person is a "Singer". They manage favorite song lists, request to join a queue to get a chance to sing, view their performance history, etc. In other words, a person is a different kind of entity with different properties in different sub-domains. • What are some common approaches to link the "User" in Cognito with their "Entity" in the rest of the app, so that auth concerns are orthoganal/cross-cutting to their business-related activites in the app? • Specific to AWS serverless/sst, my thoughts on a good design pattern is to use triggers, such as Pre-Signup or Post-Confirmation to create a banking "Customer" or "Singer" or what-have-you entity in DynamoDB that uses their unique identifier in Cognito as their partition key in the singers or customers DynamoDB table. How have other sst, or serverless in general, developers been approaching this problem?

Good day all 🙂 I wanted to protect frontend assets on development deployments with a basic auth prompt in the browser. I think lambda@edge is the way to do this right? AWS Amplify Console just has a field where you can toggle a password on and off. Would be cool to have that on the SST StaticSite Construct 🙂

is .env supposed loaded in test?

Hey @Frank I tried creating the PR for the nodeBuilder issue I posted this morning, but I do not have permissions to push to the repository.

Is there a way to specify looking in a different folder instead of

lib

with sst.json

Any tips on how to specify

customAttributes

in for a Cognito UserPool? I've looked through all documentation, but I can't make heads or tails of how to implement

ICustomAttribute

.

const auth = new sst.Auth(this, 'Auth', {
      cognito: {
        userPool: {
          signInAliases: { email: true },
          removalPolicy: RemovalPolicy.DESTROY,
          customAttributes: {
            FirstName: { ??? WHAT GOES HERE ??? }
          }
        },
        triggers: {
          preSignUp: 'src/triggers/preSignup.handler',
          postConfirmation: 'src/triggers/postConfirmation.handler',
          preAuthentication: 'src/triggers/preAuthentication.handler',
          postAuthentication: 'src/triggers/postAuthentication.handler',
        },
      },
    });

Hey guys I have this in my current codebase, and I would like to use SST to achieve this, I would like to add custom domains later on and don't want to add it manually as the is already supported in SST. The help would be appreciated. Please message me if you need more context on this.

import { App, Stack } from '@serverless-stack/resources';
import {
  HttpApi,
} from '@aws-cdk/aws-apigatewayv2';
import { HttpAlbIntegration } from '@aws-cdk/aws-apigatewayv2-integrations';
import { Server } from './Server';

export class Api extends Stack {
  constructor(app: App, props: Props) {
    super(app, 'api');
    const { server } = props;
    const { fargate } = server;

    const integration = new HttpAlbIntegration({
      listener: fargate.listener,
    });
    new HttpApi(this, 'http-api', {
      defaultIntegration: integration,
    });
  }
}

interface Props {
  server: Server;
}

Hey there – is there a reference for minimum necessary IAM permissions to deploy an SST app?

I recently wrote a util function, that creates lambdas in a directory. The logic shown below

import fs from 'fs';
import path from 'path';
import { Stack, Function, FunctionProps } from '@serverless-stack/resources';
import { getPathConstruct } from './formatting';

const INITIAL_RECORDS: LambdaRecords = {};
/**
 * Creates functions for all files in the provided directory
 *
 * @param stack - The stack in which the functions belong to
 * @param directory - The directory where the functions should be created from
 * @param props - Common handler props that you need to pass down to your functions
 *
 * @returns A record of the lambda functions with the keys as the PascalCase version of the filename
 */
export function getPathFunctions(
  stack: Stack,
  directory: string,
  props: LambdaProps = {},
) {
  const { stage } = stack;
  const root = process.cwd();
  const dir = directory.replace(`${root}/`, '');
  const functions = fs.readdirSync(directory);

  return functions.reduce((memo, filename) => {
    const fullPath = path.resolve(directory, filename);
    const stats = fs.statSync(fullPath);
    if (stats.isDirectory()) {
      return memo;
    }
    const [name] = filename.split('.');
    const constructName = getPathConstruct(filename);
    const functionName = `${stage}-${name}`;
    const id = `${constructName}Lambda`;
    const handler = `${dir}/${name}.handler`;
    const lambdaFunction = new Function(stack, id, {
      handler,
      functionName,
      ...props,
    });

    return {
      ...memo,
      [constructName]: lambdaFunction,
    };
  }, INITIAL_RECORDS);
}

type LambdaProps = Omit<Omit<FunctionProps, 'handler'>, 'functionName'>

export type LambdaRecords = Record<string, Function>;

Do you guys think this would be a valuable thing to add? We could add a static method on the Function class like

Function.fromDirectory(...)

obviously we would have to make the functionality more generic.

Does sst have this feature? - In the console, you can configure an API Gateway api to send its payload directly to an SQS queue with an SQS proxy (IOW, not using a Lambda to enqueue the message). Is there away to express this in an

sst.Stack

class?

Hey @Frank Is anyone working on https://github.com/serverless-stack/serverless-stack/issues/458

There seems to be more convention instead of configuration for sst cli. We could use “sst-esbuild-config.js”, or make it a cli flag?

Hi @Frank, I’m migrating an app from serverless to SST and I’ve got a question about deployment phases using SST on seed.run. Previously, I had a monorepo with different services -- AppSync, Dynamo, Auth, etc. I deployed those on seed.run and each service was deployed in a phase. I think I had about 4 phases, some containing multiple services. But with SST, deployment is different. It seems that lib/index.ts describes my services and their deployment order. Before, I used phases to deploy services in a specific order. Do I need to think about phases on seed.run while using SST, or is this handled by lib/index.ts?

I think I picked up a bug in the Api construct, the bundle option does not seem to work here

new Api(this, 'Api', {
      routes: {
        'ANY /any': {
          function: 'src/lambda/any.handler',
          bundle: {
            loader: {} // this does not seem to work
          }
        },
      },
    });

I get the desired functionality when I use

const func new Function(this, 'Function', {
      handler: 'src/lambda/any.handler',
      bundle: { 
        loader: {} // it works here
      }
    });

new Api(this, 'Api', {
      routes: {
        'ANY /any': {
          function: func
        },
      },
    });

I haven't had time to debug this issue.

@Frank Heya Frank, any idea why comments would not make it from a graphql schema file over to the AppSync API?

// schema.graphql
# An object with an ID to support global identification.
interface Node {
  id: ID!
}

// AppSync Schema
interface Node {
	id: ID!
}

I know AWS doesnt support the normal graphql commenting spec 🙄 but I was under the impression we could use single line comments via the above method. See https://github.com/aws/aws-appsync-community/issues/38