begin.com helps address a lot of the issues here. If you want to deploy your own arc.codes is completely open source, works locally and generates standard aws sam flavored CloudFormation.
Yes! It's great. Scales very well. Costs almost nothing. Focused only on business logic. Provision in minutes. Deploy in seconds. I will never go back.
I'd like to leave the format discussion behind. Its the least interesting part and you rarely interact with it. I'll add YAML and JSON support so ppl can judge for themselves on merit against options that have tradeoffs.
Its absolutely suitable today. We have it in production in several apps. begin.com and arc.codes itself are two examples that have seen non-trivial traffic.
Also! Killer features galore but folks having trouble seeing past the fmt. You're just making so many assumptions here it's very clear you didn't try it. It's fast.. really fast. Faster than CF.
Long story short is this existed well before CF support did for Lambda. I don't think you're actually interested in learning and more interested in appearing to know what you're talking about so I'll leave it at that.
Hey np! Difference of views. No integration w CF is absolutely true but you're also totally free to do that. It doesn't prevent you from using it.
No auth support is false. We support session out of the box and you're free to impl any auth scheme of your choosing.
Custom file format is being well addressed in other comments. If you don't like it thats fine: enjoy YAML elsewhere.
CORS could be implemented in the file format…I'm personally not a fan for a variety of reasons but its open source. PR's welcome.
Magic folders! Absolutely. Structure is a good thing.
I don't find this negative. Serverless framework is an abstraction that is easily as verbose as CF but I'm not interested in comparing to it because we have different goals. Serverless is an abstraction between clouds. If mulitcloud is your goal: use Serverless. SAM is a flavor of CF which is def less verbose but still very vendor specific and …wordy.
This isn't a 'pet framework of the month'. I do take mild offense to that. Development of .arc started in 2015 for begin.com and got met with some serious production traffic (from things like Techcrunch and Venturebeat). It held up beautifully. We decided to pivot from our original producton into CI/CD for arc with begin.com because it is clear to us that it is a better way to build serverless apps.
Architect was officially open sourced in July of 2017 and donated to the JS Foundation to demonstrate the long term commitment to it. Development has been very active since. I stand behind my work, dedication to open governance and approach we're taking and, I think, I have the track record to ask for the benefit of the doubt when I say that.
- JSON has no comments
- YAML nesting tends to get deep which makes creating bugs very easy
- Both are become hard to read / edit in larger files
The primary issue is translating the intent into a machine syntax. The format we landed focused on minimalism to communicate intent.
The the file format is the least interesting thing about .arc but one of the most distinctive. An .arc file VERY QUICKLY communicates the project intent.
An example:
```
@app
hi
@html
get /
```
The equiv CloudFormation YAML is 700 lines. You'd have no idea what that project does without digging into the code. The .arc by contrast is extremely easy to both read and author. As the app grows it becomes very clear the project intent and were to find things.
We certainly could have created a new YAML thing but many projects already do that … and I'll let their work speak for itself.
Hey, one of the .arc authors and maintainers here.
Only one of each section is what we designed for though the validations for that might be broken (and if so we can fix right away). Nesting is limited to one level. No need for more that we've seen yet.
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!