Displaying a server side rendered reactJS component within a PHP application - php

I have previously used reactJS on another project.
When building said project i noticed a downfall namely the loss of SEO benefit associated with JS rendered components.
I am rebuilding an old project and I would like to replace some of the Javascript with ReactJS.
For example, a multi step form - I'd like to replace it with a stateful component that displays the correct stage as required.
I would however like to maintain the SEO aspects of the page by having the first step spiderable.
To achieve this my research implies that I should be using React's React.renderComponentToString
Having researched the issue my thought process is that I should render the components server side using node.js and then serve them up within the browser. The component is then re-added per say to add the client side functionality. My first question is as to whether this is a suitable approach? Is there a much simpler approach that I have overlooked?
Pete Hunt mentions here (https://groups.google.com/forum/#!msg/reactjs/eUespJPdyas/hmJywyo9ZSwJ) that Instagram uses/used Django and had a setup similar to what I imagined.
My app is written in php using phalcon. My question essentially relates to this statement:
Node will then return the HTML that makes up the component. Django
takes that HTML and inserts it into the DOM via normal Django
templates.
How do I go about doing this within PHP? I don't want this component rendered behind the scenes and used when requested, but rather rendered when required by PHP with passed parameters.
I found this question (Sending messages from PHP to Node.js) which got me thinking that one approach is to simply use CURL to query the port my node instance is listening on to get the html which I then output.
My concern here is that all my experiences with CURL have suggested that it is very slow. I don't want my page load times to decrease dramatically just to get some SEO benefit.
Could anyone advise on the above questions/my direction?
Many Thanks

Stoyan Stefanov created a library for calling into the V8 JS library from PHP code for doing this sort of thing; it's available here:
https://github.com/reactjs/react-php-v8js
You can read about how he set up React server rendering in these two posts:
http://www.phpied.com/server-side-react-with-php/
http://www.phpied.com/server-side-react-with-php-part-2/
Rendering won't be instant, but it should be reasonably fast. If you're having performance problems and caching doesn't help, you can consider using Google's AJAX crawling feature in order to use server rendering only for Googlebot but not normal requests:
https://developers.google.com/webmasters/ajax-crawling/docs/getting-started
Note that browsers will also take advantage of server-rendered markup so even if the initial request is slower, rendering may be faster.

Related

Reuse a backbone application on the server side to render a view on the server side

I am working onr a backbone.js app, where one of my views is a complex feed with different types of subviews.
I will have to generate a static version of that view to be usd for email purposes. I am looking for the most practical solution that will allow me to reuse as much as I can from the existing code without duplication
I came up with two options:
Generate the view statically using php. This will men that I will have to duplicate a lot of the logic because of the different languages.
Set up a simple nodejs http server which will reuse most of the app logic to create a view on the server side. This sounds nice, but I am still unaware how practical such a solution will be in the long run. For ecample, I am completely unaware whether I would be able to use Jquery on the server side to create the layout from an existing html file.
Which one of he two options should I go for and why? Or perhaps there is a third one?
I debated a long time about this exact issue when I started working on my first backbone.js app, because like you I thought it would be a waste to duplicate so much view code. I'm working in rails, and my goal was to use the same format (haml) for partials on the server (haml/ruby) and templates on the client (haml/coffeescript), but that proved to be impossible and anyway not very advisable.
Anyway though, after having worked on the app for several months, I've come to the conclusion that the duplication is not a major issue. It certainly is not worth it trying to avoid duplication if the end result is only a couple of pages. Also, in my case at least, the static page I'm sending from the server did not end up having exactly the same structure as the templates that backbone.js renders, so it's not 100% duplication anyway.
Not sure if that helps, but in any case I'd suggest first duplicating the page and see how much extra work is actually involved. More complex solutions like #2 with the nodejs server strike me as overkill unless you'll really be serving a lot of pages this way.
For what it's worth, here are a few discussions of the topic on SO:
Rails Client side / Server side rendering using single template (handlebars or Mustache) with Sammy.js
Template language that works on both server and client

integrate two sites' content at runtime

Planning to use php-based CMS to manage content of several sites.
But 2 of them are based on Tomcat + JSP, not php - i can't integrate them directly into CMS, so I need to "inject" them from PHP internal. JSP site implemets several web forms, use ajax and live theirs own life, and I need to wrap it with CMS to manage banners, news, articles and other content, placed around jsp form.
I've wrote an proxy.php that took all requests grabs (with file_get_contents(...)) external sites's HTML, parse it with DOMDocument to add prefix to it's resources (was /js/js.js, became /external_site/js/jw.js and etc.), render html directly with "echo" and configured nginx to get static content based on /external_site/.
But the problem is that external site's forms have buttons and links, and all posts should be handled by servlets.
This is not an ideal solution from all points and all traffic should be passed throught CMS.
Main question is there some frameworks or best practice form making such includings ?
No. It would take a ridiculous amount of time/people to create and support such a framework/system/whatever. Your best bet is to replace jsp engines with the cms you are planning to use.
Жесть какая. Мои соболезнования.
Think there is another idea.
To use cURL like full request/response proxy for JSP requests.
Please, suggest articles or may be a solution of how to create http proxy to plainly pass POST requests (with cookies) without any modifications.
In this way JSP app will expect no difference of who is the source of request. And after getting response, i can prepare correct html for "echo".

Backbone and PHP Model Code Duplicate

So I have decided to take a project I have been working on, and project management system, and convert it from a standard multi-paged application to a single-page application. In the process I have looked at a number of javascript MV*ish frameworks (ember, knockout, backbone, etc...) and have decided to go with backbone.js as it seems the most flexible solution and that I already use underscore.js for both its utilities and template system.
The one biggest concern I have with doing this is the potential code duplication I am going to have for model and business/domain logic in both my PHP models and in my backbone models.
This is just a technical cost I have pay when going with an architecture like this or are there some things I can do to lessen this concern?
You may want to take a look at a previous question I answered involving Node.js:
Reusing backbone views/routes on the server when using Backbone.js pushstate for seo/bookmarking
What I'm currently doing right now is using Davis.js + Mustache + Java Spring MVC backened (based on my original question: Single page Web App in Java framework or examples?).
If the browser does not support Pushstate then I have the server do the entire rendering of the page using a Java version of Mustache (ie standard Web 1.0). If the browser does support Pushstate then the browser will make an AJAX request for a JSON version of the model. The model is then rendered client side use icanhz (ie javascript mustache).
This works fairly well if a large part of your logic is getting a model an then rendering it based on specific URL. That is your business logic is "based on some URL I'm going to render this". This is how most of the sites on the web work (including this one which is still rather web 1.0). Obviously this would not work for say something like real time chat or HTML5 game.
A python version of this design is mentioned here: http://duganchen.ca/single-page-web-app-architecture-done-right/
I'm sure someone has done a PHP version.
If you are using different languages in server and in client I think there is not possibility to avoid this partial logic duplication you are concern on.
If you definitely want to use same code in server and client you have to move all of it to the only common language: JavaScript.
There are multiple JS frameworks those integrate very transparently the development between server and client: derby, meteor, ...

PHP MVC with pure Javascript View : good practice?

My question might not be understandable enough, so let me explain the situation :
I'm working on a big ajax webApp built, server side, with PHP using CodeIgniter. This framework saperates clearly models, controllers and views. The view files are rendered in HTML and then sent to the client that does some js treatments on it (like attaching events).
This way of working seems strange to me, as it separates the view between the server side and the client side.
I was thinking about moving all the View treatments to the client part that will build dynamically its html in js. The server side will then send only raw data.
I worked this way on smaller projects, and I was really happy with the result (easily understandable, portable and reusable).
Is it a right way to implement an MVC app ? Any advices around that reflexion ?
I've done pretty much what you are describing on a fairly large data services app as an internal application. In my case I was using ExtJS for the client-side rendering/views, and was communicating to a C# WCF endpoint exposed on the web server. Essentially requests were made/submitted and responses were serialized to/from JSON. It ran very smooth, once some kinks were worked out. The original author had written a custom serializer to do direct results from their data layer directly... this leads to a lot of extra data going down the pipe. As long as you are judicious with your payload data it can be very effective.
Some caveats though...
You should probably avoid this if you expect users without javascript enabled to be able to access the site (anything involving money transactions from external users).
You will want to document your methodology as clearly as possible.
Finding developers for maintenance tasks after you have implemented your application will be very difficult. (many server-side devs are shy of, scared of, or just plain inneffective with JS skills.
For the most part it's a toss up, I find that most people at least have JS enabled, but may have other things blocked off. AJAX/XmlHttpRequest supports is nearly universal at this point.
As to templating for client-side display, there are a few options there (but that's a separate discussion).
Building JavaScript views works fine within the MVC pattern, since your view is not mixed in with your business logic or model.
However, there are a couple drawbacks to using full javascript views. Mainly it eliminates the ability for graceful degradation if the client has javascript turned off. Also, some browsers (IE) don't have a very fast javascript engine, which will make your page load more slowly. It is true that some of the view is separated between the client and the server, but it kind of makes sense when you think about it.
In most cases the HTML that you send to clients is the same for everyone (unless you are doing browser detection on the server side). However the JavaScript routines are different. If you are using a library like JQuery, this will be hidden from you, but the code that is running on each client may differ greatly. One example of this would be the XMLHttpRequest that is used by firefox/webkit etc browser and the active x control that is used by IE. Since the html portion of the content is the same for everyone it makes sense to build on the server, and since the JavaScript portion of the view may differ, it make sense that it is built on the client side.
HTH
I started using the same approach: JavaScript for the user interface layer and PHP for the database access layer. I'm using AJAX to pass all the data back and forth between the 2 layers. So far, AJAX has occasionally frozen on me, but it has been speedy enough most of the time. So I guess it'll work well enough.
(The result is that my code has gone from 90% PHP with 10% JavaScript...to 65% JavaScript with 35% PHP.)
I've also separated the code for my page views from the code for my triggered event action functions. So I like to think that I have an MVC arrangement now (even though I'm not using an off-the-shelf MVC framework like Backbone.js).
I'm not using HTML templates, though. I don't think it feels natural to have 100% separation between HTML and programming. I think simple programming loops, conditional statements, and JavaScript triggers all go nicely with HTML.
If you will think it in the way that there is the main view that creates the html/js engine and couple of ajax views with the data streams - it will be quite OK in MVC terms imo.
Is there anything more dynamic going on on the site itself? Does it do more AJAXy things, dynamically refresh parts of the site etc.? If so, it may be reasonable to have a Javascript-only site.
Since this is not how the web traditionally works though, sending HTML from the server is still the baseline. If your pages are basically static, if you want to serve older clients, an audience that may have disabled Javascript, an audience that may have accessibility problems with Javascript-only pages, alternative clients that cannot understand Javascript or search engines, you should serve HTML pages from the server. There's nothing wrong with it, it's straight forward, simple and foolproof. There are many things to consider when reinventing the wheel in Javascript on the client side. Unless you have a good use for the potential this offers (see for example the highly dynamic Facebook or Twitter pages), it may be more trouble than it's worth to your users.
It sounds like you are one step away from going from the MVC pattern to the MVVM pattern.
MVVM is ideal for complex user interfaces (which is exactly what you would be creating with all the AJAX and JavaScript and whatnot) because in this case your HTML view will be able to act as the controller via JavaScript. There is a library (warning: I've never used it but it looks promising) for this called Knockout JS.

PHP Web Design: Using Smarty vs Rest feeds with jQuery

I've been trawling SO for a couple of hours tonight looking for some answers, but I've not found anything that really answers what I'm after. My apologies if it has, in fact, been answered already.
I'm designing a new website and I'm trying to decide on the architecture to use to serve the content. In the past, my websites have used PHP feeding data into Smarty templates.
However, recently at my work, I've been working on a Java web application where jQuery was used to retrieve the data from a RESTful API (which returned JSON), where HTML template pages were used as the base and javascript was used (utilising jQuery) to fill in the content.
My question:
The website I'm designing will be in PHP, but would it be better to construct (or use an existing) RESTful API or to continue on as I've done before feeding the data into Smarty templates?
Are there real benefits to one or the other, or does it just come down to developer preference/experience?
If it helps, the website will be for a church, where the content types will be CMS-like; news/announcements, wiki-like pages, and a limited type of social networking (for the minister to communicate with parishioners).
Short answer: It sounds like filling the content with JavaScript would not be useful in your case. Loading the data with JavaScript is adding a layer of complexity with minimal or no benefit (in your case). Take a look at CMSs and websites that have similar functionality to what you're doing. WordPress, Drupal, etc.
For an example of when it might be useful to load data with JavaScript, check out the tags section on this site. When you search for a tag it queries the server without reloading the page. However, the initial tag list is loaded during the initial page load without any JS.
Here are some cases where you might benefit from loading information with JS:
There is some data that will take longer to load. For example, you're getting data from a web service. Using the traditional method, you would need all the data you need for the page to be available before it can be displayed. If you loaded that data with JavaScript, the page could load and the slow data would appear when it returns. Realistically, you would probably just cache the data but this is just an example.
You will be getting more data as the user stays on the page. You might want to update the page without refreshing.
You want the user to be able to query more data without refreshing the page.
Your users have limited bandwidth (mobile).
This site has more guidelines: http://www.oracle.com/technetwork/articles/javase/index-137171.html

Categories