Angular-cli: angular2 fullstack nodejs server structure

Created on 23 Jun 2016  路  9Comments  路  Source: angular/angular-cli

Just trying to figure out whats the best way to build an angular 2 fullstack application, where the nodejs server is serving both, a backend endpoint (eg rest/graphql/apollo) as well as the angular 2 app?

  1. Is there any structural work / concepts done on this already? Is this in the mind of the angular-cli team?
  2. Whats the "best practice" structure?

    • Having 2 git projects, one for backend, one for the frontend? (If yes how do you wire these together while developing and later in production? how you later server them from one nodejs server?)

    • Having 1 nodejs server for the backend as well as frontend (how you expose node_modules and stuff for development and only deploy a build version in production? How you handle node modules?

  3. How does a build scenario for this look like?
  4. What about server side rendering and angular universal in this context? Any work done in this direction yet? (I'd like to build on a structure which will allow to add server side rendering in future.)

    • How does angular universal resolve data loading?

Even though the question does not fit the bug reports I hope its the right place to ask this question?

Thx I really appreciate your expertise!

Most helpful comment

My team has been working on medium to large things with Angular 2 and other node-based platforms. Our experience matches the same as almost others here:

Don't use a single node project to contain both the tooling you use for your client side application, and the tooling (and runtime dependencies etc.) for your server-side application. This is a mess in numerous ways. It makes it much harder to manage the client side with a tool like angular-cli; it makes it more difficult for each new team member to understand which dependencies or for which side. It makes dependency upgrades needlessly entangle client and server. And those are just the first few problems I think of.

Instead, make two entirely separate node projects, one for the client and one for the server. Keep all of the tooling and dependencies strictly segregated. This requires a tiny amount of extra effort. During development you need to make one of the two things proxy to the other one for maximum ease. It is probably easiest to make your server-side program proxy the serving of the client-side code, this probably requires no more than five lines of code added to your node server program. There are various packages that make it easy to add such a thing if you are using express or comparable library.

(This is separate from the question whether these two projects should go in separate source control projects, or whether they should simply be parallel directories within the same source control project. There are trade-offs, I don't have any specific advice.)

All 9 comments

To be honest I think this is almost certainly not the place for this sort of question. :)

You're asking a lot of separate questions. If I were you I would take each question individually and research it, and if the question is something that could be appropriate for StackOverflow (i.e. not mainly a matter of opinion), I would ask there.

Another tactic I often take is just to plow ahead with a scratch project, knowing I'm probably doing it wrong. This often helps illuminate the path forward.

The Angular Google Group might also be a good place to ask your questions.

IMHO split it into separate projects.

I ran into problems with older pc and node_modules size and file watchers / indexing

.. + it has it's own build system

have you heard about the mean.io project?
mango express angular nodejs

http://mean.io/

Personally, with the size of the Angular2 project and, in my experience, the complexity of server projects, having two different repos feeding each other is an easier way to manage the application. The only downside I have found for this is having to do pushed to two, or more, repos to see one change.

Well auto-correct messed that up, and I can't edit in mobile. "Having to push to two"**

Personally, I think they should be separate projects. It's easier and more sane to manage.

That being said, you can currently specify a sub-directory for your project via ng new project --source-dir=frontend. This will create all of your app files in ./src/frontend/, and thus you can add another JS project in ./src/backend/.

We're working on server-side rendering in the context of https://mobile.angular.io/, as it uses https://github.com/angular/universal for server-side rendering.

My team has been working on medium to large things with Angular 2 and other node-based platforms. Our experience matches the same as almost others here:

Don't use a single node project to contain both the tooling you use for your client side application, and the tooling (and runtime dependencies etc.) for your server-side application. This is a mess in numerous ways. It makes it much harder to manage the client side with a tool like angular-cli; it makes it more difficult for each new team member to understand which dependencies or for which side. It makes dependency upgrades needlessly entangle client and server. And those are just the first few problems I think of.

Instead, make two entirely separate node projects, one for the client and one for the server. Keep all of the tooling and dependencies strictly segregated. This requires a tiny amount of extra effort. During development you need to make one of the two things proxy to the other one for maximum ease. It is probably easiest to make your server-side program proxy the serving of the client-side code, this probably requires no more than five lines of code added to your node server program. There are various packages that make it easy to add such a thing if you are using express or comparable library.

(This is separate from the question whether these two projects should go in separate source control projects, or whether they should simply be parallel directories within the same source control project. There are trade-offs, I don't have any specific advice.)

Closing as the original question seem to have been answered.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_This action has been performed automatically by a bot._

Was this page helpful?
0 / 5 - 0 ratings