A system architect-like, fluffy story about PHP systems and design ideas. I don’t think there is a model answer, but I’ll show you better practice

Sep 5, 2020 PHP design front end back end best practices

Overview

For the past five years, I have been involved in the development of open systems and have had the opportunity to use PHP.

I rarely write the code myself (order it from an external business partner), but as I look at the code written by others, I feel the “level” of the PHP system. ， I wonder if it is something like this **, a personal line is being drawn.

Also, I was watching the situation of frameworks that are changing rapidly, and ** “Guidelines for utilizing frameworks that should not be shaken” **, because my own ideas have been boiled down, it may be developing, but it is about to be an article. I decided to share it as.

From a system architect’s point of view, it may be closer to the topic of PHP system / design concept ** than the technical aspect.

It seems that it will be a composition that requires skill to combine loose and fluffy, rambling topics into one article (cold sweat).

“Level” feeling of PHP system

From old-fashioned, The Legacy PHP to modern Ikeike PHP.

The table below does not cover all the patterns, but as far as my uncle knows, ** “generally, this is what it is” ** skin sensation:

It is characteristic that the system architecture that catches up with the trends of the times becomes loosely coupled.

For the time being, I think that the trend toward loose coupling will continue **, but from the following perspectives, I think that there will be no reversal to tight coupling **:

• -Loose coupling increases code reusability
• -If loosely coupled, it is compatible with microservice orientation.

Framework utilization guidelines that should not be shaken

Considering the extension of the trend of the times such as loose coupling, reusability, and microservices, it can be said that ** module disintegration is justice **.

The important thing is not to simply disassemble, but to do it in a style that maximizes benefits such as reusability and readability.

Therefore, by utilizing a framework that is also a ** crystal of wisdom **, even if an engineer with little development experience writes code, the minimum reusability and readability are guaranteed. It is dangerous to use it blindly.

Here are some possible “better practices”.

(Please let me know if there is something better if you do this)

Better practice ① Communicate with ajax instead of <form>

There are many examples of using the <form> tag in framework tutorials, but using the <form> tag is not mandatory, it’s just an option (a matter of taste).

The <form> tag has the convenience of being able to perform screen transitions and server communication at the same time, but it doesn’t go very well with the direction that “modern” architects are heading. I feel it.

Here are some concrete examples:

• -Screen transitions tend to be centrally managed ** as a mechanism called “routing” on the framework (whether front-end or back-end).
• -The screen transition by the <form> tag gives the end user an impression of UX that is not modern because ** the whole is redrawn.

Under these circumstances, I think it is a better practice to use ajax technology instead of <form> and use routing as a gateway to cleanly separate the front end and back end.

Better practice ② Get along with the framework shallowly

Paradoxically, when choosing a new framework, I think you should first consider ** the ease of leaving that framework ** in the future.

Various acts are unrelenting, and the prosperity is inevitable.

There is no such thing as a framework that will never die in the future, and if you look at it over a longer span, there is a trend in the development language itself.

And even if the trend continues for a long enough time, the risk of ** removing the ladder of a specific function ** at the timing of version upgrade cannot be completely denied.

For example, from a developer’s point of view, there are many useful framework-specific functions (value validation, error display) around the <form> tag, and I would like to make full use of it. It is also important to keep calm ** by weighting yourself.

Excessive use of framework features can be an unexpected stumbling block when the epidemic goes away, and can be a factor in reducing portability.

It is also possible that the logic that could be easily implemented in framework A can be very difficult in the newly introduced framework B.

Better practice ③ Make it distributed

This is also related to (2) “Slightly interacting with the framework”, but I would like to emphasize it, so I will write it as a separate item.

There is no textbook on how to use the front end and back end, ** depending on the idea of the engineer **:

—— Bring everything to the back end as much as possible —— Bring everything to the front end as much as possible

• -Go neutral

I’m sure that all of the above can be “correct” or “incorrect” in the world of design philosophy.

The topic is “Do you put all the eggs in one basket?”, But ** balancing and appropriately diversifying ** will lead to future risk diversification, and it will be combined with a specific framework. I think you can avoid the ending that becomes a lotus student.

Better practice ④ Implement in a long life cycle hierarchy

Consider the length of the life cycle of each elemental technology.

In other words, in a hierarchy that is not easily affected by trend changes (eg, pure functions in the development language can be expected to be supported for a long period of time and can be used with peace of mind than the eigenfunctions of the framework). It is a design concept that keeps in mind the implementation:

• -Framework (eg Angular / React / Vue)
• -Development language (eg PHP / Java)
• -Interface ideas (eg HTTP / API)

Be as faithful as possible to a hierarchy with a long life cycle (eg, a development language longer than a framework and an interface-like idea longer than a development language).

** Wrapped around long things ** As a result, I feel that the design concept will contribute to the production of long-lasting systems and parts that are easy to reuse.

#Summary

A system architect-like “level feeling” and “better practice” in terms of PHP system and design concept.

I wrote about such a vague theme from the standpoint of ** in-house SE, that the time spent interacting with the system after the start of operation is overwhelmingly longer than the time it takes to design, develop, and release the system.

――I want to avoid trouble when rebuilding the system as much as possible. ――I want to avoid the effects of version upgrades and trend changes as much as possible.

With that in mind, when I was spending time at the system development site, I honestly felt that I was in a defensive attitude ** after writing the article.

If this is an engineer in another position (eg SIer), system reconstruction, version upgrades, and trend changes are ** important “business opportunities” that lead to business acquisition **, and this article is I think that a completely different design concept may be born there.