Our Laravel Story

in Backend by Radosław on October 3rd, 2015

Do you remember times of PHP4? No PSRs, classloaders. Almost no frameworks. Only bunch of random classes and functions.php files. These were wild times. Everyone was trying to create something on it’s own.

This was the time when DSE (Desmart Engine) was born. Our own framework. It had it’s philosophy. We knew what it should do. Yet we didn’t know how to build it properly. Behind awesome concepts there was poor architecture (core component was a singleton class acting as a classloader, factory and object registry). Still, it was awesome.

On top of DSE we’ve built robust module system, assets manager, tons of modules, our own rapid development kit for admin panels. We had even a dependency manager (like Composer) written entirely in PHP.

Time passed and some things started to change. We couldn’t handle the process of keeping our framework (and it’s packages) up to date. We started to feel that our framework is old enough to retire. I was given the task to find a decent replacement for DSE.

At first I was afraid, I was petrified.. There were like at least 5 frameworks worth using and some complete CMS solutions. I had to decide what I really wanted from our new framework. Should it be just a couple of libraries tied together or a big CMS system? Which ones are trending and are kept up to date? Should it have support for modules (or plugins)? Does it have a community?

Another problem was how to objectively decide which framework is the best. I’ve tried to read something about them. I’ve looked at the docs, opinions, even Google Trends. This led me to the decision that only few frameworks are worth choosing. I had the knowledge but still I didn’t knew which one is the best.

At this point I came back to DSE. I had in mind that changing the framework may be a shock. I wanted to make the transition as smooth as possible. We were working with DSE for years. It had its cons but it also had some pretty big pros. I’ve tried to compare the chosen frameworks with DSE. I’ve looked for similarities. I was checking if given framework can solve the problems which we had with DSE.

And bam! I’ve found it. Laravel was the only framework matching DSE “philosophy”. It’s easy to use, yet it has huge potential for building complex things. Laravel supports packages and Eloquent is the best ORM I’ve seen in years.

I’ve decided to try Laravel in one of our projects. It wasn’t easy. DSE had it’s own solutions for some things. I had to change my habits and stop thinking in the "DSE way". I’ve got familiar with the “Laravel way” and started to love it even more.

Yet, some things DSE provided were better. That’s why I've decided to write extensions giving back some of DSE modules. Very first of them was the laravel-layout - a thing which splits controller to smaller chunks called actions. Also I had to extend the pagination package to meet our needs.

We had some rough time during the switching to Laravel. Now it’s almost two years since we’re using it. Thanks to it we’re able to make awesome stuff. We love Laravel.

If you feel that it’s time for change here are some of my tips:

  1. Decide what do you expect from new framework, don’t follow the hype (back then Laravel 4 wasn’t even finished).
  2. Choose only active projects:
    • see if they have community willing to help;
    • check out the docs - do they cover the most important parts? Are they updated?
  3. Look back at the current framework - try to find similarities with the new one.
  4. Don’t be afraid of change.

← back to the blog

You May Also Like

Agile Software Development at DeSmart - Interview with Bartek, our PM

by Damian in , on January 18th, 2017

Bartek is a Project Director at DeSmart. I decided to ask him some questions about the way we produce great digital products

Why Should Clients Spend Some Time with the Software Provider?

by Damian in , on January 4th, 2017

Crafting a good piece of software requires patience and trust. It’s an intensive process that brings people together. Before the start of each IT project, it’s worth spending some time with the client and knowing each other.

Recognizing the Value of Extensive Software Testing

by Robert in on January 26th, 2017

Tester’s life in IT projects seems easy: you get the information that a given feature is ready for testing and you verify if it works as intended or not. If the implementation is correct, then your job is done.

Interested in Creating a Successful Project?

Contact us and together we'll bring your ideas to life!