LOL. I must have divination powers.
I am currently working on a UI framework and opened an issue just 3 weeks ago that says:
***
Seems that server functions are all the rage.
We are unlikely to have them.
The main reason is that it ties the frontend and the backend together in undesirable ways.
It forces a js backend upon people (what if I want to use Go for instance).
The api is not client agnostic anymore.
How to specify middleware is not clear.
Requires a bundler, so destroys isomorphism (isomorphic code requires no difference between the client and the server/ environment agnostic).
Even if it requires a bundler because it separates client and server implementation files, it blurs the data scoping (especially worrying for sensitive data)
Do one thing and do it well: separate frontend and backend.
It might be something that is useful for people who only plan on having a javascript web frontend server separate from the API server that links to the backend service.
Besides, it is really not obvious to me how it becomes architecturally clearer. It would double the work in terms of security wrt authorization etc. This is at least not a generic pattern.
So I'd tend to go opposite to the trend and say no.
Who knows, we might revisit it if anything changes in the future.
***
And boy, look at the future 3 weeks later...
To be fair, the one good thing is that they are hardening their implementation thanks to these discoveries. But still seems to me that this is wholly unnecessary and possibly will never be safe enough.
Anyway, not to toot my own horn, I know for a fact these things are difficult. Just found the timing funny. :)
346
225