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?
4
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.
All other things being equal, I prefer not to use two different architectures in the same application, unless there’s a good reason to do so (native handheld device support, for example).
That said, your solution depends entirely on your requirements. If all the administrative UI does is set some values in the database, and it will never run outside your intranet, there are all sorts of things (like the JSON API) that you can dispense with. It might be simpler to just stand up a more traditional server-rendered UI.
On the other hand, you do have a bunch of SPA stuff done already, and some of it might be reusable. Consistent look and feel (and operation) is always nice. Like I said, it depends entirely on what your requirements are.
Your decision will essentially follow the same thought process you went through originally when you decided to make a SPA application, but with different requirements and possibly with a different outcome.
I’m not sure what you mean when you say that the API code will be complected with UI code. The whole point of having a JSON API is to allow you to be agnostic about the way you write your user interface. Your API might have additional methods or endpoints added to it to support administrative operations, but that doesn’t affect your existing UI at all.