4 ms·

I like using plain PHP + PDO MySQL. I structure it so almost all files contain a single function/MySQL query, with very little dependencies. I already know how

by XCSme 5y ago

I like using plain PHP + PDO MySQL. I structure it so almost all files contain a single function/MySQL query, with very little dependencies. I already know how to implement core functionalities when needed (e.g. CSRF, user permissions). Why should I consider Laravel if plain PHP seems to work excellent in my case (been able to maintain the same codebase for over 9 years without issues, can quickly create a new app if needed, can reuse code from one project to another, understanding what the code does requires zero-framework knowledge, performance is as good as it can be, as every file executes only what's needed and doesn't create unnecessary abstractions, etc.)?

castis 5y ago
> Why should I consider Laravel If you work on all those projects alone, and you're happy doing this, you probably wouldn't. You aren't the target market for a framework like this. Laravel (and any good framework, really) is for people who want a consistent dev experience _with good documentation_.
- XCSme 5y ago
  Yes, I do work alone on those projects, but I do use frameworks on the frontend-side as I find them to help in the long term, not hinder the projects as PHP frameworks do (a lot of boilerplate). It makes sense that if Laravel is strongly-opinionated to result in a consistent dev experience, but is a consistently bloated dev experience better than an inconsistent lean one?
  - colecut 5y ago
    Bloat can be mostly ignored, inconsistencies can not.
- unfocussed_mike 5y ago
  > You aren't the target market for a framework like this. I don't know about this. But then I am of an age where I consider myself to be a team of programmers separated by time. There are the younger, less easily tired versions of myself who thought this was a great idea for a career and lived on takeaway curries, there's me, and there are the four or five older versions of myself who will hate me for trying to be clever and not trying to be consistent. Laravel helps me take on projects that allow me to hand off pieces of work among my team ;-)
gnarcoregrizz 5y ago
For me, its about the higher level things included. I don't want to write a queue, event system, or cache layer again.
- momenti 5y ago
  Though for a small-ish site (say <150 users), such techniques are typically not necessary.
  - XCSme 5y ago
    The PHP apps that I have created handle millions of monthly users without issues, so I would say that probably specific techniques are needed more to implement a given functionality instead of to achieve a better performance.
- XCSme 5y ago
  That makes sense, there are probably some more complex use-cases, but for those I would personally not use PHP (e.g. if real-time communication is required or linking together many microservices and having to do operations that involve more than a database and file system).
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)?
bluedino 5y ago
Self-made frameworks are great as long as: They work. If they are full of bugs they are a pain They are complete. If they are missing parts because they weren't needed yet, they are a pain They are documented. Documented well is a bonus There isn't a self-made framework for every project at the company The person who made the framework is still around The person who made the framework didn't also make v2 and v3, mixing them in the same project
- XCSme 5y ago
  My point was more that PHP is more of a framework-less language, as most of the functionality needed for a basic web application is built-in (file-based routing, secure PDO database access, external libraries for specific functionalities like PHPMailer for sending emails). I think that if you need something a lot more complex than this (realtime communication, processing data in separate threads, linking microservices), then PHP is not a good choice.
munk-a 5y ago
I wouldn't consider Laravel for this use case - I might consider either Laminas or Symfony though since those two frameworks allow you to pick and choose which features you actually want to roll into your project. If you'd like to simplify your routing files but otherwise leave everything else the same - Laminas and Symfony can do that trivially. If you find yourself forced into an ORM due to needing to support multiple SQL dialects, Laminas and Symfony can also do that trivially. Laravel is a sort of all-in option that tends to perform worst when integrated into a legacy project - it isn't completely overbearing (it won't creep into absolutely every file you're using) but it will end up requiring changes to a lot more files than is reasonable.
e12e 5y ago
Sounds reasonable. (how) do you do testing (unit test and integration tests)?
- XCSme 5y ago
  I don't do unit tests (tried it, it was slowing down development too much). I did have integration testing for a while for the core functionality, but in the end that was not helping much either, and after releasing a new version of the app I deleted the tests and (after 2 years) still haven't written new ones, without any bad consequences so far. I deploy a new version to a beta branch, test it myself for a few hours/days (as I do use the app myself daily), then publish it live. Customers gradually upgrade to the new version and if anyone encounters an issue they let me know, and I fix it ASAP, but it almost never happens. Also, the app is pretty complex, so writing tests for every use-case and environment is impossible. I am not a big fan of writing tests when working in a small team (<5 developers). I did work on some pretty big projects that turned out great and very robust, without having written any tests. That being said, if I ever have the time and am bored enough, I will write some integration tests, but mostly for the installation part of the application, not for the usage part.
  - tomschlick 5y ago
    > Also, the app is pretty complex, so writing tests for every use-case and environment is impossible. No, you're just using the most expensive / error prone testing methods: doing it manually.
    - XCSme 5y ago
      Maybe my comment was not clear, I do not specifically test the app and all its functionalities. I use the app myself on a daily basis anyway, which acts like a sort-of continuous integration testing program. I use the new version myself for a few days before publishing it, or provide it to some chosen beta testers that use the product anyway.
      - tomschlick 5y ago
