Front end architecture

I am a developer since 2010, but only recently I started to work a little more with front end frameworks. I've worked a lot more with backend development, I have a lot more experience creating and developing backend projects. So, almost every project I worked use MVC architecture, and when I started to work in some front end projects, using angular or react, I tend to structure my project's folders and files thinking in MVC, using the same structure I would use in a backend project using RubyOnRails.

Taking advantage that in my job team, at SumOne, we decided to organize some talks, I choose to do a talk about front end architecture so this would be an opportunity to learn. So, I started to research and read a little more about front end architecture possibilities and pros and cons of each one. Besides the type based folder structure, that is similar to MVC structure folders and what I was used to, I found that most front end developers recommend a feature based folder structure to organize project's code files.

So, I did a small presentation and develop a sample project on github to show how a react project would like on each kind of folder structure: type based, feature based and mix based. In the github project, there are master and three more branches, each one using a different folder structure approach.

First, you have the type based, that, like I said before in this text, is much similar to what rails developers are used to. The projects is only organized by type. So, you have all services files on same folder, all API files together, all view files on another folder.

On the other side, the feature based structure split files by feature, keeping service, API, action and view files for the same feature on the same folder. For example, if you have a list feature, you would have the API file that make the request call to get items to list, action file that call API and return the answer to view and view file itself on the same folder.

Lastly, you can use a mix based folder structure, organizing by feature first, and inside of each feature folder. This structure makes easy to find all code related to a feature, for example, if we have a search feature and want to change the api request for the search form, I just have to search for the api file on search feature folder. Following this mix based structure, if you have a large feature, that has a lot of code files, more than one api call, for example, you can organize files by type(API, Services, Actions, Views, Styles, …) inside the feature folder. So you have first your project organized by feature, and each feature organized by type.

Personally, I liked more the mix based structure, I think that is easy to maintain, easy to find all related files and to adds new features to a project. But you can check my presentation and the github project to build your own opinion about what you want to use on your project.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

*OBSOLETE* How to compile “blue-app-eth dockerized builder” from source in Windows 10

Tryhackme Mr Robot CTF Writeup

Internal working of get(key) and put(key,value) in HashMaps

CS373 Spring 2022: Elliot Sims

Software Engineering | Software Quality?

Special AMA Session Recap: BAoE x Satoshi Club

[Splunk]How to capture log using Splunk Universal Forwarder

Three Developer Articles that Interested Me This Week — 3/28/2022

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
João Paulo Lethier

João Paulo Lethier

More from Medium

Using Emotion in React App

How to Design a Call History UI Using the React ListView Component

Create dark mode structure in React projects (using Tailwind CSS, Typescript, and Custom Hook)