uh oh.. :grimacing: ```[Info at /dev-microservices...
# general
s
uh oh.. 😬
Copy code
[Info at /dev-microservices-api] Number of resources: 408 is approaching allowed maximum of 500
crap crap crap
a
Hahaha welcome.
😂
s
what did you wind up doing? am I going to have to split up my API?? e.g.
<https://api-tracks.reelcrafter.com>
,
<https://api-reels.reelcrafter.com>
, etc?
technically, the front end could just call Lambda functions directly.. there’s no need for an API
a
I had to delete some old stuff.
s
but.. I might run into some unexpected issues with an API-less approach
I can’t delete anything, it’s all important
a
😞
Can’t be increased?
s
nope, hard limit
a
I think you can as to aws support.
Mmmmm.
s
it used to be 200(!). they raised it. it should’ve been raised to 1000
a
Yeah I thought you can ask to support.
s
nope. some limits can be increased, others can’t.
a
Sh*t.
s
gonna do some reading up & get some ideas.
oh! you can add multiple domain mappings
though.. can you do this cross-stack?
a
Yes, this is what I use.
1 single api, with many paths.
Actually, many mappings to other apis.
But 1 entry point.
Like this…
r
Maybe a sledgehammer but you could stick an express server inside a single lambda and then route inside that
s
done that before.. it’s not a good approach
then your Express server is in charge of verifying JWT, CORS, everything. much easier to let API Gateway handle those
also, 1 Lambda = larger attack surface, and single point of failure.. so your whole app is down if something goes wrong
oh wait.. this won’t work in dev mode where I don’t assign domains to the API 😕 so it’ll just generate a bunch of
<http://xxxxxxx.execute-api.us-east-1.amazonaws.com|xxxxxxx.execute-api.us-east-1.amazonaws.com>
urls
so I will indeed have to have in my .env file,
API_TRACKS_URL
,
API_REELS_URL
, etc. yikes
a
why not use a single lambda for multiple http methods of the same route? so a users lambda could route to
GET /users
,
GET /users/{id}
,
POST /users/sessions
,
DELETE /users/sessions
. You’d thus reduce the number of lambda functions per service.
s
because, they all have different schemas
I would lose schema validation for the incoming request
a
Ah! I see, you could validate directly using ajv and json schema, it definitely complicates your logic but you have a better control on resources.
s
yeah, right now middy is using ajv to check the schema & automatically reject the request w/ a detailed error (in dev)
it’s cool, I’ll just split up the stack. we’re gonna refactor to GraphQL at some point anyway
a
yep, also do check out json schema compilation, definitely reduces the validation time.
s
I wonder what happens if a dev’s AWS account tries to create a custom domain when the Route 53 domain & SSL cert exist in the primary AWS account
it would be much nicer to just have a single domain, formatted like
api-<AWS account ID>.<http://domain.net|domain.net>
r
Yeah, don't like the express route (pun intended) either. Just throwing out ideas