5 ms·

Frameworks are useful for working in teams, and on long term projects. This is because they provide a set of idioms, patterns and decisions that everyone can le

by ehnto 5y ago

Frameworks are useful for working in teams, and on long term projects. This is because they provide a set of idioms, patterns and decisions that everyone can learn and know, without having to invent them all yourself. It doesn't have to be the perfect way, it just has to be a way, so that you can focus on your domain specfic problems. Likewise, when a new developer arrives, they know exactly where to find everything because it has a place that it belongs, and they can reference the docs if they are having trouble. It's less about the code and more about treating the project as a whole ecosystem.

XCSme 5y ago
But what if the app is a simple monolith that exposes some API routes and processes/reads/stores data in a database? Is something like this really harder to understand for a new developer than a Laravel project? .htaccess dbconfig.php /api /users create.php get.php getAll.php delete.php /products create.php get.php delete.php And where each file does something like (simplified) // /api/users/getAll.php include 'dbconfig.php'; checkPermissions(ROLE_ADMIN); $res = $db->exec("SELECT * from users"); echo json_encode($res);
- unfocussed_mike 5y ago
  There is no doubt that getting in and out of a Laravel project is a bit more difficult than the example you suggest. But the example you suggest absolutely encourages bad practice.
  - XCSme 5y ago
    > absolutely encourages bad practice Bad practice, as in security-wise, performance-wise, readability-wise, or something else? If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices? If the developer is inexperienced, can't they still implement something in a bad way in Laravel (e.g. save a user-submitted file on the disk without checking for permissions)?
    - unfocussed_mike 5y ago
      > If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices? That depends. How tired is the developer? How under pressure? How over deadline? ;-) I do get your point and I understand where you're coming from. But this model of PHP (where every URL entry point is its own script) is the thing that most encourages expedient development rather than good development, because you can just hack on that one thing without affecting anything else. It also (traditionally) encourages somewhat riskier hosting configurations, because any PHP file the web server can route may need to be executable, and because a failure of web server configuration can expose PHP files as readable. Whereas with a single point of entry (index.php router), you can locate your codebase outside the document root, refuse to directly execute anything but your endpoint script, etc. These are partly old-fashioned concerns, admittedly, but it's surprising how often the approach you're outlining is still the source of malicious PHP exploits where a script file gets buried in a hacked release, or where some server vulnerability can be inveigled into executing PHP code by some image file upload mechanism that didn't do adequate checking.
      - XCSme 5y ago
        I agree that writing secure PHP code is hard, but using a framework like Laravel, even if it has a single point of entry, makes it a lot more likely to introduce more security issues. When a framework is popular and open-source, people will spend a lot more resources trying to find and exploit vulnerabilities than in a custom private codebase: https://snyk.io/vuln/composer:laravel%2Fframework https://snyk.io/vuln/composer:laravel%2Fframework
        unfocussed_mike 5y ago
        I can see your point. But at the same time, I have never seen a project built along the lines you discussed that has not collapsed under the pressure for expedience, and it's just as vulnerable to issues in libraries (which any project of any complexity will use).
  - tomcam 5y ago
    Non-PHP, non-Laravel person here just trying to learn. That looks pretty good to me. What bad practices does it encourage?
    - XCSme 5y ago
      I wrote that example, which is simplified, but here are some security things to keep in mind when dealing with PHP/MySQL: - Always use PDO prepared statements to avoid SQL injections - Should probably implement a CSRF token check - You shouldn't output values directly from the user/database and that can lead to XSS attacks (either sanitize the stored data, or when outputting it make sure the page is always interpreted as plain text) - You might forget to check for permissions in a specific route (code enforce this via some linting/IDE rules, by using some automated tests or by checking in an included shared script that permissions were indeed verified)
      - ipaddr 5y ago
        Always use PDO prepared statements to avoid SQL injections? Sanitize your data and use whatever driver you want. Prepare statements are like sending xml instead of json. If you are populating a database with known data why add the overhead?
      - tomcam 5y ago
        Thank you. Somehow, I thought the tree structure they described for breaking down program logic was the problem. Obviously I agree with all the other stuff, which is table stakes for a safe web app
