Hacker News new | ask | show | jobs
by andy_ppp 1032 days ago
Every piece of magic in your application has the possibility of completely screwing you over when you least expect it. This includes all your dependencies and especially your backend. Given how trivial it is to write a real GraphQL API in frameworks these days, where you have complete control, it’s likely better to add that to your skill set rather than trusting a one size fits all solution that unlikely to solve every problem.
2 comments

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?

Bandwidth is not the only factor affecting the thick/thin client economics [2]

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

This is true but like with any build there are many decisions to make. We have settled on this stack for our API's and we think others will find it useful.
Cool! How does security and multi-tenancy work in graph weaver? These were a really excruciating afterthought in Postgraphile…
Here are some links around security:

https://graphweaver.com/docs/adding-local-authentication

https://graphweaver.com/docs/implementing-authorization

https://graphweaver.com/docs/column-level-security

We have deployed Graphweaver using serverless and lambda be interesting to see how we could convert it to multi-tenant.

Could you expand on how security is an afterthought in Postgraphile? My experience of using RLS and the graphile pro plugin was nice and secure imo. Curious if I missed something here
So I have a list of my own stuff but I want for other people who are in my circle to be able to see outfits I've shared with them. If all the lists of stuff are created in an automated way doing things like this is somewhat harder than the default crud stuff and managing passing tokens and doing the filtering is fine but feels like a use case that should be as automatic as possible. I haven't used the Pro plugin, I'm not sure if we knew about it or what it does.