Next.js API routes acting as duplicate of AWS lambdas?
Unanswered
Devon Rex posted this in #help-forum
Devon RexOP
When using Next.js deployed on Amplify and configuring AWS services via SAM AWS serverless, it looks like API routes are automatically converted to lambdas. Does this mean that if I write my own lambdas that are called by these API routes, that after deployment they will be basically running two lambdas per call? Is the use case to instead to just call lambdas directly from the component or instead just allow the auto-conversion of api routes to lambdas and not have your own custom lambdas written?
I am using SAM templates and have lambdas for handling DB calls and am calling them from API routes - all hosted on amplify. Does Next have a way of handling lambda specifications/paramaters/permissions/etc. if the idea is to only use API routes?
I am using SAM templates and have lambdas for handling DB calls and am calling them from API routes - all hosted on amplify. Does Next have a way of handling lambda specifications/paramaters/permissions/etc. if the idea is to only use API routes?
40 Replies
Serengeti
If your api route is converted into a lambda, and it calls some other lambda, then yes, it will be a chain of two lambdas, although caching might influence it.
Basically, you should create api routes calling other apis if you need to call them from the client and you want to hide the original api. For example if you need to supply a secret key that should only be known by your server.
Basically, you should create api routes calling other apis if you need to call them from the client and you want to hide the original api. For example if you need to supply a secret key that should only be known by your server.
If you don't need to hide it, you might as well call it directly
Devon RexOP
Excellent info, thanks!
@Devon Rex Excellent info, thanks!
Serengeti
Basically, there's no rule here, just do what makes sense to you
Devon RexOP
In this same scenario, are you familiar with NextAuth and whether using an API route is needed to validate the token for API calls?
Nothing is currently decoding the JWT in my lambda, so I am trying to figure out if it's all done under the hood in NextAuth or if the use of an api route is involved here somehow.
@Devon Rex In this same scenario, are you familiar with NextAuth and whether using an API route is needed to validate the token for API calls?
You can validate tokens in middleware
idk if the next-auth template has been updated yet, I know they were working on an updated example
Devon RexOP
Can you elaborate a bit? Middleware built into NextAuth? Something I need to write between my component and NextAuth?
Devon RexOP
Will this negate the need to do any further checking on AWS?
https://github.com/gitdagray/next-auth-intro/blob/main/src/middleware.ts
Looks like someone made an example here, mileage may vary
Looks like someone made an example here, mileage may vary
@Devon Rex Will this negate the need to do any further checking on AWS?
Not if your additional lambdas are publicly accessible, it would be better just to use route handlers. They create lambdas for you.
but your lambdas I guess could still hit a token check endpoint in your next.js app
Devon RexOP
So that's my initial question above. I know that routes convert to lambdas on amplify, but then how do you control for all the specifications that go into a SAM template for controlling lamba rules, policies, etc. in that case?
I would assume that has to be done manually in console if created via routes.
I'm not sure what you would need to add, it should generally be self-managed
Devon RexOP
There are a lot of configuration options for lambdas.
The settings would be handled by the framework, no?
Devon RexOP
The settings are generally controlled in SAM templates.
and deployed seperately from the front-end
I can 1) call these lambdas from Next, which are already created by my deployed templates, 2) call the lambdas via api routes if that's of any addiitonal benefit (but this now creates an additional lambda - so 2 per call), or 3) use api routes, auto-create the lambdas and not manage them via SAM templates, however I don't see any way to control configuration of lambdas this way - and there are situations where you might want specific parameters on different lambdas.
I thought the point of amplify was that it provides a managed service for you. They don't need to be manually managed, because it's configured by the framework. And it's not always 1:1 on if it'll create a function or a static file in S3, or something on cloudfront. IIRC they recommend using SAM and CloudFormation directly if you really want that level of control.
Devon RexOP
I'm just using Amplify for the front-end hosting. It's not managing any of the backend in this case.
Yea, that's precisely why I use SAM templates.
But in this scenario, the api routes in Next that are being hosted on amplify convert to lambda serverless functions.
Thus the two functions if I use routes + templates.
It seems to me that I should just ignore routes here, but am I losing any Next.js or NextAuth magic that comes from using routes?
Next.js is a full-stack framework. It's intended to handle (almost*) everything you would need for web applications. So using backend features, like api routes, in next would create an additional layer in your application. Even though it's "serverless" it's still a server. I don't think amplify has support for the app dir yet, so it's really only compatible with pages. Working outside of the framework could mean doubling-up on some features, but it would kinda be considered an "external service" in arch terms.
*except websockets
Worth noting that amplify is catching up to vercel in this tech (even though vercel is hosted on AWS). Azure currently has full support for the app directory.
I'd consider static export as well if you want to keep it frontend-only
(but you would lose lots of features of next)
Devon RexOP
I'm using it in pages mode anyhow, so that's no problem - and also using websockets via AppSync. Would yo be suggesting that React would be a better fit for a SAM-template driven backend in that case? I do like a lot of the other features that Next provides such as the hybrid static/SSR options and many of the other bells and whistles.
There are components of my application that would benefit from the hybrid approach.
It sounds like ignoring routes is the way to go in this case and would not necessarily be such a big loss feature-wise.
I've never used any cloud-specific architecture outside of kubernetes because I'm not a fan of vendor lock, but I'd say you're pretty well in uncharted territory. Idk if there's really a "right answer" for this, but it could be as easy as proxying requests from next back to a gateway or something. I would treat next as its own independent service that is managed by amplify, and expand out where needed.
Devon RexOP
Which makes me wonder if it makes sense if it's such uncharted territory. 😄
I've been kinda researching enterprise applications of Next, this is a potential pattern I've been looking into. In theory the whole app could be self-contained (with all the benefits of serverless).
LTDS: Long term data storage
RTD: Real-time data
LTDS: Long term data storage
RTD: Real-time data