- blowski 5y ago
  Nearly every time I see PHP projects like this, I find massive security vulnerabilities combined with extremely brittle functionality. Sure, this describes many Laravel and Symfony projects as well, and not every vanilla PHP project is bad. But there is definitely a pattern.
  - XCSme 5y ago
    I agree, one big reason to use frameworks is that they at least make it harder to make insecure things, but as you said, if the developer is inexperienced they can still introduce vulnerabilities in any codebase. I would say, in this regard, that Laravel is better than plain PHP when working with inexperienced devs that are likely to make mistakes or write bad code.
    - blowski 5y ago
      So what happens if you want to hire a second dev to help you? Or you want to sell the codebase?
      - XCSme 5y ago
        A new dev can start writing code immediately by looking at any existing file, as almost all of them do the same thing: include a shared header, get some input from the user, do one or more MySQL queries, return the result. The backend is completely separated from the frontend (so the PHP application just exposes an API to work with), so any code written there does exactly what you expect with no side effects on the client-side.
        unfocussed_mike 5y ago
        > as almost all of them do the same thing It's the almost that will get you here.
        XCSme 5y ago
        The difference is mostly the user input, MySQL query and DB table and output. This is indeed prone to typos and "brain-farts" when selecting the wrong data. Does Laravel provide any protection in making sure you don't SELECT from the wrong table?
- ehnto 5y ago
  If I am working alone, I sometimes do similar stuff. But if I am working with others, I don't really want to deliberate over every new architectural decision if a project grows. I want to be able to say, "Hey, can you make a new storelocator page" and then they can get it done using the docs. They know where models, controllers, views live, they know how to make migrations for the new tables, they can even google "store locator laravel" and probably get 90% of the way there in a day or less. Once they are done, I already know how this new feature should work before I even read their code.
  - unfocussed_mike 5y ago
    I took over an enormous system that a third party developer built in Laravel. Not good code, particularly, and not particularly good database design. Also no documentation really. But the implementation was pretty clearly pure Laravel, and the migrations ran without issue. So that was immediately a huge weight off my mind, because I knew I would be able to maintain the live, stage and dev boxes sanely. The two biggest problems with this app were 1) the number of places they diverged from using the query builder for no really good reason when scopes could have made everything so much more readable 2) a false assumption they made about subquery ordering in MySQL (implicit ordering that worked for them in 4.x but would not work in 5.x, something along those lines anyway) Because of 1), 2) was incredibly painful to fix. Dozens of bits of arbitrary SQL that could have been handled by the query builder. And I'm sure the only reason it's like that is because that's the way they started out and they had time pressure that stopped them ever changing course. Expedience kills software.
    - XCSme 5y ago
      > Expedience kills software Unfortunately, this is how the majority of software is written nowadays. This is one of the reasons I prefer to build things slowly, think about stuff, implement them nicely, find clever solutions and optimize where it's possible. I know I could build more stuff and earn more money if I rushed things more, but I prefer building nicer stuff instead of more stuff. For most outsourcing companies, this doesn't really make economic sense though, but for product-driven companies it is still possible if the leadership decides to do it. > the implementation was pretty clearly pure Laravel, and the migrations ran without issue Being able to refactor/change one part of the code without being afraid that something else might break is an excellent reason to use a framework. Once you understand how that framework works, even if a codebase is bad, you can know what and how can break if not implemented properly. It increases the visibility of "code smells".
- jonwinstanley 5y ago
  If your project is as simple as this then yes, a framework would be overkill for you. The people that benefit from Laravel use a lot of its features and aren’t willing to waste time rewriting them for themselves. In the businesses I have worked at, if we had spent the whole time building the stuff that Laravel already does for us then we’d have gone broke really quickly.
