So yeah, after that conversation I genuinely think that "Framework as a Service" describes what's interesting about the shift.
-
-
traditionally filled by in-process frameworks.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
"shouldn't" as defined by whom? Amazon explicitly documents this use case: https://github.com/awslabs/aws-serverless-express/blob/master/example/app.js …
-
The more your lambda boots a framework when it starts up, the more trouble you're going to have.
-
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.
-
It also paves a 3rd path: where fwks running in functions become more lightweight and heavy processing moves to batch workers.
-
Doesn't mean you can't have fwks, just changes the constraints of the fwks you use.
-
Fair enough. At the end of the day *some* framework concerns are fundamentally moved into the platform no?
-
Sure. That's the arch. tradeoff. Does that inhibit innovation for fwks in those spaces? Yes. Ideally the surface area is minimal though.
-
I was explicitly not complaining about it :)
End of conversation
New conversation -
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.