Nx: What is the naming convention for apps in `/apps`?

[dolanmiu]

I have about 10 apps in the /apps folder.

Should the selector of the @Components be prefixed with app-?

e.g. app-root,

or should it be prefixed with the app name?

E.g. if my app is called FooBar, then I will have a component called fb-root?

[xmlking]

My preference is abc-app(webApp), abc-mobile, abc-api

[dolanmiu]

what does abc- stand for? lol

[xmlking]

Can be your sub project/app name. In my case , I have admin, launchpad

[SebasG22]

I highly recommended the proposed way to classify the libs by @vsavkin that are mentioned on the Enterprise Angular Monorepo Patterns.

Basically the convention for libs are:

• Feature: feature-shell
• Data: data-access
• UI: ui
• Utils: utils

[xmlking]

All lib modules can be classified as

• private, public (publishable, private)
• Client-side , service-side
• Framework : angular , react, nestjs, none
• Loading/packaging : Lazy, eager
• Routable , non-routable modules

I feel we should tag 🏷 them and expect IDEs color code them, instead of trying to name them

[SebasG22]

@xmlking I think that kind of classifiers are helpful on tags for advance analysis. Because you can use multiple tags to denote their nature. Imposing Constraints on the Dependency Graph
I believe the use of the concepts for feature-shell - data-access - ui - utils are great to have a standard way to do it.

[vsavkin]

You can find some notes on using names to denote type and folder structure to denote scope here: https://github.com/nrwl/nx/blob/master/docs/guides/monorepo-nx-enterprise.md.

[demisx]

@vsavkin Can the link above be updated? We are also evaluating Nx and having hard time finding clear guidelines on best practices and naming conventions for workspaces/apps/libs etc. Thank you very much.

[jdpearce]

@demisx (et al) - You can now find the "Enterprise Angular Monorepo Patterns" book on the Nrwl Connect platform - https://connect.nrwl.io/app/books/enterprise-angular-monorepo-patterns

It's free to access and there are other books, courses and a list of "cookbook" recipes you may also find useful.

[demisx]

@jdpearce Got it! Thank you very much. Is there a way to download/buy this book in some electronic that can be read on iPad on a plane, for example? I couldn't find such option.

[jdpearce]

@demisx You should be able to download it from here : https://go.nrwl.io/angular-enterprise-monorepo-patterns-new-book

Apologies for the enormous image on that page. 😬

[demisx]

@jdpearce Thank you. Isn't this the same book as on the connect .nrwl.io website? I've read that one 3 times already, but the types mentioned there seem to be specific to a frontend Angular app. I am inquiring about what types would be applicable to a backend API app. Any examples out there?

[jdpearce]

@demisx That is the same book, yes but you should be able to use the same guidelines - they're not designed to be Angular specific. We go with fairly broad type annotations: feature-, data-, ui-, utils- etc. (as mentioned above). You may not have much use for ui- but the others would be applicable.

(Of course, that may not be true if your backend app is NextJS 🤷‍♀️)

[demisx]

@jdpearce Gotcha. My backend is Koa2 Node.js, which is pretty similar to Express, but maybe a little more TypeScript friendly. So, for the sake of simplicity, I'd assume that my backend is Node.js Express. With that in mind, here are the kind of questions I have:

1. I am still a little unclear on how to create types for the backend libs and how many there should be.
2. What are these types for in the context of an API app? Why exactly we need them and what do they affect?
3. Why the types for backend libs based on NextJS would be different from the types for backend libs based on node Express, for example.
4. What are the ramifications of not using types in backend libs at all?

And so on. Please note, I deliberately making it clear that I am interested only in the backend app/libs context here. If anyone could please share some guidance and/or real life examples on how they use types in a backend API app, I'd truly appreciate it. Thank you very much.

[demisx]

Another thought just hit me -- maybe I should not be thinking in terms of frontend vs backend when I am talking about libs since they encapsulate the majority of functionality that can be potentially reused by any app? 🤔

[BovineEnthusiast]

EDIT: Misread @jdpearce's comment. Thought she said nestjs not nextjs so you can probably ignore the framework comment below.

After reading the book and docs this is my understanding:

My guess for an API would be something like the following. I don’t think this is specific to nestjs or another framework since I believe these concepts exist in all common Node frameworks.

• Controllers (and maybe routes) go under a feature library

• Database related services go under data-access

• Guard like services (or any middleware really) go under utils

The routes could also be in an app library possibly?

The purpose of types (and this what you lose out on by not using them) is for analysis and to enforce allowed dependencies (Utils shouldn’t be allowed to import from features)

In the case that you need to create a new type (which is strongly discouraged) you would probably look at a dependency graph of your application and determine if there is a group of libraries that would be better categorized under a new type.

Does that sound correct? I think this should cover @demisx’s questions as well.

Thanks!