It seems like you are using an ad blocker. To enhance your experience and support our website, please consider:

  1. Signing in to disable ads on our site.
  2. Sign up if you don't have an account yet.
  3. Or, disable your ad blocker by doing this:
    • Click on the ad blocker icon in your browser's toolbar.
    • Select "Pause on this site" or a similar option for lancecourse.com.

Always separate front-end and back-end

zooboole

Published By zooboole

This may sound obvious for every front-end OR back-end developer. But, for a front-end AND back-end developer - full stack developer, this can be a very confusing situation.

Separation of concerns has proven itself to be the best approach to developing very consistent and maintainable systems. A good example of that is when you separate your HTML templates from your logic. You can change your application's presentation without having to break its core code. And we can go deeper.

While explaining the advantages of using collocating templates, scripts, and styles, at Laracon 2016, Evan You made mention of another level of separation of concerns:

"Separation by language is not separation of concern. Instead, separation of concern in a front-end application is a separation by components. The component is the basic unit of concern that you should worry about." - Evan You

But in this post, I will not go too deep into the smallest sizes of concerns. I am concerned about the whole front end and the whole back end. And most importantly how we define them while starting a new project.

The thing is that almost every full-stack developer starts with both aspects. What you always need to remind yourself is that the front end and the back end are two distinct things. And you must always approach them as such. You can start from any one of them, but never both.

Recently I understood the importance of such an approach when I decided to design an entire project before tackling its back-end. Usually, I work on a part of the design then I code it. It's a kind of parallel and modular coding. Tackling all languages together, and targeting only the completion of modules.

While this may sound OK on small-size projects, it can become a very big mistake when you are working on big projects. Simply because you don't have an idea of the whole system. You only see where you are. It's like coding blindly. When you knock on a wall, you have to turn back, or you break it. This usually leads to a spaghetti-like code base.

I suggest you start with the front end. Do every single aspect of it: layouts, typography, buttons, panels, badges, colors, menus, navigations, modals, etc. It will help you have an overview of the entire project. With that, you can predict its behavior and how to code it later.

Although this sounds like a lot of work, it's an approach that is used in many renowned businesses. I had the opportunity to meet some developers from hubtel Ltd recently. During our session, shocked by the beauty of their interfaces, I asked them how they go about starting such projects. One of the guys told me that they have a different team working only on the front end. The neatness of their work proves how careful the front-end guys were.

Separating front-end from back-end has so many advantages such as:

  • Cleanness
  • Focus on the whole system, not only a part
  • Easy maintenance
  • Flexibility
  • Independent development
  • Easy versioning
  • Continuous integration

One big challenge I have always had with such an approach is how to connect the two parts. Having a gulp, or webpack project at one side and a PHP API at the other side can be tricky to connect. I usually end up with a new approach from one project to another. But, I am sure this is a matter of configuration(team, goals, workstation, policies, etc).

Cover image by pixabay.com