GraphQL looks shiny, but behind that shine is a pile of extra rules, schemas, and resolvers. If you’re a Laravel dev, you don’t need all that cerem...
For further actions, you may consider blocking this person and/or reporting abuse
While I agree GraphQL should not be the default option to make the database reachable by the frontend. There are some statements I look at in another way.
First I want to get a contradiction out of the way.
In the beginning of your post you mention
But at the end you state the following
A solution can't be precise and overreaching at the same time.
When you only need a few endpoints, Laravel API routes can be the solution.
If the API is quite big, I think it is better to use a framework like API platform.
And for the use of GraphQL I think it comes down to how many instances are there that the frontend needs a single request that contains unrelated data. For example user data and product data. These requests are hard to create an API endpoint for. So if it happens often enough I think GraphQL is a good fit.
There is also no rule that states you can't use both.
It all depends on what the application requires to work in the most efficient way.
I wouldn't use a DTO by default. Most of the times API endpoints have options, which means the data that the endpoint sends is variable. With a DTO the data shape is static, which means with the options it is possible you are sending empty keys. In an application that is not a problem, but in a request it is bad. Certainly when the application needs to scale.
This is a communications break down. It is not backend decides nor frontend dictates.
This is the I-only-care-about-my-work mentality that leads to struggles that shouldn't happen in the first place.
The best way is to compare the wants and needs and find the way both experts walk away feeling good.
Thanks for your detailed thoughts. My main point in the article was less about GraphQL being “bad” and more about how backend devs in the Laravel ecosystem don’t need to reach for it by default. Most backend devs don’t want the frontend dictating data shapes or having to maintain an extra GraphQL layer. Laravel already gives us tools (API Resources, DTOs, AQC) to control what’s exposed, keep things predictable, and still deliver precision.
On DTOs — I see them as essentially the same idea as Laravel API Resources. Whether you call it a DTO or an API Resource, you’re transforming and exposing the response shape in a controlled way. That’s why I don’t see them as “rigid,” but as explicit and testable.
I agree flexibility is always possible — projects can mix approaches as needed. But my push here is simply: Laravel developers should rely on the framework’s strengths before adding new layers. GraphQL is powerful, but most of its strength is frontend-driven, and backend developers don’t need to adopt it unless the project’s complexity really demands it.
I hope that is not the case.
For the frontend wanting specific data shapes,what would be the problem? Making less requests with the data they need is a valid reason to want specific data shapes. Maybe there might be compromises on the details of the shape if it would require too much work, but the skeleton of the shape should pose no problems.
Why would the GraphQL layer be extra? It is just a decision you have to make. Creating a REST(ful) API to power the frontend can be as much work as creating a GraphQL configuration. Lighthouse is a library that takes the sting out of building the schema, because a lot of Laravel concepts are used.
An API resource is not the same as a DTO, not even as an idea. If you read the first sentence of the documentation, a resource is a transformer while a DTO is a static object. You can for example exclude attributes which is not possible with a DTO. I don't see anyone creating a DTO for each possible field option in a model.
It is also a bit strange that in the example you are using the DTO only to define the columns for the model select, but you don't use it to the actually transport of the fetched data, which is the purpose of the object.
I would think GraphQL strength is also in the backend. Create a schema and you are good to go. For an API you have to start from scratch If you don't use a framework, which requires more work because with GraphQL the bootstrapping is already done. The only things Laravel provides are the routes, middleware and resources. That gets you started, but the hard work is what comes next.
I still agree GraphQL should not be the default option, it should be evaluated on a project to project base.
I get your points, thanks for clarifying. The main issue I see is that in modern setups, frontend frameworks like React or Vue are often the ones requesting and shaping data. That shifts too much control to the frontend. GraphQL works great in that scenario, but I don’t think the frontend should be the one making those data decisions.
About DTOs and API Resources — what I meant is that they’re very similar in practice. DTOs can directly return JSON, while Resources transform and then return JSON as well. Resources can effectively act as DTOs, which is why I put them in the same category.
On GraphQL’s backend strength, I agree with you. It’s quick to bootstrap and gives a strong foundation. But it’s also self-centric — once it’s in, many projects start depending on GraphQL for almost everything. My push is just to remind Laravel devs that they don’t need to default to that dependency when the framework already provides strong, native tools for shaping APIs.
I also want to add a broader point here, which I’ve written about in my article Web Transition. When the web first came into being, the backend was responsible for requesting and shaping data. The frontend’s job was limited to three things: user interaction, DOM manipulation, and animation. Somewhere along the way, frontend frameworks took over backend responsibilities and became the decision maker for data. That’s where I see the real problem — it’s not just about GraphQL, it’s about a shift in roles that also created side effects like SEO issues. This is why I argue developers should let the backend remain the decision maker, and use Laravel’s native tools instead of moving that responsibility to the frontend.
Returning JSON is not the job of a DTO.
That is not a GraphQL problem, that is a developer problem.
That was before ajax. Since ajax, 2001 (internet explorer 6), javascript started asking for data. This is long before view libraries took over.
So asking for data in a certain format is an "old" way of improving the user experience.
Have they gone overboard with view libraries, sure. But I'm seeing the return to progressive enhancement in the javascript community.
Wanting to go back to only backend database access is a foolish idea. Both backend and frontend are going to need database access to create a good website for people.
If you only want a good SEO website, just use HTML and be done with it.
Yes sure DTOs and API Resource are returned as Payload in json. Thats what i mean.
As for GraphQL, I don’t disagree that misuse is a developer problem. But the tool’s design does make it easy to misuse. That’s why I argue Laravel developers should lean on what the framework already provides before adopting GraphQL as a default.
As about Ajax, javascript does ask about data and that's excellent but javascript has also snatched the responsibility of rendering/hyderation from backend that has caused SEO problems. Fetching is fine but dictating shapes and controlling backend decisions is where I see the problem. That’s why I prefer keeping shaping logic in Laravel rather than letting the frontend layer drive it so it is a clear distinction between asking data and asking specific data.
You mention the return of progressive enhancement in the JavaScript community, and that’s exactly the point I’m emphasizing: let the backend, which is inherently more powerful in rendering and hydration, take care of what it does best. Then the frontend can progressively enhance where it makes sense.
On the point about
I see a contradiction. JavaScript on the frontend cannot directly query a database, it must go through the backend layers. So regardless of approach, the backend is a must-have part of application. If there’s a way for frontend code to securely and directly access a database, I’d genuinely like to learn about it.
Finally, regarding SEO, I agree that plain HTML is best for crawlers, but I don't argue to go back to old static approaches. Rather, it’s about giving backend-rendered HTML for the initial load ensuring SEO and fast first paint and then letting JavaScript take over for data fetching and interactivity. That gives us the best of both worlds, SEO-friendly pages and dynamic user experiences.