Just a thought about the SSVS extensions…
Although one is specifically labeled “self host” and others as “empty,” to me, these names are a bit confusing. Since all of the templates implement the services within the web project, they are all technically self-hosting. If they were NOT self-hosting, I would expect to see the service hosted in one project and then consumed in another. So many of the SS examples focus on building and hosting that it would be helpful to see examples of how to properly consume these services from various clients and NOT nest them.
The “empty” name seems a bit misleading. My guess is that this name was chosen based on the fact that the client logic is empty. However, this template itself is more of a shell for creating and hosting a service.
Personally, I love to see these templates named for what they are… self-hosted service applications AND THEN a second set of templates to show the decoupled client consumption of the service. I’ve stumbled across many questions where people as if AppHost is required to CALL a SS service, or if they should use ServiceStackController or Resolve<> from a client app. Showing the service host separated would help clarify the full stack and reuse.
I think all the templates are logically named. All projects contain the recommended multi-project template structure. The templates that end with ‘Empty’ are effectively the minimum required dependencies that are required for a working example app, i.e. just ‘ServiceStack’ NuGet pkg and its deps.
There is only 1 SelfHost template which is appropriately named:
- ServiceStack Self Host Empty
which is conceptually equivalent to
- ServiceStack ASP.NET Empty
The other ASP.NET templates suffix suggest what type of project they create e.g. ‘MVC4’, ‘MVC5 Empty’, ‘with AngularJS’, ‘with Bootstrap’ and ‘with Razor’ - again I think they’re all logically named.
The only one that’s different is ‘AngularJS App (beta)’ which is our new style of Single Page App template that uses a node-based npm/Gulp/GruntJS build system: https://github.com/ServiceStack/ServiceStackVS/blob/master/angular-spa.md
All other templates are classic C# ASP.NET or Self-Host style templates.
Can you clarify with the Existing name with what you think it should be called instead?
Fredrick Lackey:
In their current form, it seems as if all of the current templates should have “self host” in their name since the web app is both the host, for the service, as well as the only project making a call into the service.
If they were NOT self-hosted, I would expect to see at least two web applications per template… one for the service host and one for the web app calling the service.
Personally, whenever I’m using a template as a starter, or to learn from, I’d like to see it mirror a real-life example as close as possible. The very nature of a web service implies that it is to be consumed from many client applications (web, compiled, Angular, .NET, etc.). Most web apps where a service is hosted in the same application are designed as such because they are either insignificant OR the self-hosted service is serving a business function (bundling multiple service calls, preventing cross-domain calls from the browser, etc.).
This is the reason I recommended a set of templates, similar to the current set, which show a SEPARATE client project calling into the service host. This second set would NOT have the “self host” title.
“Self Host” vs “ASP.NET” describes what type of Application / Host it is i.e. “Self Host” refers to HttpListener Self-Hosted Console App (which inherits from AppSelfHostBase), all other project templates are standard ASP.NET Web Applications (which inherit from AppHostBase).
We’ve (and other fx’s offering multiple hosting options) consistently use the “Self Host” term for a long time (and throughout our docs) to refer to ServiceStack’s Self Hosting (i.e. non ASP.NET) HttpListener Host.
All project templates are to create ServiceStack server applications, you don’t need a project template to call a ServiceStack service, just the ServiceStack.Client NuGet package (and the Servers DTO .dll) for any .NET project/platform (i.e. https://github.com/ServiceStackApps/HelloMobile).
Alternatively you can just use SSVS Add ServiceStack Reference which automatically references the ServiceStack.Client NuGet package as well as generating the remote Services DTO’s which you can use instantly with the Service Clients, more info at: https://github.com/ServiceStack/ServiceStack/wiki/CSharp-Add-ServiceStack-Reference
Fredrick Lackey:
Sorry… didn’t mean to upset anyone. Remember, I’m the guy that constantly proclaims his love to you and SS.
And, yes, I completely understand the term “self host” generally refers to hosting the service in a headless app (console). I get that. But should the technology really matter? ASP.NET vs a console app? That’s just the harness for the service. (but that’s a completely different debate).
I guess, when you think of what SS actually IS… a web service framework… then the templates names are really accurate when you keep the scope in mind.
I agree that it’s ridiculously easy to use the Client package. I guess I was just hoping to see a client implementation from the “WWDD” (What Would Demis Do) perspective. Although many of the facets would be completely architectural to the solution in question, it would be comforting to see visual examples of how YOU see the service being used… as well as any cool ways to use other pieces of SS that we may not know are there. For example, is there some uber-cool way of incorporating a staged cache with Redis… or maybe accounting for the various authentication providers from multiple client apps… or seeing a client leverage queries in the request/response pattern.
One-ff examples of a single feature (OAuth, etc.) is great for understanding how that lil’ piece is used. My vote is for a more full-fledged set of templates that show everything from back to front with caching, auth, and whatever else would go into a distributed enterprise solution using SS.
I’m just pointing out that the term “Self Host” is prevalent in web/service frameworks and that overloading it to mean something else isn’t a good idea. One of things I aim for is to keep consistent nomenclature, to reduce confusion as much as possible.
Yeah what type of Service you want to create matters a lot, whether it’s going to be deployed as a Console Application or hosted in IIS/Cloud would be highly dependent on your use case, what you’re building and how you end up deploying.
Yep it’s all good to want to to see example apps but the project templates is not a good place for them, as they’re primarily for creating new projects with, not for exploring how existing ones work.
The best place for that is cloning one of the Live Demos, which include a number of apps with OAuth enabled: https://github.com/ServiceStackApps/LiveDemos
e.g. HttpBenchmarks also includes docs about its Auth/OAuth support; https://github.com/ServiceStackApps/HttpBenchmarks#authentication
It’s definitely missing a larger application example, although each project template does contain the recommended multi-project layout which is suitable for medium/large sized projects. i.e. once projects get larger I’d only be adding more projects, not refactoring the existing project structure.
I do eventually want to get around to creating a full-featured and useful (i.e non-demo) app, ideally something integrated with Stripe, SMTP, etc. But this would mean stopping development on SS, so it’s something I can only really do once development on SS slows down, hopefully next year.
