From PHP to Node. js

If your development team is using PHP and is considering migrating it to Node. js, this article is very suitable for you. This article does not discuss the details of porting from PHP to Node. js, as well as the basic knowledge of Node. js. It covers decision making, descriptions of the starting points, deep precautions for writing Node. js servers, and deployment strategies.

Why migration?

1 stdibs decide to migrate data from Apache/PHP to Node. js + Express for five reasons:

1. Less code
2. Full-stack JS
3. Higher developer happiness
4. ROI
5. Future optimization

Less code

Based on the service-oriented architecture (SAO), 1stdibs calls the background JAVA service. This means that you need to maintain both the front-end model and the server PHP and client JS templates. Imagine that if you can get rid of PHP, you can unify the front-end presentation and background model in one language: JavaScript (some templates can be merged at the same time ). From the maintenance point of view, the code is more concise and there is no repeated logic.

Long live homogeneous JavaScript!

Full-stack JS (and its advantages)

The entire development stack is easy to use. For developers, less environment switching makes them happy and efficient. The additional advantage is that the tool is easier to use. Compared to the previous use of the Composer and npm package manager, only one package manager is required. Although Composer is excellent, nbp is always necessary because nbp is responsible for tool and client management. Once all PHP code is removed, nbp will become the only package manager.

Developers are happy

It is important to ensure that the developer's skill set is expanded and his career continues to grow. For JavaScript engineers, Node. js is very attractive. It is very convenient and efficient to use the same tools, styles, and modes as clients on the server. In addition, Node. js is quite popular and has also made great strides in enterprise-level development. Node. js is a required skill for JavaScript engineers.

ROI

We spent a lot of money in recruiting excellent JS engineers and training junior JS engineers. Due to the complexity of the client stack, we need senior JavaScript engineers. We no longer hire PHP engineers, but JavaScript engineers. Our point is, why not cultivate their skills on the server?

Future optimization

In the long run, we plan to split two huge applications into a series of independently deployed small applications. This can be easily implemented through Node. js, Express, and nbp. Theoretically, PHP (such as using Slim) can do the same thing. However, in addition to the above benefits, we will make a mess: Operations on Apache/PHP will be more complex, and the infrastructure will become somewhat strange.

Select framework

The PHP application that we replaced with Node. js eventually has the following responsibilities:

1. Logon and authorization
2. Routing selection and server template engine (service HTML)
3. Guiding front-end applications
4. Proxy service (to avoid CORS)
5. Service static resources (js, css, images)

These are the basic functions we need to replace.

We have tried many frameworks and Express is amazing (try the spreadsheet we evaluated ). Any framework that is not based on Express seems unreliable. Express is easy to understand and has good documentation. In addition, you can recruit people who have trained Express.

We added some kraken core modules (express-enrouten for routing selection, lusca for security); in addition, i18n-node provides international support, the template engine uses Swig (we later gave up Swig. Oh, open-source software is still at risk ).

We have considered using kraken in all aspects, but it is straightforward to switch from the original server-side php template engine Twig to Swig, which is very fast. In addition, Dust and i18n in kraken are not flattering.

Compiling server

After the framework is selected, the next step is to write data to the server.

When using Apache + PHP, you do not need to write another server. Apache itself is a server, and PHP is an application. If Node. js is used, the server and application are the same. From Apache/PHP to PHP, you need to handle some previously used functions, which is very important. When using Apache, you (or the system administrator) configure the server. in PHP applications, you do not have to worry about what Apache handles for you. Node. js works in a different way.

Provides static file services

Undoubtedly, the provision of static file services is the core function of Apache. Different from Node. js, you need to configure the static file service in the application. Fortunately, this is very simple. it is well documented and implemented in Express.

Logs

Many basic Apache configurations provide you with access logs and error logs. When using Node. js, you may have guessed it. you also need to configure it in the application. Fortunately, many excellent open-source software packages make it easy. Morgan is a basic request logger that is easy to configure and allows you to write logs to output streams (standard output devices or files ). If you need to write logs to the database or have other (more advanced) log requirements, try winston.

Proxy

We have a basic requirement: the ability to transmit client ajax requests to the background service by proxy. It is much easier to process all requests from the same domain than to process CORS headers. But if you want to use webpack-dev-server through proxy (as we have done), you must handle this issue in the Node. js application. Http-proxy is a simple and reliable solution.

Remaining work

In addition to the above mentioned, there are also some columns to be completed. From an MVC application, the application is based on the CodeIgniter (CI) framework to provide services for a series of single-page applications. Most of the work is Porting:

• CI controller porting to Express route selector and middleware (including logon and authentication)
• Port the Twig template engine to Swig (this step is trivial)
• Service-layer data access (to enable the client single-page application normally)

The key component of the CodeIgniter model is not listed above. In fact, you don't have to rewrite the PHP model!Awesome!Our client applications use the Backbone model. Of course, we need to extend Backbone. Model. sync to make it work globally on servers and clients.

Deployment

If your app is large, you should not launch it all at once. It can be deployed in a progressive manner. It took us several weeks.

Advantages of progressive deployment:

• Minimize bug scope
• Other engineers can develop routes and functions at the same time.
• Minimal impact on ongoing feature development and improvement-new features can be released (which may lead to repetitive work)
• If appropriate, you can quickly roll back to the previous service.

NGINX is good

How can we get online gradually? We have selected Nginx among the numerous servers.

             +----------+ http        |          |---> Apache/PHP request---->|  Nginx   |             |          |---> Node.js             +----------+

Nginx allows you to "open" only one route at a time (turn it off if you find it is not good-as we have encountered multiple times), which gives you a lot of freedom. We also found that you do not need to deploy the code when opening the route, which is very helpful. This provides us with some room for maneuver in our weekly release plan.

However, there is one drawback. make sure that the client code accepts the services provided by the old Apache/PHP server and the new Node. js server at the same time. This is not terrible, but you need to Port unoptimized functions on the old server to the new server. Hold your breath and do it (remember to write a sticker to clear your technical debt ).

Summary

From start to end, it took about a year for the entire transplant job. This may sound a bit ridiculous, but this schedule includes the decision-making process (in a hurry), writing a core framework based on Express to meet the needs, porting all functions, and gradually going online. In addition, remember that we have only one or two developers working for it-and we work part-time.

If you want to try it, consider it with caution. Can your team benefit? Can your entire organization benefit? If you are from a business organization, remember that business needs to run continuously. You need to find a good balance between business and engineering goals.

We are very happy to try it.

About the Author: Weiji

Focus on C, PHP, MySQL, JAVA, mathematics, and American dramas (especially rights games ). Personal homepage · My Articles · 10 ·