CODEWITHSUNDEEP
angular.net-corenrwl-nxnrwl
mtpultz
mtpultz

Reputation: 18268

NxWorkspace applied to existing .Net Core API with Multiple Angular Clients

I'm doing a spike on the NxWorkspace and its implementation within an existing .Net Core solution where we have multiple Angular applications that could benefit from the NxWorkspace. I understand how this would work when creating a new repo that didn’t have a .Net Core API, but I’m having a hard time envisioning the implementation of the NxWorkspace to our existing repo.

What I’m trying to figure out is best practice when it comes to using Nx with .Net Core (or a non-JS technology)? Does Nx have to be in the root, or would it matter if it was in a folder down one-level? I’ve worked through the NxWorkspace video lectures so I understand the utility of Nx, but falling short on how it could be applied to our existing repo, or whether it should be even with its benefits. For example:

BEFORE

Current folder structure in root omitting OpenShift, Docker, and pipeline artifacts:

/dotnet-webapi
/client1-angular
/client2-angular
/client3-react

AFTER

New folder structure with NxWorkspace in /client-workspace:

/dotnet-webapi
/client-workspace (NxWorkspace)
  /apps
    /client1-angular
    /client2-angular
    /client3-angular
  /libs
  /tools

VERSUS

The NxWorkspace in the root even though it won't benefit the .Net Core API at all, and it feels like it is burying the API within a JS eco-system:

/apps
  /dotnet-webapi
  /client1-angular
  /client2-angular
  /client3-angular
/libs
/tools

Upvotes: 5

Views: 1751

Answers (1)

Craigory Coppola
Craigory Coppola

Reputation: 837

We leverage several internal .NET core API's for our angular apps at work, but currently our monorepo only contains the Angular applications. We definitely have been feeling the benefits on those, and would like to eventually expand it to house the .NET API's.

Either of the two after versions should work fine. Personally, we are holding off on adding the .NET projects into the monorepo until a good plugin similar to the Nx Community GO plugin comes along for .NET. After that plugin is created, we would adopt a strategy like your second version, where the apis are under the apps directory.

While you are correct that currently it would not benefit from it, as soon as a good .NET plugin is created you would be able to add it to workspace/nx.json and start getting some benefits. Those benefits would include the computation cache, build:afffected and so on, despite not being able to reference them from the typescript portion of the app stack.

Upvotes: 5

Related Questions