High Serverless Function GBH
Answered
Bombay posted this in #help-forum
BombayOP
Hi guys, I am new to NextJs and Vercel and just deployed a popular app on it. I'm noticing very high servless function usage. I think its related to my drop down search bar in a client component, which when typed into, makes a call to api/suggestions/route.js. In route.js I make a call to a 3rd party api and return a list of dropdownoptions for the dropdown search bar. Each letter makes a call to this route, and I need to maintain that functionality. Is there any way to reduce my servless function usage with this setup. Would I be able to move this call to the client, without exposing the api key, which is included in the url of the api call?
Answered by joulev
no you cannot move that call to the client without exposing the api key. but you can debounce the input so it only fires one request after there are no new keystrokes for, say, 500ms (instead of firing a new request on every keystroke)
4 Replies
@Bombay Hi guys, I am new to NextJs and Vercel and just deployed a popular app on it. I'm noticing very high servless function usage. I think its related to my drop down search bar in a client component, which when typed into, makes a call to api/suggestions/route.js. In route.js I make a call to a 3rd party api and return a list of dropdownoptions for the dropdown search bar. Each letter makes a call to this route, and I need to maintain that functionality. Is there any way to reduce my servless function usage with this setup. Would I be able to move this call to the client, without exposing the api key, which is included in the url of the api call?
no you cannot move that call to the client without exposing the api key. but you can debounce the input so it only fires one request after there are no new keystrokes for, say, 500ms (instead of firing a new request on every keystroke)
Answer
@joulev no you cannot move that call to the client without exposing the api key. but you can debounce the input so it only fires one request after there are no new keystrokes for, say, 500ms (instead of firing a new request on every keystroke)
BombayOP
Hi and thank you! I had a few other ideas in addition to this if you don't mind thinking them over.
1. Could I cache the results of the requerst for maybe any 2 or 3 characters types. i.e. a user types in ("the") and the request hits the cache instead of the api?
2. Could I also reduce the memory allocated to /api routes? If I reduce that memory, will it signicantly slow down the functionality of the search bar? I see the minimum memory is 128mb and my calls to /api are sometimes hitting 250mb
3. Moving some of them to edge functions (not super familar with this, but hoping I can spread out some of the usage?)
1. Could I cache the results of the requerst for maybe any 2 or 3 characters types. i.e. a user types in ("the") and the request hits the cache instead of the api?
2. Could I also reduce the memory allocated to /api routes? If I reduce that memory, will it signicantly slow down the functionality of the search bar? I see the minimum memory is 128mb and my calls to /api are sometimes hitting 250mb
3. Moving some of them to edge functions (not super familar with this, but hoping I can spread out some of the usage?)
@Bombay Hi and thank you! I had a few other ideas in addition to this if you don't mind thinking them over.
1. Could I cache the results of the requerst for maybe any 2 or 3 characters types. i.e. a user types in ("the") and the request hits the cache instead of the api?
2. Could I also reduce the memory allocated to /api routes? If I reduce that memory, will it signicantly slow down the functionality of the search bar? I see the minimum memory is 128mb and my calls to /api are sometimes hitting 250mb
3. Moving some of them to edge functions (not super familar with this, but hoping I can spread out some of the usage?)
1. Yes you could implement any kind of cache you want, with Redis or something similar as the caching storage. You run the query in the server then send both the response to the client and to the caching service.
2. It depends on how you host it. On Vercel I doubt you can do it.
3. Yes edge functions are a lot cheaper. If possible move your routes to the edge runtime.
2. It depends on how you host it. On Vercel I doubt you can do it.
3. Yes edge functions are a lot cheaper. If possible move your routes to the edge runtime.
@joulev 1. Yes you could implement any kind of cache you want, with Redis or something similar as the caching storage. You run the query in the server then send both the response to the client and to the caching service.
2. It depends on how you host it. On Vercel I doubt you can do it.
3. Yes edge functions are a lot cheaper. If possible move your routes to the edge runtime.
BombayOP
Thanks again, for number two, someone sent me this link: https://vercel.com/docs/projects/project-configuration#functions