gRPC Protos

[achmstein]

I'm using gRPC with Blazor WASM! Where should I define my Protos? Infrastructer Layer?

Should I use AutoMapper to convert gRPC request class to Command or Query? If yes, where should I define mappings?

[MichelJansson]

I'm trying to figure out the same. And no matter how I twist and turn it, it doesn't seam to fit anywhere and just makes it all more complicated.

I've found two, sort of working ways so far;

1. Define it in a project shared with WebUI, and to do automapping from all the gRPC models to the Application models (command, queries, dtos..), inside the gRPC service implementation.
   Although this works, I have to define everything tree times (Domain, Application, proto), and do so many mappings it just seams crazy.

2. Ditch all the Application DTOs and map directly to the proto models inside the Application project. Doing this initially seam to make sense as it's remove all the issues the first method has.
   What we have done now though, is made our application core rely on technologies which to me is a presentation layer technology.

But what we also have to do for both methods, to have the isolation of DTOs between all the commands and queries (as Jason intended), we would basically have to create proto files for each command and query. Then these needs to be organized by namespace in some way, probably similar to the Application project namespace structure, probably making it a bit weird to use for the client as I have yet to find a way to have different namespaces for server/client.

Any thoughts and/or comments on this is much appreciated.

[AwkEng]

I've been playing around with gRPC recently and here is an example solution that has worked well for me so far. I forked the CA repo and added a Hosted Blazor Wasm project. I'm more familiar with Blazor than Angular at this point.

https://github.com/AdamQuintana/CleanArchitecture

The repo sets up a parallel gRPC service for WeatherForecast FetchData query.

Here is how I have it set up:

• I defined a proto file in the Application's WeatherForecasts sub-folder - ie. Application/WeatherForecasts/WeatherForecasts.proto

• I define all the services, requests and responses for WeatherForecasts in the proto file

• I also define all the DTOs in the proto file and give them the same name as your *.cs DTOs.

• I made my *.cs DTOs partial classes. This allows you to keep the automapper mapping code, but remove the properties since they are autogenerated by the proto.

• I had to drop all my DTOs to the same namespace level as the proto file. I'm personally OK with this because I sometimes reuse DTOs between Queries/Commands. If you want to keep them isolated by "feature" then this may require a proto per DTO
  as @MichelJansson points out. I haven't found a way around this (yet).

• Add the protobuf ItemGroup to Application.csproj. I generate the Client and Server code here, hence the "=Both". Once again, I'm personally OK with having all the generated Client/Server code in the Application project.

<ItemGroup> <Protobuf Include="WeatherForecasts\WeatherForecasts.proto" GrpcServices="Both" /> </ItemGroup>

• I created a WeatherForecastService in the Server project, which inherits from the generated server code.

• Plumb it all up in the Server's Startup.cs.

Open to feedback/suggestions.

[MichelJansson]

@adamquintana, thanks for sharing your take on this.
Though I would have to say I'm not too fond of the idea to make the Blazor WASM client depend on the Application layer/project, as then all your business logic (application.dll) would be downloaded to all your clients.
One easy way around that in your architecture would be to reference/link the proto file directly, instead of referencing the entire application project.

In the spirit of keeping it clean I'm sticking to my "option 1" for now. Both not to get stuck on this, but also to try out how horrible it actually is 😅. The upside of doing this of course is that I still have the boundaries intact and I can easily change stuff without having to redo my business logic.

[AwkEng]

@MichelJansson Very good point. My application.dll and domain.dll are downloaded by the client. I'm hopeful the .NET team will improve the tree-shaking/linker options for user code. If you are aware of anything currently please let me know. I also think AOT would help in this area too (more for obfuscation).

[AwkEng]

Found this comment regarding application linking. Haven't found a tracking issue on the .NET repo, if there is one..
dotnet/aspnetcore#22230 (comment)

And of course the AOT issue:
dotnet/aspnetcore#5466

[MichelJansson]

Very good point. My application.dll and domain.dll are downloaded by the client. I'm hopeful the .NET team will improve the tree-shaking/linker options for user code. If you are aware of anything currently please let me know. I also think AOT would help in this area too (more for obfuscation).

In your case, where you are fine with having grpc things inside application - I think it would be straight forward just to reference the protos, that can be done right now, instead of waiting for the magic tree-shaker.

<!-- Client.csproj -->
<ItemGroup>
    <Protobuf Include="..\..\Application\WeatherForecasts\WeatherForecasts.proto" GrpcServices="Client">
        <Link>Protos\WeatherForecasts.proto</Link>
    </Protobuf>
</ItemGroup>

<!-- Server.csproj -->
<ItemGroup>
    <Protobuf Include="..\..\Application\WeatherForecasts\WeatherForecasts.proto" GrpcServices="Server">
        <Link>Protos\WeatherForecasts.proto</Link>
    </Protobuf>
</ItemGroup>

<!-- Application.csproj -->
<ItemGroup>
    <Protobuf Include="WeatherForecasts\WeatherForecasts.proto" GrpcServices="None" />
</ItemGroup>

Would be cool to hear if that works. That may well be the best solution as then we only have to bend to rules slightly, as we now are only (I think?) using the Grpc.Tools for the build time code generation, and some package for the special data types.

[AwkEng]

I did try it, but started running into conflicts fairly quickly. I removed the Application project reference from the Blazor Client. The conflicts are in my gRPC Service implementation which lives in the Server project. Since it still references both Client and Application projects, it conflicts with the client's and application's generated code.

I probably won't go any further with that route. One of the main draws of Blazor is to be able to share code between front end and back end. My projects will ultimately be sharing more than just proto files - think DTOs, Enums, Utility classes, etc. It makes sense to have these in an inner layer for all to share. I just need to pray harder to the tree-shaker gods. 😬

[ivanivanyuk1993]

This configuration worked great for me, note that proto_local has only one folder ui, which we allow to be compiled by CompileOutputs="true", your case may be different

    <Target Name="CopyProto">
        <ItemGroup>
            <ListRequestProtoDir Include="../UtilNet/CRUDRequestHandlerNS/proto/**/*.proto" />
            <LoadingObservableCacheProtoDir Include="../UtilNet/LoadingObservableCacheNS/proto/**/*.proto" />
            <LocalProtoDir Include="proto_local/**/*.proto" />
        </ItemGroup>
        <Copy SourceFiles="@(ListRequestProtoDir)" DestinationFolder="proto/%(RecursiveDir)" />
        <Copy SourceFiles="@(LoadingObservableCacheProtoDir)" DestinationFolder="proto/%(RecursiveDir)" />
        <Copy SourceFiles="@(LocalProtoDir)" DestinationFolder="proto/%(RecursiveDir)" />
        <Exec Command="sh bash/compile_proto_js.sh" />
    </Target>
    <ItemGroup>
        <Protobuf Include="proto/**/*.proto" CompileOutputs="false" />
        <Protobuf Update="proto/ui/**/*.proto" CompileOutputs="true" />
    </ItemGroup>