- munk-a 5y ago
  Those files might work and your project might stay on that small scale - but you'd find it impossible to add automated tests to that. If your project grew to be serious enough to warrant automated testing then you're going to want to seriously refactor it and using a framework's dependency management is just going to make your life easier. You can make things a lot safer with just a little bit of separation and that will help protect you against bugs and security issues. This is all said by someone who is working right now with a codebase with a checkPermissions function that they added to shift things off of direct $_SESSION access and which has since been almost entirely supplanted by route based authentication. I delight in working to modernize and secure legacy systems which is why I heavily favor Laminas over Laravel due to the add-it-as-you-need-it approach, when I first worked to convert our codebase to a framework we did it page by page and component by component with everything working fine for both legacy and framework fulfilled requests and we've slowly added more components as they've become necessary (and removed ones that are no longer of use).
  - XCSme 5y ago
    It might be hard to do, but do you measure any KPIs (performance, codebase size, time needed to write a new feature, security) for before/after converting the platform to a different framework? I did switch the front-end side from no-framework (jQuery spaghetti) to a framework (React + MUI + TypeScript), but the main reason was that I needed: 1) Component reusability 2) Premade components (UI elements) 3) Data typing (thus TypeScript, to get autocompletion features) On the back-end side, the default PHP language already supports most of those things, plus the reusability part is very little for an API (it's mostly having some basic functions such as auth/db connection and writing different queries), for which a framework wouldn't necessarily make things easier, just provide a different way of writing those queries (i.e. ORM vs direct DB query). I agree, it's nice that with an ORM you get autocompletion for the fields you want to select, but the databases that I usually use only have a few (intuitively named) columns, so if you take a look at the table it immediately makes sense (but the queries are still prone to typos, so you might get an error the first time you type it).
    - munk-a 5y ago
XCSme 5y ago
> on long term projects Aren't frameworks harder to use in a long-term project if the codebase is not constantly updated to match the new framework standards? For example, a code-base written in React (pre-hooks) is probably pretty hard to understand for a developer that has only learned React recently and uses hooks for everything.
- ehnto 5y ago
  There is often ongoing maintenance for sure, but if that is a concern a framework probably doesn't fit your project for other reasons already. Frameworks are heavier, but in the same way a company gets heavier as it gets more professional and more complex. I think your use case doesn't require a framework, so don't think my angle is to convince you that you do. Just that there is definitely a time and place for them.
- jonwinstanley 5y ago
  There’s definitely an overhead in updating your codebase to work with new versions of the framework but the time saved by not having to write all the features yourself makes it worth it.
  - XCSme 5y ago
    Can you give example of some features that you have to write that don't exist in a plain PHP application nor an external library (i.e. features that have to be tightly integrated in the core of the product)?
    - jonwinstanley 5y ago
      To be honest, I'm sure all the features of Laravel I use could also be done with external libraries, but researching and finding something suitable, hooking it together, configuring, integrating it into my project is something I am unwilling to spend time on. I write code to solve problems for my company, so building a framework is very low on my priorities. I'd rather just use something that is ready on day one. Maybe it's not to everyone's taste but I like the fact I can just get on with trying to build my product.

by ehnto 5y ago

XCSme 5y ago

But what if the app is a simple monolith that exposes some API routes and processes/reads/stores data in a database? Is something like this really harder to understand for a new developer than a Laravel project? .htaccess dbconfig.php /api /users create.php get.php getAll.php delete.php /products create.php get.php delete.php And where each file does something like (simplified) // /api/users/getAll.php include 'dbconfig.php'; checkPermissions(ROLE_ADMIN); $res = $db->exec("SELECT * from users"); echo json_encode($res);

unfocussed_mike 5y ago
There is no doubt that getting in and out of a Laravel project is a bit more difficult than the example you suggest. But the example you suggest absolutely encourages bad practice.
- XCSme 5y ago
  > absolutely encourages bad practice Bad practice, as in security-wise, performance-wise, readability-wise, or something else? If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices? If the developer is inexperienced, can't they still implement something in a bad way in Laravel (e.g. save a user-submitted file on the disk without checking for permissions)?
  - unfocussed_mike 5y ago
    > If you trust the developer to implement things properly (use PDO prepared statements when storing data in DB, properly check for permissions, write efficient queries, etc.), shouldn't that automatically exclude common bad practices? That depends. How tired is the developer? How under pressure? How over deadline? ;-) I do get your point and I understand where you're coming from. But this model of PHP (where every URL entry point is its own script) is the thing that most encourages expedient development rather than good development, because you can just hack on that one thing without affecting anything else. It also (traditionally) encourages somewhat riskier hosting configurations, because any PHP file the web server can route may need to be executable, and because a failure of web server configuration can expose PHP files as readable. Whereas with a single point of entry (index.php router), you can locate your codebase outside the document root, refuse to directly execute anything but your endpoint script, etc. These are partly old-fashioned concerns, admittedly, but it's surprising how often the approach you're outlining is still the source of malicious PHP exploits where a script file gets buried in a hacked release, or where some server vulnerability can be inveigled into executing PHP code by some image file upload mechanism that didn't do adequate checking.
    - XCSme 5y ago
      I agree that writing secure PHP code is hard, but using a framework like Laravel, even if it has a single point of entry, makes it a lot more likely to introduce more security issues. When a framework is popular and open-source, people will spend a lot more resources trying to find and exploit vulnerabilities than in a custom private codebase: https://snyk.io/vuln/composer:laravel%2Fframework https://snyk.io/vuln/composer:laravel%2Fframework
      - unfocussed_mike 5y ago
        I can see your point. But at the same time, I have never seen a project built along the lines you discussed that has not collapsed under the pressure for expedience, and it's just as vulnerable to issues in libraries (which any project of any complexity will use).
- tomcam 5y ago
  Non-PHP, non-Laravel person here just trying to learn. That looks pretty good to me. What bad practices does it encourage?
  - XCSme 5y ago
    I wrote that example, which is simplified, but here are some security things to keep in mind when dealing with PHP/MySQL: - Always use PDO prepared statements to avoid SQL injections - Should probably implement a CSRF token check - You shouldn't output values directly from the user/database and that can lead to XSS attacks (either sanitize the stored data, or when outputting it make sure the page is always interpreted as plain text) - You might forget to check for permissions in a specific route (code enforce this via some linting/IDE rules, by using some automated tests or by checking in an included shared script that permissions were indeed verified)
    - ipaddr 5y ago
      Always use PDO prepared statements to avoid SQL injections? Sanitize your data and use whatever driver you want. Prepare statements are like sending xml instead of json. If you are populating a database with known data why add the overhead?
    - tomcam 5y ago
      Thank you. Somehow, I thought the tree structure they described for breaking down program logic was the problem. Obviously I agree with all the other stuff, which is table stakes for a safe web app
blowski 5y ago
Nearly every time I see PHP projects like this, I find massive security vulnerabilities combined with extremely brittle functionality. Sure, this describes many Laravel and Symfony projects as well, and not every vanilla PHP project is bad. But there is definitely a pattern.
- XCSme 5y ago
  I agree, one big reason to use frameworks is that they at least make it harder to make insecure things, but as you said, if the developer is inexperienced they can still introduce vulnerabilities in any codebase. I would say, in this regard, that Laravel is better than plain PHP when working with inexperienced devs that are likely to make mistakes or write bad code.
  - blowski 5y ago
    So what happens if you want to hire a second dev to help you? Or you want to sell the codebase?
    - XCSme 5y ago
      A new dev can start writing code immediately by looking at any existing file, as almost all of them do the same thing: include a shared header, get some input from the user, do one or more MySQL queries, return the result. The backend is completely separated from the frontend (so the PHP application just exposes an API to work with), so any code written there does exactly what you expect with no side effects on the client-side.
      - unfocussed_mike 5y ago
        > as almost all of them do the same thing It's the almost that will get you here.
        XCSme 5y ago
        The difference is mostly the user input, MySQL query and DB table and output. This is indeed prone to typos and "brain-farts" when selecting the wrong data. Does Laravel provide any protection in making sure you don't SELECT from the wrong table?
ehnto 5y ago
If I am working alone, I sometimes do similar stuff. But if I am working with others, I don't really want to deliberate over every new architectural decision if a project grows. I want to be able to say, "Hey, can you make a new storelocator page" and then they can get it done using the docs. They know where models, controllers, views live, they know how to make migrations for the new tables, they can even google "store locator laravel" and probably get 90% of the way there in a day or less. Once they are done, I already know how this new feature should work before I even read their code.
- unfocussed_mike 5y ago
  I took over an enormous system that a third party developer built in Laravel. Not good code, particularly, and not particularly good database design. Also no documentation really. But the implementation was pretty clearly pure Laravel, and the migrations ran without issue. So that was immediately a huge weight off my mind, because I knew I would be able to maintain the live, stage and dev boxes sanely. The two biggest problems with this app were 1) the number of places they diverged from using the query builder for no really good reason when scopes could have made everything so much more readable 2) a false assumption they made about subquery ordering in MySQL (implicit ordering that worked for them in 4.x but would not work in 5.x, something along those lines anyway) Because of 1), 2) was incredibly painful to fix. Dozens of bits of arbitrary SQL that could have been handled by the query builder. And I'm sure the only reason it's like that is because that's the way they started out and they had time pressure that stopped them ever changing course. Expedience kills software.
  - XCSme 5y ago
    > Expedience kills software Unfortunately, this is how the majority of software is written nowadays. This is one of the reasons I prefer to build things slowly, think about stuff, implement them nicely, find clever solutions and optimize where it's possible. I know I could build more stuff and earn more money if I rushed things more, but I prefer building nicer stuff instead of more stuff. For most outsourcing companies, this doesn't really make economic sense though, but for product-driven companies it is still possible if the leadership decides to do it. > the implementation was pretty clearly pure Laravel, and the migrations ran without issue Being able to refactor/change one part of the code without being afraid that something else might break is an excellent reason to use a framework. Once you understand how that framework works, even if a codebase is bad, you can know what and how can break if not implemented properly. It increases the visibility of "code smells".
