I’m working on an application where the client-side interface and backend server are completely separate applications. The backend is written in Ruby and only serves JSON via HTTP. The client is a completely “static” single-page browser application that communicates with the JSON API. I now need to build an administrative interface that will be used to curate content served by the JSON API.
I see a number of ways I could conceivably build this:
-
Extend the existing single-page application. Initially this seemed like the most obvious way to do it because I already have a lot of existing code for communicating with the API. The downside I see here is that the admin section would feel very tacked on. The admin concerns are largely orthogonal to the functionality of the existing SPA and I’m not convinced the amount of code reuse would actually warrant combining the two applications.
-
A separate single-page application. This could work fine. I would have to duplicate some code from the existing SPA but I think this makes a little more sense since the admin interface very much feels like a separate application. The admin area does not need a spectacular UI, though, and a traditional server-rendered web application might be a way to reduce the development effort required to build the admin interface.
-
A server-rendered web application. All the server-rendered web applications I’ve built in the past have been directly connected to a database. This, however, would need to communicate with the JSON API on each request. I’m sure it’s possible but it’s not very familiar to me and don’t see much discussion about this approach.
-
A server-rendered web application in the same process as the JSON API. This way the code rendering pages for the admin interface can directly access the db/model layer and doesn’t need to make separate HTTP requests to render the page. The part I don’t like about this is that it complects the API code with UI code and I’d rather keep those completely separate.
I’ve been considering the tradeoffs in each of these cases and would be very interested to hear other’s opinions. Have you developed a similar architecture? Which approach did you take and why?
Best Answer
I think option 2 is your best bet. While the public and admin sites are related and use the same DB most likely, admin use cases and work flows typically have little overlap with the use cases and workflows in the public site. So the admin site will likely have its own distinct set of business logic. You can certainly move code which is common into libraries which are shared so you can reuse where appropriate, both UI and domain code.
A separate admin site / app also means you can deploy it independently, and possibly lock it down better. You may only need to allow access from your intranet for example.