Ok. If you had read my “Why PHP” post from the past, you’d think we were building Skooppa with the core language being PHP and you would have been correct. However, unfortunately, that is no longer the case. Some people might jump for joy with this decision, some might laugh and some might cry. Some might say, “Oh hell. Now even more waiting.” Sorry. Good things take time. Great things even more.
When I originally came up with the Skooppa idea, I felt deeply about Skooppa including the PHP community and its 5+ million developers. The target market for Skooppa also uses PHP software, like WordPress and 80% of the websites today are powered with PHP. I was and still am a fan of PHP and its community. Those are all considerable motivators to have PHP be the core language.
During the past couple of years, I had been working on my own developer skills. At the same time I was working with a group, who had developed a special PHP server, which could also support a framework type of PaaS. PHP’s shared nothing architecture is great for getting things done quickly and cleanly for single websites or web applications, but in a “framework PaaS” scenario, application code does need to be shared at some point. PHP doesn’t offer the needed architecture for this convention. And in fact, no language does it well, without needing to do some “circumcision” of the languages capabilities. Still, on top of the troubles of “dumbing down” and securing PHP for a PaaS environment, which I had envisioned for Skooppa, the issue of sharing a core code base with different tenants of a PaaS just wasn’t feasible, let alone performant.
Also, while working on the backend strategy, I was looking for a simplification of the technology needed to create applications. If you’ve worked on any kind of large applications with PHP as a full-stack developer, it is basically a juggling act between, front-end design, front-end behavior (i.e. what happens in the browser) and back-end design and data modeling (i.e. what happens on the server). I looked at other PHP frameworks like Laravel and Symfony and learned they offer very little to relieve the developer of this juggling act. In fact, they only play as heavyweight middle-men. A couple of small examples of where they do help are Laravel’s Elexir (which is a resource manager ran with…haha….NodeJS!!!) and Symfony’s Assetic. These two examples are only asset management (i.e. controlling which files, like JS, CSS or image files, get sent to the user’s browser). That is only a very small part of the juggling!
I also delved into an experiment with MVC architecture too and dug into the concepts. I got into a deep discussion about MVC with a smart developer I was asking advice from, and he was of the opinion that I shouldn’t really need much of a controller. Other smart developers actually plead for “thin” controllers and want “fat models”. Others deny this as a necessity.
Be that all as it may, I am of the opinion that the backend need only be data resources and business logic. Some say this IS the model. I say, “kinda.” I can’t explain this in words down to the detail, as it would bloat this article to extremes, but I feel any “backend” is truly only data resources and business logic. Nothing else. Whether it is found in a model, or in some other convention, doesn’t really matter.
While looking for technologies to meet this viewpoint, all I could deduct was, what we are doing today with MVC simply isn’t “future proof”. Working in the old MVC paradigm like Symfony and Laravel do meant still living in the old box and I considered it quite limiting. REST APIs are sort of heading more in the direction I liked, but I still wasn’t satisfied. Creating REST endpoints is a messy deal.
So, I was at a dead end in terms of moving Skooppa forward. The technologies I felt were necessary for a future proof PaaS framework just weren’t available and I was just floating around, getting nothing purposeful done for a few months……..
Now, some of you in the know will say, “Scott, that is only an API technology and has nothing to do with MVC.” and you’d be partially correct. The concern of getting data to and from a view (web app, mobile app, even desktop apps) is what GraphQL is all about. You might also say, “REST also solves this problem”, and you’d also be partially correct. As I mentioned, REST was never something I felt comfortable with. It doesn’t totally solve the controller problem I wanted to avoid.
GraphQL does. It simplifies REST and improves it a lot. If you have the time, do take some to learn about GraphQL. I am betting it is going to replace REST at some point. And yes, doing GraphQL properly also means putting the view completely on the client (for the most part). It requires the client application to be a Single Page Application or SPA or a stand-alone application (like a mobile app). The GraphQL tackles a problem that caused an itch I needed scratching. It is the better and more future proof choice of API.
Finally Moving Forward (sort of)
So, Skooppa taking on GraphQL also meant the back-end was left to only send and store data and make sure business logic is adhered to. There would be no controllers! Well, not in the old MVC sense and not with REST. GraphQL was the answer I was looking for!
Sadly, the answer from Facebook left me positive that I might get the Skooppa backend done with PHP (or if need be… with Hack) at some known point in time. This hope, however, inevitably just wasted a lot of time. Facebook never published the Hack version of a GraphQL server and I wasn’t about to get it done on my own.
Also during this time, an important PHP OSS project needed for our technology stack basically died in mid-flight. The devs that started the project also ended up having to work with different languages for their own companies. So, that left me high and dry with PHP and going nowhere fast.
The Decision was Made
That brings us up to today. I am sure most of you were thinking, “nothing will ever happen with Scott and Skooppa” and to be honest, that may still be true. Though, I am still working on Skooppa in my spare time and it is a lot of fun for me. I am learning a lot and I love pushing the envelope to break out of past paradigms. That is the only way Skooppa can make any difference, if and when it becomes a reality.
This is the first time I’ve ever nailed myself down to any kind of project date. I am doing this, because now I feel very comfortable with the direction. I am now planning to have a working POC of the basic Skooppa platform (code named “S6A”) working by the end of 2017. This base framework will also be OSS software, with a couple of stipulations. I’ll make those stipulations clear, once the time is right. Also, as the POC starts to take shape, I’ll be making a lot more update posts than I have been. I’ll be showing you all some of the technologies and “wins” S6A is going to offer for developing apps. Remember, I am working hard to lower the juggling I mentioned earlier.
If you have any further comments or questions, meet me on our forum and ask away. I’d really be happy to get some activity going on our forums other than the occasional spammer. LOL!
With that, Happy New Year and cheers for reading and your interest in Skooppa.