jonwinstanley 5y ago
If your project is as simple as this then yes, a framework would be overkill for you. The people that benefit from Laravel use a lot of its features and aren’t willing to waste time rewriting them for themselves. In the businesses I have worked at, if we had spent the whole time building the stuff that Laravel already does for us then we’d have gone broke really quickly.
munk-a 5y ago
Those files might work and your project might stay on that small scale - but you'd find it impossible to add automated tests to that. If your project grew to be serious enough to warrant automated testing then you're going to want to seriously refactor it and using a framework's dependency management is just going to make your life easier. You can make things a lot safer with just a little bit of separation and that will help protect you against bugs and security issues. This is all said by someone who is working right now with a codebase with a checkPermissions function that they added to shift things off of direct $_SESSION access and which has since been almost entirely supplanted by route based authentication. I delight in working to modernize and secure legacy systems which is why I heavily favor Laminas over Laravel due to the add-it-as-you-need-it approach, when I first worked to convert our codebase to a framework we did it page by page and component by component with everything working fine for both legacy and framework fulfilled requests and we've slowly added more components as they've become necessary (and removed ones that are no longer of use).
- XCSme 5y ago
  It might be hard to do, but do you measure any KPIs (performance, codebase size, time needed to write a new feature, security) for before/after converting the platform to a different framework? I did switch the front-end side from no-framework (jQuery spaghetti) to a framework (React + MUI + TypeScript), but the main reason was that I needed: 1) Component reusability 2) Premade components (UI elements) 3) Data typing (thus TypeScript, to get autocompletion features) On the back-end side, the default PHP language already supports most of those things, plus the reusability part is very little for an API (it's mostly having some basic functions such as auth/db connection and writing different queries), for which a framework wouldn't necessarily make things easier, just provide a different way of writing those queries (i.e. ORM vs direct DB query). I agree, it's nice that with an ORM you get autocompletion for the fields you want to select, but the databases that I usually use only have a few (intuitively named) columns, so if you take a look at the table it immediately makes sense (but the queries are still prone to typos, so you might get an error the first time you type it).
  - munk-a 5y ago

XCSme 5y ago

> on long term projects Aren't frameworks harder to use in a long-term project if the codebase is not constantly updated to match the new framework standards? For example, a code-base written in React (pre-hooks) is probably pretty hard to understand for a developer that has only learned React recently and uses hooks for everything.

ehnto 5y ago
There is often ongoing maintenance for sure, but if that is a concern a framework probably doesn't fit your project for other reasons already. Frameworks are heavier, but in the same way a company gets heavier as it gets more professional and more complex. I think your use case doesn't require a framework, so don't think my angle is to convince you that you do. Just that there is definitely a time and place for them.
jonwinstanley 5y ago
There’s definitely an overhead in updating your codebase to work with new versions of the framework but the time saved by not having to write all the features yourself makes it worth it.
- XCSme 5y ago
  Can you give example of some features that you have to write that don't exist in a plain PHP application nor an external library (i.e. features that have to be tightly integrated in the core of the product)?
  - jonwinstanley 5y ago
    To be honest, I'm sure all the features of Laravel I use could also be done with external libraries, but researching and finding something suitable, hooking it together, configuring, integrating it into my project is something I am unwilling to spend time on. I write code to solve problems for my company, so building a framework is very low on my priorities. I'd rather just use something that is ready on day one. Maybe it's not to everyone's taste but I like the fact I can just get on with trying to build my product.