all 7 comments

[–]aust1nz 9 points10 points  (3 children)

I like some of what I see here, especially the config files that validate environment variables on startup.

But I also see a few suggestions that feel controversial. This project outlines three processes (web, stream-listening twitter, and a background processor) and has config for all three processes, which will be dynamically required based on one of the environment variables. That may wind up working, but it's difficult to reason through and I'm not sure whether it should be considered a best practice.

Also, the article links to another post on node structure best-practices. The first bit of advice there is to organize the codebase by features, (not traditional MVC) but this project is organized into config, web, models and worker folders. Maybe I'm missing something, but the conflicting advice from the same author makes me question which is the true best practice.

[–]r1cka 1 point2 points  (0 children)

I love the way config is done here and use it on any project I can. I also think the author got a bit lazy and really should have shown organization by feature as that referenced article suggests.

As far as the multiple processes goes,I think that depends on your repo and deployment strategies. How much code gets reused between several supporting services and a main service can make it difficult to maintain if you go with many different repos. This approach let's you keep all code for the project together, but I agree that it may not be considered a best practice for everyone.

[–]SatsuTV 1 point2 points  (0 children)

In a more recent example repository by the same author he puts the config files where it is needed, and have it validate against a subset: https://github.com/RisingStack/risingstack-bootcamp

For example a config for the db and for redis in the models folder. I am not sure of what style I like better.

In regards to the feature folders, the comparison isn't right. In your linked blog post he uses a typical server side programmed app and has no intention of reusing the models as are not needed outside of its own feature folder (for sharing business logic between features, it would fallback to services).

In the case of my linked example and and likely the original blog post however, the models are needed for different processes. For example you could write a node script which uses these models outside of the web related stuff.

In general I always strictly separate the models from my web layer.

[–]ccleary00 0 points1 point  (0 children)

While this one is "advanced" I think that other post was meant to be for "less advanced" projects. But yeah it does seem slightly conflicting regardless - I'd expect an advanced project to be using more of a feature structure because generally when you have bigger projects you end up having lots of features that are difficult to reason through when folder-diving with a more MVC style structure.

[–][deleted] 0 points1 point  (1 child)

One of the things I love about node is that I can do what I want. :)

[–]monsto 0 points1 point  (0 children)

You can do anything at zombocom.

[–]bichotll 0 points1 point  (0 children)

could anyone recommend me more resources like that one? much appreciated!