Hi all, I'm in the design/architecture phase for a new, green-field system and am considering using serverless, and thus SST. https://journal.plain.com/posts/2022-02-08-a-magical-aws-serverless-developer-experience/ kind of blew my mind. I watched a variety of talks on AWS serverless architecture patterns, where it seems that AWS recommends a blend of choreography (event-driven architectures with AWS EventBus) and orchestration (step-by-step definitions using AWS Step Functions), for example: . These kinds of architectures seem to rely heavily on features like API Gateway's native AWS service integrations, i.e. for API Gateway to call EventBridge's PutEvents or Step Functions's StartExecution: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-aws-services-reference.html . Additionally, the ability to have API Gateway call AppConfig's GetConfiguration, without a Lambda intermediary, seems like a really powerful way to set up a kind of

/info

or

/meta

API endpoint that, with caching (even minimal, one-minute caching) set up in a CloudFront distribution, basically guarantees nearly free usage (basically actually guaranteed after setting up enforcement, e.g. https://www.wellarchitectedlabs.com/security/300_labs/300_multilayered_api_security_with_c[…]and_waf/3_prevent_requests_from_accessing_api_directly/ ). From reading the SST book, and what I'm finding in the SST docs, that SST would rely on CDK escape hatching to set most of this up? In other words, that I should forget the higher-level

Api

abstraction that SST offers and basically only use the core/required

App

,

Stack

, and

Function

constructs? If I use the CDK escapes, can I still add stuff like the CDK-created API Gateway to the SST Console? It seems like the pattern is to use the "import an existing Http Api" https://docs.serverless-stack.com/constructs/Api#importing-an-existing-http-api option, thus a) create the API Gateway through CDK and then b) create an

Api

, relying on the CDK-created API Gateway as the canonical API Gateway code, and import it from the CDK, therefore c) because it was imported, now it will be visible in the SST Console? Basically I want to try and find a way to get the core value of SST - Live Lambda Development, the SST Console, using Seed for CI/CD, while architecting to take full advantage of the above patterns. It seems to me like the high-level constructs (

Api

) are well-documented and serve as a great way for developers who aren't as well-versed in advanced AWS architectures to hit the ground running, but the more advanced approaches aren't so clear. To be clear - I don't expect the higher-level constructs like

Api

to fully track AWS upstream and support every tiny feature immediately (I don't think that's a reasonable expectation for anyone who builds abstractions), and if SST's core value fits well into advanced architectures then I'm really excited about it. Thanks!

(Opinions are my own) I was in your shoes about a year ago, and made the decision to go completely serverless, at least until a solid reason presented itself not to. I had experience at a previous company with serverless architecture, and a good sense of upsides and downsides, and one of the main downsides was running locally. Doing so required “raising atlantis from the ocean” (my words) using docker with a number of containers. At this company, we also had separate developer AWS accounts, a notion I can firmly say was a terrible experience (despite Plain telling you otherwise), and that initial developer training time was staggeringly high. SST presented a way to have local-like development, while needing to run nothing else locally, and quick access to slapping one piece of infrastructure into another, shared set using stages. This combo represents about 90% of the benefit of SST for me, and at the time it was 100%. This matches your quote:

and basically only use the core/required

App

,

Stack

, and

Function

constructs?

Later,

NextJsSite

showed up, and I was using Amplify at the time which was a terrible CDK experience, so I switched (this is the other 10%). This is a unique offering that no one else in the market has in the CDK. v1 changed the interfaces some, and made the CDK escape hatch much more prominent, but aside from maybe the code looking a bit ugly, there is no real downside to this over the CDK itself, and you can always switch back and forth so long as you are in a

sst.Stack

. Our workplace choice has been to draw the line at

alpha

, as in, we use CDK constructs for most infrastructure (including

App

and

Stack

), especially things like persistence that MUST never change and there only be one of, but when using something with stages or a package in

alpha

, we are likely to use SST. Also when SST has a unique offering, of course, like Next. All of this means we basically use your 3 listed, plus

Api

, and use lots of escape hatching on

Api

