In the old days we have API to get data, and then later we have RESTful, and then now we have GraphQL.
In the old days, we have custom-made query, to get exactly what we wanted, no more, no less.
And then, we have RESTful, and it was somehow treated like a gospel. And then, it was said that it was overfetching data, and underfetching data at the same time, and the exact data is wanted instead, no more, no less.
And then we have GraphQL... it just seem we are back to the old days, except in the old days, the backend team wrote the SQL queries for us, and use table join to give us exactly what we wanted. But now, the full stack or front end engineers can write it. How is GraphQL different from the old days?
Oldest comments (20)
I think you answered your own question... Frontend devs can now write their own queries, rather than asking the backend devs to make/modify an endpoint every time the business requirements change
But why can't front-end developers just use SQL? You have to learn something in order to return the data, why is GraphQL a step forward if the end result is that front-end developers learn a query syntax? The data still lives in the database, there's just a new layer between them now.
Because raw SQL queries should never be performed on the client.
Of course you're right in that the data still has to be stored somewhere, but GraphQL is generally much more flexible and efficient, because from a single endpoint one can traverse an entire dataset from the client, rather than calling many REST APIs or using crazy query parameters.
GraphQL is also great for federating many different microservices which is common in modern apps.
I agree the downside of GraphQL is a steep learning curve and extra burden for Frontend developers. But the trade-off is more efficient network requests and theoretically reduced workload for backend devs
The point of GraphQL is to have the front-end not learn new syntax. Front-end is already familiar with JSON, so GraphQL query is designed to mimic JSON. In contrast, SQL is very different from JSON.
The layer is for asynchronous cooperation. The GraphQL schema acts as the rendezvous point for all the front-end teams and back-end teams, instead of ad-hoc temporary team-to-team connections. It solves a scaling problem which not everyone has.
Yes agreed. I didn't literally mean writing SQL queries on the Frontend (poor articulation on my part), but rather, the concept of querying relational data from the client (using familiar JSON syntax, as you said). GraphQL still has a steep learning curve for most frontend devs though despite the JSON syntax
Now, I have to worry about SQL injection in GraphQL as well, as well as unauthorized access to CRUD.
Nah man, that's the whole point of having a middle data layer - but you WOULD have to worry about SQL injection if, like Joshua asked, you tried using SQL queries on the client
As for unauthorised CRUD access: you're going to have to deal with this no matter how you handle remote data. If you had exposed REST APIs that let anyone make put requests to your database, that's no different to unauthorised access in GraphQL or whatever other method, right?
I am a penetration tester and graphql injection is very fun. A lot of the security controls built into SQL libraries, ORMs, frameworks, what-have-you are not present in GraphQL yet. You have to do all the validation and authentication yourself, which gives you an opportunity to do it wrong.
SQL - used a prepared statement, you will never have SQL injection.
GraphQL - ???
Now if your GraphQL schema doesn't take any variables, now you only have to worry about whether I have authorization to access the subset of data I'm requesting. I've seen authentication and authorization checks on parts of a schema where some nodes are missing it. It's very easy to make those mistakes with GraphQL today - and it shouldn't be.
Edit: disable introspection on your prod GraphQL endpoint and make my job a lot harder!
Another edit: here's an article with a list of a few published findings against some brand names from graphql. I remember some of these but I didn't look at the details again. They probably have some further examples.
Oh fair enough, that's an area I can't comment on cos I don't know cybersecurity in-depth. So taking onboard your comment then I guess poorer security might be another current downside of GraphQL.
It's the same as any new-ish technology, it will definitely have flaws. The question is whether its advantages outweigh the disadvantages for your application. If you're building apps which are based heavily on relational data then GraphQL is probably worth considering, otherwise REST works fine for less complex apps
Yeah I believe that graphql is going to be awesome once it figures out these things.
I wonder how can one do GraphQL injections. Could you provide an example?
Sure - here is a page with some example techniques and it links to a lot of relevant articles.
github.com/swisskyrepo/PayloadsAll...
And
lab.wallarm.com/securing-and-attac...
(No)SQL injections can be prevented by prepared statements, though. Other points are valid I guess.
Well here's the thing - by adding a layer between the sql and the user input, you've created a way to generate arbitrary sql. Even if you use a prepared statement in the resolver, it may be possible to inject something through the graphql query.
Which is the case for REST API as well, isn't it? (User Input -> REST -> SQL). Or for any API in general. You can pass something like
someone'; drop database prodto a REST endpoint (or any endpoint, doesn't matter which technology stack you use) and if there's no preparation done when building a SQL statement, you've done an injection. Nothing new there - always validate user input.The difference is the graphql schema creates valid sql in a prepared statement, it just might not be what you would normally allow the user to retrieve.
But yes, validation of user input is key. GraphQL needs some better tooling support around that.
It depends on the implementation. I've once used GraphQL in a pet project and you could only pass some generic values (e.g. ids) and then select fields you want, for example:
idthere would be passed to an ORM (Users.get(by: id).with(model: Post)) and I'd simply return this data to my GraphQL level which then would fetch everything user requested (so if my User model has id, email, etc., a GraphQL library would only takeloginandnamefrom it andpostswould return an array of posts that would be handled the same way) and return it to them. I've fetched everything I needed in one query compared to 2 REST calls (/api/users/1,/api/users/1/posts) and it's pretty safe as long as you prepare theidvalue under the hood. I doubt anyone uses GraphQL just like a SQL generator. It's not safer than exposing a raw SQL endpoint like/api/sql/$whatever_sql_you_can_come_up_with?variable=;drop everything; --lul.Of course there are downsides such as complexity and attribute accessibility by roles, though I've implemented that by dynamic attributes that would return an error/
nullif you don't have permission to read this attribute. And the complexity problem was solved by the library itself - I simply put a limit on the depth of the query, so you can't do something likequery { users { posts { user { posts { user ... } } } }We had mainframes and dumb clients; then we put more power into clients so no mainframe was needed; then we got huge services in remote servers and browsers for clients; and now the Cloud having the whole application (backend) and frontend clients (Apps and browsers), even media and games streaming services; is the circle of life. And people feeling clever saying "the Cloud is just other people machines", no idea what they think remote hosting, web APIs, websites, chat servers, THE ENTIRE INTERNET, are.
Functional is getting in fashion like it is a new thing, the new things are: flip phones, streaming services looking increasingly like cable TV; IoT like remote control and monitoring is new; social media like BBS and IRC never existed; people talking about the new concerns about privacy when the first rule of the internet was "never give real information in the internet".
One of these days people will may even realize that C is not dead and 90% of what they are using is actually written on it. XD
For years people avoided SQL putting things in front of it and leave it as back and hidden as possible, even replacing with NOSQL in clearly structured scenarios (NOSQL of course has its uses, but is no replacement for SQL) and just now realizing the SQL is actually a good way to query a database, who knew.
The circle of life, my friend, we just have to realize it, appreciate it, let it go, hakuna matata :)
I just found out "hakuna matata" means, as Arnold Schwarzenegger said, "No problemo".
The good thing about old stuff getting "new" is that we already have seen it, is like my with clothes, people say fashion is cyclic, so I'm not out of it, I'm just ahead of the next one ;)
So when people says something like SQL is old and obsolete or performance and optimization is worthless because computers are to fast nowadays, I just smile, nod and wait.
For example, I think that the golden age of slow PL is about to be over, we are hitting the end of the line of HW power, until a complete makeover, for a while SW people relied on HW people dealing with performance and we just kept worrying about the new features, bells and whistles, but HW is (in its current form) about to hit a wall of physics. So in the next years I think performance in SW will get even more important, after all you can double your HW or halve the needed resources. Old is the new, new.