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: