We are about to develop a web service, which will have some "social" features.
We will need to create a (responsive) web site and apps for mobile (iOS/Android at least).
I have already developed web services which have APIs (for app access; generally not public). However, this time I was thinking about applying a different, reverted approach, and I would like some opinions about it.
Instead of developing the web site and then add APIs on top of it for letting the apps communicate with the service, I was thinking to start from the APIs and then build everything (including the web site) on top of it. There will, then, be a service (either a PHP or Node.js app) which communicates with the database, and both the web site (on server-side, not client-side) and the apps will communicate with this server.
Positive advantages of this approach:
- Complete separation between data and view. The web site will run on a different, separate server than the API backend.
- Possibly more scalable
However, I am also aware that this approach requires creating an extra layer between the web site and the database, and this could impact performances negatively.
What do you think? Do you have experience with this design, or case studies?
This is a perfectly suitable approach and one that is used successfully by many companies, including mine.
We tend to start with an API suite which permits access to Javascript/HTML web-applications. We predominantly use AngularJS to create the web application.
As an extra-layer (which you have identified) we sometimes also create more traditional server-side applications as clients of the web-service. This often feels like a lot more work than just creating seperate applications with different (but similar) subsystems, for example data-access, authentication. However once you have built these layers and "primary" applications you get the webservices for free! and you can publish the API suite with some documentation for integration partners to use, and you can build mobile applications on the same backend as your web-applications.
The major benefit we find is that there is less to test and maintain as the projects mature, whilst retaining heterogenous connecting clients.
Best of luck
I think this is perfectly reasonable. Any performance concerns are allayed by using a good single page web application framework (like Ember, Angular, etc.) and/or some functional reactive programming with something like Bacon.
Basically, make the web component as asynchronous as you can. When you got that covered, I think the code reuse and scalability will be very much in your favor.
This approach sounds attractive, but in my experience it can be constraining in the future. Once you have (hopefully) a good community of applications using your API, it becomes very difficult to change it. On the other hand, you want to retain the ability to iteration your web site quickly without worrying about breaking 3rd party applications.
I feel that in the long run, you are better having an API that is hand crafted to support what your 3rd party developers want, and a separate hand crafted UI or API that delivers exactly what the users of your web site want. These are different constituencies of users and might very well have different requirements.
For example, your application might want a rich API with the ability to do SQL-like queries (think OData) and display lots of details of your entities. Your 3rd parties might prefer a simpler API that just allows bulk requests/updates with a small subset of the properties of your entities - say for synchronisation use cases.
Trying to create an API that will support both your app and 3rd party apps could leave you failing to satisfy either.
Note: I'm not against the user of an API to provide separation etc. I'm talking about using a common API for your app and 3rd party apps.
For a serious application you should always have some sort of "service" layer and/or "message bus" layer but this does not equal "API". IMHO by definition an API is public and rarely changes which is not going to be the case for any new website. Also your website is probably going to have different requirements than your mobile app.
But the spirit of your idea is right and you should strive for separation just be aware that you need to make it so that you can make change things quickly. And thus (and I can't stress) this enough: you don't need physical separation for service oriented architecture. You can just separate your code and follow the golden rule of SOA: separation of state and behavior (ie stateless, you have service objects and data objects, no OOP). All to often I have seen projects where to make a change requires so much because there is too much physical separation in the beginning (ie over-engineering).
Also you should know when you want to do RPC based (REST, request/response and synchronous) vs Event Message based (MQ, pub/sub and asynchronous). Most web applications prefer RPC but mobile and HTML5 apps allows asynchronous messages (websockets or native).
