separated data server, content server, client server and back-end server
last few years my company's practice was install our own cms on client's server/host and develop front-end. But its already time to change way we work. Now i am thinking this way. There will be few servers for contents, one server for client side (front-end), one server for back-end and one server for Database/data.
Back-end app and server
Every clients access to one back-end app. There will be only one back-end and it will store data on data server. Back/front-end will request data and data server prepares json data from mysql database then send it back to client. Contents will temporary upload to back-end server then content server will copy temporary contents to multiple content servers.
There will not database/data on front-end server. Front-end websites,apps, mobile applications will get all data from data server/api via json, either contents from content servers. So there will be only front-end scripts on front-end server.
Its not like CDN, all content servers placed in one place. Connected and synchronized.
Store all data on mysql database. There will api that prepare json data from mysql database.
Now questions are:
- this structure is dumb or correct way manage hundreds of websites and apps ?
- api prepares json data from mysql database and send it back to requested app is slow ? or normal ?
- Separated content server (Not CDN, but it will create caches of contents) can be better and faster than load contents and scripts from one server in one request.
- Client access to front-end server -> front-end server request to data server -> data server will prepare json data from mysql db -> send it back to front-end -> browser gets contents from content servers -> render website, app. is this way is slower or faster than all in one server ?
- Our back-end has to be very fast and very cool. Mission is Real-time app with history back, url without hash tag, when url changes then browser won't refresh and not harm back-end app media player (many gadgets), real-time notifications and messages. What techniques should we use for this app ? Please answer it from your experience.
You setup is definitely correct, multiple front-facing client servers, pointing to one or more centralize data server, passing small chunks of data over the wire via JSON.
Having the centralize back-end app also makes practical sense, from a maintenance perspective, you are only dealing with one application. You'll need to consider, if you plan to store all the data in one global database, or create a separate database instance for each application.
The question is, are your app's/websites maintaining session information, if so you'll need to put some thought into how to handle the session. Also if you plan to put a load balancer in as well to properly distribute load.
In my personal experience, I cannot say much on the session conversation, (my thought would be to store the session in a database) but perhaps someone else can shed some light on that.
Hope that help at lease guide you in the right direction.
i was building something similiar with this stack
backend server - mongo, mariadb, nodejs frontend servers - nginx, that proxies requests to backend
i think you are on the correct way.
there is one nginx server as a load balanced in front of all it, we used nginx as load balancer too, because Pound load balancer (http://www.apsis.ch/pound) has issues with websockets , but it is little faster