I will be developing a mobile app, which will mainly act as a client. There will be an API on the cloud that these mobile clients will interact with, and there will also be a web application for administrative purposes.
I'm thinking if I should use two separate applications for the API and the admin application. My thoughts are:
- If I keep the API and the admin applications as one, the admin application could directly access things from the database, thus have better performance. But this will introduce a coupling.
- If I separate them, I remove the coupling, but this might take a toll on the performance.
Just as a side note, I will be using Ruby on Rails for the API and the admin application, regardless of whether or not I separate them.
These applications are developed for us, and we will provide the mobile applications and the admin application to our customers as a service. Our customers won't use the APIs directly, but our client applications will.
I saw some similar questions here, but they mainly talk about a web API and a consumer web app, while I'm talking about only combining the admin app and the API.
Best Answer
As you are already writing an API for your app clients to consume, you already have a library of business models and logic. Having the admin system access the data via the API means you don't have to replicate that logic, meaning less chance of a discrepancy between the client app interactions with your data and your admin system.
There is, however, security to consider. By it's nature, an admin system will have rather sweeping powers of listing data, possibly including user account details, and of modifying that data - far beyond what your client apps should be able to do.
To avoid replication if logic - create the client API and then have your admin API extend it. That way, if core logic changes, you should only be changing it once.