6

We have a website and two mobile apps that connect through an API. All the platforms do the exactly same things. Right now the structure is the following:

  • Website. It manages models, controllers, views for the website. It also executes all background tasks. So if a user create a place, everything is executed in this code.
  • API. It manages models, controllers and return a JSON. If a user creates a place on the mobile app, the place is created here. After, we add a background task to update other fields. This background task is executed by the Website.

We are redoing everything, so it's time to improve the approach. Which is the best way to reuse the business logic so I only need to code the insert/edit/delete of the place & other actions related in just one place?

Is a service oriented approach a good idea? For example:

  • Service. It has the models and gets, adds, updates and deletes info from the DB.
  • Website. It send the info to the service, and it renders HTML.
  • API. It sends info to the service, and it returns JSON.

Some problems I have found:

  • More initial work? Not sure..
  • It can work slower. Any experience?

The benefits:

  • We only have the business logic in one place, both for web and api.
  • It's easier to scale. We can put each piece on different servers.

Other solutions

  • Duplicate the code and be careful not to forget anything (do tests!)
  • DUplicate some code but execute background tasks that updates the related fields and executes other things (emails, indexing...)

A "small" detail is we are 1.3 person in backend, for now ;)

Improve this question
1

2 Answers 2

Reset to default
13

I've encountered this before (many times) and what I've ended up doing preferring is:

Take the BL out of the website. Make the website a consumer of the API. Treat the website as just some other client of your API. Your API IS the service.

If you find yourself thinking that you need special API methods just for the website, think again! If its good for the goose, it is good for the gander. If you really really really need special functionality for the website I would suggest that what you've really found is a difference in "user profile" and therefore this is a situation where the API should still support the "special" functions, but then you control them via authorisation.

Not convinced?

Take the paradigm a step further ...

The phone app is running on a platform where bytecode is executed, the app lives in the phone and consumes API services via HTTP/JSON

The website is an app running on a platform where HTML+Javascript is the executed, the app lives in a the browser and consumes API services via HTTP/JSON

Same same!

Extend that to tablets, TVs, other phone platforms, plugins, third party apps, mashups, ...

Lots of different user experiences all plugged into a common API.

Your app IS the API. The website is just one client (of many)

Improve this answer
4
  • +1 Quick question, when you say HTTP/JSON do you mean HTTP/AJAX/REST/JSON? For non-public API extensions it's easiest just do add an authentication layer for a subset of request routes. It's really only takes a minor modification to the REST API.
    – Evan Plaice
    Dec 13, 2012 at 3:52
  • thanks Jason. Are you saying that in the website the controllers should call the API through a REST call and return HTML? Wouldn't that add more time?
    – fesja
    Dec 13, 2012 at 7:58
  • Yes @Evan, that is pretty much what I meant.
    – Jason Glover
    Jun 19, 2013 at 21:04
  • No @fesja, I wasn't suggesting that the API should return formatted HTML. The API should always just return data; however there is a neatness gained from looking at the website like it is just another client of the API. Websites though ARE different to a mobile app as they inevitably contain some server-side processing and some client-side.
    – Jason Glover
    Jun 19, 2013 at 21:13
1

Barely a question in here but some thoughts:

You ask: "More initial work?" compared to what? This background task stuff sounds link more trouble to setup.

The background task solution is coming down to the same thing, invoke common/shared code. Only you do it indirectly. How is that be a better or more maintainable solution?

Working mostly with background tasks also complicates scenarios where you need to know the outcome of a task. The waiting and marshaling of return values is going to be a burden and add complexity.

Then you ask: "It can work slower. Any experience?" setting up background tasks to be handled by another process is never going to be faster then invoking the task directly and immediately (preferably in the same process).

The scaling benefit you propose does introduce having to cross process boundaries, or worse network boundaries, constantly. I would prefer creating an in process service layer if possible. And create a middle tier if really needed.

Code duplication is never a solution as far as I am concerned, it's asking for a maintenance disaster.

Improve this answer
1
  • So I understand you clearly prefer the service oriented approach. thanks!
    – fesja
    Dec 13, 2012 at 1:31

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.