Huge shout out to @Frank and the SST team for the NextJS support. I've fully migrated https://www.hautehijab.com over to AWS using SST/Seed.

I see lot of people happy about NextJS, is there any reason to move from ReactJS? Which use-cases are you guys covering with this framework?

@thdxr I see you in the niches of programming corners https://twitter.com/thdxr/status/1433132137033707525?s=21 😆 or maybe it’s just the corner of fp and things.

For someone who knows next to nothing about hardware, can someone explain when (assuming CDK and/or SST support it) I should consider changing my lambdas to the new ARM architecture? I realise that lambdas with binaries, like sharp, won't be able to use it, but otherwise, is it a no-brainer to move? If not, what are the considerations?

I was going through the design principles docs. It has this snippet of code which contains a couple of random

-

(hyphens), what are these? I’ve never seen these before, is this something new in javascript? Code snippet for reference :-

cron.attachPermissions([
  new cdk.aws() -
    iam.PolicyStatement({
      actions: ["execute-api:Invoke"],
      effect: cdk.aws - iam.Effect.ALLOW,
      resources: [
        `arn:aws:execute-api:${region}:${account}:${api.httpApiId}/*`,
      ],
    }),
]);

For those of you using vscode + eslint plugin, do you see linting errors in your editor using the standard sst setup?

So in my typescript monorepo I split up code into core and services. Core contains all business logic and services simply call into core. I've been thinking about this more - does this actually make sense or is this a legacy pattern from the non serverless world? If you're all in on serverless, sometimes your business logic is implemented as a step function and splitting that creates a two way dependency. The historical benefit of splitting is so that core functions can be called in a variety of places. For example writing some kind of migration script. But in the serverless world, are local scripts even the right pattern? Most scripts like that are better modelled as step functions and you might as well run everything in the cloud

So, I’ve a well performing SST based application right now. It is performing well, almost every endpoint that’s user facing is within 35ms response time. Fortunately, my API and my user base reside in the same region and so it was simple to achieve this thanks to AWS, the CDK, SST and SEED. Now, I need to take this further, I am targeting global outreach. In case of the dynamodb and aurora database, I can use global tables for the reads, the writes will have to be to the main table, that’s fine I guess. How would I go about global deployments for the API though, will I have to maintain region specific stages to achieve this? Also, suppose I go ahead with region specific stages how would the custom domain mapping work out? For ex: I’ve 3 stages, one in ap-south-1, one in us-west-1 and one in eu-south-1. If I use my current setup, my custom domains would be

<http://ap-south-1.dev.api.com|ap-south-1.dev.api.com>

,

<http://us-west-1.dev.api.com|us-west-1.dev.api.com>

and

<http://eu-south-1.dev.api.com|eu-south-1.dev.api.com>

. This would also create a problem of implementing some logic as to how to route requests from

<http://dev.api.com|dev.api.com>

to the appropriate region. I believe Lambda@edge is one possible solution but how would I use it here? I could use it for routing requests to appropriate regions, I’ve heard of people doing that. I would love it if you awesome people could chime in with your opinions and experiences on how to build a global serverless API. Most of what I’ve read up involves people creating k8s clusters across multiple regions and using a service mesh such as Istio or Linkerd to coalesce those clusters together at L4. It would be great if we could figure out a L7 solution which needs minimal intervention / management. I know, it’s a lot to ask, but I’d be grateful for any assistance.

Does anyone have an resources they recommend for CDK. Trying to have some understanding of what I’m doing with SST a little bit better.

Those of you that use Typescript - do you rely on the terminal output from

sst start

to catch errors or do you generally rely on your editor? Reason I'm asking is I'm seeing other code watching tools like Vite drop printing typescript errors in the console. Allows stuff to be reloaded faster if people are mostly looking at their editor. Can make it a bit trickier to find things you broke in other files though

For teams that are scaling like our team, I have to say that AWS's search UI in their console is totally abysmal. They're all implemented differently, and pagination and searching seems to be done client side. We have at minimum 2000 lambdas in between all our devs and live envs. Phew! Pretty interesting problem to solve later.

AWS console is down for me 😱

Show off 😉

Who is using RDS Data API?

Wow, how did I mis the --hotswap 😄 Quick question - how well does it work with SST? ANyone tried it?

I see a fair few people reporting issues around the use of yarn which makes me think that there must be big benefit to yarn over npm to persist with it. What are those benefits? Am I missing out with npm?

Did some benchmarking of some relational db stuff ahead of some of the work we're doing for RDS: https://thdxr.com/post/serverless-relational-showdown

Faced my first DDOS attack on my sst API, time to integrate AWS WAF and API throttling, 😅

just bought the new 14" MacBook Pro (M1 Pro chipset), and an M1 Mac mini. can’t wait to switch to Apple silicon!

Oh if I had a dime for every article written about serverless by someone who just doesn't get it.. https://thenewstack.io/please-serverless-have-an-opinion/

Just a typescript question here... I am using a library called "runtypes" to define all of my item types and to preform runtime validation. They have a feature called "pick" where I can reduce a type down to certain fields. Whenever I get an item from dynamo I want to support sending attribute projection expression to get only the fields I need and I am trying to figure out how to get the return type on the function correct. Here's what I currently have:

import { Record, String } from 'runtypes'

const DynamoItem = Record({
  id: String,
  something: String,
  else: String
})

export const getItem = async (id: string, attributes?: Parameters<typeof DynamoItem.pick>) => {
  const { Item } = await dynamo.get({ id }, { attributes })

  if (!Item) throw new Error('No item')

  return attributes ? DynamoItem.pick(attributes).check(Item) : DynamoItem.check(Item)
}

Currently its always the full "DynamoItem" type even when I call

getItem('myItemId', 'id')

I'm doing my first GraphQL project. For those of you using AppSync are you using codegen to manage resolvers?

so… has anyone else been let into the GitHub Copilot beta? I did the other day, and my mind is bloowwwnnn

Random question.. how many times are you hitting an issue where what you want to do is not available in CDK?

Just a thank you to everyone here who has assisted me and to sst and SEED. My microservices handled a record of 98k invocations per minute with P95 response times averaging 35ms. Never in my life could I’ve imagined to build an API that would handle 1.6k requests/s almost out of the box. Of course AWS needs to be credited for the cdk and cloudformation but I doubt I would be able to get this experience and community support from them. Thank you everyone, I really appreciate all what you try to do here. 😁🙏

Creating a test bed to see how sst scales for lots of stacks/functions

I did some experimenting and found a way to get the round trip time from us-east-2 to my machine in NY from 150ms down to 30ms. The question is, is this worth doing? How do people feel about roundtrip times to their machine? Is it fast enough? Do you feel slowness in other places that aren't the round trip?