https://serverless-stack.com/ logo
Join Slack
Powered by
ooh man.. my API stack is getting rather full :swe...
# sst
s
ooh man.. my API stack is getting rather full 😅 I think CF has a 500 resource limit, right? anyone else run into this limit yet? I wonder if it might make sense to just centralize the permissions so they all share the same policies (like Serverless Framework does). it’s not ideal, but with every single API endpoint having its own policies, it definitely eats up that resource quota
f
Yeah I think we can add an option, something like:
Copy code
new sst.Api(this, "MyApi", {
  sharedLambdaRole: true,
});
What do you think think @Sam Hulick @thdxr?
s
can’t you just currently do:
Copy code
new sst.Api(this, 'MyApi', {
  defaultFunctionProps: { permissions: [...] }
})
I’d assume that just creates one role/policy and points all the Lambda functions to that
or.. I guess it can’t do that. because it has to merge the props w/ whatever the Lambda func overrides with.. which could be permissions too
f
U mean making it the default behavior for lambdas to share the same role?
If an individual route has custom permission, it can have its own role.
s
a single API route has 7 resources 😮 the Lambda, a custom log retention resource, IAM policy, IAM role, API Gateway route, API Gateway integration, and Lambda permission. so.. 150 API endpoints = about 1050 resources, which is not possible. I’m just wondering if there’s a way to cut down on some of these resources
t
I actually manually do this where I create a shares role up front and set it as default in one of my stacks
s
AWS often does this, where they recommend a certain pattern (yes, use one Lambda per API endpoint).. but then they have restrictions that don’t really let you do this at scale
it’s frustrating
@thdxr so in SST/CDK, if you create a single role and use it in 
defaultFunctionProps
, it won’t create roles/policies for every single Lambda func?
t
Yeah that's right
s
ahh.. so that’s good. for 150 endpoints, it’d bring the resource count down to about 750'ish
or maybe 600. the API would probably still need to be split up into two 🤔 this’ll be solved once we refactor & move to AppSync, where we’ll have just one Lambda function (data source) per area of concern.. which there’ll be about 5 or 6
@Frank @thdxr BTW, if you lump permissions into 
defaultFunctionProps: { permissions: [] }
, it actually does not share them among functions. it just duplicates the same permissions across all functions
I just checked
Copy code
const api = new sst.Api(this, 'BillingWebhook', {
      defaultFunctionProps: {
        permissions: [[props!.appSyncApi.graphqlApi, 'grantMutation'], 's3'],
      },
      routes: {
        'POST /cb-hook': {
          functionName: `${this.stackName}-billing-webhook`,
          handler: 'lambda/billing/webhook.main',
          environment: {
            GRAPHQL_ENDPOINT_URL: props!.appSyncApi.url,
          },
          // permissions: [[props!.appSyncApi.graphqlApi, 'grantMutation']],
        },
        'PATCH /cb-hook': {
          functionName: 'who-cares',
          handler: 'lambda/billing/webhook.main',
          // permissions: ['s3'],
        },
      },
    });
IMO, a way to share permissions will be crucial for large enterprise apps that have a lot of REST endpoints
I’m at 348 now 😬 (was at 309 earlier). hopefully I don’t hit the 500 max. and I only have 40 routes BTW!
t
@Sam Hulick you should probably start thinking about splitting the stacks 😉
2 Views
Open in Slack
PreviousNext
Powered by