Architecting Multiple SPAs Inside One Website

[gsr...@gmail.com]

Hello.  We’re in the process of re-imagining our suite of software applications and need some advice.

Currently, we have 8 fairly large, legacy Windows applications that we need to rewrite into 1 intranet website.  What we’d like is to replace each of the legacy Windows apps with a new single page app written using Durandal.  However, as I mentioned, each of the new single page apps needs to be in 1 intranet website; that is a collections of SPAs.

We were thinking of using ASP.NET MVC areas to separate out each app, but instead of the normal ASP.NET MVC stuff (i.e., Razor views, etc.) in each area, the area would be the entire SPA, including multiple views, HTML, JS, data binding, AJAX calls, routing, etc.

Does this make sense?  Does this sound like a logical and appropriate solution?  Or, is there a better way to architect multiple, full featured SPAs under 1 website?

Thanks.

[Rob Eisenberg]

It sounds like a reasonable solution to me. Other developers have done similar things.

--
You received this message because you are subscribed to the Google Groups "DurandalJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to durandaljs+...@googlegroups.com.
Visit this group at http://groups.google.com/group/durandaljs.
To view this discussion on the web visit https://groups.google.com/d/msgid/durandaljs/d3901574-dceb-4c50-9c6a-95831405b80c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Rob Eisenberg,

President - Blue Spire
www.durandaljs.com

[Rob Allen]

We're doing the same sort of thing. But instead of areas we just have 8 controllers with 1 view (Index.cshtml). They all share a master layout (_Layout.cshtml) and we still use bundling to add external/global js & css libraries. We also use normal asp.net authentication in the controller.

Our views are incredibly simple:

<script src="~/Scripts/require.js" data-main="@Url.Content("~/App/library/main")"></script>

Regards,

rob

[gsr...@gmail.com]

Thanks Robs.  :)

Rob Allen, your idea sounds pretty good.  So, if I'm thinking of it correctly, is your project using the normal MVC routing to get to each SPA/controller (perhaps using an @Html.ActionLink to point to each controller actions)?  And then once "inside" the individual app, does the SPA use Durandal routing to navigate/load views within the SPA?  This is sort of how I was envisioning it.

Thanks.

[Rob Allen]

Pretty much yes - although not quite with regard to the top nav. Instead this is a ko array where we inject the application path so the URL works in dev/test etc.

So it starts off pretty simply - 1 shared layout, X controllers each with 1 view. All standard MVC. Inside _Layout.cshtml we have this javascript:

    <script>

        window.appRoot = "@Request.ApplicationPath"; // global application path

    </script>

This just saves us a whole heap of trouble with regard to ajax requests, links etc., so we don't have to care whether we're using port numbers, virtual directories etc.. We can just prepend that to anything and it just works.

In the controller we handle any authentication, and then we render the view (Index.cshtml). e.g.:

<script src="~/Scripts/require.js" data-main="@Url.Content("~/App/mail/main")"></script>

From then on, we just have the standard durandal folder structure. Inside "shared" we have a bunch of helper functions, including the top nav shortcuts. This is just an observable array and we pass in an id to set the active application. I can email you some code, if you need a better example.

We use localStorage (fallback to cookies) in the event we need to store any data between apps. To be honest we haven't needed to so far, as any user preferences sit in our database (e.g. selected language).

Our only real issue is trying to minify/optimise each application - plus the the shared folder - for deployment (e.g. library+shared, mail+shared). I just haven't figure that out yet.

Hope that helps.

rob

[gsr...@gmail.com]

Thanks for the help, Rob.  And, thanks for the offer of showing more code.  I may take you up on that sometime.  But, everything you've shared makes sense, so I think I need to go play around a little more and see what I can come up with (I've prototyped a single Durandal SPA, now just need to put the multi-SPA concept to work).  Unless you have some additional thoughts now???

Thanks again!

[Rob Allen]

Nah, just code away, see what how you get on. Always the best way :)

I found this really helpful when thinking about the architecture I wanted:

http://addyosmani.com/largescalejavascript/

We're using durandal/app as our mediator and it's working a treat. We're also using klass to allow us to have a number of base classes throughout the app. It's pretty cool.

Good luck,

rob

[Peter Wone]

>We were thinking of using ASP.NET MVC areas to separate out each app,

That approach introduces artificial dependencies.

Why don't you make them separate Virtual Applications? By munging everything into one huge MVC app you lose the ability to manage them independently - both application lifecycle and deployment. You increase the number of things a new team member must learn, and you increase the number of failure points.

Keep it as simple as it possibly can be.