I actually like this. I build serverless apps all the time, mostly manually. 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.
Architect – A Serverless Framework
31–40 of 76 posts
Re: Architect – A Serverless Framework
#32Lambda and SNS are super expensive. I'll skip it.
Re: Architect – A Serverless Framework
#33Great! Another file format for me to learn. Why can't everyone use one of the standard file types, like YAML/JSON?
To summarize: a three line .arc file yields a 700+ CloudFormation YAML document. Let me know if you have any more questions!
Re: Architect – A Serverless Framework
#34Re: Architect – A Serverless Framework
#35Earlier quoted context omitted.
To summarize: a three line .arc file yields a 700+ CloudFormation YAML document. Let me know if you have any more questions!
This is just not true. The discussion is about the syntax (.arc vs yaml), not the information it contains.
Re: Architect – A Serverless Framework
#36Every 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.
Re: Architect – A Serverless Framework
#37Earlier quoted context omitted.
I really wish people wouldn't use JSON for configuration. The lack of comments and shortcomings in formatting abilities make it particularly ill-suited. { "_comment": "this is a comment" } is cringeworthy to. It's great for transport, but horrible for static file config. YAML is good, but not to everyone's taste. I've been using it for a long time (as a ruby developer) but many people I know find it ugly. I think Arc…
Rather than inline-comments I've always had separate documentation. This helps prevent trying to cram all the edge case caveats and everything into the configuration file.
It aids in troubleshooting greatly to have inline comments point out "odd" settings in configuration without having to look at seperate (usually old) documentation.
Re: Architect – A Serverless Framework
#38Earlier quoted context omitted.
I really wish people wouldn't use JSON for configuration. The lack of comments and shortcomings in formatting abilities make it particularly ill-suited. { "_comment": "this is a comment" } is cringeworthy to. It's great for transport, but horrible for static file config. YAML is good, but not to everyone's taste. I've been using it for a long time (as a ruby developer) but many people I know find it ugly. I think Arc…
Then use json5. Super weak excuse. Or use yaml or some other format and pipe it into some to-json converter. Also, json has json schema which tools like VS Code support. They can autocomplete your config. Pretty promising over most other tooling. But coming up with your own config has pretty much all the downsides. Yeah, you can invent some cuter syntax. But now your users can't even get syntax highlighting in their…
Re: Architect – A Serverless Framework
#39I 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. What does "serverless" framework really tell veterans? Who are you selling to? What are the considerations for adoption?…
To me, serverless is as normal a progression of abstraction as anything in software development. What about FaaS crosses a line for you, where (presumably) PaaS doesn't?
Re: Architect – A Serverless Framework
#40Don't invent some other file format please, just use whatever most people use unless you have a real specific reason for it.
Author here: we did? Pretty well documented issues w JSON and YAML (coming from CloudFormation perspective). Both have problems (that are unique to each) so we created a format for solving that. If you like JSON and YAML and don't mind those issues you are well served by existing solutions. Cheers!