. FWIW while getting the team spun up, I havent regretted a single decision thus far, and the developer productivity curve is much steeper than other processes I have seen. SST learning curve was near zero, setting up AWS profiles was far worse. 🙂

Nice! Thanks @Derek Kershner In my specific case, the frontend is a mobile app (Flutter), so

NextJsSite

and its web frontend similars aren't relevant. I saw the SST + Flutter guide: https://serverless-stack.com/examples/how-to-create-a-flutter-app-with-serverless.html which looks fantastic.

With mobile, I always worry about the “Sync” aspect, so that it will continue to work offline. AppSync is, in my own opinion, far more difficult initially than something like Firestore and has weird interfaces, but Firestore has other downsides, like security, which has a super weird interface. I am not sure the example covers this scenario, and I am definitely not an expert here.

Oh I wasn't planning on AppSync / GraphQL at all - my opinion on GraphQL is that it's intended to allow frontend developers to work independently without pestering backend developers for changes to the API. Adding GraphQL at the beginning of a project, where there's only a handful of people working on it, is premature - much easier to just add the relevant routes as needed. Interesting re. using

stage

only for code-only splits, I'll have to think about that a little more closely in the design. Anyway, another reason not to use the SST

Table

it seems.

Hey ari! One other thing I'll add is if you're new to serverless, a lot of what you'll be reading especially from the AWS world is on the "extreme" side of serverless which is functionless this basically means direct service to service integrations without a lambda glue in the middle. while it is super cool and a future I'm excited about I personally do not feel that it is the way the avg company should be building today there are companies who do go to that extreme and commit to it but it's still early and pretty rough and they're really on the edge. the blog post from the plain company - most of their code is running in a single graphql lambda for their API and then they have functions consuming events off eventbridge. I think that setup can work for 90% of companies today and that's where SST is focused right now

We went with GraphQL from the get-go, FWIW, but we have a very-public and very flexible API, and would not recommend in all cases. It hasnt been cumbersome, though. Agree with Dax right above me, trying to use infra for absolutely everything rather than writing any code at all has gotten us into trouble in a few cases, and we have escape hatched into a lambda.

Great, yeah I definitely don't plan on zero lambdas, if I did I'd probably just use the CDK directly

your thoughts are in line with my experiences. 🙂 it really sounds like you are on what I would consider the right track.

That's pretty awesome! I heard early horror stories (years and years ago) about Lambda/serverless being overly expensive at scale, but the more research I do, the more it seems that high costs are a symptom of poor design rather than inherent to the paradigm. Glad to hear you're succeeding at scale

Consider

provisioned concurrency

to be your escape hatch for scaling lambdas. There is now a little machine learner that can actually help set this for you. It takes the cost of a lambda more or less down to the cost of Fargate, which is pretty cheap. We also take the extra steps of using HTTP API from APIG, SNS instead of EventBridge, etc. to make things cheaper. Tradeoffs.

It seemed to me (from my research) that REST APIGW is the earlier variant on APIGW and AWS would rather suggest that people use HTTP APIGW anyway moving forward? Especially considering that it's 1/3rd the cost? Stuff like REST APIGW direct to DynamoDB sounds cool until you realize that you pay an additional $2.50/million calls to avoid $0.20/million requests on Lambda plus, what, another few pennies for a million requests at 128 MB and 10 ms average, to transform the request for DynamoDB? Yeah HTTP APIGW makes more sense. I'll take another look at replacing EventBridge with SNS where appropriate (no seeming need for complicated event rule logic), thanks. Do you have a link to the automatic setting of provisioned concurrency? Sounds interesting

I’ll take another look at replacing EventBridge with SNS where appropriate (no seeming need for complicated event rule logic), thanks.

Dont take my word as gospel here, we just didnt need the extra features and the 300 rule limit was going to hurt us.

https://www.sedai.io/ is a 3rd party tool that sounds similar tool to DevOps Guru for RDS

@Drew yeah I have a feeling I'd need it eventually, but it's not as important in the early design phase. More of an optimization to keep in mind if the project succeeds

Totally