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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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?
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