Architect – A Serverless Framework

Is it inherently better in a way I'm not seeing?

Would arc be suitable enough for a new project to adopt?

But then our db on AWS is another $110, where it's included in heroku.

I know it will depend on your memory usage, etc. and as we grow, we expect to move to ec2, but I'm curious as to where/how you had such a huge difference in cost.

If you want to get started building serverless functions and APIs quickly, do it in your browser with https://code.xyz - we just released it along with an announcement of our most recent $2M in funding from Stripe [1] who join Slack and others as investors and customers.

Disclaimer: I’m the founder.

[1] https://stdlib.com/blog/stripe-code-xyz

> No integration w CF is absolutely true but you're also totally free to do that.

It just seems then that there is no real way for me as a developer to transfer all the accumulated knowledge I already have about AWS to your framework. Looking through Architect's source, it actually seems as if everything is done via the AWS Javascript SDK, which seems a bit ... odd, to say the least. I'd even venture as far as saying it goes against the AWS Well Architected Framework guidelines (1) (which recommends using CloudFormation).

> No auth support is false. We support session out of the box and you're free to impl any auth scheme of your choosing.

Apologies, I couldn't find any mention in the docs. I meant more in terms of using an AWS service such as Cognito Federated Identities, and in terms of protecting API routes with either AWS_IAM, API keys or Cognito Authorizers.

> CORS could be implemented in the file format....

An Architect project deployment is not exactly repeatable if I still have to go to the Web Console to enable CORS now, is it?

> Magic folders!

I personally would prefer either my project's root `node_modules` or a Webpack bundle be deployed, over which I have some measure of control. Node already has a hard enough time with its resolution algorithms, must we add to the madness?

> Serverless framework is an abstraction that is easily as verbose as CF

I can't agree with you on Serverless being as verbose as CloudFormation, and I think you should know better as someone who has dealt with the complexity of setting up API Gateway programatically.

> but I'm not interested in comparing to it because we have different goals.

I think the comparisons are fair - both Architect and Serverless claim to be "Serverless frameworks". I could be in the minority though.

> Serverless is an abstraction between clouds. If mulitcloud is your goal: use Serverless.

I mean... you're not wrong, but that's grossly oversimplifying it. I've personally added support for Serverless AWS projects to allow hooking up Lambdas to Cognito User Pool triggers. That's a pretty solid AWS-only use-case, that likely isn't available on other cloud platforms (or at least, I never implemented it for them).

> SAM is a flavor of CF which is def less verbose but still very vendor specific and …wordy.

Well, isn't Architect vendor-specific as well?

> This isn't a 'pet framework of the month'. I do take mild offense to that.

Apologies for that remark. I'll be honest - I'm not really interested in the story behind the framework, I'm more interested in what it brings to the table. I'm glad your project worked for you and your company, and I wish it the best, but personally I don't see why Architect couldn't have just been a layer of syntax sugar over SAM/Serverless framework. If there was a killer feature that's specific to Architect, I can't see it (unless you count the file format as a feature).

(1) https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-A...

code.xyz gives some 'hello world' examples, but it doesn't even link to any docs--it just goes "look how easy it is! Here, sign in to our service!" I went hunting for the stdlib docs, and it took me five minutes to figure out how to call my service by HTTP--apparently I just get a special username.stdlib.io endpoint that I can call, but when I clicked 'Calling Services' the first thing I got was a page that explained how to use bearer tokens. I still don't know how I can POST to this endpoint, but I have learned that apparently stdlib has invented the concept of a 'source code' because apparently having a pre-canned Slack bot integration is super-important to any self-respecting FaaS provider. Also apparently I can find prebuilt 'source codes' in the 'stdlib registry', but the docs don't link to said registry, only the aforementioned Slack integration. At this point I gave up; I don't have the patience to learn a brand-new meaning for 'source codes' when all I want to do is make an API call when I get a webhook payload, which I already know how to do in a dozen lines of Python.

I realize this complaint sounds kind of harsh; you're getting a lot of my frustration dumped on you. Really all I want is basically a managed, autoscaled version of Express.js. Maybe there's some reason it's like this (I've never worked with anything that could be remotely described as 'at scale', it's mostly been line-of-business apps with a few dozen users maximum, or at most a web shop that still runs on a single dedicated server), but it seems like all of the Serverless providers add a bunch of extra concepts and confusion on top of what should really be a simple principle. Or maybe I'm completely misunderstanding the point of Serverless and it's actually intended to solve a completely different problem I've never had--I'm also open to that explanation instead!