Project Architecture For Front End Applications

Deciding how to design your project’s architecture is still a complex thing. Everybody while starting a project goes through different articles and blogs to understand the ways to develop one’s project’s architecture.

Working on a badly designed project’s architecture is as difficult as designing it well.

The Architecture of your project should be so neat and descriptive so that if a new developer starts working on it, one should not encounter any problem in understanding the path that the data follows to render the ui.

People using architecture other than component based can consider component as their individual files.

Why should your project’s architecture be neat and descriptive ?

• Easily Manageable
• Easily Understable
• Optimized Coding
• Updation of Components becomes easy
• Smaller files or components are easy to debug

Here’s an image describing the gist of this article.

Project’s Architecture

So here’s the road to drive in, in order to structure your project :

Division into Components

Smaller the components, the better the handling.

Break down the UI into smaller components. The lesser the lines of code(LOC), the better you can handle the code, debug them and update them when necessary. Try to enhance the architecture of your project by :

• Moving the common components in a different directory
• Limiting the individual files to a max of 2–3 components that do not have common code with each other
• Try to generalize your components so that those can be used in different use cases
• Group the components into a single directory that are related to each other which are not used by components that are outside of the current directory

Helper Functions

Helpers should be strong and aloof

Helper Functions should be separated from the rendering logic. Helper functions should be used whenever required by the components and should be commonly declared. Helper functions are the functions that:

• Manipulate data received from the server to fit into the UI logic
• Are specific to the component logic
• Are related to the browser-specific
• Are related to the logic implemented by the developer having different criteria to reach a goal

Group the functions into a single file that are related to each other and separate the general functions into utils file

API Services

Services are the links to the data

API Services are the code that calls the server for the data given the parameters. Services should not be called directly from the UI logic. If the same API call is implemented at multiple places and there is a change in the endpoint, headers, etc then it becomes difficult to modify the services at different places. So How services are declared :

• Should be the basic implementation of the API call
• Should accept configuration (variables etc) to be passed as an argument necessary for the API call
• Should pass on the data received from the server to the calling component without modifying it
• If using React and Apollo, try using Render Props method to build the services component

Config

Config is the key to connect to the server

Config contains the configurations with respect to the environment in which the application is running. Keeping the configurations separate from the actual codebase is really necessary. Configurations should be :

• Different files for a different type of environments
• Different for a different type of resources to be fetched, i.e. assets domain, server API URL, etc.

Routes

Routes are the leading way to UI satisfaction

Routes determine the URL format or pattern through which we achieve the different webpages of the web app. While defining Routes, things to keep in mind :

• Try keeping the proper order for the routes so that your path to UI does not get lost
• The naming of routes should be as simple and short as possible

Static

Static files are the files that are not included in logics

Static files are different files such as CSS, images, js (that are rarely changed), fonts, etc. The static files should be:

• Grouped by their type
• Of low sizes if possible

Pages

Pages are the different destinations of the web application

Derived from the concept of NextJS where the directories or files in the pages directory are the destinations of the route’s path. This makes the routes and destination linking easy when we separate the first component after the route is deciphered. Pages should :

• Contain only the point of contact between the routes and the other components
• Contain the files in which the initial conditions are mentioned to boot the page
• Not contain whole logic, it should be moved to the different components with respect to their functionalities
• Be named carefully as the name of the file represent the build file and the routing component (in case of NextJS)

Graphql Queries

Graphql is the data query language to get the data from the server

Graphql requires the query format to fetch the data with the specified keys. This query language files should be kept in a different directory with a different query in different files. These should have:

• Queries grouped in one with specific type group inside those as directories
• Mutation and Subscriptions likewise
• Fragments for the queries should be excluded from the queries like a common piece of code in a different directory
• Try keeping a prefix for each query, mutation, etc name to differentiate different web apps requesting single server. like query abcPost… and query xyzPost… same query different web apps, easily differentiable
• When the files are included or required in a component then try keeping the names in caps so that it is easily recognizable for the developers to differentiate between a component and a query

Everything Else

Others comprise of different tools and tricks to power the web application

Everything else contains different tools to be used in order to start the application, manage the build, manage the spreadsheets, manage the syntax of the files to be used, etc. These should include:

• Server file to start a front end server
• Package Listing file to specify the packages or modules being used in the project
• Readme.md file to describe the project specifications, releases and different aspects on how, why and what this project is for
• .babelrc file if using babel for the compilation of the scripts
• Webpack configuration if using webpack as a bundling tool
• If using any other tool or package like apollo-client, then try making another directory for that package’s configuration as that might have more than one file related to each other