Live data from Hacker News

Show HN: Serverless boilerplate to get started quickly

github.com

11–19 of 19 posts

Re: Show HN: Serverless boilerplate to get started quickly

#11
post #9

Christ, all you need is a function to stick in there. A "boilerplate" for serverless is an oxymoron.

That's unfortunately not true. Everything the boilerplate provides is both necessary to get a nice developing experience and not provided by default by serverless.

Re: Show HN: Serverless boilerplate to get started quickly

#13

OT: Who has experiences with serverless and which providers/services could yoi recommend?

I do, and if you are building a large app, I would recommend against using serverless. At least the library, since it has a limit of about 20 endpoints unmodified.

Re: Show HN: Serverless boilerplate to get started quickly

#16
post #13

OT: Who has experiences with serverless and which providers/services could yoi recommend?

I do, and if you are building a large app, I would recommend against using serverless. At least the library, since it has a limit of about 20 endpoints unmodified.

I did not know that, could you share a proof to back this statement ?

Re: Show HN: Serverless boilerplate to get started quickly

#18
post #16
post #13

Earlier quoted context omitted.

I do, and if you are building a large app, I would recommend against using serverless. At least the library, since it has a limit of about 20 endpoints unmodified.

I did not know that, could you share a proof to back this statement ?

Try adding 40 endpoints to one serverless.yml file. You will quickly run over the 200 resource limit for cloudformation.

Actually, now that I think of it, since this is an AWS limitation, it may actually be fine on other providers.

Re: Show HN: Serverless boilerplate to get started quickly

#19
post #18
post #16

Earlier quoted context omitted.

I did not know that, could you share a proof to back this statement ?

Try adding 40 endpoints to one serverless.yml file. You will quickly run over the 200 resource limit for cloudformation. Actually, now that I think of it, since this is an AWS limitation, it may actually be fine on other providers.

I guess the limit could be avoided by using only one endpoint and use the path and HTTP method to decide which logic to execute though.
Post reply on HN