Skip to content

Instantly share code, notes, and snippets.

@AmanAgarwal041
Last active July 29, 2023 10:23
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save AmanAgarwal041/c872a059d00675d837f6352aa838b4e1 to your computer and use it in GitHub Desktop.
Save AmanAgarwal041/c872a059d00675d837f6352aa838b4e1 to your computer and use it in GitHub Desktop.
Project Architecture For Front End Applications

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 your project's architecture.

Project's Architecture
Working on a badly designed project's architecture is as difficult as designing it good.
The Architecture of your project should be so neat and descriptive such that if a new developer starts working on it, one should not encounter any problem in understanding the patht 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

  • Optimised Coding

  • Updation of Components becomes easy

  • Smaller files or components are easy to debug

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


Division into Components

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 different directory

  • Limiting the individual files to 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
Helpers should be strong and aloof.

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

  • Maninpulate 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 to 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
Services are the links to the data.

Api Services are the code that call the server for the data given the parameters. Services should not be called directly from the ui logic. If 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 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
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 code base is really necessary. Configurations should be :

  • Different files for different type of environments

  • Different for different type of resources to be fetched, i.e. assets domain, server api url etc.


Routes

Routes
Routes is the leading way to the 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 gets lost

  • Naming of routes should be as simple and short as possible


Static

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. Static file should be:

  • Grouped by their type

  • Of low sizes if possible


Pages

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 destination of the routes 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
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 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 common piece of code in different directory

  • Try keeping a suffix 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 recognisable for the developers to differentiate between a component and a query


Everything Else

Others
Others comprises of different tools and tricks to power the web application.

Everything else contain 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment