Live data from Hacker News

Architect – A Serverless Framework

blog.reifyworks.com

31–40 of 76 posts

Re: Architect – A Serverless Framework

#31

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.

arc.codes is the main docs site. happy to help if you have any questions.

Re: Architect – A Serverless Framework

#33
post #2

Great! 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!

This is just not true. The discussion is about the syntax (.arc vs yaml), not the information it contains.

Re: Architect – A Serverless Framework

#34

Earlier 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.

exactly

Re: Architect – A Serverless Framework

#35

Earlier 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.

it's precisely true; but I get your gist. if you enjoy writing that much cloudformation then by all means have a good time!

Re: Architect – A Serverless Framework

#36
My problem with the serverless movement is database connection pools.

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.

Re: Architect – A Serverless Framework

#37

Earlier 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.

inline comments are handy for pointing out "non standard" configuration settings for your enviroment. especially on production systems.

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

#38

Earlier 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…

JSON5's support for unquoted keys seems like a misfeature. Not to mention that (by its nature) it has the same (lack of) support burden as any other new configuration format. If you're going to go through that frustration and incompatibility, why not pick something better suited to the job?

Re: Architect – A Serverless Framework

#39

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. What does "serverless" framework really tell veterans? Who are you selling to? What are the considerations for adoption?…

> I think this whole idea of pushing "serverless" as a concept to engineers is deceptive at best and damaging at worst…

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

#40

Don'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!

What problems did you solve and how were they solved with your new format? I'm neutral in this argument at this point, so I'd like to hear your justifications. Thanks!
Post reply on HN