Comment by liampulles 7 days ago
Just be careful with this backend-code-in-frontend stuff. If it's needed for some computationally expensive logic that is logically client side, then fine. But be wary of letting the client dictate business rules and having open-for-anything APIs (GraphQL is particularly prone to this).
I've seen teams do this in the wild more than once.
REST is the solution to this but it's reduced to JSON RPC over HTTP nowadays.
If we're talking about a HTML server (a REST API) then I agree, but if it is a choice between JSON REST and JSON RPC, I'd take JSON RPC any day to be honest with you.
a REST API needs to be descriptive enough and have a wide enough contract with the client that the response can modify the behaviour of the client so as to deal with any multitude of situations going on with the server. This works great if the response is HTML and the client is a browser, as the HTML dictates where and how to interact with the server (e.g. a link is a GET request to XYZ, followed by a page load). For JSON REST to meet that bar one needs JSON+HATEOAS, and having worked on a project that tried that, let me tell you that there is HATE aplenty to be found in trying to make that work.
So if we abandon the strict notion of what REST is, then what does JSON REST mean? In my experience, its been a lot of arguing over what paths and methods and resources to use, which at best are a waste of time (because no one is going to see the choice, its just whatever your JS lib is going to call and your backend is going to return) and at worse it puts bad constraints on how the backend is modeled by forcing one to do it in terms of Resources for ones REST API to work effectively.
In my opinion, its much better to use an RPC API which simply describes API "functions". These APIs can work over any number of actual db resources (and sometimes none) and importantly, leave you the time and the freedom to model your backend in terms of business rules and not "RESTful" norms.
What I meant was using a backed oriented language for frontend oriented work. My shorthand was unclear, apologies.
Yes you are right: this is a subsequent point and not related to my original point. Apologies for that.
Did you want me to expand my thoughts on "backed oriented language for frontend oriented work", or does that address your query?
Well, the "Is this a good idea?" section in the README already addresses the issue.