I feel like this architecture may not scale. There's a concurrency lambda invocations limit of 1000 per AWS account. Also there's a rate limit on Cognito calls. Hitting Cognito on each GET, POST, and PUT request may be a bit wasteful. They would've been better off using an authorizer on API gateway. It has caching there.
The main issue with this is migration, if in the future you need to migrate to container based like fargate, you’ll have to refactor your entire backend if you did not abstract it enough to work with something like Fastify/express/nestjs. The best approach is to create your backend using one of those, then deploy them to serverless lambda - yes, they will still work as normal, as if they are running on a persistent process like a server or container. Because later, when the need arises, you can migrate without much of a refactoring need. Also make sure to use a serverless database like FaunaDB over something like MySQL because they don’t keep a persistent database connection, they are 100% compatible with serverless architecture.
How do they know they will need to migrate? If they don't get big enough, they won't have to. If they get big enough, they can just rewrite their code base.
@@alexrusin it's the mindset of production level CI/CD and if they didn't think about it then they are not serious as it will be a tech debt sooner or later. Refactoring later cost more for a product.
It’s one of those things that you wouldn’t need to do often but when you do need to do it, it’s almost like the life of the product is on the line. So the success is highly dependent on how prepared you are for it. And if it comes to a point when you need to do it too often, then you have a bigger fish to catch.
Every minute that your product is not operating on an optimal level is money thrown out the window, imagine that on a much bigger scale, it would be millions in lost opportunities.
don't agree, it's actually quite trivial if you abstact your logic outside the event handler, I actually think that it's way harder to replace SDK calls, whether it is AWS or GCP or Azure, than going from serverless -> container
Amazing content like usual ! Thanks for all the work you're providing us with !
this ilograph tool seems amazing! Curious how hard it is to diagram with it
This is very helpfull i really needed this information
Great video!
Would be great to make a course how to make SaaS with AWS step by step.
great as usual, thanks bro)
I feel like this architecture may not scale. There's a concurrency lambda invocations limit of 1000 per AWS account.
Also there's a rate limit on Cognito calls. Hitting Cognito on each GET, POST, and PUT request may be a bit wasteful. They would've been better off using an authorizer on API gateway. It has caching there.
The main issue with this is migration, if in the future you need to migrate to container based like fargate, you’ll have to refactor your entire backend if you did not abstract it enough to work with something like Fastify/express/nestjs.
The best approach is to create your backend using one of those, then deploy them to serverless lambda - yes, they will still work as normal, as if they are running on a persistent process like a server or container. Because later, when the need arises, you can migrate without much of a refactoring need.
Also make sure to use a serverless database like FaunaDB over something like MySQL because they don’t keep a persistent database connection, they are 100% compatible with serverless architecture.
How do they know they will need to migrate? If they don't get big enough, they won't have to. If they get big enough, they can just rewrite their code base.
@@alexrusin it's the mindset of production level CI/CD and if they didn't think about it then they are not serious as it will be a tech debt sooner or later. Refactoring later cost more for a product.
It’s one of those things that you wouldn’t need to do often but when you do need to do it, it’s almost like the life of the product is on the line. So the success is highly dependent on how prepared you are for it.
And if it comes to a point when you need to do it too often, then you have a bigger fish to catch.
Every minute that your product is not operating on an optimal level is money thrown out the window, imagine that on a much bigger scale, it would be millions in lost opportunities.
don't agree, it's actually quite trivial if you abstact your logic outside the event handler, I actually think that it's way harder to replace SDK calls, whether it is AWS or GCP or Azure, than going from serverless -> container
wow!