https://serverless-stack.com/ logo
Join Slack
Powered by
> :loudspeaker: Update For those of y’all that’...
# general
f
📢 Update
For those of y’all that’ve been fed up w/ cryptic function names, in v0.54.4, you can now pass in a callback for 
functionName
. It allows you to apply a naming convention to some/all of your functions. For example, to name functions based on their handler file names:
Copy code
import path from "path";

app.setDefaultFunctionProps({
  functionName: ({ functionProps, stack }) => (
    `${stack.stackName}-${path.parse(functionProps.handler).name}`
  )
});
r
This looks cool, what is the behaviour if this is set for a stack that has already been deployed?
f
I think the functions will get replaced
r
Ok, cool
f
Yeah, maybe try setting it on a single function first.
a
Can I set this in the index? at app level?
Also, we need this for other resources too, not only Function.
At the moment I’m suing same “helper” to name queues and EB, etc.
f
yup, the snippet above is at the app level. 
app.setDefaultFunctionProps
a
Ok, cool.
What about naming other resources @Frank?
Also, this is not the “final” name right? because is missing the “stage” part.
f
Ah I see. Yeah let’s wait to get some feedback on the 
functionName
callback. If there isn’t much of a downside, we can add it to all other Constructs.
a
Ok nice.
Also 
stack.stackName
would include “-stack”, if we follow existing convention.
My stacks are named like 
networkVpn-stack
.
So my helper function removes the 
-stack
part 😂 .
f
yeah maybe something like 
stack.stackName.split("-").slice(0, -1)
a
Yeah exactly.
This is what I do..
Copy code
export function getNamePrefix(stack: Stack, scope: App): string {
  const projectName = stack.stackName.split('-')[2];

  return `${scope.stage}-${scope.name}-${projectName}`;
}
Is the stage included now?
f
stack.stage
gives u the stage
a
Yes, so it’s not included in your example.
I want to understand if it’s added by default or not.
f
stackName
should have stage in there
a
Ohhhh I see.
f
Just curious, how r u naming ur queues with ur helper function?
a
I can show you, one sec.
m
This is cool. We've done something similar, but I'm happy to deprecate mine for yours. If you have consistent naming for functions, you can also manage the creation (and thus deletion) of log groups in a stack. Any thought to supporting that?
a
Copy code
const namePrefix = getNamePrefix(this, scope);

EB rule

ruleName: `${namePrefix}-intercomContact-eventBridgeRule`,

Queue:

queueName: `${namePrefix}-createOrUpdateCompanyDlq`,
Still can’t find a good way to name things 😂 .
m
Yeah, and I'm with @Adrián Mouly. I could see using this on other resources.
a
Yeah, still can’t find a 100% perfect naming convention.
Should we put 
queue
in the name? should we put 
function
? or we should just name them based on the business.
Also, this so “open” that some developers put Queue, and others just don’t put Queue in the name… 
dev-sst-myCoolQueue
-> I tend to do this 
dev-sst-messagesToProccess
-> others do this This is an example, some developers forget to name it.
f
@Matt Morgan
you can also manage the creation (and thus deletion) of log groups in a stack
Currently, SST/CDK does not explicitly create log groups. AWS Lambda creates them when a function gets invoked for the first time. Are you looking to manually creating them?
m
We've done that in most of our stacks, yes. I guess it doesn't matter all that much once you're in a steady state, but I find the fact that named log groups linger after a stack is removed hurts experimentation. You'll start to see this problem once you start having consistent function names because the function name drives the log group name.
f
Ah, would setting the removal policy to remove for experimental stage work?
Copy code
if (app.stage !== "prod") {
    app.setDefaultRemovalPolicy(RemovalPolicy.DESTROY);
  }
m
I don't think that would do it automatically without some extra code.
f
Wait no.. I don’t think it gets set on the Log Groups b/c SST isn’t creating them.
Right..
m
It's a minor thing. Was just wondering if this was on your radar. I'm not fully convinced it's worth the effort, but I find accounts littered with unused log groups unsightly 😉
f
Yeah that’s definitely annoying.. U r right.. just found this CDK issue https://github.com/aws/aws-cdk/issues/11549
It seems to be on their radar.
m
There's a built-in catch-22. The custom resource to clean up log groups will automatically create log groups. 🤡
f
oh god.. u’ve definitely thought this thru 😂
We can definitely make SST do some cleaning up outside of CloudFormation, ie. calling AWS SDK to remove the dangling log groups. What do u feel about that?
m
That would be cool. Maybe make it a cli option or something 
--remove-log-groups
. Anyway, don't build it just for me but maybe somebody else cares about this too.
f
Yeah, let’s keep an eye on this. Took some notes here https://github.com/serverless-stack/serverless-stack/issues/1175
m
how to apply this naming convention to already deployed app ?
@Frank
f
Hey @Mehmet Ali SARAÇ sorry for the late follow up. Are you referring to Solution 1 above?
3 Views
Open in Slack
PreviousNext
Powered by