3

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:

  1. 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.
  2. 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.

Improve this question
4
  • 2
    Why not improve the performance? Why use an API with bad performance?
    – Frank Hileman
    Mar 21, 2017 at 15:13
  • Larger businesses will want access to the API and smaller ones may expect your system to integrate with a service like Zapier.com so they can be like all the other cool kids.
    – JeffO
    Mar 21, 2017 at 15:23
  • 1
    @JeffO, this is a solution in the hospitality industry, they don't even understand what an API is, let alone use it :) Maybe it will change in the future. Anyways, so far, I'm leaning towards structuring the admin application as a consumer of the API.
    – hattenn
    Mar 21, 2017 at 16:13
  • @hattenn - There are large companies in every industry, they're just not your customers.
    – JeffO
    Mar 22, 2017 at 14:24

4 Answers 4

Reset to default
5

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.

Improve this answer
2
  • 1
    I'd say that there can be an additional admin API, allowing to do the admin stuff. The admin application can use the admin API and the normal API, as much as it needs normal access to data, too. The admin API can and should reuse much of the code that the normal API uses.
    – 9000
    Mar 21, 2017 at 20:15
  • 1
    @9000 yup - that's one way - though, writing the APIs as complementing modules means you have the client API on one server, and client+admin on a different one (possibly locked down to specific IP sources), making it a bit simpler for session/token credentials to be used in all subsequent requests after initial authentication/verification into the admin system.
    – HorusKol
    Mar 21, 2017 at 21:02
2

Creating an API and creating an administration panel are two completely separate things. API is meant to be as lightweight and fast as possible, administration panel is supposed to be user-friendly.

As the project's responsibilities completely differ so do the team members who work on them.

Besides many other things...

For administration panel you will need people who:

  • understand UX,
  • design graphical UIs,
  • code graphical UIs,

for API, on the other hand, you need people who:

  • understand API standards,
  • know how to profile applications,
  • know how to build scalable and performant systems.

When you look at the very basic summary of people you are after for each project you can see it makes very little sense to put the administration panel code directly into the API project. As a back-end developer I could not care less about your front-end.

If you change a color of a button so be it, but God forbid that change to spoil my git repository where I am dealing with issues of response being returned in 800 ms rather than 150 ms (and vice versa, I doubt a front-end developer is interested in caches, queues,...).

Your worries about performance are nothing to be worried about. Administration panel is accessible only to administrators of said system. It is rarely required an administration page must load incredibly fast, and "slower" (the difference really is just a few ms) load times are not an issue.

Decoupling aside, the other benefit of separating the projects is increased security. You do not have sensitive credentials in two projects (or their appropriate build scripts) but only one - the API project. If you decide to hire a new programmer for the front-end in some cases you can get them up&running possibly even without them signing a NDA because there's nothing to be compromised in the administration panel - they do not have direct access to the database.

Hiring the API developer could be a longer process where a signed NDA is a requirement to give them access to the code.

Improve this answer
0

Taking into consideration the first of the SOLID principles (Single Responsibility Principle) on the modules level I would separate the API app from Admin app. This is always case of maintainability and flexibility of software. It also gives you the ability find eventual bugs easier.

Improve this answer
0

Separate the admin application from the API. The performance will probably be fine, do not limit your options based on "hunches".

Your description does not point to any obvious performance bottlenecks. While it is a good idea to keep an eye for performance, it is also a very common reason for premature optimization.

Reconsider only if you measure real performance problems.

Improve this answer
2
  • 1
    I appreciate the answer, but isn't saying "the performance will probably be fine" a hunch too? I know I might be overthinking this, and trying to optimize prematurely, but it feels like making a change like this in the future would be a huge overhaul.
    – hattenn
    Mar 21, 2017 at 11:02
  • 1
    By making everything use the API you only have one place that can be causing possible errors, also by making the admin app use the API you can easily change the database system to everyone instead of having to update the admin app for database changes.
    – DMH
    Mar 21, 2017 at 11:17

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.