Definition of Switching point - Frontend vs Backend #4771
Comments
|
In my opinion, separation on frontend and backend as individual application is needed in like 5% of applications. Lets me explain further. If we talk about code organization, you can just create 2 folders : frontend and backend, and put relevant code in each. Just for better code organization, you do not need frontend and backend as different apps. So why you need frontend and backed as different aps ? Because your clients need it that way ? Clients are on first place. If they want to have separeted frontend and backend as 2 applications that may or may not be connected, well do it... But as I said at the beginning, you will not have many clients that will need such thing. Even further, if your clients do not need this separation and you force them to do use it, you are probably doing bad thing. They will be unhappy. Who wants to visit 2 different URL's for managing his site if he does not need to ? And if you connect frontend to use everything that is in backend, you are losing the point of having backend as different app. When is this separation needed ? It depends on the type of application. Blog apps do not need it of course. But for example you may have an aplication where super-admins need to controll in details what their clients can do. Clients will use frontend part of app, super-admins will use backend. Also, having backend part of app as different application on different URL, can be security improvenment if used properly. Basicaly, you will know do you need something like this when your clients give you their app request. Next question is, can frontend be connected with backend. In other words, if you create some functionality for backend side of your app, can frontend use some of it? Answers are yes and no :). For systems where high security is needed, I do not recommend mixing frontend with backend. This means, that frontend should have its own administration pannels, db tables, or even separate database. If very high security is not needed, then yes, you can share backend stuff with frontend just by having RBAC to control who can use what. |
|
@nenad-zivkovic, thanks. To summarize your argument:
|
|
Frankly almost evey application I have had has required a separation of admin view from front end views. I rarely separate models, in fact never have however, separation of view/controller logic has been in 100% of all my Yii1 and Yii2 projects. It is a very common use case to have two sections to a site, one being the front end that the user sees and the other being a fully fletched backend for administrators.
I do not. I house these, with the models/widges/assets/etc, in the common folder. The only time I have done this kind of separation is on some widgets that are just too close to the frontend to logically be in the common folder. Other than that the separation most commonly in views and controllers. However, people do also separate moels sometimes when the logic ould be too much to bare in a single file.
Yes, I have commonly have an admin I have one controller
What do you mean?
Yep, makes my structure better.
Does make for better code convention to know where to find admin functions. It also makes much more elegant and cleaner coding.
The last point includes consistency as well.
Despite it being more coding it does make maintanence easier when you know exactly where to look for things and your controller files are not cluttered with both backend and frontend crap (not only that but the code is isolated to your problem and you will not be effecting code that could be working, introducing bugs to that code).
Does make separation of CSS/JS specifics easier too. Also having it as a comlpetely spearate app helps external designers who don't know Yii or how a MVC framework works understand the structure of what they are looking at without training, it is logical.
Separation.
Yes, mostly. However, it does have other benefits, some of which are mentioned above.
This is probably a question best answered by experience rather than a generic rule that applies to all projects. A developer will just know when the application merits a frontend and a backend. I don't think I can apply a single fit for that documentation page, maybe providing a few pointers as to when to consider separation of backend and frontend but I cannot say: "In this case do this". To go back on what others have said:
Even a blog would need spearation between an admin end and a user end, take Wordpress for example, I would clearly separate that into a backend and frontend; in fact they have tried to, they are currently limited by the CMS' implementation.
Having built many "high security" systems even wtih Yii2 I can tell you that backend and frontend can easily share functionality and should, for example I share everything except views and contollers between the two sides.
Doesn't that kind of defeat the point of an admin end if it is not effecting the data it is supposed to be administrating? Some thoughts there for you. |
|
@Sammaye, of course, frontend & backend have different views & layout. But you don't necessarily require complex tiers separating 'frontend', 'backend' (like in the advanced app) for this.
Well, thats the whole point of this discussion. Thats the main question. |
|
Well it might not be the answer you want, but that is the answer from someone who is experienced in this kind of separation. I can give pointers as to when to consider separation but as youyr argument points out:
Separation is subjective to the view of the (lead) developer(s). I do not personally see it as complexity, I see it as logical and clean. I mean you could see it as complexity because you are dealing with an app which has not recieved the complexity required for you to find combining the two together difficult but it could also be just because you don't like it. If you don't like the sound of separation it doesn't matter how much jibberish comes out of my mouth, you shouldn't use i. |
|
@Sammaye, of course my thanx for your arguments & experience on this matter. Can I summarize your switching point as:
|
|
I would add external factors to that, I have found that designers prefer separation, they hate nothing more than having a css file that they have to strip down to get what actually effects the user, since many designers consider the frontend and backend separate as well. So as well as the point you summarised I would add that external individuals have shown to prefer it, at least the ones I (we) have used. |
|
@Sammaye, I am talking about 'tiers' here. Please read the first alinea https://github.com/yiisoft/yii2-app-advanced. When should multiple tiers be used. |
|
Yeah it is an English barrier, tiers here are thought of differently, in database and sever terms than application terms. Tiers is in fact a very vague word for me, so I call it separation. |
|
Well, would you use multple yii separations (tiers) to solve issues with designers? I.o.w, to simplify the work of designers? |
|
Yeah, it allows them to have isolated design control of a specific tier, so if you want them to edit the frontend they can do it indiscriminately without effecting the backend. Many designers don't know how to progam PHP let alone Yii, but they know what PHP code looks like and how it echos. Having the folder separation and physical CSS/JS separation at times helps with this. Widgets can still be a problem though but we solved that by crating overrides in the frontend assets so that we we have one central point of coding but tiered designs. |
|
alright, we're getting somewhere. Ill add this as a turning point. Thanks |
|
Of course this only works if you have distinct designs between the two, most applications I have built have coincidently had different design requirements for the frontend and backend. Though I think it is not a concidence afterall that a client will have different requirements between the two. So all of this is conditional to the clients request as well. So that is something to bare in mind with this point. |
|
I'm choosing advanced when I need any of these:
Most of the time if any of these is required it will get more and more controllers, components etc. and I prefere to separate these right from the start. I'm choosing basic for:
|
|
@samdark, what are the exact criteria for those 4 examples? |
|
These are exact criteria. |
|
in other words, the logic behind those examples. |
|
??? |
|
ok. I will further explain. What criterium is affected by using a separate tier? Why do you want to put all the effort in using frontend/backend/common folders & namespaces, instead of using modules?
|
|
I'm searching for architecture & programming logic. In example, I see the logic behind a UserController from the Admins perspective and a UserController from the User perpective. The creation proces could be in two different processes/actions. Separation would then be logical because of:
Therefore a 'rule of thumb' could exist:
|
It can be complicated... based on requirements and so forth. What I wanted to explain is this: |
|
Aha. I was thinking about no separation vs separation but you're talking about modules vs applications. OK. From this perspective it is a bit different. I'd prefer applications in the following cases:
In case of installable product (like Wordpress, Drupal etc.) one of your primary goals is to make installation process as simple and straightforward as possible. That's why multiple webroots won't fit. |
|
@samdark, thanks. To summarize:
|
|
What I am noticing again in this discussion is the confusion about the gray area around the 'frontend' and the 'backend'. For instance in the following example of @nenad-zivkovic , 3 environments can be extracted.
Environments :
The environments are the same ones I want to realize. The definition of backend & frontend is quite ambigious as you can see. What seem logical is to use different names & to add one.
With all the different 'advantages' mentioned in this topic & clear naming, this looks like a complete advanced app to me. |
|
I have never encountered an app with 3 layers, only 2 layers and a clever RBAC system. Take my latest project in Yii2 as an example: a ecommerce site. I have an entire backend which can deal with all the in-house cataloguing and pricing and integration into external resources like NetSuite, Parcelforce, Neilsen, whatever and then I have a frontend which takes the form of the actual website. On the back I have functions which certain people should not access within the company if they are not of a certain pay grade, for example me as an IT administrator have access to everything, as such I am given the rbac role of god whle many others in the company are given the rbac role of admin. Normally you have 2 sides to an application with a clever rbac in between to restrict access. |
|
it all depends from which perspective you look at the application. If you look at it from your perspective and @samdark #4771 (comment), you will get:
From a programmers perspective it could also make sense to look at it from a presentation perspective. How records from the DB are presented:
As you can see its about designs & filtering. Separate application could make customization easier, cleaner & get other benefits mentioned in this topic. |
|
@qiangxue, do you see a point in separation by presentation? |
|
This again comes down to personal preference as you have said: applications are entities and I don't class super admins and admins as different entities. The are the same group: admins. Only difference is one is allowed to see x while the oher can only see y. For example guests and users of an e-commerce site would not get two different apps. When you go to Amazon you don't get two different sites depending on whether you are logged in or not. An end user, whether logged in or not is an entity and a admin, whether super or normal, is an entity. That's how I look at it. I have been trying to think of a time where I would make an app with three layers. I cannot, not retail, governmental, domestic, private etc etc. I cann't think of a time where I can split more than two entities. |
|
But that being said, if you are cataloguing on Amazon (which you can) or you are doing an Amazon admin function you do then get a new site, a backend, so to speak. It looks old and decrepid but it is still a different app. So yeah, that is the way I see it. Some apps I can see I wouldn't even split out: a stock monitoring system in a finanicial institution would be all one app, all the users would be admins, the only difference is that one admin can see x while the other can only see y. |
|
The backend application as I see it serves one purpose - that's the administering of the website itself. I.e. when we have global admin interface for administering the whole website. A place where we see revenues, number of registered users, charts on how many new users registered by day, how many downloads we had, we're even handling deployments from our admin interface. Honestly - I don't want my Deployment model in the "front" part of the application.I also don't want any of the Statistics models there... etc. Yes, you can put everything in basic template with two main controllers but it's not as clean as having the backend application. |
|
Please help me with back-end path issue ... I can't access to back-end module in my project :-s .... My backend project link like this: http://calcart.axeo.net/backend |
|
@jasonhai use forum. U have problem with web server configure |
|
@lynicidn : I also dont understand your mean. Please ping me via skype: pmhai90. Thanks so much |
|
@lynicidn Thanks all for your help !!! |
|
Let's say I want to build an e-commerce with front-end for customers, backend for admin, another backend for suppliers, and one more backend for delivery companies. So I keep the shared models in common folder, but how to create the other backends with their own user type login? Whats the correct process for each section? Modules? Extensions? Application instances (tier)? |
|
If going with app instances, you can do it by copy-pasting backend directory. It's nothing more than separate apps with their own entry points. |
|
@samdark Thanks! Will try this out |
|
Make sure you make a deploy target for them else you will find you have to On 1 April 2015 at 11:53, Khalid Al-Mutawa notifications@github.com wrote:
|
|
@Sammaye Can you please explain or point to where I can find how to do that |
|
@samdark @Sammaye @qiangxue I am using mdmsoft module (for Rbac ) in the advanced application and separated frontend for website and backend for admin panel.In this case in the mdmsoft module routes of frontend app visible in frontend app and routes of backend app visible in backend app but here superadmin wants to see all the routes at same place. As per my project requirement there will be a admin panel accessed by multiple type of admin users with different permissions needs to manage main website and a superadmin will manage the permissions of few registered users of website and admin users both. Please suggest us a whether we use advance app or a basic one and how. |
|
So, two years further, I can conclude that its very useful to expand an app by more tiers. However, the developer should be careful though. The more tiers, the more complexity you will add to your configuration files. This is the largest setback. Another thing that makes it more complex is the deployment. The more tiers you have, the more deployment settings can be necessary. Also, the more tiers you have, the more difficult is to optimally test your project. If you are running a multi thread testing environment, you have to allocate your CPU's to the tiers which has consequences. With respect to the advantages. There are many. Code is better organized. Config is better organized. Theming is easier. Performance is better. Risks are lower and its even possible to deploy by tier. |
Sorry to come back on it again: a subject on which already a lot has been said. There are examples of use, examples of advantages and arguments like '@samdark: that there couldnt be one single way of use'.
Either way, I am still not satisfied with the current documentation & discussions about it. Its too vague:
Now, after 2 months of development, I keep on being confronted with the same architecture design issues - over and over again.
The same questions keep on coming back. What exactly is the real advantage for me. Is it about structure? About convention? About consistency? About making stuff easier? About easier design?
Whats the focus? Is it about users v.s. administrators? But what if users can also manager their own content. etc. etc.
Current discussions & wiki's don't give an answer on this question, apart from the example of the advantage of 'different servers'. Therefore this thread. To make it different from other discussions, I would like to focus it on one specific definition:
This definition would be of great value for the docs and people new to this subject (and for me, because I still havent got one single definition). I dont like vague scenarios, I prefer 100% solid proof definitions. Since you have the choice to use this separation or not, it means that there must be a important criterium to switch. Which is it or which are these?
The text was updated successfully, but these errors were encountered: