The Joys and Cons of Development using a Framework.

(See what I did there?  For the record, Nintendo Switch all the way).

Once upon a long time ago, I helped a friend build a website ( using PHP and MySQL.  It was difficult, and had many, many challenges associated with it.  The easiest part about it was getting people on the site, which most people say is usually the hardest part.  Most of our users had just been de-platformed and were looking for for some where else to go, which made it easy.

Developing Eielson For Sale was difficult because we did the entire thing by hand.  We essentially built an entire content management system for buying and selling old junk from scratch, and it was a beast to maintain.  Development was complicated further because we had just started learning about object-oriented programming.  Moving from linear-style development to object-oriented development was a total mind trip for me. 

I found the transition to object-oriented programming particularly difficult because most of my practical experience with any sort of development up to this point had been Bash or Perl scripting.  I love Perl, and it will always have a place in my heart, but things had changed and I had to move forward. When I first started working on My Field Manager, I sat down with the President of StableBrook Software to pick his brain on the best direction for a very large project I was getting ready to start.  In summary, he pointed me at ye-olde bullet-proof PHP, and a PHP framework called Yii2 which I had never heard of up to this point.

Yii2 is a PHP framework that leverages a development concept known as MVC, or Model-View-Controller.  MVC is a monstrously large topic by itself that I’m only going to touch on briefly.  The basic concept behind MVC is that you segregate your code for better security and maintenance.  You have a Model (ie: database table), a Controller (code that performs various functions), and a View (what the user sees and interacts with).  The Controller sits between the model and the view and is essentially the content/traffic cop.

While leveraging MVC, the Yii2 framework takes the majority of the complexities associated with development (such as user permissions, interfacing with a database etc.) and it makes it faster and safer to build. From a practical perspective, it looks like this: I build database tables and give them certain constraints.  I then generate a “model” using the framework of this database table.  This model is now the gateway to that table.  If I try to shove the wrong data type into the table, the model prevents this from happening.

Why is this a big deal?  It’s a big deal because one of the most prevalent threats to modern web development is SQL (Structured Query Language) injection.  SQL injection generally happens when you take data from an end user and you throw it at your database (like a submission form).  If the user is crafty enough, they can provide your system with new SQL statements that you did not intend for them to run.  This can cause all sorts of issues, like deleting entire user tables.  That’s a bad day for someone.

So Yii2 allows a developer to safely spin up very large, scalable applications, which are inherently very secure, and significantly easier to maintain than some of the code I’ve written in the past.  So, what are the drawback you might be wondering?  Well, let’s start with you have to learn how to use a framework.  Not only do you have to know the underlying programming language, but now you must also learn how to interact with the framework itself. Luckily Yii2 has a very large community with a ton of information available about how to use it. Nonetheless, learning a framework takes time and energy.

Besides the additional learning required, my primary complaint about working with frameworks in general, is that sometimes they prevent native language functionality from working properly. Case in point.  I just very recently spent far too much time figuring out how to integrate the Stripe payment system into My Field Manager to receive payments and handle user subscriptions.  Most of the example code that you are provided with by Stripe will not work out of the box because of how the Yii2 framework operates.  It’s not a flaw in the framework, it’s just a flaw in how the developer (in this case me) tried to integrate it – a lack of understanding, if you will.

Stripe provides something called a “Webhook”. This is a basically a piece of back end code that sits somewhere in your web application and listens for data coming from Stripe. When you integrate the Stripe Webhook, your Yii2 application can now listen for Stripe to tell it all sorts of fun things, like that a user just paid you (yay!).  So how does it work?  Well, Stripe sends your application a big chunk of data to let you know the who/what/how much etc. So what didn’t work correctly? Glad you asked.

Take this snippet of code directly from Stripe’s Webhook integration guide:

$payload = @file_get_contents('php://input');
$event = null;

try {
    $event = \Stripe\Event::constructFrom(
        json_decode($payload, true)
} catch(\UnexpectedValueException $e) {
    // Invalid payload

The very first line of this code sets the $payload variable, but it will not work out of the box with Yii2. The reason for this is that Stripe is sending a raw JSON object to my application with data in it and my application doesn’t know how to receive it properly using that line of code.  Stripe’s example does work however, with vanilla PHP.  To work around this, I spent hours trying to figure out why (maybe I should have just read the manual?) the $payload variable would never contain the data that the Stripe documentation was telling me should be there.  It just didn’t work.

Well, the problem was that Yii2 has a specific function that you have to use if you want to capture that raw JSON data.  Ultimately what fixed this problem was changing this:

$payload = @file_get_contents('php://input');

To this:

$payload = Yii::$app->request->getRawBody();

The big difference between statements is that Yii2 uses a function called getRawBody() if you need to get raw JSON data.  I did not know this (because I didn’t read the manual), and it plagued me for several hours. One of the major drawbacks to using a framework is that while they generally make everything better, sometimes they also complicate things that would otherwise work just fine.

So there you have it.  Developing with a Framework is very fast, and much safer than trying to do things from scratch.  But, you really have to get an understanding of how the framework operates so that when you run into certain situations you’ll know how to handle them.

Ryan Farley

Ryan Farley

Lead Developer @MFM


Share on facebook
Share on twitter
Share on linkedin

More Posts