Project Layout

[adamreed90]

Current Layout and Project Owners:

• HelloDotNet6/
• HelloDotNet6/Console (Console App) - @georgestevens99
• HelloDotNet6/ServiceAgRPC (ASP.NET Core gRPC Service) - @adamreed90

[georgestevens99]

A year ago I did a few code samples using ASP.NET gRPC services and I ran into problems with the protos directory path name that took a lot of my time. This directory is where the protobuf file(s) live. So I just did the simplest thing and left it as the VS templates made it. That is probably a good thing to do at least at first.

[adamreed90]

The Grpc.Tools has come a long way, you simply point to the Protos in your .csproj file, I found it MUCH easier to use!

https://docs.microsoft.com/en-us/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-6.0&tabs=visual-studio

[georgestevens99]

Thats good to hear. I was attempting to have a single copy of each protobuf file in a special Protos directory the solution directory, rather than having multiple protobuf files as does the link you provided. Having a single copy for all clients and services to use in common makes code changes much less work. Let's save that for later and do it the way the tutorial does it. That way it will be easy for Dapr learners to understand.

[adamreed90]

What I haven't tried yet, is keeping the Proto files in a Class Library and referencing it in both projects, I'd be interested in seeing if that is possible, so that keeping 2 Proto files in two separate projects sync isn't necessary.

[georgestevens99]

Here is more for the project layout, keeping it flat and simple to avoid time consuming issues with file locations, etc. It builds on yours.
HelloDotNet6/
HelloDotNet6/Console
HelloDotNet6/ServiceA
HelloDotNet6/ServiceB

Where ServiceA is an ASP.NET Core grpc service and ServiceB is an ASP.NET Core WebAPI service.

[adamreed90]

I suggest naming them very explictly, like GrpcApiService, HttpApiService, etc. so they can be easily identified throughout (for example if we get docker-compose working properly)

[georgestevens99]

I created a branch and added a grpc service. I created a pull request (Scaffold grpc service a dapr#107. Open. georgestevens99 wants to merge 3 commits into dapr:master from adamreed90:Scaffold-grpcServiceA). It is awaiting review. I am worried I did something wrong since it is trying to merge into dapr:master. Please let me know if this is OK.

And I used explicit naming, ServiceAgRPC. I dropped the API since all services have APIs. Thus the http WebAPI would be called WebAPIAhttp. I used "A" to allow for the possibility of having multiple gRPC services and or WebAPIs.

Any way, naming is the least of my worries since I may have messed up the merge. It is no problem for me to delete everything and start over since I made no code changes.
Thanks.

[adamreed90]

You did a PR to the main dapr repository.
You'll want to make a branch on our Repo,
then make PR's to our master branch. You'll want to delete that.

Once our project is complete and tested we would PR to the main dapr/samples repo.

[georgestevens99]

I just closed my 3 failed (due to DCOs) PRs on the main Dapr/samples repo.

[adamreed90]

@georgestevens99 @paulgyro Who wanted to do what? I would like to handle the gRPC Service, but I'm up for whatever you like.

[georgestevens99]

That's fine with me.

I plan to take my console code from my Dapr Mesh example and copy it into our Console and then comment it out. Then pick out parts that can be used to interact with the existing WeatherForecast of the WebAPIAhttp, just to get it working. Then clean up to code a little later on.

From prior experience, the code in the WebAPI that communicates via service invocation to grpcServiceA, or just via straight grpc for that matter, is fairly simple and quite terse. @adamreed90 @paulgyro

[adamreed90]

Sounds good, I'll keep track of the project layout and ownership in the first thread here.