Frontend architecture

Question

For now we have very heavyweight frontend (frontend+backend in one application actually). Frontend contains all the logic: UI, business logic, persistence logic and so on. It's very complicated and hard to maintain, because of some platform problems (it's written in PHP) like absence of connection pooling, for example.

So I came up with an idea to separate frontend and backend. Backend can be written in some more convinient platform (we plan to use Java), and frontend can continue use PHP.

I think UI logic is all frontend should do. And some limitations should be applied to codebase which is executed here:

1. No direct database calls. DB calls are hard to scale and hard to provide SLA.

2. Nonblocking integration plotocol to backend. If frontend asks something to backend, frontend should be able not to block on this request. It can help us in two ways:

   a. we can send parallel requests to backend (parallelize I/O);

   b. we can provide timeout for requests (SLA). Sometimes it's better to fail quickly and do not block client.

So, considering all above, I think the best architecture for frontend (in my case, i'm not propagate silver bullet) is UI logic which is communicates only to REST/SOAP backend in nonblocking way. What do you think about this stuff?

Answer 1

Sounds fine to me, and you have the option of sucking info out of the (java?) BL both at the server-side and client-side (via AJAX).

I think UI logic is all frontend should do.

Yep - you're definately thinking straight :)

Answer 2

You may want to look into node.js for your frontend - it's new, but it has a really cool asynchronous (ie nonblocking) architecture. Does mean leaving PHP behind, but if your doing a major rewrite anyway that's not going to add too much new work.