Yar (yet another RPC framework, the leader asked me why it always starts with Ya, haha, because the name is easy to come by) was developed by me more than 3 months ago to solve a practical problem. A PHP extended RPC framework, different from existing RPC frameworks (xml-rpc, soap), this is a lightweight framework that supports multiple packaging protocols (msgpack, json, php), and the most important one The characteristic is that it is parallelizable..
Consider the following scenario:
Traditional Web application, one process, one request, as a matter of course. However, when The processing of a request involves multiple data sources, and there is a certain degree of independence between them.
It is still a traditional Web application. With the rapid growth of the business, an application has a turnover of developers. It will slowly enter a vicious cycle, with only additions and no subtractions in the amount of code. Because as the system becomes more complex, one change will affect the overall situation, and the new maintainers do not have so much time for the original system. Give him a comprehensive grasp. Even with so much time, it is not easy to master the combination of the thinking of so many maintainers...
Then, in the long run, this system will It will become increasingly unmaintainable... When a large application enters this vicious cycle, the only thing waiting for it is reconstruction.
So, can this system be decoupled?
We have done a lot of decoupling, data, middleware, business, logic, etc., and various layers. But when it comes to Web applications, how else can we divide them? We have already done MVC...
Based on this, Yar may be able to solve these two problems you encountered...
Yar is a very lightweight RPC framework. When I implemented Yar, I pursued the ultimate lightweight , it is very simple to use. For the server side:
<ol class="dp-c"> <li class="alt"><span><span><?php </span></span></li><li><span class="keyword">class</span><span> API { </span></li><li class="alt"><span> </span><span class="comment">/** </span> </li><li><span><span class="comment">* the doc info will be generated automatically into service info page. </span> </span></li><li class="alt"><span><span class="comment">* @params </span> </span></li><li><span><span class="comment">* @return </span> </span></li><li class="alt"><span><span class="comment">*/</span><span> </span></span></li><li><span> </span><span class="keyword">public</span><span> </span><span class="keyword">function</span><span> api(</span><span class="vars">$parameter</span><span>, </span><span class="vars">$option</span><span> = </span><span class="string">"foo"</span><span>) { </span></li><li class="alt"><span> } </span></li><li><span> </span></li><li class="alt"><span> </span><span class="keyword">protected</span><span> </span><span class="keyword">function</span><span> client_can_not_see() { </span></li><li><span> } </span></li><li class="alt"><span>} </span></li><li><span> </span></li><li class="alt"><span class="vars">$service</span><span> = </span><span class="keyword">new</span><span> Yar_Server(</span><span class="keyword">new</span><span> API()); </span></li><li><span class="vars">$service</span><span>->handle(); </span></span></li> <li class="alt"><span>?> </span></li> </ol>
Is it very similar to the method of using Soap? Yes, in this way, your API class can provide services to the outside world..
Yar binds documents and interfaces together to facilitate development. For the above example, if we make a simple GET request for this interface address, we will see the following information page: