From a scalability point of view is it advisable to have the ServiceStack API and MVC projects in separate projects. The solution overall is far more API heavy than web. Seems like a possible waste to scale option 1 below due to the bloat from the web element of it.
Just wondered if anybody had any thoughts on the following approaches:
Option 1
Single Project - MVC/ServiceStack combo. All web and API call into single place - scale this.
Option 2
2 Projects - MVC/ServiceStack combo -> service gateway -> Pure ServiceStack API project (Scale this API project which also services the web project)
The approach we’ve taken is to have our MVC project separate from our API project. We’ve had this in use for several years now and has been the right decision (for us).
It’s a little more difficult for testing locally as you have to setup a full IIS server on your dev box, but that’s not a show stopper.
The approach allows us to deploy individually or together. We expose public endpoints for 3rd parties and don’t always require our MVC project to be updated at the same time. It also allows for creating a new client side app with little difficulty. For example, we’ve been MVC for about 4 years, but recently we’ve decided to re-write the client in pure angularJS. And to be clear, in our current MVC app we just use the servicestack client library to make our api calls.
It can be a difficult decision, but I think it’s easier to move from individual projects and combine than going the other way.
I’d recommend shipping MVC/ServiceStack together unless you have a good reason not to, it reduces the management overhead of managing 2 deployment units and provides several opportunities to call ServiceStack from MVC, reuse dependencies, etc without the additional latency of out-of-process calls.
Of course if your solution is more API heavy than Web, maybe you don’t need MVC at all and can go with ServiceStack’s Razor support or a pure Single Page App with static html, (i.e. without Razor) which is usually my preference.
Thank you both for your valid views. I’m leaning towards two projects to keep separate as the ultimate aim is to SPA completely at some point. However I’m also going to consider Service Stack Razor and unifying.
Out of interest how do you deal with passing through authentication/session/httprequest info to the API layer when called via client library from the MVC project?
Well, right now we use the default \auth endpoint with custom credential provider. But you can use any of the existing ones here. In return we get a session cookie that’s passed back with the client calls. We use a redis server to hold the sessions data. It’s very easy to use as it’s just built right in.
What we are actually in the process of now is converting to use JWT.
In the end it’s very easy to deal with as ServiceStack has everything built in. And if you need to customize things it’s very easy - once you know where to look.
@dandcg Your MVC Controllers can inherit ServiceStackController to get access to ServiceStack’s features, e.g. you can access your Custom ServiceStack Session with:
[Authenticate]
public class MyController : ServiceStackController
{
public ActionResult Index()
{
var session = SessionAs<CustomUserSession>();
//...
}
}
On a side note is it possible to write tests which allow me to rollup an instance within a test context to execute dto’s through the gateway without actually fully self hosting and binding to a url. The ServiceStack service gateway has essentially replaced the mediator in the project I’m working on. Our composite tests currently use a series of messages that aren’t necessarily exposed through an api but are just passed to the Mediatr - i.e., they are called internally from the MVC controller. Unless I’m barking up the wrong side of the tree?
When you use the Service Gateway in the ServiceStack Controller you’re not going through HTTP, you’re calling the Service in code.
If you just want to execute Services in code you can use the BasicAppHost which initializes a ServiceStack AppHost without any hosting on any HTTP Endpoints.