Web and API – Reusing Business Logic

Architecturesoaweb servicesweb-applications

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 😉

Best Answer

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)

Related Solutions

DDD Application Services vs REST API – Conceptual Mismatch

I've had the same problem and "solved" it by modelling REST resources differently, e.g.:

/users/1  (contains basic user attributes) 
/users/1/email 
/users/1/activation 
/users/1/address

So I've basically split the larger, complex resource into several smaller ones. Each of these contain somewhat cohesive group of attributes of the original resource which is expected to be processed together.

Each operation on these resources is atomic, even though it may be implemented using several service methods - at least in Spring/Java EE it's not a problem to create larger transaction from several methods which were originally intended to have their own transaction (using REQUIRED transaction propagation). You often still need to do extra validation for this special resource, but it's still quite manageable since the attributes are (supposed to be) cohesive.

This is also good for HATEOAS approach, because your more fine-grained resources convey more information on what you can do with them (instead of having this logic on both client and server because it can't be easily represented in resources).

It's not perfect of course - if UIs is not modelled with these resources in mind (especially data-oriented UIs), it can create some problems - e.g. UI presents big form of all attributes of given resources (and its subresources) and allows you to edit them all and save them at once - this creates illusion of atomicity even though client must call several resource operations (which are themselves atomic but the whole sequence is not atomic).

Also, this split of resources is sometimes not easy or obvious. I do this mainly on resources with complex behaviors/life cycles to manage its complexity.

Finite State Machine – How to Store and Validate Data Between State Transitions

I'd go one of two ways depending on the exact implementation details.

(Apologies, I'm not familiar with Django, so my answer speaks generically about the architecture and doesn't have specific suggestions for the language you're using)

1. JSON fields for data using Single Table Inheritance

As you suggested, I'd put the data in JSON(B) fields in Postgres. I'd validate by subclassing (or similar) the Tasks model using Single Table Inheritance (STI).

A quick google suggests that Django might not do STI natively, but you could get a simple enough version working by adding, say, a type column to your tasks table and use that to dynamically load the class that contains your validations for that type of task.

Pros

Expressive - your validation rules are as flexible as the language
Simple - Easy to get up and running with

Cons

Awkward to scale - If you have lots of different types of tasks, this could get out of hand for maintenance. (This can be mitigated by grouping similar tasks to use the same validation class)
Developer dependent - any changes to validation or adding new tasks requires a developer

2. Store validation also in JSON

Have a second table storing your task types that uses JSON schema to describe the attributes and validation of a task