|
|
|
|
|
|
by jrockway
1032 days ago
|
|
|
I don't think a GraphQL to SQL compiler is strictly a bad idea. It is kind of like allowing forum users to post HTML-formatted comments; you absolutely can't pass it through unmolested, but you can parse the HTML and walk the AST to emit a safe subset when you're displaying the comment. Basically, this sort of thing is very easy to get wrong, but it's not an intrinsically unworkable idea. At the end of the day, the backend database does the same thing; a connection says "SELECT foo FROM bar" and it has to decide whether or not the current user is allowed to do that. To some extent, this is kind of reverting to "old times". Back in the day, client applications connected directly to the database and the database handled auth. There is no real reason to not let Javascript apps running in the browser to do that, modulo implementation details (hello popular database with a 100 connection limit out of the box). With that said, I remain unconvinced about whether the modern SPA architecture is the right thing. In a day and age where everyone has gigabit fiber or 5G running over HTTP/3 to a replica of your website hosted in the same city as your ISP, is downloading HTML on every click really that bad compared to making power-savvy devices parse and compile your application every time they visit it? |
|
|
Compute is the big factor , unless your app needs fast load times to make money like e-commerce, cmses etc the trade off of paying for additional compute on the server side is not worth it .[1]
Today the browser handles most of the app and Auth state token refreshes, inflating data into an UI, a lot of the validations , all these components on the server costs more compute cycles which someone has to pay for.
If is always cheaper for the user than application developer , the app developer is renting every cycle compared to the user who has already bought a powerful device
Same reason Stadia and similar stacks have hard time proving their economic viability, if they are not able to create a large enough market of users who will not buy a high end device but will be ready to pay for a sub for somewhat poorer experience then they fail .
Also from development point of view you would need to likely maintain a separate API anyway for your native mobile apps , building a server rendered [1] app and API is not worth the development cost usually.
[1] SSR and various hydration tooling blur this line ever in favor of SPAs but I am ignoring that to keep the point simple
[2] hardly everyone has always on 5G or fiber access in developed G-20 economies let alone the world , YouTube and dozens app charge for downloading for a reason