1
I have a question that has not yet been clarified, in the development with php, the ideal is to separate the backend of the frontend, using Rest and consequently web services, or the traditional way, running everything on the server?
2 answers
2
There is no correct or wrong answer to this question.
In my opinion...
separating you win:
- Less demand for Internet link and server resources.
- Technology-independent and separate codes (can change the technology of one without affecting the other, example: BACKEND in ASP can be changed to PHP without affecting the frontend).
- You can host the frontend on one server and the backend on another server.
separating you lose:
- Performance on old machines with little processor and memory, as it will require more customer processing.
The most modern frameworks, example Angular2, uses the separation, being the frontend in Typescript (a simplified way of writing the Javascript) and the backend in Node.Js.
-
Okay, I get it. Plus which is the most traditionally used form and frameworks for them you would have this answer?
-
I updated the answer.
1
There is no right way.
While there are many reasons to separate the back end of the front end in many projects, there are specific situations (which I’ve already passed a few) that implementing a new layout in the catch pages has been wasteful of resources. You have to know exactly what your project needs. If your project is a platform, or application, and has institutional pages, you can separate the layout application, because the previous one is capture pages.
If your project, the layout is part of the business plans, you can create all the modules separately (search by MVC architecture), still being part of the same system, as the frameworks and Cmss. However, if you use some framework, customizing code that was not written by you can take time, and you have to see if it’s worth, often, better not to waste time stirring.
If you are building your system from scratch, you have the freedom to study a little bit of OOP, and create scalable interfaces, with a good use of MVC-oriented code.
-
Right, a large software, the idella would be the separation in layers with MVC, using web services only for statistical data query for example?
-
2
Yes! As you specified which type of system is, in this case yes, using MVC is practically mandatory for maintenance reasons. Remember, that MVC, not the only way to work with the complexity of a large system. A sub-technique of MVC is data access Object (DAO) that facilitates the migration of one database use to another. Remembering that large systems should be scalable, ie, resistant drastic maintenance. Object-oriented programming is highly requested. The more abstract, the greater the complexity support, such as SOA use, Apis, etc.
-
@Marcospaulo, why come out negatively everyone? If you have something better to contribute write a response and contribute to the community.
Browser other questions tagged php rest
You are not signed in. Login or sign up in order to post.
It seems to me that there is a confusion between the terms frontend and view of MVC in this question. Backend is the code that runs on the server to mount the view. Frontend is the mounted code that runs in the user’s browser. Apis whether REST or SOAP can be used to interconnect systems. Your question is whether making a web service for your ajax frontend or mobile app communicating is a trend. That may be, but I don’t see the need for that extra division for most cases. As a fad it is a thing to hinder development, but it already leaves the system ready for when to evolve.
– Antonio Alexandre
There is no ideal. You have to know and apply the knowledge case by case. There is a lot of nonsense on the internet of ready-made recipe, but many of them, if not most, teach extremely complicated things to solve very simple things, as if every problem were the same.
– Bacco