One of the biggest promises that I can see about the serverless movement is:<p>The ability to have the infrastructure isolated from the raw code being written. (Think more of a grid computing and automatic planning being included)<p>Unfortunately, I'm not seeing it. I'm seeing that it's heavy on the initial business idea: "Get people to pay more and utilize our servers better".
DISCLAIMER: I've contributed a few times to the Serverless framework.<p>I like some things about Architect, but there are things that just don't make sense:<p>- Integrations with Slack but no way to define custom CFN resources<p>- No authentication support<p>- Custom file format (3)<p>- Not being able to set CORS in this custom file format (4)<p>- Magical vendor folders (5)<p>I am sorry for the negativity, but brianleroux has posted in this thread several times claiming his framework saves 700-line CloudFormation templates. What I don't see is him comparing snippets with say, the Serverless framework(1), or AWS SAM(2). He seems to portray the choices as either his pet-framework-of-the-month or plain old CloudFormation, and that's just not true. That's not to say Serverless or AWS SAM are perfect (they most certainly have their warts), but they are both arguably more mature and have larger communities behind them.<p>(1) <a href="https://serverless.com" rel="nofollow">https://serverless.com</a><p>(2) <a href="https://github.com/awslabs/serverless-application-model" rel="nofollow">https://github.com/awslabs/serverless-application-model</a><p>(3) <a href="https://arc.codes/quickstart/arc-project-layout" rel="nofollow">https://arc.codes/quickstart/arc-project-layout</a><p>(4) <a href="https://arc.codes/guides/cors" rel="nofollow">https://arc.codes/guides/cors</a><p>(5) <a href="https://arc.codes/guides/sharing-common-code" rel="nofollow">https://arc.codes/guides/sharing-common-code</a>
I actually like this. I build serverless apps all the time, mostly manually.<p>Serverless framework is alright, but I felt it was really bloaty. There was just so much going on. Too many variables and it confuses the user. This looks clean. I might give it a try. I didn't find a link though in your blog.
I’m a big fan of code generation. I can usually adapt to new formats or concepts without too much issue. I feel that while it’s not difficult to build up strings dynamically, the harder part can be overwriting and verifying values, and working with logic. That’s my main issue with YAML over JSON. How would you recommend working in this area with this format, or benefits over JSON?
hey nice project.
I had my Show HN recently. I've built a tool to also use it in a serverless fashion. Check it out at <a href="https://triggerfs.io" rel="nofollow">https://triggerfs.io</a><p>It has been a month since then and the feedback was awesome.<p>I would love to hear your opinion and how you could possibly use it (use case), since you can do a lot with serverless/FaaS etc.<p>cheers
My problem with the serverless
movement is database connection pools.<p>Every time a function runs, it has to create a new connection to the Postgres database so it can run a query. This is super slow, and dead in the water. If I have to maintain a separate server to have a global connection pool, I might as well just have a server for my API as well.
I think this whole idea of pushing "serverless" as a concept to engineers is deceptive at best and damaging at worst when you think about all of the naive new developers entering the industry having to shovel all of this shit into their minds alongside proven technologies and conventional formats.<p>What does "serverless" framework really tell veterans? Who are you selling to? What are the considerations for adoption?<p>There's so many questions that pop up before I even look at the software, and once I did, there's more questions which obscure the point. Why should I use your bullshit?<p>Worse, 5 years in after a company has adopted this junk, some poor sap is going to have to maintain it after being 100k SLOC deep in it, with no vision of how to port out of it alongside meeting existing technical task completions, at which point this will have become completely irrelevant.