Home > Article > Backend Development > The inventor of PHP talks about MVC and website design architecture. It seems that he does not support PHP and use mvc_PHP tutorial
The inventor of PHP talks about MVC and website design architecture. It seems that he does not support PHP and use mvc_PHP tutorial
- WBOYOriginal
- 2016-07-21 15:29:33787browse
Q: More and more Web 2.0 websites are moving toward application platforms. What do you think is the key to building such platforms?
A: Simply put, the application platform is the API. Any Ajax or Web 2.0 type website uses API on the application platform to create the interactive effect of the visual interface. For example, Yahoo Mail reads subsequent emails through a simple Request call. When building this kind of website, how you plan to solve the problem will determine the future scalability of the website, rather than the performance that determines the development of the website.
Q: How to plan the website structure so that it can be scalable?
A: Divide a website application into dozens of independent small programs. The front-end provides services through API, and the back-end is an application engine. This will naturally lead to scalability. Because each part of the application has different levels of usage, requires different scaling levels, and requires different mechanisms to handle it. In terms of developing Yahoo Mail, we need to develop an address service program, a mail reading service, and a mail sending service. The mail sending program has nothing to do with the mail reading program. Given the scale of Yahoo, these tasks need to be completely separated in order to be scalable.
Q: What is the most important key to this way of planning a website?
A: The key is that you must build separate and modular independent endpoints instead of putting them all in the same big basket. Most of the development frameworks of today's MVC framework (MVC framework) use the so-called front-end controller (Front Control). Every time the browser makes a Request request, this front-end controller will be called, and then the front-end controller will Identify which program the user wants to execute. Doing so makes no sense at all.
At the browser level, the program can completely know what the user wants to do. For example, if the user just wants to read a letter, the program does not need to send the request to the server and let the server determine what the user wants to read. Letter or delivery. Pulling this kind of decision-making work out of the browser and letting it be handled by the server will waste a lot of server resources on work that has no actual use for the user. Scalability comes from architecture, and many development frameworks tie everything together and limit the architecture. Choose the wrong development framework and you won’t have scalability.
Q: Are you saying that the MVC model is not conducive to website scalability?
A: The MVC model is more suitable for use at the page controller (Page Control) level. Basically, each web controller is an independent module, and the mail reading and address checking are different web controllers. Therefore, the mail reading program will not interfere with the address checking program. Therefore, there will be no problem using the MVC pattern to create a small web controller at each endpoint. However, most frameworks that use the MVC model default to using a front-end controller in the website instead of a web controller. This MVC model is only suitable for small or single-server websites.
Q: How would you choose a development framework?
A: Don’t use any framework. However, I will find out the functions I need from these development frameworks, use the program modules I need, or refer to the design ideas in them, instead of applying the entire framework. Most frameworks I've seen don't focus on creating efficient extensibility and moddability.
Q: Don’t developers need a framework or architecture?
A: The website does need a structure. Everyone needs a framework. The framework is a way to solve problems. But you don't need a general framework to solve all problems with a front-end controller, which usually doesn't work. Every problem is different, and you need to bootstrap the framework and use the right design patterns to directly address the real problem you're dealing with. How can it be possible to meet the needs of people all over the world by only producing one type of car?
It’s okay to use frameworks to develop prototype systems, but don’t apply them all to real products. It's easier to start with the framework, but you need to dismantle the entire framework, remove runtime checks, remove unnecessary functions, and leave only the program modules you will use. You don't need a general purpose framework that doesn't provide future extensibility, but you don't need to start from scratch, you need something in between.
Q: How long does it take for the website to plan for expansion needs?
A: I always hate having to think too much about the future. When you can't predict the future, you can't make decisions for the future.
The Internet changes so fast that I usually only plan things within half a year. Deciding now what will happen six months from now may lead to wrong decisions and make things worse. If you don't solve the current problems, but imagine the problems that will happen in the future, I don't think it's worth it. I would rather solve the problems you can see in front of you and really focus on the products you need now.
Q: So, are there any guidelines that architects can follow?
A: The most important principle is to carefully consider how to allocate program modules, decompose the program into smaller components as much as possible, and adjust the appropriate API. What you should plan is the user endpoint Things like what is the type of browser request? How should the application respond? Can it be cut? Is it possible to distribute these tasks to completely separate servers? Even on the same server, you can architect the application from the perspective of user endpoints. One day, when you grow larger, it will be easy to add a second server, just in the front-end server Traffic sharing can be performed without storing any data. The biggest mistake common developers make is to make the interrelation between the program codes too deep. Each different component needs to communicate with other external components. This makes it difficult to adjust a very clean API. Developers will be unable to extract slow APIs and put them on the secondary server, leaving the primary server to execute only the necessary APIs.
Q: What is the difficulty of the cutting service and disassembly process?
A: You must understand the problem very well before you start. When you finish writing the first version of the program, you start to dismantle the problem. It is almost impossible and difficult to deal with afterwards. It's really hard because the questions keep changing. But if you start with a simple architecture and keep that spirit in mind to separate your application modules. Every time the website changes, the problem change will only affect a small part. You will be able to know that place very well and solve the problem directly. Just like the Lego game, if you build each small building block, if there is any deficiency, you only need to add a small piece, without changing the whole thing too much.
Q: In addition to scalability, how to improve website performance?
A: To improve performance, you must first know how much time each program takes. I would ask, after the user sends the Request request, how long does it take to receive the first Byte of data? Many developers don’t know how long this time (First Byte Latency) is, or how much time their code takes? You can use Profile to track performance and draw a visual performance flow chart to understand where the bottleneck is.
Even taking into account the latency on a single machine, through the system-level tracking program, you can know how long each system call (System Call) executed by the program takes. We also need to consider the delay in the browser and improve the way web pages execute based on the actual speed experienced by users.
Every time you add a new feature, be able to calculate how many milliseconds the new feature will add and think about whether it is worth it.
Q: So, what principles should be paid attention to for website security?
A: The basic spirit is very simple, just use the concept of data firewall to design the website. Internet firewalls closely monitor every communication port and only allow packets without security concerns to pass through. However, website developers, on the contrary, only block content they believe is dangerous. Developers cannot trust any data obtained from the outside. By borrowing firewall concepts and techniques and establishing a data firewall, website security can be improved.
Q: What are the requirements for a good architect?
A: You must understand technology very well and understand every detail, such as designing a data storage mechanism. You need to understand what kind of data can be stored, how big a file can be stored, how much data can be stored, and how fast can it be stored per second? How to copy data? Which data format must be used by the front end, etc. The architect does not need to know how to fix Oracle database errors like a DBA, but he must be able to understand the capabilities of the Oracle database. This kind of person is hard to find. You must have failed many times before you have enough experience.
Q: There are still many old websites in Taiwan using PHP 4. Should they upgrade to PHP 5 now? Or wait for PHP 6?
A: Upgrade to PHP 5 as soon as possible. As long as you make some tests and modifications, you can get better performance and security, why not do it? There is no need to wait for PHP 6, the way the open source community works, there is no promise of a launch time. Many new features have been put into PHP version 5.3. It is most important to upgrade from 4 to 5 as soon as possible.