Architecture Considerations

Question

I'm currently designing a web application and I'm considering using python-django for the front end and C#-WCF-Entity Framework at the back end. My core competence is C#, hence the choice of back end technologies. I, however, do not want to use C# at the front end because I prefer django's clean design vs ASP.NET plus the flexibility offered by a dynamic language. I intend to make REST calls to the WCF service for ALL data access (i.e. I won't be using django models at all).

My questions ...:

• Is this a good architecture, in terms of scalability? Are there glaring, project-threatening disadvantages to the architecture? Would it be better to simply use ASP.NET and forget about REST calls?

• The architecture also raises concerns about hosting since it's difficult to find a django host that also does .NET. Would hosting the front-end on Google App Engine and the back end on Windows Azure be a wise thing to do?

Your responses will be highly appreciated.

Thanks.

Answer 1

A robust business tier, developed in the language you feel most comfortable with - that seems like a good idea.

Decoupling the presentation layer , perhaps even in the future having more than one such tier for different client platforms - also reasonable, I've seen successful systems on those lines.

RESTful services do seem to be very effective in terms of ease of development. I would expect there to be some performance overhead in using a textual data transfer mechanism (Web Services of any flavour) but with careful design this is not usually an insurmountable problem - look at the performance of many Rich UI browser-apps they are almost certainly using AJAX calls with textual payloads.

I don't see the choice of this architecture as intrinsically obstructing scalability - clearly you have to get the business tier right, manage state carefully etc, but I don't see why this choice technolgies should introduce scaling problems.

Answer 2

In general having a python-django at the frontend and calling some core services via network for data retrieval and analysis is quite a normal architecture. We use that almost for everything in our company here. We don't use .NET, but I don't think it makes so much of a difference. This approach is very scalable, since if our bottleneck is the core -- we add computing power there, without touching the frontends at all and vice versa.

Since all your core services are not accessible from the outside, you can make quite strong assumptions about the kind of data you receive and lay the burden of the validation on the frontend side, which is pretty handy, since in the core you have strongly typed language and data validation is much easier with dynamic one. In order to exploit this gain more fully I'd advise you to use some type-aware protocol for communication of the two parts, something like SOAP or Thrift

Answer 3

Indeed, finding a host that allows this may limit your options.

Python/Django, REST, etc. all seem nice choices. Avoiding ASP.NET's frontend stuff certainly sounds good in terms of maintenance cost, portability to other (i.e. cheaper) frontend servers etc. Scalability should actually improve by implementing the architecture you are suggesting.

As to Google AppEngine, you could opt for AppEngine, Java and Google web toolkit. A really nice platform for web applications, especially if you need a rich user experience and scalability is a serious concern. The choice for Azure in this setup does not make sense at all unless you are 'locked into' using .NET.

Answer 4

I would recommend simplifying the architecture by reducing the number of technoligies that you are using.

In particular use ASP.net MVC for the front end instead of python.

Use WCF to comunicate between your front end and backend. Using SOAP or REST is then just a configuration change.

When you use REST to talk to your backend, you have the option of hosting it yourself or using Windows Azure.