Help a little on the shelves to put things right ...

There is a project - everything is standard there "html + js client" and "php server part", everything is located on the standard apache web server under centos 6.4. I want to rewrite a piece of the project to react flux / redux, but how to deal with the server - in all tutorials, the express from node.js rises and everything works fine there. I tried to write the simplest application on redux - it runs only on express, which is generally understandable the server should be able to render pages. But in the end we have a situation in which, under react flux / redux, you need to raise a unique infrastructure and make the project completely under it. That is, my project to transfer to react will gradually fail, or is there any option?

  • Um, what? Redux / Flux is the client-side architecture, what does the server have to do with anything? - D-side
  • Well, who is familiar with react / flux understand "what's the server in general," I repeat that flux / redux is rendering the client part on the server, so the server should support this. Something I’ve dug up on stackoverflow.com/questions/9831594/… or garrows.com/blog/… and just in case I ’ll repeat the question of how gradually having the client part of js + html translate it to redux. In general, I have already come up with something like: - Yury Ivanov
  • 2
    I am familiar with a re-frame that uses the same idea as Flux. Flux has nothing to do with it. Server rendering of React is a completely different topic (and optional for Flux) and yes, this is usually solved by rendering the same code with a slightly “shaved” version of React running on the server; since React is on JS, you need an artist on JS, for example NodeJS. But I, it seems, have already begun to answer the question? .. - D-side
  • one
    And what is all this for? What is the ultimate goal of moving to Flux / Redux? To simplify client application development? So for this the server part is not necessary at all, it can be a clean client application without server support. - D-side
  • 2
    ... an application on React may well render itself on the client. I'm getting to it. Or something does not suit you in this approach? - D-side

1 answer 1

In fact, React + Flux is a client application architecture. What exactly you use on the server side does not matter. Especially in the context of REST architecture. You can easily implement the REST API to your existing application in PHP, and the client part to implement on Flux + React.

However, there is one thing. In conjunction with React + Flux, node.js + express is often used (although this is not necessary at all). There are several reasons for this:

  • Using the same programming language on the server and client allows you to reuse the same program code.
  • Using one programming language allows you to dismiss the entire staff of server programmers and replace them with JavaScript by developers of a wide profile. (In practice, such a decision may be questionable.)
  • A typical problem of SPA applications is SEO (we will postpone discussions on the possibilities of modern search robots). The essence of the problem boils down to the fact that when a search page is requested, the robot receives not a ready-made HTML code for the landing page, but a “blank”, which is filled with real markup and data no longer a client. In some cases, special tricks are used to render the page completely on the server when accessing, and to initialize the SPA on the client. All this requires the same frameworks on the client and server.

It seems to me that in your case, the developers of the manuals just kept silent about the possibility of using something other than node.js on the server. Most likely, this was done on purpose, in order to protect newcomers from unnecessary complexity.