I'm
> On Jul 26, 2017, at 6:21 AM, Zlatko Đurić <[email protected]> wrote: > > Certainly! Personally I would strongly suggest separating the codebases > completely (backend is 1 repo, for now, frontend is another completely. Takes > care of so much confusing things.) > > Anyway, you need a few things set up. Like, you don't wanna let your entire > node_modules/ folder public. You might have something that's critical or can > even jeopardize the underlaying system (like, exposing the del, rimraf or > similar). Which means, angular and other public code is limited to, say, > public/ folder. > > But, how do you do the sharing then? Well, another thing you should be doing > anyway (and luckily it's easy to do) is run a production build. Something > like webpack/rollup. You know, tree shaking and all. What it does is it takes > your Angular code, and Angular libs from node_modules/, and any other libs > your code uses, and bundles it all up in one (or a few) nice file - and you > only serve this file to public. > > Which again means you'll have to setup to deal with. Say your > compilation/build step (what I said above) puts stuff from public/src to > public/dist folder. You tell express to use only that code. > > And that's basically it. Maybe a few more things, like namespacing your npm > scripts better and you should be good. > > > Of course, while you're developing, you probably have some sort of local > angular dev server, which autocompiles your changes in typescript and other > files, and reloads the browser. So you could either run that dev server on a > separate port or somehow adding tihs compilation step into your dev pipeline > for your node server. So you run your node server and whatever's watching for > those changes, is also watching for frontend changes to restart or refresh > the statically served routes and fire off a browser reload. > > That's why I strongly suggest that you take the other, IMHO much better > approach. Build the node backend in one folder. Clean and simple, and make > tests for your endpoints. Don't bother with unit tests if you don't have > those already. Just make sure your GET /api/users returns an array and can do > paging and make sure that POST /api/comments asks for proper authentication > or permissions. > > Than make your frontend app in a separate repository. Also write all the > tests and ignore anything on the backend. > > That's much easier to reason about. When you're working on backend, you don't > care about pixels or form alignment or whatever. Just index the database > properly. And when you're done, you go align the pixels and forms and don't > have a singlest worry about database indexes. And as a bonus, you could still > add another build task to your frontend code, that takes whatever frontend is > built currently and copies it to the backend /public folder. > > Although I suggest splitting that one too, because again it simplifies > deployment and stuff. Don't worry about numbers of servers. You can serve > Angular apps off of S3 for probably less than a dolar, or off of a 5$ digital > ocean bucket if you really need something advanced. And your node backend is > deployed wherever you deploy it anyway. And you sleep much better, trust me. > > Also, don't worry about your node_modules sprawling for now. If you have an > older android phone, it might be a problem. I mean, if you're developing > stuff on it. Because I've just looked at size of all my node modules on this > laptop: > > find projects -name node_modules -maxdepth 2 | xargs du -shc > ... > 2.5G total > > It has my major work projects, 2 node backends, 3 angular2 projects and some > of it is just a copy of itself (for stupid reasons, don't ask), and some > random nonrelated stuff. > > My main workstation probably has like 6 gigs of node modules. I have a last > year's phone and this all could fit on it and still leave ton of space for my > photos. Although I don't know what I'd do with it on the phone. > > Well, there's my totally oversized and unnecessary, but probably not harmful > midnight answer to your question. Just like my node_modules/, oversized and > all, but it's not in anybodies' way. > > Cheers and ask specific questions if you have them. > > > > >> On Tue, Jul 25, 2017 at 6:38 PM, Tito <[email protected]> wrote: >> ok been a while and now I am ready to dive in. so yes I am using angular >> code with node.js >> I would also like to use same node_modules for these I do not want >> node_modules sprawl. Is that possible to have shared modules folder for both >> to use? >> >> Thanks >> >>> On Wednesday, June 21, 2017 at 1:16:28 AM UTC-7, Zlatko Đurić wrote: >> >>> Hi Tito, >>> >>> Congratulations on your first production deployment! :) >>> >>> There are multiple ways to run multiple "apps" from one Node (express) app. >>> You're saying Angular apps, but it seems like Node.js is involved too, so >>> I'll try to address some cases. If you have one very specific >>> >>> TL;DR: >>> - if it's just angular apps, serve app.use('/app-virtual-path', >>> express.static('/path/to/app')) >>> - if it's Node.js code as well, write those in their own modules, and >>> export their routers (not the whole express apps), than mount the >>> individual routers on a global express server. >>> >>> >>> If it's just multiple angular apps, than it's pretty simple - serve apps on >>> different routes (or even domains/network interfaces/whatnot). >>> >>> E.g. simplest way to serve those with Node on different paths, e.g. >>> server.example.com/app1 -> serves angular app 1 >>> server.example.com/app2 -> serves angular app 2 >>> etc. >>> >>> app.use('/app1', express.static('/path/to/app1')); >>> app.use('/app2', express.static('/path/to/app2')); >>> // ... >>> app.use('/appN', express.static('/path/to/appN')); >>> >>> Basically, every app is served in its own virtual path. >>> >>> Alternatively, you can serve the angular apps on different subdomains, e.g.: >>> app1.server.com -> serves app1 >>> app2.server.com -> serves app2. >>> >>> How to do this depends on your server setup. You can route it directly with >>> node, using something like this: >>> https://www.npmjs.com/package/express-subdomain. Alternatively, you can use >>> the simpler version above, but than use some rewrite rule on the reverse >>> proxy that's in front of node (such as nginx, or IIS since you're on >>> windows). >>> >>> If you also need some server-side specific code, those separate routes >>> handle the stuff, for you. For clarity, maybe just separate those in their >>> own files/folders with their own routers, than mount it all on one global >>> express router and handle routing properly. The added benefit of running it >>> all on a single node instance is that you get to share common middleware >>> like authentication or authorization, which is likely to be useful in an >>> environment that you describe. >>> >>> Example: >>> >>> // app1.js >>> const router = require('express').Router(); >>> router.use('/app-specific-endpoint', (req, res) => { >>> res.json({ message: 'Here is something that is specific for this app' }); >>> }); >>> router.use(express.static('/path/to/angular/code')); >>> module.exports = { router };helps a bit >>> >>> // app2 -> the same, just for the different angular app. >>> const router = ... >>> module.exports = { router }; >>> >>> // global express app file, e.g. server.js >>> const express = require('express') >>> const app = express(); >>> const middleware = require('./middleware/'); // optionally, if ou need it. >>> const router1 = require('./app1').router; >>> const router2 = require('./app2').router; >>> >>> app.use(middleware.auth()); >>> app.use('/angular-app-1', router1); >>> app.use('/angular-app-2', middleware.hasRole('admin')); // specific for >>> app2, say, permissions check >>> app.use('/angular-app-2', router2); >>> const port = 8080; >>> app.listen(port, (err) => console.log(err || `Listening on ${port}`)); >>> >>> I hope this gives you ideas on how to start. If you share more details, >>> maybe you can get more specific answers. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Angular and AngularJS discussion" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/angular/gR9Yii7oSGQ/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/angular. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Zlatko > -- > You received this message because you are subscribed to the Google Groups > "Angular and AngularJS discussion" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Angular and AngularJS discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
