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.
The 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!
Yes, 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.
It'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.
The 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.
Also, 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!
