
Show HN: Serverless boilerplate to get started quickly - harijoe
https://github.com/harijoe/serverless-boilerplate
======
FridgeSeal
Hhmmm, I’m not really sure I see the point wthis: it’s really only “get
started quickly” for “the single exact case where you happen to be using JS
and DynamoDB and Webpack”. It doesn’t seem to really offer anything over the
base format that you couldn’t add in like 2 mins flat anyway.

~~~
yebyen
I disagree, as someone who has nominally used serverless (but never on Lambda)
and nominally used webpack (but with little experience outside the context of
building with webpacker in a Rails app), this actually looks like exactly what
I needed.

And I likely won't use DynamoDB, but little depth has been spent on explaining
anything at all about Dynamo, it works as an example of how to get to use
serverless plugins. To me this looks like just enough tutorial to cover the
top of one page without losing my interest.

Reading past the "serverless offline" part, I think I've just made up my mind
and will try the serverless framework again.

------
SpaceNugget
I think you should just have your boilerplate set up middy with your
middleware, that is the point of a boilerplate project after all.

You are depending on your own 'handly' project 'based on' middy but its really
just middy without the option to pick what middlewares you want.

your readme for handly says to

    
    
      import handly
      const handler = /* a handler */
      export handly(handler)
    

where handly is essentially

    
    
      import middy
      const handly = handler => middy(handler).use(/*a bunch of middleware*/
      export handly
    

I don't speak for the middy project and I don't know how long you have been
developer so I don't want to discourage you too much, but that seemed a little
off.

unrelated: I tried to check out your website and got a certificate error.

~~~
harijoe
Actually handly is just here to allow a single import on every serverless
handler. I haven't worked much on the readme yet, but the idea is to gather
all the "mandatory" middy middlewares as well as some middlewares I find
necessary into a single dependancy.

------
avip
sls user (though not very frequent) here. Read the entire readme, still can't
figure out what it does and why/if I need it. This is meant as constructive
feedback - please put the "what problem it solves" section at the top. I don't
know what "boilerplate" is.

~~~
yebyen
I think it's sort of advertising for handly/middy and the other "getting
started" things that the author uses himself.

If you're already using sls, you might not need it. I still haven't quite
figured out how one is meant to use Serverless, so I think this was written
for me. (I am a Rails dev with lots of Kubernetes experience, not that you'd
need that...)

------
semireg
If you prefer Webtask, check out this boilerplate I published last week.
[https://github.com/semireg/webtask-
webpack](https://github.com/semireg/webtask-webpack)

------
tuananh
isn't this already solved with serverless framework?

[https://serverless.com/](https://serverless.com/)

~~~
harijoe
The serverless framework does not offer the best developer experience out of
the box, that's why serverless boilerplate exists.

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

~~~
Aeolun
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.

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

~~~
Aeolun
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.

~~~
harijoe
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.

