search

Glimpse / Glimpse.Prototype

Glimpse v2 prototype
MIT License
185 stars 44 forks source link

Figure out Install-Package experience #13

Closed nikmd23 closed 9 years ago

nikmd23 commented 9 years ago

What does the Glimpse v2 install experience look like? This issue is not about nailing down names or actually creating all the packages, but rather represents a thought exercise that should solve:

  1. How will users install Glimpse into their greenfield application?
  2. How will Glimpse grow with users when they move to a multiple WFE environment?

To be considered, Agents, Server, Client(s), Storage & Extensions, both client & agent based.

avanderhoorn commented 9 years ago

The current proposed package structure is fairly granular. This has the benefit of facilitating a lot of code reuse/sharing, as well as a lot of facilitating a lot of different deployment models.

Base Structure

Its is built on the back of the following shared packages:

Then when it starts coming to concrete implementations we have the following packages:

*Denotes packages that are not yet in existence

Common Configurations

Many different configuration options are possible, but the two most common use cases pivot around whether one is in development or production. During development, setup and configuration should be simple and easy to understand. When moving to production, due to the very nature of production and the different possible setups, configuration should be explicit and defined by the user.

Development This will most commonly be used during development or in single server server test environments, where persistent storage isn't needed. It would leverage the following components:

Service Configuration The combination of packages and the agent and server running in proc on the one machine would result in a service configuration like the following:

public void ConfigureServices(IServiceCollection services)
{
  services
    .AddGlimpse()
    .RunningAgentWeb()
    .WithAgentBrowser().WithAgentMvc().WithAgentAdo().WithAgentEf().WithAgentNetwork()
    .RunningServerWeb()
    .WithLocalAgent()
    .WithClientWeb().WithClientHud();
  //...
}

Production This is used in cases where multiple servers are at play (hence the agent needs to run on multiple machines) and a central Glimpse server is used to consolidate the collected data. It would leverage the following components:

Service Configuration The resulting package split needed to run the agent and server on different machines would result in a service configuration like the following:

// Agent config
public void ConfigureServices(IServiceCollection services)
{
  services
    .AddGlimpse()
    .RunningAgentWeb()
    .WithAgentBrowser().WithAgentMvc().WithAgentAdo().WithAgentEf().WithAgentNetwork()
    .UsingSocketConnection()
  //...
}

// Server config
public void ConfigureServices(IServiceCollection services)
{
  services
    .AddGlimpse()
    .RunningServerWeb() 
    .WithClientWeb().WithClientHud()
    .UsingXyzForStorage();
  //...
}

Meta Packages

Despite the fact that the package structure allows for a high degree of flexibility on the behalf of the user, for the most common use case (development), it requires a large amount of knowledge to get the various pieces to work together. "Meta" packages are commonly used to service the most common use cases for a project - as leveraged by Microsoft.AspNet.Mvc. Hence the following meta packages are being proposed:

Glimpse.Development/Glimpse This package is targeted at simplifying the Development time use case above. By adding the one Glimpse.Development/Glimpse package, it would bring in the following packages automatically:

Service Configuration Further more, it would reduce the service configuration to the following:

public void ConfigureServices(IServiceCollection services)
{
  services
  .AddGlimpseForDevelopment();

  // NOTE: `.AddGlimpseForDevelopment()` would be a wrapper around the following
  // services
  //     .AddGlimpse()
  //     .RunningAgentWeb()
  //         .WithAgentBrowser().WithAgentMvc().WithAgentAdo().WithAgentEf().WithAgentNetwork()
  //     .RunningServerWeb()
  //         .WithLocalAgent()
  //         .WithClientWeb().WithClientHud();
  //...
}

Other Other meta packages could be considered but they could also result in confusion if over used. The other two that possibly make sense are:

These would wrap up the most common Agent and Server scenarios. Note, server is more difficult as in the Server case, a storage strategy is required to be setup by the user.

Feedback

If you have any thoughts on the proposed package setup please let us know.

nikmd23 commented 9 years ago

I have a few questions:

  • Glimpse.Web.Common: Anything that any package that is on a web stack would need

Q) What's an example of something that would go in there?

Agents:

  • Glimpse.Agent.Browser: Browser agent host & base agent inspector, served from the below Host

Clients:

  • Glimpse.Client.Web: Web Client that acts as primary view, served from Web Server
  • Glimpse.Client.Hud*: Hud Client that acts as secondary view, served from Web Server

Q) Is it safe to assume that these won't be a NuGet package but rather an NPM, Bower or JSPM packages?

  • Glimpse.Agent.Connection.Http: Connection agent strategy using Http connections for Agents
  • Glimpse.Agent.Connection.Socket: Connection agent strategy using Web Sockets for Agents

Q) Connections are tricky because there is a client side and a server side to each end. Some clients are JS based while others are .NET based. Perhaps it'd be good to elevate connections to their own section of the document? I think #22 covers all the combinations we'd support.

Note, it may make sense to loop back to this question once #22 is complete.

Server:

  • Glimpse.Server.Web: Web Server & Service which coordinates storage and client access

Q) Is the idea that there would be more packages in this section to handle hosting the server? For example, how might deployment of the server to an Azure Web Site work?

Glimpse.Development/Glimpse

Q) I really like the idea of the development time meta-package just being called Glimpse. I wonder how that will play up with 1.X packages.

Service Configuration

Q) I appreciate you adding this detail in. I think we have some room for improvement on the configuration stuff, but that's not the purpose of this issue.

Other Other meta packages could be considered but they could also result in confusion if over used. The other two that possibly make sense are:

  • Glimpse.Agent & Glimpse.Server

Q) I think there is a good use case for at least something like Glimpse.WebServer.Agent. I'd see users graduate from Glimpse.Development to Glimpse.WebServer.Agent when they move to a webfarm.

avanderhoorn commented 9 years ago

Ok updated the questions inline, seemed easier.

avanderhoorn commented 9 years ago

For what we need to workout at the moment, I'm going to close this off. Can reopen when we actually want to make further decisions