New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application Parts usability issues #4420

dandago opened this Issue Apr 7, 2018 · 1 comment


None yet
3 participants

dandago commented Apr 7, 2018

I think there are several areas where this new "Application Parts" concept can be improved.

First of all, why "application parts"? As someone new to the term, I see it as something very vague and unintuitive. What is an "application part" anyway? Is it just a location where grains are loaded, or does it serve some additional purpose? Why was there the need to confuse people with a new term, rather than just providing an API like LoadGrains(...)?

As a result of this, I find the following code (from here the Hello World sample) completely unreadable:

.ConfigureApplicationParts(parts => parts.AddApplicationPart(typeof(HelloGrain).Assembly).WithReferences())

Looking at this, one wonders:

  1. What is an "application part"?
  2. Why do I give it an assembly?
  3. What does WithReferences() do?

Well, let's check out the method documentation:





As it turns out, Application Parts documentation is buried deep within the Deployment section of the documentation.

"Although this step is not technically required (if not configured, Orleans will scan all assembly in the current folder), developers are encouraged to configure this. This step will help Orleans to load user assemblies and types. These assemblies are referred to as Application Parts. All Grains, Grain Interfaces, and Serializers are discovered using Application Parts."

If developers are encouraged to configure application parts, then I believe they should be referenced in all documentation which describes setting up a basic silo. That includes the Hello World sample documentation and Running the Application (although this needs to be cleaned up first as per #4416).

@sergeybykov sergeybykov added this to the Triage milestone Apr 10, 2018


This comment has been minimized.


ReubenBond commented Apr 10, 2018

I'm not sure that we should encourage developers to configure these things unless they run into issues. Ideally, the default behavior is sufficient and only if users want to optimize startup times or write an extension library should they need to understand Application Parts.

Why "application parts"?

We used the same name that ASP.NET used:

The functionality covers grain classes, grain interfaces, and serializers.

Your criticisms are fair and your input is welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment