Is there a github link I missed?
https://arc.codes for docs and src can be found at https://github.com/arc-repos
Architect – A Serverless Framework
51–60 of 76 posts
Re: Architect – A Serverless Framework
#52I’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?
YAML is far easier for humans, and has a few advanced features (node references) that are REALLY nice for any kind of configuration, since you can re-use blocks. Let's say you have to define a bunch of services, with mostly the same environment variables. You can make a "defaults" node, and then a) reference that node in the service descriptions to re-use those env vars, and b) selectively override those defaults in…
YAML is bad because it has far too much magic behavior. See, for example, Ansible's big list of gotchas: https://docs.ansible.com/ansible/latest/reference_appendices...
Re: Architect – A Serverless Framework
#53Earlier quoted context omitted.
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!
There are many issues with both formats:
- 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.
Re: Architect – A Serverless Framework
#54Earlier quoted context omitted.
it's precisely true; but I get your gist. if you enjoy writing that much cloudformation then by all means have a good time!
I don’t think you get my gist about syntax vs information. I can express the same data in a different format, in the same way that JSON and YAML can often be transformed into each other. You are pulling a straw man by implying that requires much cloudformation, which is completely unrelated. Besides, CF is a good example of how you can use two different syntax to describe the same information.
> I don’t think you get my gist
if so, leading with "just not true" contributed to this (which seems like a non-sequitur if you're not saying the claim is false)
Re: Architect – A Serverless Framework
#55Earlier quoted context omitted.
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!
There are many issues with both formats: - 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 .a…
[deleted]
Re: Architect – A Serverless Framework
#56Earlier quoted context omitted.
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!
There are many issues with both formats: - 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 .a…
> The equiv CloudFormation YAML is 700 lines
Accepted, but that's not the topic of debate.
The issue here is that you can write the example you gave in YAML like this
app:
hi
html:
get /
Hope I explained my point correctly.
This is just a matter of UX/ API, not how it works.
If you somehow felt that I disrespected your work, forgive me.
Re: Architect – A Serverless Framework
#57Earlier quoted context omitted.
There are many issues with both formats: - 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 .a…
> The equiv CloudFormation YAML is 700 lines Accepted, but that's not the topic of debate. The issue here is that you can write the example you gave in YAML like this app: hi html: get / And it could still generate the same result. But this way people can write the config in a more familiar syntax. Hope I explained my point correctly. This is just a matter of UX/ API, not how it works. If you somehow felt that I disr…
I agree. And isn't that exactly the solution the Serverless framework implemented?
Re: Architect – A Serverless Framework
#58Earlier quoted context omitted.
> The equiv CloudFormation YAML is 700 lines Accepted, but that's not the topic of debate. The issue here is that you can write the example you gave in YAML like this app: hi html: get / And it could still generate the same result. But this way people can write the config in a more familiar syntax. Hope I explained my point correctly. This is just a matter of UX/ API, not how it works. If you somehow felt that I disr…
I agree. And isn't that exactly the solution the Serverless framework implemented?
I am not sure, but serverless requires more config and tweaking as compared to arhitect.
In contrast, serverless is a more mature and flexible platform.
Re: Architect – A Serverless Framework
#59Earlier quoted context omitted.
I agree. And isn't that exactly the solution the Serverless framework implemented?
I am not sure, but serverless requires more config and tweaking as compared to arhitect. In contrast, serverless is a more mature and flexible platform.
It was more of a rhetorical question, Serverless definitely uses .yml
https://serverless.com/framework/docs/providers/aws/guide/se...
Obviously that's a verbose example and there are defaults for most everything AFAIK.
Anyway, Architect seems cool too! Always down for more options and competition!
Re: Architect – A Serverless Framework
#60DISCLAIMER: I've contributed a few times to the Serverless framework.
I like some things about Architect, but there are things that just don't make sense:
- Integrations with Slack but no way to define custom CFN resources
- No authentication support
- Custom file format (3)
- Not being able to set CORS in this custom file format (4)
- Magical vendor folders (5)
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.
(2) https://github.com/awslabs/serverless-application-model
(3) https://arc.codes/quickstart/arc-project-layout