Yes, I agree. But if you want to do some form of dynamic rendering and not static rendering HTML only is not an option. PHP matches HTML pretty well.
1,022 karma · joined October 29, 2020
> `#[foo` used to be legal PHP 7, but is illegal in PHP 8).
So it is not a comment in PHP8 then.
You can meet people fresh out of university telling you that PHP is bad even though they have never written a line of PHP. They just know.
This is quite bad for the industry as a whole, because it plays right into large companies that is pushing their technology in an effort to subvert web.
It is the magic part that is the problem, regardless if it is the framework or your own code that it is doing it.
If number of potential users of alternative operating system is less than 1 percent, then that hardware will never be produced.
It is quite telling how far stagnation has gone when the latest and greatest operating system can basically do the same stuff as one from 13 years ago.
In the end of the 90s on my Pentium machine I had Windows 98 with 10 mbit LAN, web browsing, instant messages, code editor, word processor, spreadsheet application, video player, music player, image processing, content streaming, 3D accelerated games etc (on slower hardware).
The two major differences since then I can think of is that increased quality of media (images, videos, music etc) and interoperability, it is usually easier today to share documents and the like between different platforms.
Sure, there has also been improvements with system security and system stability, but neither of them adds to user workflow and productivity.
I tried Windows 11, but I had to go back to Windows 10, because I couldn't keep my old workflow, a workflow that has existed since Windows 95.
My own first computer that I bought for my own money, a Commodore 64, on that you just powered it on and started coding in BASIC.
Rewrites rarely succeeds, it is a typical fallacy for a team to believe that their problems lie in the language they are using and not in themselves. Seen it too many times.
I can have fullstack that is better than a specialist. Specialist only means that they have specialized in one part of the architecture, that doesn't necessarily mean that they solve problems particular well, that depends on the skill of the developer.
And the point is that even if they do have more skill within that domain, total overall domain can still suffer. Many SPAs suffer from this, each part can be well engineered but the user experience is still crap.
If your developers is lacking in skill, then you should definitely not split them up into multiple teams. But again I'm talking about organization in general, that splitting teams has a devastating effect on organization output. Difference in culture will make it harder to move between teams, thus the organization will have much more difficult time planning resources effectively.
BFF is all about reflecting the need of the client, but the argument was the a generalized API is better because of re-usability. The reason why you split into multiple BFFs is because the workflow isn't the same, it differs a lot between a web client and a typical app. If the workflow is the same you don't split, that is why I wrote BFF per client type, a type that has specific workflow (need & requirement).
> This is a case by case basis on the product.
Of course, it was an example.
> That sounds terrible, and very OO. I'd rather generate another client for my openapi documented API, in whatever language is most appropriate for that client
I'm talking about the server here, not the client.
> That's a stretch, if I need a form, I likely need the same data if I'm on iOS, Android, native, or web. Again it's about execution of a workflow.
But the authentication and redirects will probably be different, so you can reuse a service (class) for updating the model, but have different controllers (endpoints).
> Yes, those API are not being designed correctly
Every generalized API will have that problem in various degrees, thus BFF.
> Yet ORMs are tools of generalists.
Oh, you think a fullstack is generalist and thus doesn't know SQL. Why do you believe that?
> That depends a lot on how the orm is being used.
Most ORMs, especially if they are of type active record, just misses that mark entirely when it comes to relationship based data. Just the idea that one class maps to a table is wrong on so many levels (data mappers are better at this).
ORM entities will eventually infect every part of you system, thus there will be view code that have entities with a save method on, thus the model will be changed almost from everywhere, impossible to track and refactor.
Performance is generally bad, thus most ORMs has an opaque caching layer that will come back and bite you.
And typically is that you need to adapt your database schema to what the ORM manage to handle.
> We literally write clients for APIs we don't own all the time,
The topic here is APIs you control yourself within the team/organization. External APIs, either that you consume or you need to expose is different topic, they need to be designed (more). The point is internal APIs can be treated differently than external ones, no need to follow the holy grail of REST for your internal APIs. Waste of time.
But even with external APIs that you need to expose they can be subdivided into different BFFs, no need to squeeze them into one, this has the benefit that you can spend less time on overall design of the API, because the API is smaller (fewer endpoints).
> That's what a client is...
I'm specially talking about server architecture here, the client uses the adapter.
Framework solves a general problem, but we try to solve a specific problem, thus it will always be a mismatch, frameworks usually solves that with a combination of magic and opaque abstraction layers.
Frameworks works best for short running projects, long running projects tend to outgrow the framework.
Prefer libraries over frameworks.
Yes. I’m generally against specialization and splitting teams. This of course depends on what type of organization you have and how complex the frontend is. iOS and Android is usually complex as it is so they are typically specialized but I would still keep them in the team.
Specialized teams not only creates synchronization issues between teams but also creates different team cultures.
What this does is that it induces a constant time delay for everything the organization does. Because teams no longer can solve an entire feature the organization instead spends more time on moving cards around in the planning tool of choice. The tiniest thing can require massive bureaucratic overhead.
Solutions also has a tendency to become suboptimal because no technician has an general overview of the problem from start to finish. And it also quite common that the same problem is solved multiple times, for each team.
By making BFFs specialized, instead of the teams, you don’t need to spend time to create and design a generalized API. How many hours hasn’t been wasted on API design? It adds nothing to customer satisfaction.
This also means that you separate public and private APIs. External consumers should not use the API as your own web client.
Specialized BFFs is not only to have a good fit for the client consuming it but it also about giving different views of the same underlying data.
E.g assume we have an article with multiple revisions (edits). Handling revisions is important for the Admin API but for the web client that serves the final version of the article not at all, it shouldn’t even be aware of that the concepts of revisions exists.
Creating a new a BFF is as easy as copy&paste an existing one. Then you add and remove what you need.
The differences between BFFs is usually how you view your schema (GET). Writing to your model (POST) is likely shared because of constraints.
What is then different views of the same data? An SQL query (or VIEW). Too many APIs just maps a database table to an endpoint 1:1, those APIs are badly designed because the consequence of that is that the client needs to do an asynchronous HTTP JOIN to get the data it needs, very inefficient.
By writing SQL to fit your BFFs you will then realize that the ORM is the main problem of your architecture, it usually the ORM that creates the idea that you only have one view of the same data, one table to one entity. But SQL is a relationship model, you can’t realistically express that with 1:1 only.
By removing the ORM you will also solve the majority of your performance issues, two birds one stone scenario.
Ownership of a BFF should ideally be by the ones consuming it.
iOS and Android can usually use the same BFF, they don’t differ that much to warrant a new BFF. If there are any differences between the two, give them different endpoints within the same BFF for that specific use case. When designing APIs one should be pragmatic, not religious.
BFF is nothing more than an adapter in hexagonal architecture.
And just because you serve HTML doesn’t necessary mean that you backend code is tightly coupled with the view code, HTML is just one adapter of many.
A boundary doesn’t get better just because you slip a HTTP barrier in between, this is the same type of misconception that has driven the microservice hysteria.
Example on improvements
1) auto-escape output - one of the biggest reason not to use PHP for templating is that you need to manually escape your strings to avoid XSS, whereas a dedicated templating library can do this for you. This could be done with a either a special opening and closing tag or let you register a tag hook.
2) today you can use the alternative syntax for if, while, for, foreach, and switch
https://www.php.net/manual/en/control-structures.alternative...
This could be expanded for match expression, closures, and other block expressions.
3) custom HTML tag support, register a HTML tag like <my-form> and implement it thru an API, perhaps a class that implements an interface. And now you can do much better reusable components that can automatically close them selves instead of multiple calls.
e.g instead of
<?php open_form() ?>
<button type="submit">Buy</button>
<?php close_form() ?>
<my-form>
<button type="submit">Buy</button>
</my-form>
And it would be easy to share these custom components on github with composer.
ORMs invites you to write bad code, instead of thinking ahead of what queries I need for this specific operation, you just start writing ORM based code aimlessly and try to make it work with the tools available in your language of choice.
And the ORM entities will eventually infect every part of your project and it will almost be impossible to remove them after the fact.
The drawback is that there is usually relatively little information outside of the forum and uncommon that code is shared on things like github, instead code sharing is typically done by copy&paste on the forum, which makes it a bit harder to track and standardize conventions.
If you use a framework then try to write all your own code outside of the framework and pass in all needed framework data as arguments to your own classes/functions.
Your solution works, but unfortunately not something that has any community support. I proposed something similar a year ago but use classes instead because classes seems to be the internal building block in PHP.
For both our solutions is would relatively easy to add a shim to older PHP versions.
module.php
<?php
return new class {
public const MY_CONST = 47;
private const MY_PRIVATE_CONST = 127;
// with PHP 8.1 you also have readonly properties
public string $myPublic = 'foo';
private int $myPrivate = 17;
public function helloWorld(string $name): void
{
echo "Hello, World {$name}!";
}
};
<?php
final class ModuleException extends Exception {
}
function module(string $name): object
{
static $modules = [];
if (isset($modules[$name])) {
return $modules[$name];
}
try {
$module = @require $name;
} catch (Error $error) {
throw new ModuleException("No such module {$name}", 0, $error);
}
if (!is_object($module)) {
throw new ModuleException("Module {$name} is not an object");
}
$modules[$name] = $module;
return $module;
}
$my = module('module.php');
$my->helloWorld('Module system');
$other = module('module.php');
assert($my === $other);
I also recently downgraded from Windows 11 to Windows 10. Windows 11 was just too intrusive and many non-configurable features. Windows 11 is also slower, has more bugs and more unstable than Windows 10.
I'm guessing that we need to abandon Microsoft's products when Windows 10 reaches end of life, not something I looking forward too because I'm not a big fan of Linux desktop nor the Mac desktop.
And why would a good programmer agree to suffer to the whims of a Professor that is clueless about programming even if the domain itself is important and interesting?
Difference is of course that most software engineers work on some commercial project with relative little effect on the world politics, and not bleeding edge science that affects current world politics, thus it ought be higher requirements for scientific computing than commercial computing.
Sweden enacted in 1938 (Saltsjöbadsavtalet) a treaty where unions, employers and the government came to an agreement that agreements between unions and employers should be done without government interference. Instead of conflict try instead to find common ground where both parties benefits.
It is of course far from perfect, but I think it is still better than the alternative.
And you should use your database to its full capabilities, including vendor specific queries, otherwise you are just wasting computation. Becuase of this I don't even use query builders anymore, just raw SQL.
if (article > 0)