5 ms·

Nearly every time I see PHP projects like this, I find massive security vulnerabilities combined with extremely brittle functionality. Sure, this describes man

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?
        unfocussed_mike 5y ago
        Generally I use the model builder methods for this anyway, because I'm using the ORM and the models represent tables, so I barely ever build my own select statements at all. https://laravel.com/docs/8.x/eloquent https://laravel.com/docs/8.x/eloquent
        XCSme 5y ago
        Even with an ORM, isn't there the risk of typing Flight::select('name') instead of Passenger::select('name'), if both values return the same data type (string)? Is that harder to do than accidentally typing `SELECT name FROM flights` instead of `SELECT name FROM passengers`? Aren't most of those issues found as soon as you first test the feature?
        unfocussed_mike 5y ago
        I don't understand the point you're getting at here. Isn't this kind of typo more or less universally possible? Which code library or generator can protect you from errors like this (and divine your intent?) You can be protected from SQL injection and you can have various other query operations, and you can gain refactoring support (e.g. by telling the models the new table name), or you can add custom scopes that encapsulate transformations on the query. Laravel also allows you to express model relationships, so Flight might have: public function passengers(): BelongsTo { return $this->hasMany(Passenger::class); } and then you can do things like: $flight->passengers->where('name', 'like', 'XCSme%'); > Aren't most of those issues found as soon as you first test the feature? I don't know. The thing is, an ORM brings you other stuff (like a query builder integration) that allows you to construct queries without having to glue SQL strings together (and chain and pass query objects). And Laravel separately also brings you a migration tool that allows you to encapsulate upgrades to your database as code snippets (so you can put code live without manually fiddling with SQL at all). In my experience even really small apps benefit from this at some level. The discipline of using regular patterns like this is really useful. (The Lighthouse GraphQL binding is where this stuff gets really interesting) At any rate, we're unlikely to agree. [edit: removed a tired-brain word choice mistake!]

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?
      - unfocussed_mike 5y ago
        Generally I use the model builder methods for this anyway, because I'm using the ORM and the models represent tables, so I barely ever build my own select statements at all. https://laravel.com/docs/8.x/eloquent https://laravel.com/docs/8.x/eloquent
        XCSme 5y ago
        Even with an ORM, isn't there the risk of typing Flight::select('name') instead of Passenger::select('name'), if both values return the same data type (string)? Is that harder to do than accidentally typing `SELECT name FROM flights` instead of `SELECT name FROM passengers`? Aren't most of those issues found as soon as you first test the feature?
        unfocussed_mike 5y ago
        I don't understand the point you're getting at here. Isn't this kind of typo more or less universally possible? Which code library or generator can protect you from errors like this (and divine your intent?) You can be protected from SQL injection and you can have various other query operations, and you can gain refactoring support (e.g. by telling the models the new table name), or you can add custom scopes that encapsulate transformations on the query. Laravel also allows you to express model relationships, so Flight might have: public function passengers(): BelongsTo { return $this->hasMany(Passenger::class); } and then you can do things like: $flight->passengers->where('name', 'like', 'XCSme%'); > Aren't most of those issues found as soon as you first test the feature? I don't know. The thing is, an ORM brings you other stuff (like a query builder integration) that allows you to construct queries without having to glue SQL strings together (and chain and pass query objects). And Laravel separately also brings you a migration tool that allows you to encapsulate upgrades to your database as code snippets (so you can put code live without manually fiddling with SQL at all). In my experience even really small apps benefit from this at some level. The discipline of using regular patterns like this is really useful. (The Lighthouse GraphQL binding is where this stuff gets really interesting) At any rate, we're unlikely to agree. [edit: removed a tired-brain word choice mistake!]