In 5 minutes, make Single Page Application available for Google and Facebook.

Introduction

Dynamic web applications (SPA, Single Page Applications) are becoming increasingly popular. Their use allows you to simplify and speed up development and support due to the following advantages:

• no server-side rendering required;
• a site is a set of static files (html, js, css, images, fonts) that lie on a CDN;
• no cost to scale frontend;
• The frontend code is localized in one project. (Previously, part of the code was on the server-side, part of the frontend.);
• reduced backend development costs (API only);
• reducing the load on the backend (only API requests);
• the ability to use services like ( https://scaphold.io ), microservices, lambda instead of your own backend.

Of the popular libraries for the SPA I want to separately highlight ReactJS. Its use allows you to create complex web applications quickly and easily, to maintain the speed of development on a large base of code, to avoid regression errors when adding new functions.

The big unsolved problem of the SPA is their complete incompatibility with web crawlers of search engines (indexing sites) and social networks (sharing in social networks). Currently, crawlers do not perform javascript on their side and therefore cannot receive the contents of the SPA as html code. In 2015, Google officially refused to support the execution of javascript code on its side.

Solutions

Today there are several types of solutions for projects that want to fully develop a SPA.

Support for custom server-side rendering

What it is

This is an old approach to the organization of a web application in which the server-side rendering of html pages is preserved. When the SPA is loaded in the client’s browser, usually the application first deletes all the html code created by the server, and its place is filled with the result of the program. Currently it is the most commonly used solution.

What's good

• it works;
• all yours

Why is it bad

• increases the cost and slows down development due to the need to twice implement the same functions on the server and client;
• increases the cost of support and scaling, because requires to manage and maintain the web server;
• increases the probability of failures, errors, failures.

Isomorphic rendering

What it is

The idea that the same code can be executed on both the client and the server. Unfortunately, this idea works only on very simple applications. In addition, it is very difficult to support all new browsing functions on the server, which leads to the need to often do additional work to adapt the application to work on the server.

What's good

• works on very simple applications like "hello world";
• does not require to implement the same functions twice on the server and client.

Why is it bad

• does not work on projects harder than "hello world", which require working with dynamically loaded content, managing request queues, websocket subscriptions for data updates;
• expensive development, because does not work out of the box, in fact you still need to additionally deal with the server code;
• increases the cost of support and scaling, because required to manage and maintain the web server.

Prerender.io

What it is

This is an open source service that allows you to organize the redirection of traffic from crawlers to a special browser that executes javascript code and returns a static html page. PhantomJS is used as a browser.

What's good

• open-source (you can deploy at home and not pay for the Cloud solution, in fact, it turns out more expensive);
• works for complex projects;
• can correctly give 404, 301 from <meta name="prerender-status-code" content="404"> ( https://prerender.io/documentation/best-practices );
• reduces development costs (only frontend is required);
• reduces support costs (frontend can be distributed from cdn, like a set of statics).

Why is it bad

• paid;
• slow on complex projects. Crawlers often do not wait for an answer. Moreover, if a smart google crawler after some time tries to get the content of the page again, then the social network user who wanted to share interesting content of your site with his friends and didn’t wait for an answer is lost forever.
• on complex projects, crawlers almost always get cached pages. Those. almost always get the old information and the second time.
• sometimes requires additional efforts from the development;
• if something does not work, it is very difficult to debug;
• Regular reindexing of pages for cache creates additional load on the backend;
• requires a web server for integration.

Integration Ways

Offers many of the same type of integration for different frameworks and web servers. They consist in proxying traffic from a crawler to prerender.io (if UserAgent matches the crawler in the request header or _escaped_fragment_ is in the request parameters). The rest of the traffic is given in the normal mode (static set).

Renderjs.io

What it is

Cloud based service, which works similarly to prerender.io, but works fast, does not use cache, uses the latest version of Chromium.

How it works

After the first download, SPA applications in modern browsers work very quickly. To draw a new page usually requires only a few requests. Renderjs.io is a service that does this for browsers. Chromium browser is used for rendering. When a crawler is first accessed in the present, the real Chromium opens a bookmark with a web application. This tab does not close for a long time. When accessing a new url, it does not completely load everything, but only pushState into an already loaded application. Thus, rendering works very quickly and is very easy to debug, if your Chromium works, it also works on Renderjs.io .

What's good

• works for complex projects;
• can correctly give 404, 301 from <meta name="status-code" content="404"> ;
• reduces development costs (only frontend is required);
• reduces support costs (frontend can be distributed from cdn, like a set of statics);
• works fast;
• uses Chromium for rendering;
• does not use cache - pages always contain relevant information;
• allows you to connect in 5 minutes using DNS integration.

Why is it bad

• not open source;
• only works inside the application. Since history.pushState used to change the url, then going beyond the boundaries of the application will not work.

Integration Ways

Integration using middleware is similar to prerender.io.

Integration with DNS records. With this integration method, the project redirects all of its traffic to cdn.renderjs.io and receives full processing of traffic from the crawler through the render service, and the rest of the traffic to its web service. This method allows small projects in 5 minutes to make your SPA accessible to search engines and to do more important things.

Follow a few simple steps:

1. Register;
2. Create a new project;
3. Fill in the fields. Domain is the domain name field (mysite.com) from which requests will come, and the origin field is the url (usually the host mysite.imtqy.com) which your application rests on;
4. Create a CNAME record on your DNS service mysite.com -> cdn.renderjs.io;
5. Check your application (in the curl http://mysite.com terminal curl http://mysite.com or in the browser view-source:http://mysite.com/?_escaped_fragment_= );
6. If everything is correct, get rendered html.

FAQ

Q: And why not give all customers ready html code?
A: For several reasons:

• without javascript support, the client will still not be able to fully use the application, so it’s better to give some fallback.html with the word enable javascript;

• rendering takes time - it's still longer than getting a set of static (html, js, css) from cdn.

  
  

  Q: How to index closed sections that require cookies?
  A: Technically, this is possible, but not required in practice.

  
  

findings

We believe that for young projects at the initial level, the use of renderjs.io and DNS integration is an ideal solution that allows you to simultaneously get all the benefits of a full-fledged SPA and focus on solving really important tasks, namely creating value for the client.

New projects with traffic can also use renderjs.io with DNS integration or nginx integration.

Let big, successful projects be independent. If there is a desire to deal with problems that have already been solved, why are they big, they themselves know what to do.

About Us

purelab.io - We are a team of professional developers. We specialize in developing high-quality and modern web applications based on ReactJS. We use functional programming. We have our own solutions for doing things right. We can help, advise, develop. Write, we will be happy.