Don't invent some other file format please, just use whatever most people use unless you have a real specific reason for it.
Architect – A Serverless Framework
11–20 of 76 posts
Re: Architect – A Serverless Framework
#12One of the biggest promises that I can see about the serverless movement is: The ability to have the infrastructure isolated from the raw code being written. (Think more of a grid computing and automatic planning being included) Unfortunately, I'm not seeing it. I'm seeing that it's heavy on the initial business idea: "Get people to pay more and utilize our servers better".
> The ability to have the infrastructure isolated from the raw code being written. (Think more of a grid computing and automatic planning being included) Can you elaborate? It sounds like you're saying that if you write code that's deployed to a serverless infra you end up with 'serverless code'. This hasn't been my (very limited) experience - where the serverless stuff is just a thin layer around your business logic…
I think they’re saying that you can expose your lower-level atomic APIs as serverless functions, and then, separately, build a “routing and aggregation layer” that exposes APIs that people might actually want to use. And that, for a lot of projects, that routing/aggregation can be entirely specified in a declarative manifest format, rather than involving any coding.
This neatly cleaves responsibility: your business logic team can just build+deploy+expose functions; and your frontend and ecosystem teams can build+deploy+expose the APIs they want on top, perhaps being maintained within their own codebases.
These can even be done on two entirely-separate platforms, rather than both being a part of the same “serverless” IaaS. You could use any combination of commodity FaaS providers (including your own hosted FaaS clusters) to deploy functions to; and then you could use some “smart” load-balancing system (e.g. Cloudflare Workers, or the routing component of an FaaS) to do the routing+aggregation on.
Re: Architect – A Serverless Framework
#13Lambda and SNS are super expensive. I'll skip it.
Re: Architect – A Serverless Framework
#14Great! Another file format for me to learn. Why can't everyone use one of the standard file types, like YAML/JSON?
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 config looks much better than anything they could have come up with using JSON/YAML. Optimize configuration files for humans, not machines. If its simple enough to learn and be readable, more power to em.
Re: Architect – A Serverless Framework
#15Earlier quoted context omitted.
> The ability to have the infrastructure isolated from the raw code being written. (Think more of a grid computing and automatic planning being included) Can you elaborate? It sounds like you're saying that if you write code that's deployed to a serverless infra you end up with 'serverless code'. This hasn't been my (very limited) experience - where the serverless stuff is just a thin layer around your business logic…
I think they’re saying that you can expose your lower-level atomic APIs as serverless functions, and then, separately, build a “routing and aggregation layer” that exposes APIs that people might actually want to use. And that, for a lot of projects, that routing/aggregation can be entirely specified in a declarative manifest format, rather than involving any coding. This neatly cleaves responsibility: your business l…
That is exactly what I was shooting for. I just didn't have the words at the moment to explain it.
What I've seen AWS Lambda being used: One-off functions with manual output management. They aren't really being chained together.
Re: Architect – A Serverless Framework
#16I’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?
I'm not the creator of this project, but JSON just isn't fun to write. It's readable, but still icky to write. I think to create a format really needs to strike the balance between usability and how natural it is to write. I think ELM for example finds a good balance.
I agree on that point.
Re: Architect – A Serverless Framework
#17I 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.
There is a link, but it's buried in the middle of the second paragraph. There should really be another link in the call-to-action section at the bottom.
I've wanted to try building something as a serverless architecture for a while, but every time I look into it I get confused by all the different things you have to set up to get an AWS Lambda function working, or I look into a framework but I can only find pre-canned examples for hooking into Slack, or just generally get confused by blog posts with lots of buzzwords and very little substance. In the end I always wind up just writing another daemon and sticking it on my server to get the job done. All I want to do is write some code and trigger it with an HTTP request, but for some reason Architect is the first framework I've seen that puts an example for how to do that on the homepage.
Re: Architect – A Serverless Framework
#18I’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 the service description's node while leaving the rest of the defaults untouched. It's really nice.
Re: Architect – A Serverless Framework
#19Earlier quoted context omitted.
> The ability to have the infrastructure isolated from the raw code being written. (Think more of a grid computing and automatic planning being included) Can you elaborate? It sounds like you're saying that if you write code that's deployed to a serverless infra you end up with 'serverless code'. This hasn't been my (very limited) experience - where the serverless stuff is just a thin layer around your business logic…
I think they’re saying that you can expose your lower-level atomic APIs as serverless functions, and then, separately, build a “routing and aggregation layer” that exposes APIs that people might actually want to use. And that, for a lot of projects, that routing/aggregation can be entirely specified in a declarative manifest format, rather than involving any coding. This neatly cleaves responsibility: your business l…
You can also use AWS API Gateway for that.
Re: Architect – A Serverless Framework
#20Lambda and SNS are super expensive. I'll skip it.
Wouldn't any serverless framework assume something like lambda and SNS?