I just hope that that doesn't mean we become reliant on Amazon (closed source) to add important fwk features we used to be able to do OSS.
-
Show this thread
-
Replying to @wycats
Lambda support exists at language level, not framework level. You're not really locked into framework features unless that changed?
1 reply 0 retweets 0 likes -
Replying to @lsegal
You are because you can't (or shouldn't) run stuff like a router inside your function. So you're reliant on Lambda to perform the role ...
2 replies 0 retweets 1 like -
Replying to @wycats
"shouldn't" as defined by whom? Amazon explicitly documents this use case: https://github.com/awslabs/aws-serverless-express/blob/master/example/app.js …
1 reply 0 retweets 0 likes -
Replying to @lsegal
The more your lambda boots a framework when it starts up, the more trouble you're going to have.
1 reply 0 retweets 0 likes -
Replying to @wycats
I don't disagree but it's a problem with every *aaS. If you give up control of process lifetime, you lose on boot time.
1 reply 0 retweets 0 likes -
It also paves a 3rd path: where fwks running in functions become more lightweight and heavy processing moves to batch workers.
1 reply 0 retweets 0 likes -
Doesn't mean you can't have fwks, just changes the constraints of the fwks you use.
2 replies 0 retweets 1 like -
Replying to @lsegal
Fair enough. At the end of the day *some* framework concerns are fundamentally moved into the platform no?
1 reply 0 retweets 1 like -
Replying to @wycats
Sure. That's the arch. tradeoff. Does that inhibit innovation for fwks in those spaces? Yes. Ideally the surface area is minimal though.
1 reply 0 retweets 0 likes
I was explicitly not complaining about it :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.