My thinking exactly.
Scott
Digging up this topic again and sort of a thread within a thread. But I think it is fitting here.
When I created my “super thin controller” (first attempt at coding a framework or real coding at all, no testing, crappy code) MVC mini-framework, I was thinking I could avoid the complexities I was finding with working with current frameworks. I was certain I could avoid things like a router and have a very minimal set of controllers. (like with only a few lines of code in a single class). However, I finally came to the realization that this just isn’t very feasible.
The problem being, there is always a need to decipher a URL and POST data (for creates, updates and deletes (CUD)), because it holds the key to what was being requested. I kept thinking though, the URL and POST data could be “picked apart” logically and thus I could create a model on those “pickings” and feed it to the view on GET requests or the controller on CUD requests. The idea works, but at the expense of a lot of logic splitting across the request and model objects, which isn’t very…logical 
or rather, intuitive.
Then I ran into Facebook’s GraphQL specification. I think it is the exact answer to the problem I was trying to solve. If the Type API is in front of the model layer, there is no need for a controller. Actually, in a sense, the type API is the controller, but also standardized, controlled by the view and without a router! Exactly what I wanted to achieve. Wow!
Obviously,GraphQL is devised for thick clients or rather, is best used between a thick client and a server.
I am still a bit in a split about developing for “old school” standard web applications with an MVC framework pretty much all on the server side. Theoretically, one could use the same Type API to access the model layer and have it between a view system located on the server too. But, then a “relay emulator kind of thingy” would be necessary for the server side view to work and we’d be back with a need to have some sort of a router and controller again, not to mention the amount of development work it would take to make the emulator.
I’d like to just go with the opinion that we should be thinking for a mobile application first and do web as an extension to the mobile version, especially looking a lot more forward into the future. I just don’t see web pages being completely generated on the server anymore.
Any other thoughts on this direction would be welcome.
Here is a good quick video about GraphQL, but especially its implications for web development. I think Facebook has hit on some gold with it. Do you think that too?
This is another neat video about GraphQL. Can you also see the potential?
Scott
Interesting stuff about this GraphQL - it looks like a great solution to the problems they (FB) used to have and useful for many other scenarios. I think the best usage for GraphQL is communication with different clients as it is language agnostic and efficient.
Were you thinking of implementing it for self contained PHP applications (without any outside clients)? I’m not sure if it’s not too excessive - a GraphQL parser would slow things down a little and besides, is it necessary to specify the API in GraphQL while you can do so in PHP?
Having said that, I think the idea behind GraphQL could have a lot of benefit because it forces you to think about a natural and clear API for your business model and makes the application layers more independent. However, the same could be achieved with pure PHP without adhering to GraphQL specification. If it’s only you and your team of programmers dealing with the API then I don’t see there is much benefit in sticking to that particular API implementation.
I don’t understand how you see there is no need for a controller. If there is no controller then how do you pass input and request data to the Type API? From the view?
I don’t see how the Type API can be the controller because certainly it should not deal with reading input data. I think it is actually the model - the front-most layer of the model that provides an API for communication with the outside world: your controllers, views and possibly external clients.
Overall I like the idea of a natural model that FB guys implement with GraphQL, as opposed to CRUD-oriented model (see CRUD is an antipattern), and I was considering this in a previous thread where I wanted to get rid of an ORM. Actually, the main thing would not be to get rid of an ORM but to stop using it as a business model API, since it is very CRUD oriented instead of business oriented and we could get rid of much complexity within the model API if the model exposed a very specific API necessary for our business requirements instead of a general CRUD API with some business specifics sprinkled on top of that. So here I would compare a typical CRUD/ORM-like API to the RESTful communication that was mentioned in the videos, while a business oriented model API would be the equivalent of GraphQL - only the question remains whether we need to use GraphQL itself as it is just an implementation detail?
The project I am working on will form a multi-tenant PaaS, when it is finished. So the tenants would also be dealing with the API. As I see it, GraphQL allows for a lot of flexibility and at the same time standardization, when it comes to supporting diverse rich SPA applications with a data model back end, and that is exactly what we want and need. As I tried to explain in my post above, it is solving the problems we want solved. BTW, there is already a PHP implementation of the GraphQL spec.
Yes, the view is in the browser within an SPA. But, saying that, I just realized, there will still be controllers and a routers on the client side.
Correct. I see it the same way. GraphQL represents a communication method to a model. So, the VC of MVC is on the client and the M is on the server. Makes total sense to me and simplifies and homogenizes the architectural needs = less resources needed. Still, this leaves open a major design question, which we haven’t answered yet. Should we still support “old school” pure server side application programming? Even if we did, we’d still have to support some sort of AJAXy technology too, so that means additional RESTful APIs. I am thinking, why not just dive into the deep end and go straight with GraphQL? I really believe it would simplify a lot for everyone, just like it is doing at Facebook. The potential wins are huge.
Scott
I just opened a book I am reading about OOP and it started to explain XML. If you think about it, GraphQL is XML with the ability to actually request the data. Extend the DTD capability to explain the request, then you would have XMQL. LOL!
Scott
I forgot that nowadays we often have ajax, which can be thought of as a separate client to our php applications so with the use of GraphQL we might be able to use the same API to access the application both from the PHP controllers and from javascript in the browser. This might be interesting - and I’m wondering if this could possibly lead to pure implementation of MVC where the view is actively passing user input to the controllers like in desktop applications? This might be feasible because in this scenario the controller would sit on the client side in javascript and would be capable of receiving input events.
This might be worth doing, maybe you should give it a go? I imagine that eventually, PHP would ship with GraphQL support as a built-in extension so that we can design applications like this without unnecessary complications and overhead.
I think what GraphQL brings to the table is the ability for views to define what they data they need without the view having to query for it themselves. So, in theory, you can change your view without making too many upstream changes.
That’s great but it does add complexity and you will have to decide if your system really does have an issue with views needing to be independently updated.
Keep in mind that even the implementation you referenced is only one tiny piece of the application bundle. You still need some sort of router in front of it, some sort of database layer behind it and some sort of business layer.
By all means start a project and dive into the implementation details. Be curious to see what the results look like.
Yes, this. The browser is a “proper” client. It puts MVC in a different light, if you ask me.
I see the advantage to GraphQL being, it allows the view and the model to be disparaged to each other. What do I mean by that? It means, sort of like you said, you can change the client side code, without having to change the back end model. Or vice-versa and even more important, you can change the back-end model, and the client will still work. It makes the two sides a lot more independent.
Yes, of course. And even a controller and router of sorts, within the client application. The advantages are numerous though. One. This architecture is mobile friendly. Probably mobile friendliest. You could have hybrid, html5, or native apps, all using the GraphQL interface and not lose too many beats in development, because of it. Two, it standardizes the data exchange, which makes versioning, which is common in REST, a thing of the past. That is a huge win. Three. As you said, it allows the view to call on the data it needs for a request. A goal I had with my mini-MVC project. This simplifies the UI development, because the designer can concentrate pretty much on getting the design right and less about worrying that the back-end is supporting their efforts.
The only thing missing is the ability for the designer to actually define a type herself. Oohhh…and I have ideas for that too. 
Me too. A lot of work to do. A lot of work. Thankfully, Facebook is doing a lot of it for me (us). LOL!.
Scott
Yeah, this is not the right word. Or rather, the whole sentence isn’t communicating what I wanted to say. I wanted to say, GraphQL, in a “mobile first” application, basically trivializes the connection between the client and server. For instance, if you look at the GraphQL-PHP repo I linked to, there is a “naive” example of what it takes to create an HTTP end point. Talk about simple.
use GraphQL\GraphQL;
use \Exception;
if (isset($_SERVER['CONTENT_TYPE']) && $_SERVER['CONTENT_TYPE'] === 'application/json') {
$rawBody = file_get_contents('php://input')
$data = json_decode($rawBody ?: '', true);
} else {
$data = $_POST;
}
$requestString = isset($data['query']) ? $data['query'] : null;
$operationName = isset($data['operation']) ? $data['operation'] : null;
$variableValues = isset($data['variables']) ? $data['variables'] : null;
try {
// Define your schema:
$schema = MyApp\Schema::build();
$result = GraphQL::execute(
$schema,
$requestString,
/* $rootValue */ null,
$variableValues,
$operationName
);
} catch (Exception $exception) {
$result = [
'errors' => [
['message' => $exception->getMessage()]
]
];
}
header('Content-Type: application/json');
echo json_encode($result);
I’d need to work out a decent model with a database back-end behind this too, to see how complicated it would get.
Scott
Well, but I don’t think the advantage you are talking about here is specific to GraphQL - in any well designed application the client side code will be independent from the back end model. GraphQL is just one of many ways of communicating between the end points - and while it seems to be a great way, the advantage you are talking about can be also achieved without GraphQL. I’d say GraphQL’s advantage is interoperability - because of its simple text format it can be easily used by systems in any programming language while a PHP interface can be used only by PHP code.
Hmm… tell me if I am wrong, but REST APIs are the current, most popularly used method of connection between two systems. There is also SOAP, but obviously REST has won over SOAP, due to its ability to direct actions against specific resources. With REST though, there is the issue with the request’s formulation. It must be “deciphered” before it can be passed to the business layer. As I see it, with GraphQL, the deciphering can be directly built into the business layer/ model, forgoing the router/ controller mess.
Scott
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.