5

The application that I work on needs to have a web interface (ASP.NET MVC) and mobile interfaces (Android/IPhone native). The features for mobile applications and web application might not overlap (some features are similar, some are different)

At the moment, I'm thinking of 2 ways to structure the applications like below:

enter image description here

For the top approach, just need one web server that server both web and mobile clients. Mobile will communicate with server through Json (serialized by ASP.NET MVC). The service layer is just a plain class library to be referenced by web layer

  • Pros
    • Faster, since there's no cross-machine communication between web and service layer
    • Simpler
  • Cons
    • Security? Any security concern here?
    • Less flexible when scaling (can only scale both web and service layer as one unit).

For the bottom approach, need one web server and one application server (for WCF/Web API). Mobile will communicate directly with application server through Json

  • Pros
    • Can secure web and application servers separately, extra layer of protection on application layer. But the application server is exposed to mobile anyway right?
    • Can scale web and application servers independently
  • Cons
    • Slower
    • More complicated due to WCF/Web API in the middle

It's the first time I do the application for both web and mobile like this. Which approach is commonly used in this scenario? User tends to favor bottom approach, but I think in this case it might be overkill to follow bottom approach

|improve this question|||||
6

The main problem that I see is that with the top approach, your website needs to be able to accept requests from mobile, as opposed to the services. That seems like something the website should not have to worry about. In particular, it implies either your website has a bunch of "pass-through" logic to duplicate the API of the services, or the website is providing a different API from that of the services (probably a little of both). Either way, that's a huge maintainability problem. Plus, it adds one extra hurdle (and potential bottleneck) for mobile requests to jump through, compared to talking to the services directly.

The claims about needing one or two servers in each case are really an orthogonal issue: You can put the website and its services on the same server if you want (I've done this many times at my job). Whether you do that or not doesn't have much to do with whether or not the mobile client is talking to your web page or your services. I would expect this decision has more to do with (as you pointed out) security or complexity, or perhaps with scalability (ie whether the bottlenecks are in your services or your website). But for a sufficiently large/complex/important website, I believe these factors would all lean towards using separate machines.

Therefore, I would recommend the bottom approach.

|improve this answer|||||
  • thanks, your answer does make sense. However regarding security, do you have any opinion on how do the two approach compare to each other? I think the bottom approach does have bigger surface of attack (since both web and service need to be exposed to public) – Phuong Nguyen Apr 6 '15 at 4:38
  • From a security perspective, neither approach is ideal. I believe you would want both mobile and desktop clients to go through web server(s) (maybe the same one, maybe not; depends how many requests you get) to handle things like authentication/load balancing, and then only those web server(s) are allowed to talk to the app server(s) with the services. You'll also want to make sure you have a proper "DMZ" if you have any sort of internal corporate network alongside this. security.stackexchange.com is the place to go for questions about this stuff. – Ixrec Apr 6 '15 at 7:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.