Where is it better to store the admin panel for the site?

If we talk about a serious approach to site building using gulp , then the structure of the site files will look like this:

enter image description here

Since the admin panel is, in fact, a separate site, it is likely that it will have to create a separate myproject for it. Is it worth doing?

  • And besides the galp, use something else? Any framework? If for example Laravel, then the files are stored in the same place as the whole site and there is no need to share anything - Ilgam Karimov
  • Everything, except files to which you allow access by a direct link (CSS, JS, images, audio, video, etc; in one word - assets), must be kept under the site root. - Roman Grinyov 4:34
  • I do not use any framework; I do everything on HTML, CSS with preprocessing, JavaScript with jQuery and PHP. It's all. - Bokov Gleb

2 answers 2

Perhaps such a structure would suit:

 myproject (app) /admin // Ρ„Ρ€ΠΎΠ½Ρ‚ для Π°Π΄ΠΌΠΈΠ½ΠΊΠΈ /api // сСрвСрный ΠΊΠΎΠ΄ /webside(ΠΈΠ»ΠΈ frontend) // Ρ„Ρ€ΠΎΠ½Ρ‚ сайта /common // ΠΎΠ±Ρ‰Π΅Π΅ для Π°Π΄ΠΌΠΈΠ½ΠΊΠΈ ΠΈ сайта (сюда ΠΌΠΎΠΆΠ½ΠΎ ассСты Π·Π°ΠΊΠΈΠ½ΡƒΡ‚ΡŒ)
  • Thank you for the answer! All these folders will go in dist, right? - Lateral Gleb
  • @GurebuBokofu yes - stasovlas

If you are developing a site using a modular (component) approach, and if you allow the likelihood that components will intersect between projects, then admin assets should be stored in the same place as the main site. For example, if you are developing an online store, then you may have many components that will intersect between the admin area and the main site. For example, product cards. On the main site, these cards are displayed in the product catalog, and in the admin panel - as a preview. Such an approach will allow you to get rid of the duplicate code and arrange the admin panel in a style similar to the main site. In addition to serious components, you can also protect yourself from repeating code when creating such trivial things as shapes, buttons, icons, etc.

If you do not use modularity, that is, if your components are dependent on each other, then divide into two projects.