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?
