←back to thread

28 points aaossa | 3 comments | | HN request time: 0.631s | source
1. recursivedoubts ◴[] No.43708873[source]
Aaaayyyy yooo, i wrote this a long time ago, but I think it holds up!

TLDR: there is a trade off in how much expressive power you can surface to front-end developers when their logic is written in-browser because anything you give to them, you give to anyone who can open up a console. That makes things a lot more dangerous and is in contrast w/ the back end, where you can give developers access to a full SQL implementation.

replies(1): >>43708963 #
2. Etheryte ◴[] No.43708963[source]
At the end of the day, it's still only shuffling around where you define your constraints, because you need them either way. Whether you define a rigid API endpoint for the frontend (named the problem in the article) and handle access control there, or make the API fluid with e.g. GraphQL (the first solution in the article) and define access controls there, it's still the same problem.
replies(1): >>43709110 #
3. recursivedoubts ◴[] No.43709110[source]
I don't agree with that.

You can give a back end developer SQL, because the users of your application don't also get SQL. Not true of GraphQL.