5

We're trying to decide what architecture to use for an upcoming web application that will eventually have a mobile portion as well. The core of the project is a social networking web application, and the mobile portion will most likely have a limited subset of the web functionality.

The two options we are looking at is either a complete web service back end, or using a traditional MVC framework for the web application and then developing web services on the side for the mobile application later.

Some arguments for web-service-only route is that it would be "simpler", as we would just have to create 1 web service as opposed to creating both a web service for the mobile portion, and additional database functions/calls for the web application. Using this method, the web application will fetch data from the web services using javascript, which would then generate the html page (sounds kind of like what a traditional MVC framework does, but this way would require everything to be done in javascript).

I'm not feeling good about the idea of using web services only because it doesn't make sense to me, but I am having trouble clarifying my issues with it.

So what should I consider when trying to determine if we should use a complete web-service backend for our project instead of traditional MVC with web services only available when needed for the mobile portion of the app?

I'm looking for a comprehensive answer to this question, not many answers each containing one piece of the answer.

Improve this question
3
  • 1
    "What language/framework I should use" questions are off topic - please review the FAQ. However, if you have more detailed requirements or a specific problem you need to solve please don't hesitate to ask.
    – ChrisF ♦
    May 12, 2012 at 10:17
  • Just watch this: youtube.com/watch?v=WpkDN78P884 A bit long but really worths it.
    – Hakan Deryal
    May 12, 2012 at 10:20
  • 2
    @ChrisF It's true that "what language/framework should I use" is off-topic, however I think this question is asking what should be considered when trying to decide whether to use architecture A or architecture B. I've edited the question to try and clarify that, so please consider reopening.
    – Rachel
    May 14, 2012 at 14:12

3 Answers 3

Reset to default
5

When implemented properly you may be able to have both worlds. When you go the web service route you may be sending the json version of the models you would be using to render your MVC views with otherwise.

For the web version you would need to build your html somewhere. I think you can do this mostly server side or do it using some form of javascript client side templating. The data/model either requires is going to be the same.

If the web service route means SOAP I would disagree also.

Why not make the web application mobile capable? You may end up not needing a native mobile app at all...

Improve this answer
1

It seems like the typical approach to MVC is to use exactly one Model, one Controller, and one View all tied specifically to a given page type.

But the whole point of separating these concerns is to solve problems exactly like this one. You should be able to have a model and a controller that operate on two different views, your mobile view and your web app view. Or at least a shared model.

The web service thing requires that you have back end devs capable of delivering data in a an easy-to-parse form to front end devs who know how to juggle strings, data, and DOM manipulation, but if they don't have experience at it, I'm not sure I'd trust them to know it's going to be easier. I'd be a bit wary of it because it puts all the burden of structure and organization on the front end, which people tend to be bad at structuring and organizing. If it's a fairly simple app it would seem reasonable to me.

Improve this answer
0

Factors that would push towards a unified service interface include a complex data model, need to enforce business or security rules consistently, encapsulating data models from long upgrade cycles, or having many different types of client applications sharing data. The web services boundary can also be a useful organizational boundary in larger teams - have some developers focus on the API while others build applications on top of it.

In your case, I think the hybrid would be the better choice. It sounds like most of the features will be on the web site, and it would be extra work to build the site on top of an API built mostly for the web application.

As a point of clarification, you can use MVC with web services. In the client you would write data access objects that talk to the web service, and then build controllers on top of those to manage the UI. On the API side, web service interfaces benefit from applying MVC. You could support multiple protocols using alternative views - such as JSON, SOAP, RMI, Avro - while sharing a common model.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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