dabernathy89 5y ago
There are lots of reasons someone like you might benefit from a framework, but this one jumps out immediately: > I already know how to implement core functionalities when needed (e.g. CSRF, user permissions) Even if you know "how", this is still wasted time on your part. These are solved problems. Particularly when it comes to security features like CSRF, relying on yourself to implement it sounds like a major footgun opportunity. When you use a framework that has this built in, you have to try really hard to bypass these security features. You barely even have to think about how to implement it.

by XCSme 5y ago

castis 5y ago

> Why should I consider Laravel If you work on all those projects alone, and you're happy doing this, you probably wouldn't. You aren't the target market for a framework like this. Laravel (and any good framework, really) is for people who want a consistent dev experience _with good documentation_.

XCSme 5y ago
Yes, I do work alone on those projects, but I do use frameworks on the frontend-side as I find them to help in the long term, not hinder the projects as PHP frameworks do (a lot of boilerplate). It makes sense that if Laravel is strongly-opinionated to result in a consistent dev experience, but is a consistently bloated dev experience better than an inconsistent lean one?
- colecut 5y ago
  Bloat can be mostly ignored, inconsistencies can not.
unfocussed_mike 5y ago
> You aren't the target market for a framework like this. I don't know about this. But then I am of an age where I consider myself to be a team of programmers separated by time. There are the younger, less easily tired versions of myself who thought this was a great idea for a career and lived on takeaway curries, there's me, and there are the four or five older versions of myself who will hate me for trying to be clever and not trying to be consistent. Laravel helps me take on projects that allow me to hand off pieces of work among my team ;-)

gnarcoregrizz 5y ago

For me, its about the higher level things included. I don't want to write a queue, event system, or cache layer again.

momenti 5y ago
Though for a small-ish site (say <150 users), such techniques are typically not necessary.
- XCSme 5y ago
  The PHP apps that I have created handle millions of monthly users without issues, so I would say that probably specific techniques are needed more to implement a given functionality instead of to achieve a better performance.
XCSme 5y ago
That makes sense, there are probably some more complex use-cases, but for those I would personally not use PHP (e.g. if real-time communication is required or linking together many microservices and having to do operations that involve more than a database and file system).

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)?

bluedino 5y ago

Self-made frameworks are great as long as: They work. If they are full of bugs they are a pain They are complete. If they are missing parts because they weren't needed yet, they are a pain They are documented. Documented well is a bonus There isn't a self-made framework for every project at the company The person who made the framework is still around The person who made the framework didn't also make v2 and v3, mixing them in the same project

XCSme 5y ago
My point was more that PHP is more of a framework-less language, as most of the functionality needed for a basic web application is built-in (file-based routing, secure PDO database access, external libraries for specific functionalities like PHPMailer for sending emails). I think that if you need something a lot more complex than this (realtime communication, processing data in separate threads, linking microservices), then PHP is not a good choice.

munk-a 5y ago

I wouldn't consider Laravel for this use case - I might consider either Laminas or Symfony though since those two frameworks allow you to pick and choose which features you actually want to roll into your project. If you'd like to simplify your routing files but otherwise leave everything else the same - Laminas and Symfony can do that trivially. If you find yourself forced into an ORM due to needing to support multiple SQL dialects, Laminas and Symfony can also do that trivially. Laravel is a sort of all-in option that tends to perform worst when integrated into a legacy project - it isn't completely overbearing (it won't creep into absolutely every file you're using) but it will end up requiring changes to a lot more files than is reasonable.

e12e 5y ago

Sounds reasonable. (how) do you do testing (unit test and integration tests)?

XCSme 5y ago
I don't do unit tests (tried it, it was slowing down development too much). I did have integration testing for a while for the core functionality, but in the end that was not helping much either, and after releasing a new version of the app I deleted the tests and (after 2 years) still haven't written new ones, without any bad consequences so far. I deploy a new version to a beta branch, test it myself for a few hours/days (as I do use the app myself daily), then publish it live. Customers gradually upgrade to the new version and if anyone encounters an issue they let me know, and I fix it ASAP, but it almost never happens. Also, the app is pretty complex, so writing tests for every use-case and environment is impossible. I am not a big fan of writing tests when working in a small team (<5 developers). I did work on some pretty big projects that turned out great and very robust, without having written any tests. That being said, if I ever have the time and am bored enough, I will write some integration tests, but mostly for the installation part of the application, not for the usage part.
- tomschlick 5y ago
  > Also, the app is pretty complex, so writing tests for every use-case and environment is impossible. No, you're just using the most expensive / error prone testing methods: doing it manually.
  - XCSme 5y ago
    Maybe my comment was not clear, I do not specifically test the app and all its functionalities. I use the app myself on a daily basis anyway, which acts like a sort-of continuous integration testing program. I use the new version myself for a few days before publishing it, or provide it to some chosen beta testers that use the product anyway.
    - tomschlick 5y ago

dabernathy89 5y ago

There are lots of reasons someone like you might benefit from a framework, but this one jumps out immediately: > I already know how to implement core functionalities when needed (e.g. CSRF, user permissions) Even if you know "how", this is still wasted time on your part. These are solved problems. Particularly when it comes to security features like CSRF, relying on yourself to implement it sounds like a major footgun opportunity. When you use a framework that has this built in, you have to try really hard to bypass these security features. You barely even have to think about how to implement it.