Separate admin from front-end

[thomporter]

Interesting thought I had while mulling over #472 in my mind... I've actually always kept my admin code separate from front end, and for Agnular that's meant building 2 sets of files, one for front, one for admin (keeps the front-end's file size down and in some cases keeps from exposing sensitive biz logic in the JavaScript to the public.) So typically I'd have "app.js" and "vendor.js" for the front-end and then "admin.js" and "admin-vendor.js" for the admin.

How do you all feel about separating the admin & front-end code, so that the client's app.js is free of any admin code or it's dependencies, and then there could be "admin.js" and "admin-vendor.js" files for the admin. I don't think this would be hard to implement, I'd be happy to take a crack.

Footnote:
At the moment I have a project I built w/ this generator that I actually created 2 separate projects for, "front" and "admin" (running on separate sub-domains.) They even use independent APIs (I did symlink the model files.) This has worked great for me, though I'm not sure it would be to everyone's fancy.

[kingcody]

As far as a build goes, could you explain the advantages in splitting up app and admin? It would increase the amount of requests for a page load. Now I do understand that with http1.1 pipelining, the overhead is reduced but I guess I'm just wondering why modularize the final product?

[thomporter]

It would increase the amount of requests for a page load.

I'm not suggesting we link "admin.js" into the front-end at all. Instead I'm suggesting we have a new HTML page, sitting at it's own URL, and only it has the admin.js and admin-vendor.js linked in - essentially making it a separate app. If an admin logs into the site, and then clicks the link to go to the admin, the browser would do a full page refresh to get there. No extra request for a normal user on the front-end.

There are 2 reasons I do this:

1. File Size - Most of the projects I've worked on have ended up having a lot more code in the admin (especially vendor dependencies.) To give you an example, a project I worked on recently had a 24K vendor file for the front end, and almost 500K vendor file for the admin. 😢 (these are uncompressed, unminified sizes, but still, it illustrates the point.) The admin had a lot of functionality that just wasn't used anywhere on the front end (things like sorting lists, editing the product catalog, etc.)

2. Security - If there is anything in the admin that exposes some business logic we want kept private, then that can't be in the front-end JavaScript. This is rare, but when it does comes up, it is a critical issue to the client.

For me, reason 1 really is enough. I want my front-end apps to be as small as possible, so they load fast. Admin users can deal w/ an extra page refresh, and all of my clients have understood the reasoning behind it.

All that said, I'm quite happy to continue to use the generator how I mentioned in the footnote of my original comment, but I thought I'd mention it to help the rest of the community. I suppose this can be left to the dev to decide, but trying to set this up as I've described (a separate admin.html and admin assets) would require a lot of legwork in the Gruntfile...

We could make this an option in the generator. Maybe filters.separateAdmin? I do believe it would require very few changes to code outside the Gruntfile... In fact I think just the express middleware would need some code to detect if the admin URL is being requested, and if so, it serves up the admin HTML instead (assuming the user is logged in, if not, redirect them to login on front end app.)

[simonh1000]

This would be interesting for me too. I wanted to build the database admin tools (used by 1 person) alongside the client database-using tools (used by all), and could not readily see a way of keeping the code separate - I'd started building the functionality into new routes on the server side before I saw this question.

Added later: thinking about it some more, if I want to make my admin pages inaccessible to general users, then they should not be built into an app at all, I think? I need to serve those pages directly from express after testing auth.isAuthenticated. Am I right on that?

[thomporter]

The solution for me is still to use a separate sub-domain and have two completely separate projects, sharing a common DB. It's not very elegant, it is a pain when you're working on one and need to pull up the other, but otherwise works well for me. And it's kind of nice knowing the publicly available API is extremely under-powered. Even if someone compromises an admin password they can't do anything with it on the front-end, they have to find that admin sub-domain...

[vineshhpatel]

@thomporter I am exactly looking for a solution like yours i.e. having separate SPAs for admin and normal landing pages. Do you have project structure set it up on github or somewhere in article? I would love to go through it as I am having trouble setting up the structure.

[keatz55]

+1

[kingcody]

For anyone interested, I am working on moving the admin functionality into its own module. That should make it a lot easier to move it to a separate project, as requested here.

[keatz55]

@kingcody I ghetto-rigged my build to handle multiple modules, fe. admin, main, etc.. I have a Shared module between them all as well, but I'm sure yours is 10X better than mine and would love to see what you have cooking up.

[palfaro91]

I know this is an old question but I just stumbled upon this situation and I'm stuck. Any guidance as to how to get this going? Admin would be used as product/user management and the other would be the website visible to the public.

[worthy7]

The way I see it is this.
We can have a basic user, and a super-admin, and also anything in-between at some point in the future.
So because of that chance, a super-admin should just be a basic user with many of permissions/roles added, and the app should react accordingly.

IE, show extra things in the dashboard for the extra permissions the admin user has. Surely your admin is an actual user too right? So why make them have two accounts.
This also facilitates when they leave the company, and you want to revoke the permission. You just do that. Otherwise you would have to change passwords etc if they are all on one account.

As for the front end, file size + security issues:

1. The files SHOULD be as small as can be if you are managing your modules properly. This means making Admin a lazy loaded module, protected by a guard.
   https://angular.io/guide/router#canload-guard-guarding-unauthorized-loading-of-feature-modules
   It will tell the angular cli to chunk off the entire admin branch, and the client will only download that when they have permission/click it.

2. The security aspect I'm not 100% sure. I'm sure it's somehow possible for a basic user to flick through all current code, and find the url to download the admin code. It's going to be compressed/obfuscated, but still they can probably fine API endpoints. As long as those endpoints are all secure (check the permissions of the user) then it should be safe enough. Business logic is going to be so obfuscated, but not impossible I guess.

I think the trade of for that tiny risk of someone getting that far is worth it to keep an app simple.
Now... how do I make angular read admin.myapp.com and go directly to my admin panel...