5 ms·
Unlike with RESTful APIs, a server basically only needs a single endpoint that parses and responds to GraphQL commands. This isn't as far off as you suppose to
by applecore 11y ago
Unlike with RESTful APIs, a server basically only needs a single endpoint that parses and responds to GraphQL commands. This isn't as far off as you suppose to be the case.
- stevepike 11y agoThe trickiness will come in handling authentication for all the nested resources (e.g., user X can only see public photos for user Y, and can't update them) and generating efficient queries to a relational datastore. Coming up with a clean architecture for that actually seems like a fun project!
- applecore 11y agoIt's a good thing that relational databases solved the problem of generating efficient execution plans for ad-hoc queries about thirty years ago—with SQL.
- TheCoelacanth 11y agoYeah, but the stupid users insist on clicking buttons and stuff instead of typing in SQL.
- applecore 11y agoThe point is that relational databases will serve as the data model for most GraphQL application servers. Obviously, end-users don't have to write their own queries.
- darknoon 11y agoAlso, keep in mind that most big websites aren't just a single box you can query. A plan for fetching data across >>1000s of boxes works a bit differently than within MySQL or whatever. Usually you end up making layers of abstraction / cacheing / parallelization atop them that don't have an easy SQL interface for the frontend to query. FQL was heavily sanitized and abstracted anyway, not directly SQL onto the boxes--imagine that security shitshow!
- dgreensp 11y agoYes, this is exactly the hard/interesting part to implement. Facebook uses their own graph databases which lets you specify access control rules. You'd need something similar on top of SQL.
- applecore 11y agoYou mean handling authorization.