Episodios
-
Full transcription below.
Some show notes
https://github.com/run-as-root/gitlab-pipeline-templates
https://github.com/mediact/testing-suite
https://github.com/phpro/grumphp
https://github.com/captainhookphp/captainhook
https://github.com/rectorphp/rector
https://github.com/fabpot/local-php-security-checker
https://github.com/GoogleChrome/lighthouse-ci/
https://github.com/renovatebot/renovate
https://github.com/Brunty/cigar
https://github.com/sitespeedio/sitespeed.io
https://github.com/zaproxy/zaproxy
https://github.com/phpstan/phpstan
https://github.com/exakat/php-static-analysis-toolshttps://github.com/jalogut/magento2-deployer-plus
https://github.com/userfrosting/fortress
Transcription
Jisse 0:01
Hey, everyone. Welcome to The Podcast Registry number 2021.5 CI/CD, I guess, right?
Peter Jaap 0:15
Yep.
Jisse 0:16
There are two Dutch guys, Peter Jaap and me. Yes Sir.
Peter Jaap 0:21
Hello.
Jisse 0:21
We're going to talk about Tech stuff, Magento stuff and Oriented for back end developers, I guess. In this episode, we're going to focus upon CI/CD. Basically, maybe an introduction a little bit about what we understand of CI/CD. What it's should be doing? How it fits into our own businesses and etc.? But Peter Jaap you came up with a topic.
Peter Jaap 0:48
I think, actually, you did.
Jisse 0:50
I did already. So, actually, I have to admit that something else is on my mind. So, you notice Swedish Chef, who says like, a bird, bird, bird, bird. Have you heard about the Finnish Chef, who for, who for, who for. It's changing our agenda quite a bit. The new front ending of internet supported by internet. So, who face is on the rise? But we're not going to talk about that. There was the previous episode. Number four was dedicated toHyvÀ. Today, talking about CI/CD. So, what is CI?
Peter Jaap 1:40
What is CI? CI/CD is accommodation of "Continuous Integration" and "Continuous Deployment", those two topics are a lot of the times combined, mentioned in one sentence, CI/CD. But if you split them up, they're actually two parts. So you have the Continuous Integration (CI) part and the Continuous Deployment (CD) part. So, let's start with Continuous Integration. What is Continuous Integration? I'm not going to give 100% correct definition, but I'll say what I interpret SCI and I guess that resonates with most people. Because he was integral part in your code flow, where you integrate all the different lines of code, all the different packages, all this other stuff, you combine and have written yourself into one monolith in most cases and you check, mostly whether it integrates with each other. This could be unit tests, although those are more on a unit basis. So, not necessarily integration but that's usually part of this step and Integration Tests is like, End to End Tests.
Jisse 3:01
The Integration Tests of Magento itself as well. So, kick starting the Integration Testing Framework MFTF (The Magento Functional Testing Framework) for Instance has told a part of it.
Peter Jaap 3:13
Cypress IO is used a lot.
Jisse 3:16
Definitely, yeah.
Peter Jaap 3:18
Stuff like that. So, that's the integration part and then you have the continuous deployment part that's where you actually push code to a test environment or review environment and acceptance environment, whatever you want to call it and eventually to a production environment. So, what's this "C"? Because now we've talked about integration and deployment. So, why is it continuous? It's continuous when you trigger these actions, mostly using pipelines, automatically when there's a commit or attack release. So, you automate this stuff, you don't have to do it manually. And then when the pipeline succeeds, then all the checks have passed and you're fairly confident to be able to put your new stuff live. The main benefit of CI/CD is assurance, more assurance than you otherwise would have to deploy stuff. Because you are supposed to have some rigid testing in place, that almost guarantees that nothing will break when you put it live, if you have set it up correctly. This is a Utopia in my opinion, stuff will still break.
Jisse 4:42
Yeah. I think the burden always is that it's quite an effort to put it all up and make sure that it's functioning. So, what would you say about the costs involved to set up everything properly, compared to actually the benefits in general.
Peter Jaap 5:01
In general, it by far outweighs any cost to set it up, especially now since all the systems have become so much easier. I remember when we set up CI/CD for Magento One like, five, six years ago, that was painful. Magento one didn't really Lint itself. They have supported the building stuff like that. The tools we have now weren't as great. Back then as they are now. There were a lot less people working on it back then. So, it was a lot less support, a lot less blogs, and a lot less general knowledge in general about CI/CD. I think when we first set up our deployment pipeline and our review, our testing environment system, which we'll talk about later, probably, I think I spent like, three or four months, full time on building this setting it up.
Jisse 6:03
Yeah. To me like, well, it sounds maybe that you're much more experienced with this whole stuff than I am. However, as soon as I'm using a looking at my own business. While I'm not busy with projects. I have a couple of projects, but those are my own, then I have extensions, I've micro services, I've got a lot of diversity in there. My tool here is never the same. So, it's all sounds pretty impressive. Seeing you talk about all of this stuff that always comes to the natural.
Peter Jaap 6:38
I always feel the other way around that you know more about this stuff than I do. I always say, with your extensions, I always see you're setting up test environments, Unit Tests End to End Tests.
Jisse 6:50
The funny thing is I guess, it's a totally different thing. So, for all my parts, the testing part is much more important, because I'm focused upon extensions that are reusable in numerous environments. Therefore, I need a certain guarantee, easier to apply with. But that's maybe the continuous integration part. So, the continuous integration part is on my end, pretty important. While continuous deployments, I've got a couple of scripts, doing stuff, making sure that everything just works. So, I think, it's also fair to say that it just depends upon your needs and maybe one of the points that I'm always trying to make with regards to testing but it's also true for CI/CD is that if it's overwhelming at first, to get started, then don't try to equal us. Don't try to complete everything at once. But just start with a minor, simple step and see that step actually catch human error, small little mistakes that are caused by this automation process. And if you do that, once you start to see the benefits, and then you can do it another time and another step and so on.
Peter Jaap 8:04
So, what will be the first step in your case?
Jisse 8:07
Yeah, I think actually, the first step is to guarantee that it goes on the hosting or on the local development environment, it's just managed in a correctly. So, one of the things that I still remember of a couple of months ago is that I have created this Microsoft Office for myself, based upon YAML files, and then sooner or later, I created a little typo in that YAML file. Well, there was no any kind of tooling that prevented that eyeball to go live in production. I only found out about it two days later. The Microsoft Surface was basically debts, but hidden away behind all other micro services and a couple of websites and I simply didn't notice it. I should have called that simply by linting YAML. Now, that could be part of the CI/CD part as well. But it could also be just part of your local community.
Peter Jaap 9:07
What is linting for the audience?
Jisse 9:11
Linting, I don't know the perfect definition but it's basically looking at the syntax of a specific language, just to make sure that it's correct. For instance, if we're focused upon XML. Well, XML is all about opening and closing tags. If a certain closing tag is not there, its bad linting step more complex, of course, we have XML schema validators or XML schema definitions exist ease. So, that basically leads into that you could also check for the schema there. Likewise, JSON, if somebody makes the mistake of during a single growth or a double quote into single quotes, stupid little things like that. So for me, YAML would be that it's actually not perfectly lit. But more of that you simply have a PHP parser that is able to read a YAML file and lead into data originating from that YAML file. I think that's not a perfect definition of linting. But at least it's a good step forward.
Peter Jaap 10:16
I described it the same way.
Jisse 10:19
Basically, with linting, you're much more focused upon the syntax. So that stupid little typos don't end up causing bugs that you don't need to analyze. I think that's one of the more peculiar things. While personally believe that unbelievably annoyed with PHP storm lately, because every time when I'm opening up a specific projects, it's automatically suggesting to upgrades PHP environments, so that if I'm running a project based upon PHP 7.3, it's not only supporting PHP 7.4, which sounds great, but then I end up automatically generating all these getters and setters based upon 7.4 syntax, and then I push it into production and then it fails for some kind of reason. That's maybe also a good point. If you're linting, it's not only that you're linting for the PHP version that you have available locally, but you're also linting it in Deployments, specifically for that PHP version that runs in production. I'm not sure if you're personally use it also in a similar way to prevent PHP 8 functionality from ending up in production with 7.1.
Peter Jaap 11:40
Yeah, definitely. We have a PHP linter, specifically for PHP version. We usually put stop files in our project. In the root of our project dot PHP 7.1, dot PHP 7.2, 7.3, 8.0, 8.1, whatever and then, based on that, it will load the correct PHP linter. We'll check for any methods that are deprecated or not available yet.
Jisse 12:05
Yeah. Well, that's basically something that you could do locally, of course, by using tools like, Captain Hook and Grumpy or GrumPHP.
Peter Jaap 12:17
GrumPHP.
Jisse 12:20
Never sure how to pronounce it. I'm still using it in some projects. So, with me. I'm focused upon extensive developments, little experiments, then the total number of repositories that I'm actively maintaining is about 100 or so. I lose track, basically, of where I've configured what, but it seems like you guys really are rolling out grumpy and other trash for every single project.
Peter Jaap 12:52
Yeah. We've been using GrumPHP for about four years now. We basically have rolled our own. Since a few months, we started using the mediaCT Testing suite. So one of our colleague companies here are falling and they it's on GitHub, it's an open source project. If you install that one, it will pull in GrumPHP, has a few checks. It does PHP stands for static analysis of PHP code, PHP mess detector, which is a piece of software to check for messy code in your PHP stack. PHP unit, it will try to find PHP unit tests on from several known locations and London. PHP code sniffer, which basically checks the coding style we adhere to.
Jisse 13:52
Including the Magenta 2 coding style as well. So, that's set for.
Peter Jaap 13:57
I'm not 100% sure.
Jisse 14:02
It's supporting Magenta 2 but it's depending upon your own configuration, whether you want to apply that or not.
Peter Jaap 14:08
It uses the magenta 2 coding standard from mediaCT. mediaCT slash coding stands for Magento 2. This is I'm pretty sure it's a slightly altered one. It pulls in. I'm just checking it out. It pulls it in from Bitbucket slash mediaCT.
Jisse 14:30
One of the things that I always find harder to manage on a more organized scale is actually that with Phpstan and with Phpcs you always can check for things up on a certain level. So that's within the Phpcs that's the security level and with Phpstan that's, I think, also security.
Peter Jaap 14:54
Yeah also. It goes up to 8 or something or 9.
Jisse 14:56
That's always the question. The thing about phpcs, in combination with the magenta 2 coding standards is that the marketplace, the official marketplace, is allowing for any extension that simply just lives up to security level 10. However, the really interesting stuff is more present there with the lower security levels, so that your own code needs to be compliant to more strict standards. I've got a couple of libraries where I'm sticking with Phpstan level four, which was kind of like masochistic to get there.
Peter Jaap 15:37
We also use love for.
Jisse 15:39
Yeah, exactly. Likewise, theoretically, with Magento 2 the coding standards, it could also be just to in tune down to a lower security level, which is basically that it's stricter. That also the harder the punishment if you do something wrong. Cool. Interesting.
Peter Jaap 16:00
If we have level four, which is basically I think it's good average between safety and looseness. Level zero is some basic texts, and its multiple paths level zero. And then you'll get further along. So, basically, level one Checks Form Magic properties, magic methods and getters, unknown methods, level three is Return Types of a fours, death, goat checking, instance of Jack's death, else branches and stuff like that. And then you go away up to seven or eight, which it gets a lot stricter and harder to fix. It's fun to check where project you are, just start with eight, see how many messages you get and then go down.
Jisse 16:54
Exactly. Keep on fixing things until you give up basically.
Peter Jaap 17:01
Exactly. One more thing we do with immediacy testing suite, we actually have our own, which is based on this one, but we add some stuff. And one of the things we always add is a Git Blacklist, that's also an option in in GrumPHP itself. Where you can put in blacklisted words, basically. So, we put in stuff like dump, var_dump, dd, because we do a lot of Laravel as well. So sometimes that sneaks in. It checks for print_râs without the true argument, it checks for the object manager. Yeah, yes sir. We don't want that in there. We check for we actually have a check for swear words. Luckily, my guys write pretty decent stuff. They never put in any swear words. But sometimes we inherit a project. And then there are all red flags everywhere with some, that's funny. So, that's also a good way to make sure nobody uses the object manager in custom code.
Jisse 18:05
I think the difficulty with all of this would be to configure it to your own needs. So, my personal findings are that sometimes you need to configure a Phpstan in a certain way, with Magento for instance but I'm developing things under Laravel, I'm developing things on Symphony, every time there's a different scenario. Personally, I've always found it overwhelming myself, to just keep track of all the different configuration and the tips and tricks of how I apply them and recently, I found myself actually disabling GrumPHP temporarily because it was just recommending or not allowing me to do any commits. If I was not running the correct PHP version and I was just so annoyed because I needed to fix something.That's kind of like the difficulty that the more you add on top of it, still the more you have to manage. Therefore, my earlier question like, where does this paying off? Well, then I think the bottom line is where it hurts. So, you're doing all of this just to make sure that bugs don't end up on production in short.
Peter Jaap 19:26
Yeah, that's where also CI/CD comes in. We have GrumPHP running locally. It's a GitHub. When you do a Git commit, it'll check these things. If you commit a PHP file, it will only check the PHP linter and the PHP stuff. If you commit a YAML file, it will only run the YAML linter and not all the other stuff. That's great but you can skip it by Passing-N which stands for "no scripts". In that case, you'll just bypass GrumPHP and commit the code anyway. To make sure that code, when it's not as clean as we want it to be, doesn't go into production. We also add these checks into CI/CD pipeline, which cannot be skipped. In that case, our developer can skip it locally, but then it gets onto Gitlab and then the pipeline rule fail. Because there's a swear word in it.
Jisse 20:26
A common question there would be where in that pipeline does the group? I assume that you guys also have Gits strategy, like feature branches and development and no longer Master, but that's called, I don't know, production or something?
Peter Jaap 20:44
Yeah, we renamed it to main. The integration part is in the feature branches. That runs on every feature branch. So, the static type checking the GrumPHP suffer. This tells you about Phpstan, PHP mess detector code sniffer, blacklisted words, linting, pdepend, all that stuff happens in the integration part of the pipeline that runs on all the feature branches. As soon as that gets merged into develop and later on into main. Also, the integration tests for run. And then eventually, when it gets merged into main, also deployment part for run.
Jisse 21:33
One of the interesting things that you just mentioned is like, I'm familiar with tools like a mess detector gold standard Phpstan but then there's also the Phpcpd, sort of copy paste detector but what if your own codes is just looping along perfectly identical to third party extension. I don't know.
Peter Jaap 21:59
How would that happen? Somebody copy pasted code there.
Jisse 22:06
To make this more practical. Did you ever encounter issues where the the pipeline fails because of Phpcpd running into issues?
Peter Jaap 22:18
Yes. But not with third party vendor code. Usually, it's not just with our own code. There's a block here. We needed it somewhere else, let's copy it over. And then refactor later, then forget about refactoring is committed, then Phpcpd complaints like, hey, I see these exact 20 lines here as well. Maybe there's an idea to inherit, or refactor. What's the word, composition?
Jisse 22:48
Composed?
Peter Jaap 22:50
Yeah, that's extracted into a few models of it.
Jisse 22:53
Actually, you're saying that there's a gentle kind, little suggestion to do so. But actually, the whole point is that it's enforced.
Peter Jaap 23:02
Yeah. First, it's a GrumPHP is a locally, it's a suggestion and further down in the actual CI/CD pipeline, when it's in the Git repo then it's enforced.
Jisse 23:14
No. Doesn't that lead into too much refactoring, where actually the refactoring becomes more difficult to understand than the original?
Peter Jaap 23:26
No.
Jisse 23:28
It's also a question that I don't get to answer but as I go along.
Peter Jaap 23:34
I can probably think of a few scenarios where that might be the case. But I think in essence that shouldn't be the case.
Jisse 23:45
For instance, if you create a module in the Magento back ends with an enabled flag, then theoretically, the configuration to XML file, so that's the system dot XML file in the admin HTML folder, would be almost identical with about like, eight lines of codes. So, getting of course also on how strict the copy base directory is tuned.
Peter Jaap 24:12
That's exactly it. You can set copy paste detected to I don't know, free lines and I will complain on every free lines it'll run into but Magento as we all know, is a lot of boilerplate code. It's not that strict. I'm just, I'm just trying to check in the configuration what we have set for Phpcpd but can't find it this quick, but it's from the top of my head, it's about 20 lines, minimum or something.
Jisse 24:38
I'm just also trying to remind me of something. There's always a lot of different tools out there that allow for static analysis. But there's actually this link, or this GitHub repository it is called a Phpmetrics analysis tools, which is just listing up all of those different tools like Phpmd and why everything basically, that we mentioned, but even more like, I'm just looking at for thresh of what used it once in the past and I'm not sure if the project is Gits fan, which is like Phpstan but difference. So, that there's alternatives out there as well. That might be nice to include in our notes as soon as we're publishing these.
Peter Jaap 25:30
I don't know any of those but there has to be multiple of these.
Jisse 25:37
Yeah, exactly and then there's another one that is maybe less important for you guys. But more importantly, on my side as well, Gold Rector. So, Rector, I'm not sure how to define it. But it's kind of like a transformation tool or you could transform things. For instance, I've been only recently working on this, to write my own goals in PHP 7.4 or maybe even PHP 8, share text. But as soon as I'm publishing that code, it automatically transforms, she'll be released as PHP 7.3, just to make it compliant with as many users as possible. I think for a project, that's less relevant, because if a project is running in real life in PHP 7.4, you do want to make sure that the development environment is also 7.4. But from the standpoint of extension development, it's kind of like a cool tool.
Peter Jaap 26:36
You're saying, you're using Rector, not to do upgrades, but to basically do downgrades, itâs like polyfills, it automatically adds in polyfills or something?
Jisse 26:47
No, no, it really just modifies the code itself to become different.
Peter Jaap 26:53
So you write PHP 7.4 code and record will make PHP 7.1 code out of it.
Jisse 26:58
And then automatically branches into gates, or what...
Peter Jaap 27:03
I've only ever used it the other way around to upgrade 7.4 code. I didn't even know we could do downgrades.
Jisse 27:09
Well, it's downgrades and upgrades. In other words, that weird stuff.
Peter Jaap 27:13
Go for it.
Jisse 27:16
In general, yeah.
Peter Jaap 27:18
I didn't know we could go both ways. That's cool.
Jisse 27:22
Apart from that, we began with linting but I just gave a little example for y'all and we talked about PHP but in general, I think linting is just also one of the things you could do locally but also in the in the pipeline. So, CD, it really becomes useful, just to guarantee the minimum level at which the goal should be committed, or should be working. What is that about next?
Peter Jaap 27:53
You were talking about Rector, which is basically if you look at their GitHub page, it says instant upgrade. I thought about instant upgrades of Magento, which is something we've been experimenting with a few weeks. There are two parts of this. It's not just upgrading Magento, but its upgrading composer packages. On GitHub, you have the dependabot, which does automatic upgrades. That doesn't exist for Gitlab, which we use, in a self-hosted environment. But there's an alternative to dependabot called Renovate Bot. We've been implementing Renovate Bot in past few weeks, in our Gitlab instance and that's such a time saver. It's really cool. We make a separate Gitlab project in the group of our clients called Renovate Bot and runs a scheduled pipeline at night, which tries to update all the composer packages it can. We skip the Magento package, because we don't want to automatically upgrade that with Renovate Bot. Renovate Bot tries to update all the other packages within the version constraints you have in your composer JSON. So, every morning, I wake up and then I check my merge requests, because they're automatically assigned by Renovate Bot to the project leads, and in some cases, that's me and I check the change log, it automatically creates change logs with links to the Compare on GitHub. Then I can click on those, scroll through the code, see what changes and if I think it's safe enough, then I'll merge it or I'll check it out locally and test it locally. So, the first time we did that, we got about 40, 50, 60 merge requests per project. That was a lot to get through. But once you've done that initial batch, it's really easy to keep up with it, so you don't have to keep track of which packages are updated in mean time, you stay on a continuous update cycle, you don't do it every once in a while. So, it feels great to automatically update those little packages and have little fixes, processed pretty much every day. Because if there's a small fix, and it's a batch version for any of the PHP composer packages that are upgraded and it's a patch one and I look into the change log in, it's a minor code change for some fix or whatever. I just click merge and the CI/CD does the rest. It's excellent, it's safe to upgrade check sort of it's still compliant for compiles. And if it does it, just push it live. So, that's been a great time saver for us. Also, when you actually get to upgrading Magento, you basically only upgrade Magento and the dependency that it has not all of the packages, you should have been updating along the way, because that's already being done by Renovate Bot.
Jisse 30:01
You mentioned that you don't want to do the upgrade itself with Magento itself. So, that's kind of like common sense in the current state of the ecosystem like everyone else. But why? It's simply because Magento is then sometimes rolling out goals that is known to break stuff. Its sounds a reality that should change.
Peter Jaap 31:23
Yes, that's true. But that's not entirely Magento fault, that's because we do all of the Magento agencies and you, do a large part of our job is customization. So, you customize based on what you have on the latest Magento version. If a new Magento version comes out, and something's changed, like interface, or implementation, which you did a plugin for or whatever, it'll break. There's no way to automatically safely automatically upgrade Magento. There always has to be a manual check for stuff. We don't want to upgrade magenta automatically because there's no way we could safely merge it. So, there's no sense in it automating that.
Jisse 32:05
But that doesn't that count the same for third party extensions as well.
Peter Jaap 32:12
Sometimes yes, if you do a plug in on a third party extension.
Jisse 32:18
You didn't bump into issues there yet.
Peter Jaap 32:22
No. Not yet. We are assigning merge requests to the project lead and project lead usually knows where modifications are being done. So, if they know like, for instance, we have Algolia and some projects, Algolia is sometimes there's major updates in there Magento 2 extension. So, we know to be careful with an Algolia extension because that usually breaks stuff.
Jisse 32:44
It's more on per basis that you know about which packages could easily be managed this way and which not. Personally, I am eager to also implement this because of my other business case being that I want to be loved my extensions to be checked continuously with whatever updates are available. Actually, I would include Magento updates automatically as well, because then I want to know whether the current sources that I shipped with my extension are actually working together with the greater parts of Magento as well. Yeah, that's really cool.
Peter Jaap 33:27
That's really cool. Another thing I just mentioned, we don't do automated Magento upgrades for Renovate Bot. That's true, but we are trying to do automatic Magento upgrades with our own pipeline. That's the Magento auto upgrade pipeline we're developing right now. What that basically does is when we create a new branch called Upgrade-{Magento version}, so let's say, upgrade-2.4.2. Whatthen will happen is a pipeline will be kicked off that does a composer update magento/project-community-edition:2.4.2 --no-update and then run a composer update. This will automatically try to update Magento and if composer runs into dependencies, it can't resolve at that point, the pipeline will fail and we'll know, we will have to update some of the features restraints on the packages or emotional packages or relevant.
Jisse 34:26
To check up on something manually because that the upgrade fails and there's a reason. Yeah, cool.
Peter Jaap 34:33
In that case, we just do a Git checkout of that branch, added the composer JSON and then push it again then the pipeline will again start and we'll try to do a composer update if it succeeds, it will commit the composer log file to that branch. So, we'll have an updated Magento composure package. But at that point, Magento will most likely break something and that's why we use in the pipeline, we use the ampersand patch helper. The magenta to upgrade patch helper. We've talked about this one before, I still think it's underused. I want to point people towards it one more time. But that runs automatically in the pipeline. It will give you an output of all the files that have been changed in the meantime, and which of your customizations, touch those files, and then we'll give you a list. And then you can walk through that list or actually the pipeline creates an issue and assigns it to the project lead with all the things they need to check. When they check that they can update the pipeline again, and then as well run some checks. Eventually we'll be able to move that into development and into main. We'll semi automate the Magento upgrade. We don't have to do a lot of manual stuff.
Jisse 35:55
Cool. That's basically leading into educated upgrades. Magento, with much more confidence. Did you guys already use this for 2.4.2, the latest release?
Peter Jaap 36:01
Yeah. It's just as easy as somebody creates a branch named upgrade to 2.4.2. Click Create Branch and then wait a few minutes and then in our Slack will get a notification whether it failed or succeeded and then we know what to do.
Jisse 36:15
Yeah, exactly. There's also like, we mentioned earlier that the testing could be part of the story as well. Unit Testing, Integration Testing, but also End to End Testing. But then for End to End Testing, you also need to have a domain name, Temporarily Domain name, Temporary Domain name to access the site under. If things would fail, without upgrades, would that instance be still available, somehow? No, not in this automated way.
Peter Jaap 36:46
No, it won't get there. First, we do the all the checks in they will do to build stuff. Once we get to the deploy step. This is a review environment, then we spin up a Kubernetes cluster on Google Cloud Platform, then we use Docker containers to push the Magento site there and then we use the Digitalocean API to create a DNS a record for our development domain, and it will attach it to the IP we get from Google Cloud Platform, then it will generate a random admin user and password. Once that all done, we'll get a Slack notification in the in the clients channel with this information where we can reach debrief your environment.
Jisse 37:43
Basically, this is already touching upon deployment. So, that of course, the CD part that we're slowly leading into. Maybe it would be good to sum up also, that of course, there's Deployer Plus. To my understanding it is right at this moment, the most popular tool to deploy Magento sites. And other people are using still Capistrano. But personally, if you're using Capistrano, my advice would be either you're a Ruby developer that loves Capistrano or you're a PHP developer that doesn't know about the Deployer Plus.
Peter Jaap 38:26
That were we like five years ago, we ran it to Capistrano, implemented it, then later found Deployer. Luckily, Deployer is basically a Capistrano clone. So, we didn't have to change a lot. It's just the runtime changes, but the output and the folder structure stay the same.
Jisse 38:47
Deployer Plus, for those people who don't know, it's just a variation of Deployer(Deployer). Deployer is also kind of like in the in the symphony Laravel, ecosystem pretty large. Well, that there's also a layer. So there's different deploy. But in general, the PHP deployment tool of choice is Deployer, but then on top of it, there's Deployer Plus created originally by Jellow Good.
Peter Jaap 39:19
Jalogut.
Jisse 39:23
Yes, one Alonzo and I'm not sure if you know about pulling a Juan.
Peter Jaap 39:28
Pulling a Juan?
Jisse 39:29
Yeah, that's basically your reference. If you're going out for a wild night after some kind of meet Magento conference, together with somebody named one, and then the whole group is leaving, when one is actually through the toilets. Maybe look for the party, like hours later. That's pulling a Juan.
Peter Jaap 39:53
All right. I need to do that post-Corona.
Jisse 39:57
Exactly, yeah. But anyway, one just created the jelly goods or created Deployer Plus, and I guess he's still maintaining it, then there's not a request anymore. But anyway, that it's a wonderful tool and why? Because you're using it, also because of the file structure of the Deployer Plus.
Peter Jaap 40:19
Actually, we're not using Deployer Plus but that's more of a rendant when we started using Deployer Plus wasn't built yet. We along the way, we created our own Frankenstein Deployer Plus but one made a much more concise and more generic solution of this. So, one of the thing is on my To Do list is to switch to Deployer Plus instead of our Deployer Frankenstein creation.
Jisse 40:46
Was also personally my favorite is actually that there's always a specific needs. In the past, I've customized my own deploy PHP scripts, and a couple of other indications of how things are being organized and simply just looking at the organization, the goals of others, trying to improve my own version. It's just that it's open source. It's based upon deploy PHP and there's reasons why it's more elaborate than just using deploy PHP but I think also it's not for everyone. I don't know like, there's specific choices being made with organizing all of the different files. I forgot a little bit like, what kind of issues I heard about this in the past. But while, my personal take is that deployment in general, but also, therefore, CI/CD is always something that needs to be customized and you don't necessarily need to stick to a tool like Deployer Plus, just like you guys also created something similar in the past as well. That's my main points. It's all gravy, freedom of choice.
Peter Jaap 41:58
Yeah. But as long as there are provisions built into your sidestep the default route, like to buy a plus has.
Jisse 42:11
The rest of the deployment step, basically comes up with compulsory installation, static content deployments. The compile also included there and then actually, the deployments itself. Any comments there, like what is specific in your own CI/CD pipeline or CD pipeline actually?
Peter Jaap 42:37
Compared to Deployer Plus not much, I don't think so. We used to do a Git pull. The Deployer will log into the proxy server and do a Git pull on the Git repository there. But we don't want the Git repository to be there, because we want the files on the production server to be read only. So, we move to push only approach where we create an artifact in the Gitlab pipeline and our sync it to the production server and then extract it there and then make the files read only.
Jisse 43:14
One of the things that needs to be done as well during deployment is, if needed, turn on the maintenance mode, run all of the setup upgrades and turn off automated maintenance mode again. I've been tracking their 60 for a couple of projects, where I simply encountered that the setup upgrade was run every time again and again, as if, with every upgrades of composure, there were still too many modules being upgraded by simply incrementing. Their setup underscore version tag in the module dot XML file, while was actually not needed. What is your current experience there? How often is the setup upgrades actually enforced by the whole upgrade system? While it's actually not really needed, simply because people make mistakes with that set perform, I don't know.
Peter Jaap 44:08
I don't know. I've never checked. When we setup DB status was introduced in magenta 2.2 point something. We implemented that and I've never actually checked whether it does too much a little.
Jisse 44:26
I've been implementing it myself. I've just been noticing that looking better back at the deployment logs, I'm seeing actually that there's a certain downtime, simply because that maintenance mode is needed because setup content-deploy status is just reporting that there's something changed and that actually leads into sometimes well but depending upon your setup but eight seconds or 20 seconds, even of downtime, while the whole goal is of course that we have zero downtime.
Peter Jaap 44:59
I've never noticed that. I've never noticed excessive downtime or unexpected downtime while we weren't expecting it. But we do I'm just looking at our stats, we did over 50,000 pipelines last year, I think of which, I don't know, maybe a quarter of those are deployments. So, we do a ton of these because it's so easy and we're fairly certain everything goes right when we started deployment. So, we do it on a Friday afternoon, what do we get? We do a ton of them. I actually never checked but we've never noticed any excessive downtime.
Jisse 45:36
No, it's only something I started to notice, as soon as I've added to my own deployment scripts, to add a little bit of a timestamp before the maintenance mode is turned on and after the maintenance mode was turned off again. It struck me that basically the 1/3 of the times that I'm actually deploying, the upgrade scripts are taking more than they're needed. So, there's actually an upgrade of the database happening. While I was personally just expecting that I just upgraded a couple of modules and my personal belief in there is also that there's a couple of modules that are using their own set up recurring scripts, so that they're actually doing something pointless with every single upgrade that you do. One of them is something I've already tracked down the Magento New Relic module. So, that's hooking into the recurring face, so that every time that you're running setup upgrades, it's kicking off its own thing for reasons.
Peter Jaap 46:41
We don't use New Relic, so we never, we always accepted. So, we can use it.
Jisse 46:46
Maybe good. Then what else is there actually to consider with CI/CD?
Peter Jaap 46:55
After actual deployment, we run a few sanity checks. That's our latest step. That's part of the process. Some performance testing, we kick off a lighthouse check. To check the lighthouse course, we do site speed delay, to check site speeds, we do a smoke test using Cigar that reads out a Cigar JSON and the project route that will check as some predefined URLs and their status coded returns and our second to last step will be security checks. So, there we do the PHP security track checker from Symphony or that used to be the row for security advisories.
Jisse 47:34
I've been using row for quite some time, but then it got replaced. I keep forgetting about it.
Peter Jaap 47:42
Yeah, it's deprecated. Now it's not the fault local PHP security checker. So, that checks for whether that are known composer packages in your system that are compromised, that have some abilities and we do, wasp check. The zap, wasp zap. That checks for a bunch of rules on server, service security and cross site forgery request checking. All kinds of stuff.
Jisse 48:09
Interesting, maybe sooner or later to just dive into security on its own, which is always like an in depth topic.
Peter Jaap 48:17
We need to get to latch on. If I'm forgetting one step, by the way, the last step in our case is report check. All these tools have an output, obviously and we combine these outputs into a little website generates it and we put that up and get lab pages. So, there's a link, the clients can check or we or developers can check to see all these reports.
Jisse 48:42
Yeah. It's just a large tree of different steps that you need to take just to make it to the old success, so that's also why we're sharing stuff like this. Slowly, we should be ending the podcast. It's always getting late with this guy.
Peter Jaap 49:05
I think we skipped about half of what we wanted to talk about there's so much here.
Jisse 49:08
That simply leaves room for version six as well.
Peter Jaap 49:14
Yeah, in a few episodes, we'll do see CI/CD part 2.
Jisse 49:19
The left overs, but babies still really interesting stuff. Awesome, little listening. We'll be sharing a lot of the different links with the public later on as soon as the podcast is being published, right?
Peter Jaap 49:37
Yep.
Jisse 49:40
Any final comments?
Peter Jaap 49:44
Nope. Live long. Live long and prosper. Feel the CI/CD pipeline.
Jisse 49:51
That's awesome. To the listener, I hope you found it interesting and hope you learn something about it. We're open for debate as well on any of these toolings that we mentioned. It's sharing and caring and let us know your own thoughts as well. But thanks for listening. I hope to see you all back to have us listeners for the next episode on, I don't know what but something interesting.
Peter Jaap 50:20
We'll see.
Jisse 50:22
We'll see.
Peter Jaap 50:22
All right, thanks.
Jisse 50:23
Thanks. We'll see you.
Peter Jaap 50:25
Bye.
-
Full transcription below the show notes
Show notes
We talked primarily about https://hyva.io/
Some other links we mentioned along the way:
https://tailwindcss.com/https://github.com/alpinejs/alpine https://laravel.com/ https://laravel-livewire.com/ https://reactjs.org/ https://vuejs.org/ https://angular.io/ https://jquery.com/ https://knockoutjs.com/ https://github.com/magento/pwa-studio https://github.com/SnowdogApps/magento2-alpaca-theme https://www.shipperhq.com/enhanced-checkout https://github.com/SnowdogApps/magento2-vue-checkoutFull transcription
Jisse: Hi, everyone. Thanks for tuning into the registry number four. Oh, and I made a little bit of mistake actually while starting because we were supposed to start in Dutch. So my accent is going to be very, very Dutchy.
Peter Jaap: Very Dutchy?
Jisse: Very Dutchy. And Peter Jaap?
Peter Jaap: Hello
Jisse: Hello. And Willem Wigman.
Willem: Hallo
Peter Jaap: Willem Wigman.
Jisse: Yeah. So The Registry, the podcast number four. And I had to ask Peter Jaap before we started, because I simply lost track. It feels like we have been talking about nonsense for ages already.
Peter Jaap: It is only four? I thought it was 14.
Jisse: 42, yeah.
Peter Jaap: 42
Jisse: But yeah, so the format is a little bit different. Instead of boring all of the listeners with two Dutch guys talking, we thought we can do better. So there are three Dutch guys. One from the middle of the Netherlands, so that's me. One from the North, that's Peter Jaap, and one from the South, that's Willem. So hi, Willem.
Peter Jaap: The deep South.
Willem: Hallo.
Jisse: Yeah, thatâs the accent.
Willem: Yeah. I come from the warm place in the Netherlands.
Peter Jaap: That's why you're the only one without a sweater. I get it now.
Willem: Yeah.
Jisse: Yeah. So in the South, it's about 0.01 degrees warmer. So indeed, itâs quite a difference.
Willem: Yeah, climate--
Jisse: So thank you, Willem, for joining us.
Willem: Thanks for having me.
Jisse: Yeah, we came to this conclusion that it might be nice actually, to have you talk a little bit about the new thing that you've created. And I think a lot of the listeners will know about it but yeah, there was actually almost no attention for it during ReactorCon, and nobody asked you to do any kind of podcast or interview ever since. So actually, from the community, it was just dead silence. And we felt it was time for a change, right?
Willem: Yeah, I would like some change as well. That's been kind of the headline of what we've been doing. Yeah, and certainly not enough attention.
Jisse: Yeah. And so the obvious start always is with what it's called. So the name is Hyfa, hoofa, hufter⊠So what is the real pronunciation? Here we go.
Willem: Huva.
Jisse: And that's Swedish?
Willem: Itâs Finnish.
Jisse: Itâs Finnish.
Willem: Finnish, yeah.
Jisse: Itâs finished.
Willem: Itâs Finnish, yeah. People are going to have a hard time recognizing where it's sarcasm and where we're being serious. They're used to it from you but maybe from me, it's new. But to say the first serious thing here, Hyva is Finnish, and it means good, desirable, and trustworthy. So it has a lot of positive meanings and Finnish.
Jisse: Yeah. And I think in general, do we want to make sure that people get the memo? Could you maybe describe Hyva in a few sentences?
Willem: Yeah, sure. So as a lot of listeners might well be aware of Magento 2 front end has been kind of an issue since Magento 2.0. Arguably, before, a little bit as well, but especially since Magento 2.0. The whole knockouts require jazz front end has been a pain to work with. It has become a bigger and bigger problem to have it performant and score well in Google. And it's just as a developer, it's no fun at all to work with. Magento has decided that the solution for this is not to fix the front end but to replace it. That's PWA Studio and headless. So there's a lot of PWA solutions now that will replace the old Magento 2 front ends but none of those solutions really suited me and I guess I can say the agency Integer_net where I work.
Also didn't feel at home with the new solutions that are currently being provided, and we don't really believe in the whole PWA heavy JavaScript framework solutions. And so what Hyva is, to just round it up, and then I'd be glad to take your criticism already. So Hyva is our attempt to fully replace the old Magento 2 front end, which is still PHP, HTML, CSS based. It's fully server-side rendered, and you could say it's the current Magento front end redone in a good way. So it's performant, it's less complex, and it's fun to work with. And speed in which you can develop things is much, much faster than what we've seen with the old front end and what we've seen that PWA currently offers.
Jisse: Yeah. Well, and I think Peter Jaap and I, we both know a little bit more about Hyva as well. We've seen the ReactorCon presentation that you ran there. And in general, could you say also that the real innovation of Hyva is that you simply just dump all of the JavaScript and write it into as less JavaScript as possible?
Willem: Yeah, so we're trying to leverage the capabilities of modern browsers as much as possible. And a modern browser is perfectly capable of, as an example, to do form validation. We don't need 500 kilobytes of library to do form validations because your browser is perfectly capable of doing this. It's just a lot of developers don't really realize this because we've been depending on libraries for so long since jQuery was released years and years ago. We kind of went to the developer approach, where we use a library that serves multiple browsers and fills the gaps of capabilities that those browsers have. So we use a library because then it also works with Internet Explorer. That's how we used to do it. And now we're still used to using libraries for all the little features that we need. And in most of the cases, we don't need these libraries anymore.
And as soon as you look at this, React and Vue and all these PWA libraries or frameworks, they heavily rely on frameworks. And it will always come with at least hundreds of kilobytes of boilerplate JavaScript, while you then have nothing but a page that renders. Then on top of that, you need to write a lot of code to actually also render HTML. And your browser can both render HTML, you can render your code on the server already, and then your browser has to do very little to create an interactive page. So in my opinion, we kind of drifted away from the core principles of web development, and I wouldn't say that there's no room for app development in the web ecosystem. So if you look at the website of Twitter, or maybe an Adidas, or a Nike, or Amazon, they might benefit from an app like experience, and then it maybe makes sense to ship a lot more JavaScript code. But for the typical e-commerce project, a typical website, you don't need a full-fledged app for that. And besides that argument, the current web browser capabilities can do a lot of things already that don't rely on React or Vue. That's already baked into the browser.
Jisse: Well so I think, to open up for the criticism, the main point that you're making is maybe that Vue and React is maybe too much when it comes to simpler logic, simply just to have a catalog of product pages and category pages to have CMS content out there and etc. But I think, of course, the real benefit of React and Vue is to have the functionality of a single page application. And as soon as you talk about a single page application, it's also about loading, maybe that abundance of JavaScript, but also the CSS only once, because once it's loaded, you can navigate to another page. While theoretically, in your case, if you're navigating from the product page to the category page, the checkout CSS has already been loaded into the browser as well. And of course, I can hear you say that that if you keep the CSS to a minimum anyway, who cares? But I think it's kind of harder to measure. And I think there's also an opportunity for Vue and an opportunity for React, but I think your main point is that if you're looking at e-commerce, and the requirements of having SEO in there, and product and category pages that are fast to navigate, we've been overlooking the fact that actually maybe PWA is slowing things down. And that's where the revolution that you bring in actually pays off.
Willem: Yeah, so I personally think that a typical e-commerce website doesn't need a lot of state handling and data management, it's not data-heavy. It's a quite simple website that shows products, and you can add it to the cart. And then comes the complex part, it's checkouts. That's perhaps the most complicated part of an e-commerce site. And that, we don't build it with plain HTML and lightweight JavaScript, we chose to use React there because then we have a lot of state management and extra logic, and you actually have a UI that changes when you select a shipping method and a payment method. And then you need some extra tools to build an interactive interface there. But for the rest of the website, you don't need that much.
Peter Jaap: I think that's where you hit the nail on its head. You have to use the tools which are built for a specific purpose only for that specific purpose. And where, for example, PWA Studio went, is where they use a reactive framework, like React, in an area of an app, or website or webshop, in this case, where it's not actually needed at all. So this introduces a huge layer of complexity in the form of JavaScript, which is then pushed on to a community of PHP developers. And that says, âHey, work with this complex system to make a front end and to solve the problem we introduced years back with a new problem.â Instead of simplifying the solution, they actually made it again, more complex. So React shines in the places where you mentioned.
We build a lot of product configurators in React, which, that's perfect for it. That's exactly the use case React was built for, or Vue or Angular for that matter. But it's overkill to force a webshop into a single page application where the product page or category page, which are, in essence, very simple pages, yeah, put a lot of JavaScript on top and then have all kinds of developers struggle with this massive new framework. And I think the great thing you did with Hyva, is simplifying what we already had, leveraging the good stuff, what developers already know, bring in Tailwind in this case, utility-based CSS framework, which brings back the amount of CSS that's being downloaded. And if we don't handle preloading stuff in a smart way, so that the checkout CSS is already loaded on the product page or the category page, then we can leverage all these modern browser tools and make a really fast webshop without having other JS complexity.
Jisse: Well, I think on top of it, what you say is actually that with React and Vue, as soon as you deal with that single page application strategy, sooner or later, you need to make it SEO compatible as well. And then suddenly, you need to think about server-side rendering and then you're opening up the box of Pandora in the complexities of everything. So actually at the beginning of this year, I was at a Vue Amsterdam conference, and I kind of sneakily interviewed a lot of different attendees to see how many of those Vue developers played around with server-side rendering. And then actually, most of them didn't. And actually, those people that didn't never did something with e-commerce either. And actually, those people that had experience with server-side rendering dealt with e-commerce, but then were less enthusiastic about the same area as well. So maybe we've been looking at PWA for the wrong reasons as well. And that's why it's so refreshing that a Dutch guy stands up and says, âHey, we can do it different.â
Willem: Yeah, so--
Peter Jaap: This is what happens when you use a tool that's built for a specific purpose and tried to force it into a general-purpose area, where you just put on layers and layers of exceptions. âOh, yeah, it was originally built for this but now we also want it to do this. Or then we add thisâ and then complexity, complexity, complexity adds, and then you're stuck with this monster.
Willem: If Magento is famous for one thing, I guess it's choosing the wrong tools to do a job.
Peter Jaap: They initially thought that less is more, but it turns out Sass is more.
Willem: Sassy. Yeah, and thatâs--
Jisse: To be honest, I would like to nuance that a little bit because if we're dealing with Composer, Composer is perfectly fine. If weâre dealing with the PSR standards, they push the code into the right direction.
Peter Jaap: Those arenât really choices.
Willem: Okay, so let me then rephrase that. They are famously bad for making decisions in front end tools.
Jisse: Yeah.
Willem: And what I love about Magento is mostly the back end capabilities. And the core of the front-- So the most technical part of the front end, say blocks, Vue models, layout XML, those are really good. And that's exactly the parts that we're keeping because we love those parts, and they have their roots in Magento 1, and they've been ported over to Magento 2 in a pretty good way. Then what's on top of that, is just a pile of not such great things and that's what we've cut out. So the bloat of HTML and the complexity of the layout XML, and all the JavaScript had to go. And we replaced it with something that's better as proven tools that come from the Laravel ecosystem.
Peter Jaap: Let's dig a little bit deeper on the technical side. How did you actually strip it out and rebuild it?
Willem: Yeah, so because I knew I wanted to keep a tight coupling between back end and front end, I knew I wanted to keep layout XML as the core technology. So I wanted to still leverage the flexibility of composing your front end with layout XML, but I needed to get rid of all of the default PHTML and JavaScript that's being inserted by XML. So we have this reset theme. And we don't inherit on any theme, we have a reset theme. And that's basically it only contains layout files that do nothing but they overwrite layout XML files and they empty them. The only thing that remains there is containers, and all the blocks are being thrown out. And from that point, so that was my starting point, I built this reset theme. And then I created a chlid theme that just presented me an empty HTML file. So if you rendered the front end, you would just have a head and a body tag and except for that, nothing. That was my base point to get started and reintroduce HTML and see whatever JavaScript I would need to make it interactive again, and I really started from 0.0, blank page. Yeah,
Jisse: Maybe to jump in, so I think what has been putting off a lot of people to do the same thing in the past is because if you remove, if you reset everything in the XML layout to zero or zero plus containers, then you're stripping out all of the blocks, outputs all of the PHTML templates, and etc. which basically means that you have to redo so many things. Did you find it hard to rewrite everything? Or maybe another sneaky question, does Hyva at this moment support everything?
Willem: No, well, that's an ongoing process, and we are shifting priorities there. And we're selecting things that we really want to have, things that we kind of want to have, and things that we certainly don't want to have. And one of those don'ts is, for example, multiple address shipping. Not a single soul in the world--
Jisse: Who ever used that?
Willem: Yeah. And it's been classically implemented in the worst possible way and no one uses it. And I think even PWA Studio decided that this is one of the features that are not going to make it into the new format. And that's just a few features that we plan to do at a later point, which is, for example, compare products. And I think that's a feature that serves 1% of the market. There are certainly people that want to work with Hyva that will want to have compare products, but that's, I think, a minority, and we will serve them but not with the initial release. What we have right now, we're almost ready to release configurable products. We have samples, downloadables are mostly working, then we move on to grouped products, which won't take long. And then we have bundled products also scheduled to at least do before the end of the year.
Jisse: So you're mentioning a lot of different features, right?
Willem: Yeah.
Jisse: Then you're basically mentioning as well that grouped products doesn't need to take that long. So what is long? Is it two hours, 20 hours or 200 hours?
Willem: No, I'm not talking about roadmap release time. And I'm planning to do within hopefully two weeks, a release that contains those features, so different product types that won't include bundles yet, but those are coming after quite soon. We're wrapping up some things in the customer accounts area. We're wrapping up the wish list functionality in the account area.
Jisse: Maybe to rephrase my question before this just becomes a long, long feature list and the roadmap. So I think it's fair to say that that you started it, and instead of just finishing it from the start, which is totally impossible with the ever-growing feature sets of Magento itself, it's simply fair to say that there's always a little bit of work that you need to put on top of it. And you're being open about it, and the roadmap is there. And there's progress being shown as well, if you say also that a certain feature is going to pop up in weeks, not months, not years, but just weeks. So that's a benefit. But basically, it shows also maybe that to add new features, it's not that bad. So the impression I get, I think a lot of people would get from Hyva is if you remove all of the JavaScript, if you remove all of the CSS, and then on top of it, you also remove all of the HTML, you're left with nothing so that actually you need to go through so much work to get a single feature in there. But my feeling is, that's not true. So could you lament a little bit on that?
Willem: Yeah, absolutely. So what took me the most time was just thinking things through. There has gone so many hours into just the process of figuring out what the best way would be, how different elements in the front end would work with each other, and how certain components would interact with each other, and how they would be easily replaceable. And in the foundation, I almost finished the configurable products and that wasn't a superlight task, because I didn't want to fully copy it over from the default Magento because the code is just too complex, in my opinion. So I really took time to simplify the way that works so that hopefully, if a developer reads that code, they actually understand what it's doing so it becomes much easier to expand on it or to modify things. And we're now at a point where a lot of things have settled. The things that are there are solid and won't move around anymore, and building new features goes very fast.
And we have the benefit that we're copying over a lot of stuff from core Magento. We're modifying it, we're improving it, we're making it less complex, but in the basis, we're not reinventing wheels. We're just reinventing simplicity and developer experience. So we're using better tools to redo what's already there. And that's so much easier than when you look at a headless framework where thereâs no example how to do things yet, and there's no tight coupling with a back end. Only thing that you have is a GraphQL endpoint, so you have data. And from there, you need to do everything by yourself. And we can look up a lot of things like âHow is data being managed? What actions are sent by which form?â and then rebuild that same data flow and those same actions, but prettier and nicer. And that's a very nice process and a very satisfying process. And at this point-- Yeah.
Peter Jaap: The development of Hyva itself is very quick compared to developing PWA Studio Iâd imagine. Do you also have any real-life data on implementation times? Do you already have a project at Integer_net that is using Hyva?
Willem: Yeah, so within two weeks, we finish up the project that I demoed at ReactorCon, this is in this B2B shop. Thereâs a little bit of work there still for the checkout but except for that, that shop is done. Then we have one internal project that we're redoing that was being built with one of the bigger PWA solutions. We spent nearly nine months building that and we decided not to see it through.
Jisse: Could you comment on which kind of certain PWA solution this was? Feel free, come on.
Peter Jaap: Digging up the dirt.
Jisse: So that's VueStorefront. Okay.You convinced me.
Willem: I did not make any comment. So, we have some experience with that particular framework. One project we finished, no one really wanted to touch that project after it went live. So we're going to redo that project as well, that's actually started already. And then the other project we didn't finish, and that customer really wanted to have it finished before the end of the year. And we couldn't sell him data based on the PWA solution, but we could sell it based on Hyva. So we started about six weeks ago, redoing nine months of work with PWA, and we're past the functionalities that we had with the PWA solution. We already surpassed it. And I'm not completely up to date with the timeline but I think that's going to be finished this year as the client wanted.
Peter Jaap: So what's that a man hours? You already had a design, you already had a feature set, you âjustâ needed to rebuild it.
Willem: Yeah, again, I'm not fully on inside of-- I'm not running the company where I work. I'm not doing project management at the company where I work, so I don't have full insight on how many hours go into that project.
Peter Jaap: Right. You could share one.
Willem: I could look it up but--
Peter Jaap: We're as you already know, at our agency, we're already using Hyva. Weâre one of the well, how'd you call it, pilot beta testers, launching partners? So we've implemented the first versions and upgraded ever since you came out with new releases. We also had one project that needed a redesign, that needed a rebuild, that was on SmartWay Portal. We inherited that project. We had never used those portal templates but it's now we know why. So we did a rebuild of that on Hyva with a new design. So this was a new design, some new features, and the rebuild. We're nearly done, and we clocked in around 90 hours on it, man-hours. So that's with two developers. It's within three weeks, we went from SmartWay Portal to Hyva based new design. So that's our using.
Willem: If you put that on a scale of complexity where you normally operate for webshops that you build, is this a low complexity or a high complexity, somewhere in between?
Peter Jaap: It's definitely a low complexity. The recent builds we did, we were based on Snowdogâs Alpaca theme using fractal. That was also a lot quicker than the system we used before. Hyva shares some features with that in the sense that it's still a Magento theme and it's component-based. But we used to move a design from Figma into fractal components or Alpaca components and then move them into a Magento theme, whereas we now skip the component part and then immediately implement them using Tailwind, so the iterative phase is much faster. It's a shorter feedback loop with Tailwind because you don't have to go through all the naming stuff. And we used BEM with Alpaca. Now, obviously, we moved to Tailwind, utility-based CSS. Not having to think up names in the meantime, and having to define the CSS elsewhere is also saving a lot of time. The pages reload a lot faster, so just the whole development flow is a lot nicer. My colleagues are doing this project, I'm taking on a different project where I'm doing a rebuild of React-based PWA solution we implemented a while ago.
Jisse: It shall remain unnamed?
Peter Jaap: Which shall remain unnamed.
Jisse: Are you talking about DEITY? That's DEITY.
Peter Jaap: This is also one of those projects that nobody in the company wants to touch because it's just so JavaScript involved and thatâs just there.
Jisse: One of the difficulties with having this conversation is maybe also the licensing scheme. So I've been hearing actually a lot of positive feedback in the community about Hyva, so that's wonderful. And I think also that my feeling as soon as I heard about Hyva, basically, that was also based upon the stories that Willem was telling is basically that the developer experience goes up. But it's not only the pleasure to work with something more bare-bones, but it's also actually that the efficiency goes up as well. So instead of just wasting hours on building something with SmartWay Portal which seems simple, but then you need to tune things, then you need to troubleshoot the JavaScript errors, and then you're still stuck at the lowest lighthouse rating ever. I think that proves a lot. However, then it's still hearsay because I think a lot of people hear these stories and then they look at the pricing page of Hyva at this moment, and then they see that it is costing âheavyâ, and I'm putting that between quotes because that's where the discussion is. A heavy sum of 1000 euro per year.
Willem: Well, no, you should see that as a one-time fee why you buy the product. And it includes a year of updates, so security updates, Magento updates, so we keep it compatible. And then after a year, there will be a recurring fee to keep receiving updates. And that will include access to support, access to screencasts that weâll do to explain how to build stuff. So it's not 1000 euros per year, but it's 1000 euros to get access to tools that save you many, many, many hours on each project that you do.
Jisse: Yeah, so maybe to comment on it because I always love the numbers. So let's say that you have a development theme somewhere in a lower wage country, for instance, India. And I'm not saying anything about the quality of that, but just a little bit of outsourcing to have lower development rates. And let's say that actually the developers there are costing 20 euro per hour, then we're actually talking about 50 hours of such a person to be hired, right? That's the expense that we're talking about yet both of you actually say something different as well. The project that you were working with, Willem, for nine months with a certain PWA solution, it took only six weeks to refactor that. So that's, I don't know my numbers, but that's at least a winning of two times as many hours. Well, it's basically exceeding that 50 euro right away. And I think that's the same story with Peter Jaap. So that's why I asked the question.
Peter Jaap: And now you're only taking in one part of the equation because the other part of the equation is the webshop will be a lot faster, will convert better and you'll earn more money. So just that part, if you're doing any serious business at all, a minimum increase in performance and decrease in time spent on their page being loaded, has a pretty big effect on conversion ratios. So if youâre doing any kind of relevant turnover, so let's say for the EU market a million plus, that thousand euros will be earned back in the first month. This amount of money shouldn't be a problem for agencies who reap the benefits or merchants who reap the benefits of a system like this. There will always be a place in the market for the SmartWay Portals and for the fully custom designs and for the PWA Studio, but I do think that for a lot of agencies doing mid-market, SMB e-commerce shops, especially in the EU with a yearly turnover of between or maybe even 500K and upwards up to 20, 40, 50 million, whatever you do on Magento 2. I think this is one of the most cost-effective solutions out there and 1000 euros is peanuts.
Jisse: Yeah. So basically anyone who starts to complain about the pricing needs to do the math. And unless we're dealing with somebody who's volunteering all of his or her time towards Magento and is not earning any money, then maybe that person has a point. But I think as soon as you run projects, as soon as you make money out of Magento, then actually this is just a smart investment.
Peter Jaap: Definitely. Any agency should be able to reap thousand euros of benefits using Hyva.
Jisse: Yeah, but I've got also a more technical question. And that's maybe leading into also one of my pain points with Hyva as well. So Hyva is based upon Tailwind and as soon as I started to read about Tailwindâs CSS usage, I learned about just adding all of those CSS classes to the HTML, and then automatically stuff starts happening. And then instead of just adding one CSS class to one HTML element, you're adding like 20 just for that thing to happen. Which made me wonder like, hey, wouldn't it be more efficient to move all of those CSS classes into a CSS file, and simply just create my own definition of CSS? For instance, a class name called cards, or product gallery, or main menu, and then just import all of those Tailwind utility classes as a mixin like I was used to with Sass or with Less. And I read about that it's possible. So then at that moment, it was my impression, basically, that Tailwind-- That's apply you say, Peter Jaap?
Peter Jaap: Yeah. Add apply.
Jisse: Add apply.
Willem: We're doing this.
Jisse: Oh, you are.
Willem: Yeah, we're doing this in the least amount that makes sense. And what that means is that as soon as we have a repeating pattern that we see that is part of the base of the themeing, something that, for example, a button, or the way that we style an input element, or these containers that we use, we call it card, C-A-R-D. That's used for block elements and product listings, and in many places throughout the theme. And that's the kind of thing that we extract from the HTML, we apply one class and we add that to our CSS in Tailwind, and then as Peter Jaap says, you can use apply. So it means you say the class cards. It uses these Tailwind classes. So you say apply, and then the padding and rounded corners and shadow. So you can use the Tailwind classes, compose them in CSS.
And the reason we're not doing that for just everything, the way we're used to doing it, is because you're setting things in stone in your CSS file, and it's decoupled from the actual HTML that you're writing. And your HTML is bound to change. Your CSS is not bound to change that often. So you remove an element from your HTML. So there was a header component, and you removed it, a button that was there, and you removed the button, but the CSS layer, so there will always be this header button class with the styles applied to that. And if you're very strict, and you pay attention to these things, maybe you clean it up in the CSS, but usually your CSS just keeps growing.
And besides that, Tailwind is built in a way that by its own definition, your CSS remains the smallest. So the final CSS file remains the smallest when you compose different utility classes. And when you compile your CSS with Tailwind, it looks at the HTML, it looks at the classes that you actually used, and reduces that to the smallest amount of CSS. So a Tailwind by itself, the whole library is almost two megabytes. And when we compile the CSS and only use the classes that we need, we end up with 35 kilobytes of CSS. As soon as you start extracting CSS and putting it into classes like you proposed, then immediately your CSS starts growing. You get repetition of certain--
Peter Jaap: Yeah, so the repetition part is important here. So Tailwind when gives out these classes, like border b2. So you have a border-bottom of 2 am. So that's one class. If that's used somewhere in your front end, then that class won't be purged. So it will be in your CSS file. So let's say you create a card class that contains a few of these Tailwind classes, and then you apply it to one element. In that case, you introduced extra code because you introduced this class, which again, copies the data from the individual Tailwind classes, and you apply it to one element. If you would have just applied the Tailwind classes immediately to that element, you would have less code than you would have now. But if you have two elements that use that, then you can extract that into one class that uses those composite Tailwind classes.
So what do you do like in a BEM situation? You name everything, and you create maybe one class for one element that's used in one place in your whole application. That introduces a lot more CSS code than the Tailwind way where you try to find the least common denominator between all classes using a certain component, put that into a Tailwind class, and so for example, the button, you define the width and the height and the border, etc., or a base color. And then if you have the same button somewhere else, but in a different color, you just use the Tailwind color class in your HTML, and you do not create a new class called âButton Redâ, and then add the color red in there because that would, again, duplicate code. So it's a fine line but if you do it correctly, and if you really think about where you will split up your classes and use the least common denominator properly, then you'll end up with way less CSS than in the BEM structure.
Jisse: So I'm making that suggestion, actually, for two reasons. So first of all, I'm a CSS nitwit. So every time when I need to create a simple CSS definition, I need to look it up online like well, âWhat kind of properties do I have?â
Peter Jaap: Me too, but Tailwind is created for developers like us.
Jisse: I get that point. And theoretically, I also get the point about BEM being less efficient, especially when there's less code to be made reusable. And that's also where you came in Willem, that you simply mentioned that sometimes youâre using the identifier strings within the HTML to refer to CSS, where it's all about reusability. But sometimes you're just checking those utility classes of Tailwind in HTML to get the job done. And it's all still about performance so I get that first part, and that's clear to me.
Willem: Not only. There's an extra thing - interchangeability of components. And that means when you write a block of HTML with Tailwind, it contains all the styling by using Tailwind classes. That means that if I cut and paste something from another website, from a library, there are loads of Tailwind libraries where you can get all kinds of layouts and call to actions and a newsletter subscription. Think of it and it exists. And you can just simply copy that HTML, put it in a PHTML file, and then replace the static content with variables and recompile your CSS and it works. As soon as you start introducing project-specific or framework-specific classes to it, it becomes much harder to take something and extract it and reuse it. And we're planning on creating a library of different UI elements. Weâre creating the third variation on the menu right now. So we have a static menu, just a few links on a line, then we have a drop-down menu now that's fully dynamic, and rebuilding at the moment, a mega menu. And it will be super simple to just swap the menu, take the PHTML file that contains the mega menu, replace it in your theme, recompile the CSS and it works. And if you would do that in a traditional way, you would need to have an extra CSS file that contains the CSS for your menu, and thatâs just bloat everywhere.
Peter Jaap: Yeah, which brings me on third party extensions because when you just explained is exactly what third party extensions now do. They provide a PHTML file, maybe a .js file, some CSS, you put it in, the Magento system hooks into it, pulls it into your CSS file, merges it, minifies it, whatever, and then the functionality is there. How will you handle third party extensions?
Willem: With compatibility modules. And that means if I take an example, we have this GTM module from Yireo.
Jisse: Oh, whoâs that?
Willem: And we made that compatible with Hyva. And what that entails is, we take the module that Yireo or Jisse created, we put it in with Composer, and then we put in an extra compatibility module that we created that only contains the PHTML file and the JavaScript that we changed to make it compatible. So there's one module that sits in between, and that overrides the output. And in this case, for this module, it took less than two hours to rewrite it to work with Hyva.
Jisse: Okay. This is maybe also where I would like to make a point. So the thing I was trying to get to earlier was actually that if the amount of work to strip away all of the nonsense JavaScript and the nonsense CSS and the nonsense HTML that is shipping with this average third party extension, if removing all of that is peanuts because there's a reset, but additionally, to rewrite such an extension to behave in your own way, then I get that if you're fond of Tailwind, and you've thought out this modular system on your own already, then it's kind of cool. However, what I still see is-- So I'm still a CSS nitwit, right. And I think Tailwind is cool, but I still think Bootstrap is cool as well, and I think foundation is cool. And I think any kind of tool that makes your life easier so that you don't need to write CSS from scratch, I think that's cool. I think on top of it, writing CSS from scratch is cool as well. So my main point is--
Willem: But you're free to do that. You know what it is?
Jisse: Thatâs my question.
Willem: Yeah, so you have a base theme, which is our default Tailwind theme, and it contains 35 kilobytes of CSS. It can even become less if you decide to throw things out but that's your baseline. And I don't care if you add jQuery, pull in jQuery, and write a component that uses jQuery, it will come with a small penalty, it will pull down your page speed score. Same goes for whatever CSS framework that you would like to put on top of it as long as you make sure that they don't conflict, so you can add a prefix to your Tailwind or add a prefix to classes from whatever tool that you Bootstrap, and that will work perfectly. But I'm really just aiming at simplicity, reduced complexity, and performance. And we get the maximum performance by not including these third-party libraries. And so far, when I started building this, I fully expected to have to include more libraries. I thought the mini card, I'm going to have to build that with React because it will be more complex and Alpine.js won't be able to handle that. Alpine.js, I think could even do the full checkout. It's just at that point when it becomes so complex, React or Vue becomes the better tool to build something like that because you want to have--
Jisse: Could you still comment a little bit about the current state of the checkout as well?
Willem: Yeah. So we chose to go two paths here because not everyone that will use Hyva will be technically adept enough to use React to build a checkout. And using Alpine doesn't really make sense to rebuild a checkout. It will become so complex that youâll also need to write a book for someone to understand how it works. So first of all, to have the shortest path to getting a production-ready website, we have a full back Luma checkout module. And that's for the person that wants to have a perfect website for 90%, and go live with that and have checkout that still relies on Luma. And that works perfectly. So if you have shipping extensions, payment extensions, they're all already compatible with Luma, so as soon as someone enters the checkout, they enter a page that actually renders the Luma theme. So if you want to go live fast, you can build your Hyva site in one or two months. Don't bother too much with the checkout, and perhaps hire someone who can customize the checkouts for you using React or Vue. But at least you don't need to have a lot of technical knowledge about how the checkout works.
Then the second half, the second option is that we open sourced a whole React checkout that's not fully functional yet, we're still building out features there, but we have a React checkout that works fully headless. It's built with React, only uses GraphQL. It's compatible with default Luma, you could use it on your old Luma site, you can use it with Hyva in our front end, but you could even use it in any headless Magento shop. I started building that in January, actually, and then put it on hold for a while. And then we had a project at Integer_net where we needed a React checkout, so I started implementing it for a B2B shop. So it currently has the billing address, it has a cart implementation where you can add and reduce items in the cart, it has the totals, we're finishing up checkout agreements, order comments, and then it's really not a big step to also include the shipping address, the selection of the payment type, and the selection of the shipping type.
That's on the roadmap. Weâll hundred percent finish that module so that all the base features will be in there. So if you're in a hurry, you could build your shop now and use the Luma, fallback checkout, and wait until we fully featured the React checkout. Or you choose to use the ShipperHQ React checkout or the Snowdog Vue checkout. Or I mean, there are many checkouts out there. And I tweeted this a few weeks ago, I tweeted âHyva is a bring your own checkout conceptâ, which maybe confused some people that had thought that we're not bringing a checkout. But it's a bit more nuanced than that. In fact, we have the fallback checkout rebuilding the React checkout, but you have any choice to implement another checkout as well. There are options, there are plenty of them.
Jisse: So maybe the problem is choice. So to me, there's still one really annoying thing in this whole story. And that's ever since Magento 1 came out and as soon as Magento 1 came out with an XML layout, somewhere in those days I met up with Yoav Kutner. And Yoav explained to me, hey, the reason behind this XML layout is actually for people to create their own front end to have the liberty to build whatever they wanted to build. Because the front end is always going to be moving faster than the Magento back ends. He had that vision. And then actually Magento 1 happened and it became popular also with maybe lower end merchants or less capable developers. I'm not trying to be rude but maybe that's what happened. And everybody got stuck to prototype and Scriptaculous and they believed they were stuck. And nobody ever came up with this ID to create a second front end based upon jQuery because that was hot. And then Magento 2 came out and Magento 2 just continued with not necessarily something that is really bad because they needed to choose between maybe creating their own JavaScript stack like before with Magento 1, or they would have gone the Angular way or they chose actually for knockouts thinking back then it was a good ID. And then they maybe learned their lessons, but they created a legacy. And I often say that we shouldn't blame Magento for creating all of that stuff because on top of--
Willem: We asked them to.
Jisse: We asked them to, and they've created it for free as well. And we became dependent on it. So what really bugs me, what for me, the really most annoying thing is, is that actually from the very start of Magento 1, which is like ages ago, there was this tendency or intent that actually the community would step in and create an alternative front end, which was better, depending upon what kind of front end technologies came up. And only like 10 years later or a little longer, then this Dutch guy comes along, Willem Wigman, and he creates something like that. And I'm just really scared that actually, people start to embrace Hyva and not see the opportunity of them recreating a lot of stuff themselves, not seeing that opportunity to drop Tailwind and embrace Bootstrap if they want to. But basically, looking your direction for maintaining everything and then just blaming you if the progress is not fast enough. So how do you see that? Why didn't somebody else come up with this ID earlier?
Willem: I think the timing is just perfect with the tools that we have right now. And I think Laravel has played a very big role. I mean--
Peter Jaap: Tailwind
Willem: No, so Tailwind comes from the Laravel ecosystem. And that's a very happy PHP community. And the tooling there is great and moving super fast. And Tailwind and Alpine.js, are a result of a flourishing Laravel ecosystem. And well, there are probably other tools that are great as well, that we could have used, but in this case, it's the most performant and the most lightweight tool that you can use to build. So that's where I made the choice. One, developer happiness, I see the developer happiness in that ecosystem, and I wanted to tap into that. I didn't want to make the switch to Laravel development because I'm a Magento guy, but I wanted to recreate that happiness. And so far, if I look at the developers that are working with it right now, I'm succeeding in that. And that alone makes me very happy.
Why didn't it happen before? We're not fully done yet killing Internet Explorer but we're almost there. And I think that has been a great factor in holding people back. And then it's a scary thing to do, right? If you would have given me the task to rebuild a front end for Magento, I wouldn't have gotten started with it. But I had the perfect use case where I was just fiddling with my own little project, I was trying to build a webshop for my wife, and I was imagining, how could I do that in a way that I'm having fun? Because quite honestly, in my day job doing Magento 2 front end, it's not that much fun anymore. And that's kind of depressing, so on my side projects, I was trying to do something that would make me happy. And I just got started. And that way, it wasn't something dumb or something unreachable that I was trying to do because I wasn't trying to rebuild a Magento 2 front end. I was trying to do a simple shop for my wife with the least amount of code possible.
Peter Jaap: I guess it's a perfect storm of you running into that situation, having browser compatibility up to a point where stuff gets a lot easier, the existence of Tailwind, Magento being in a more competitive market than they were five to 10 years ago when they were pretty much the only player in the open source e-commerce environment, SaaS platforms getting better and better - the competition is on - and then PWA coming along as this sort of panacea, cure for everything, please use our PWA offering, it's great. And then it turns out it isn't great. So I think all of those combined culminated into what is now Hyva, and who knows, maybe there will be a Hyva competitor down the line. All the better; that will probably serve a different angle and serve a different market.
Jisse: Yeah, and I think that that's basically maybe also one of the points to learn from the story. Regardless of whether you're going to use Hyva, Willem is just pointing the community towards a very obvious point that if the current Magento for content is too complex, you might just work really, really hard into improving it. But you might as well just create something new, and that something new might be totally different but a lot better. And that's basically what Hyva is right? A better front end than Magento.
Willem: Yeah. And I think it's gone really fast, which is, I think a product of the fact that I did a lot of the things on my own. So I didn't have to argue, I didn't have to plan things, I didn't have to write things out. I lay awake for many, many hours thinking about how to do stuff. I would wake up in the morning at six o'clock work one and a half hour on Hyva, and then take care of my daughter and work. So it took a lot of dedication.
Peter Jaap: Wait, your daughter wakes up at 7:30?
Willem: Yeah, 7, 7:30.
Peter Jaap: My God. You are one lucky person. I start work at five because my daughters wake up at six.
Willem: It depends, if it's a day she needs to go to school, it's a little bit earlier. But I had this period where even on a holiday my wife and daughter would sleep until nine and I had two full hours to just fully focus.
Peter Jaap: Wow. So basically, we have to thank your daughter for Hyva.
Willem: Yeah. I think--
Peter Jaap: Final comment.
Willem: Final comment. I'm excited. We're getting really close to bringing this to a lot more people. We've been holding back a bit, giving just a few people access so that we can check on the code quality and see if there are gaps that we still need to fill before we publish it. There's a list of people that I'm really thankful of that they're still waiting for me to give them access. And I'll be very happy to give that to them soon. Yeah.
Peter Jaap: Right. Sounds great, Willem. Thanks for being here, and I guess we'll see you in the future. Maybe we'll do a report back episode in half a year or so and see where you stand with Hyva at that point.
Willem: Yeah, we need to hear how your projects are.
Peter Jaap: Iâll probably blab about it here in one of the next episodes.
Jisse: Basically, in half-year time. That's the impression I get. You can both say that you've built like 20 different shops in two monthsâ time or so because the speed just comes up tremendously. Yeah. So Willem, thanks for joining us.
Willem: Thanks for having me.
Jisse: It was awesome, so thank you so much. And thank you everyone for listening, and we'll be back with another episode on⊠Peter Jaap?
Peter Jaap: I have no idea yet.
Jisse: No, I mean the topic was you. No, Iâm just kidding.
Peter Jaap: All right! Yeah. Sorry CI/CD, pipelines stuff.
Jisse: Oh nice. Continuous integration, continuous deployment. Let's do that. So totally different topic but I think this one was really awesome. So thanks again to Willem.
Peter Jaap: Absolutely.
Willem: Thanks, guys.
Peter Jaap: See you guys. Bye-bye.
Jisse: Bye-bye. -
¿Faltan episodios?
-
Full transcription below show notes
Show notes
Extensions mentioned
https://github.com/davidrjonas/composer-lock-diff
https://github.com/magento/quality-patches/blob/master/patches.json
https://github.com/mage2tv/magento-cache-clean
https://github.com/kiwicommerce
https://github.com/olivertar/m2_api_product_images
https://github.com/experius/Magento-2-Module-Experius-MissingTranslations
https://github.com/netz98/headless-guillotine
https://github.com/markshust/magento2-module-disabletwofactorauth
https://github.com/magento/security-packageMeld diff tool - https://meldmerge.org/
Architecture repo - https://github.com/magento/architecture
Database MediaStorage in M2 - https://github.com/magento/architecture/issues/111
File system framework in m2 - https://github.com/magento/architecture/issues/219Upcoming episodes:
#4 Willem Wigman & Hyva
#5 CI/CDFull transcription
Jisse: Hi, everybody. Welcome to episode number three of The Registry with me, Jisse Reitsma and--
Peter Jaap: Hello, Peter Jaap here.
Jisse: Cool. So there we are. Yeah, episode three. We started off with episodes one and two, kind of like, a little bit awkward, a little bit eerie like, âWas this going to work? Did we only make it to produce a single episode? Or would this be a series?â But slowly, I think itâs becoming a series, right? So that's a cool thing.
Peter Jaap: I think it's officially a series where you have three.
Jisse: Okay. Not a miniseries, but maybe it's becoming also like one of those long-going series as well. Yeah.
Peter Jaap: Yeah.
Jisse: So the concept is simple. It's two Dutch guys talking about random things related to Magento 2, related to developer stuff, things that we find interesting. Yeah, and maybe the kickstart of everything is we're recording this actually, while Magento 2.4.1 has been out already for, I don't know, like one week, two weeks? Two weeks ago already. So Peter Jaap, did you upgrade already?
Peter Jaap: Well place your bets. What do you think?
Jisse: I think you didn't.
Peter Jaap: No, we didn't. We're helping everybody on to 2.3.6 at this point, which is a really easy upgrade from 2.3.5-p2 where most of them are coming from. I just did one today from 2.3.4, which also was a pretty small step. Wasn't that big, that much of a problem so I like. 2.3.6 was an easy upgrade so I don't know, should I go to 2.4.1? What are your thoughts?
Jisse: Well, if I have to admit, so I'm running a few production shops, and they're actually just doing fine. I see also, agencies that I'm helping out struggling with the same kind of issues that you have. So the real question is like, do you really need it or not? Well, you don't need it to get rid of MySQL search because well, you can do that already with the older version. So yeah, there's not that many improvements that you might be eager to adopt unless you're running a Hettle shop already, something based upon PWA Studio or-- And personally, what I find-- Yeah, go ahead.
Peter Jaap: Or I did upgrade one shop to 2.4.1 because we're starting Hyva implementation on it and that requires 2.4. So I did do one upgrade and it was a fairly simple shop and that went pretty easy. But yeah, that's because of Hyva, but we'll get into that next week. But yes, I lied. I did do one.
Jisse: Hoofa, hoof, hoof, hiff, hife, hifaâŠ
Peter Jaap: Hoova, hoova, hivva, hyva
Jisse: I donât know what itâs being pronounced as but yeah so actually, this episode--
Peter Jaap: Willem pronounces it as hoova.
Jisse: Exactly. Yeah. And this is episode three.
Peter Jaap: Itâs Finnish or something.
Jisse: Yeah. Well, definitely next episode, he's joining us to explain everything, including the right pronunciation and including the real meaning.
Peter Jaap: Oh, good because I don't understand anything.
Jisse: Exactly.
Peter Jaap: I think that mainly has to do with it being front end stuff and I'm not very good on that.
Jisse: Now, for me for the upgrade to Magento 2.4. So I've been doing that upgrade for a couple of simple shops and there, I didn't really find any issues. One of the things that I'm kind of eager to play around with is the controller decomposition. We mentioned this in the previous episodes, and I can see really the differences in loading times that a controller based upon the old extending upon the abstract action or the admin actions that are there. And then suddenly replacing it with one of these, or just an implementation of an interface, a clean constructor that you basically have for your own dependencies, it's just reducing per controller loads about 50 to 60 milliseconds per Ajax goal or per load. That's pretty awesome. But yeah, it's not included in the core. So none of the core modules have been adopting to that new strategy yet because of, well, I don't know, backwards compatibility, and so on. But yeah, so let's not talk about the upgrade any further.
Peter Jaap: So just ripping out all the dependency injection in these controllers is giving you this speed increase.
Jisse: Yep, which makes you wonder, of course, like, âHey, what on earth is all of that dependency stuff then doing?â Well, it's dealing with events, it's dealing with, maybe also really cool stuff, plugins that are doing all kinds of tricks in there. But if you want to reduce it down to your own controller deciding upon what needs to be done in a very clean and direct way, it's kind of cool.Peter Jaap: So if you use the decomposited, decom, whatâs the word?
Jisse: Decomposition
Peter Jaap: Decompositioned controller, you don't have any events triggering, or is that handled in a different way?
Jisse: So as far as I know, the events are simply skipped. Yeah.
Peter Jaap: Okay. Interesting. So that's a thing to watch out for.
Jisse: Yeah. But maybe that's also the strategy that I think should become more popular - less is more. So instead of just adding more functionality to Magento 2, sometimes it's actually good to reduce functionality, remove things that you have out of the box, just for the sake of performance.
Peter Jaap: So configuration over convention. Less magic, more explicitly, yeah.
Jisse: Yeah.
Peter Jaap: Okay
Jisse: Yeah, now let's skip the rest of the talk about the upgrades. I'm maybe going to ask you next time again, as well.
Peter Jaap: This will be a recurring item in the podcast, âDid PJ upgrade to 2.4?â
Jisse: Yeah, so episode 26, âPJ, have you upgraded already to 2.4.1.?â
Peter Jaap: Who knows? Maybe I'll do one every week and then in like 20 episodes from now, all our clients are on 2.4.
Jisse: Exactly. Yeah, and other news that is out there is Composer 2. So I've been playing around with Composer 2 myself quite a bit already, even trying to implement it in a couple of my own continuous integration steps on my own personal GitLab instance. And if you're using Composer 1 together with prestissimo, then actually the speed is already pretty cool. But now out of the box, it's also there with Composer 2. And you're only going to bump into actually two areas of issues. One of them is something I'm still not able to explain in a maybe correct way, but there's a feature in Composer 2 called canonical repositories. And basically, canonical means that as soon as Composer is going to search for a specific package, it's going to find that package maybe in a single or the first repository that it encounters. But then theoretically, if that same repository is also registered under the same name in other repositories as well - so for instance, both on packages in the Magento Marketplace - then Composer 2 might be bumping into issues. And the solution is quite simple. Just simply add a âcanonical is falseâ flag to the Magento Marketplace, and then you're good to go.
The second one is actually more problematic, as in that if you're using Composer 1 plugins, then those Composer plugins are no longer compatible with the new Composer 2 API. So that makes you wonder like, âWhat kind of composer plugins do I have?â Well, prestissimo is one of them. So you can't use prestissimo but well, that's kind of common sense, because the same functionality is in Composer 2 already, but there's a couple of others as well. Two of which come to my mind right now are, first of all, the Composer plugin that Magento is shipping. So I'm not sure what the official name of it is again, but it's managing your Composer dependencies
Peter Jaap: Magento Composer Root Plugin.
Jisse: Yeah, exactly, that one. And that's basically currently not compatible so that basically if you're using Composer 2, this Root Composer Plugin doesn't have the ability anymore to update your Composer 2 JSON file to the latest version if you're upgrading Magento - well, that's a pity. And a second one was more problematic, that Magento has been migrating their Zend stuff from Zend into Laminas.
Peter Jaap: Laminas
Jisse: And then there's this Laminas backwards compatibility layer of some kind. So, I didn't really dive deep into it, but I got an impression that actually this Laminas compatibility thing is allowing for backwards compatibility with Zend goals so that you can still fall back to Zend classes or Zend namespaces while actually it's being replaced with Laminas. Well, that again doesn't work, so theoretically that's going to break also systems if you're trying to use Composer 2 with the Magento 2 versions. But yeah, there's a simple flag ignore platform requirements, which allows you to still install Magento 2 under a PHP 5. Iâm not sure if that's going to work but the save flag allows you also to skip those Composer plugins and ensure it works, it's speedy, it's nice. Yeah. Did you play around with Composer 2?
Peter Jaap: Yeah. [Iâve been 10:54] using it as much as possible. Although you just said prestissimo, that the speed difference between Composer 1 with prestissimo and Composer 2 isn't that big, I have a different experience. Because not only the downloading of the packages is faster in Composer 2 - that's what prestissimo did for Composer 1 - but also the SAT dependency tree resolving is much, much, much faster and smarter implementation than it was in [Composer 1 11:27]. So if you're going to do a huge Magento upgrade with tons of packages and dependencies, it will resolve up to 10 or 20 times [faster 11:40]. That's the main benefit for me using Composer 2.
Jisse: Cool.
Peter Jaap: So speaking of Composer, I ran into this also during one of my Magento upgrades. I needed a way to see which packages were upgraded during a Composer upgrade or a Composer require. So sometimes you are in a project and you run a Composer require whatever package and that will also upgrade the dependencies of that package, which you might already have in there. And it will show these upgrades and these installs in the output of the require command. But usually, I don't really look at it, or I don't save it anywhere. And then, later on, I think, âOh, maybe one of those packages that updated might have a bug in itâ if I run into something. So then I have to manually go through the Composer lock files to see which have changed. And that's a mess because it's a diff file and that's not pretty cool.
So there's this package, it's called davidrjonas/composer-lock-diff, and it's basically a little diff tool, like a PHP binary, that diffs your two Composer lock files, and it will show you a table of the previous version it was in the old Composer lock file, the current version, and it will give you a link to the GitHub repository with already the version numbers in the âcompareâ functionality. So you can just copy-paste the link and open it and then you'll see exactly what code changed between these two versions of the package that's listed. And this is great stuff, so we've already put it into a protocol at our agency. Whenever you do an upgrade, and when you finish the upgrade, generate the lock diff file and post that into the issue as well so someone who runs into problems down the line can have a nice overview of what actually happened. You can actually pass Git commit references to the binary. So it will fetch it from Git and then compare it with the one in head or the one in a different branch or whatever. So great, great little tool.
Jisse: Yeah, you love your Composer stuff, right?
Peter Jaap: I love Composer so much. And it's not just I love Composer, it's sometimes so hard to see with the diffs and the patches and there's so much going on at any time, so any tool is welcome. Oh, it just reminded me of one. I'm running Ubuntu Linux distribution, and I ran into this GUI tool thatâs called Meld, M-E-L-D. You can just use apps to install it, and you can diff entire vendor or entire directories. So I now use it in addition to the upgrade patch helper I mentioned in the last podcast, to diff the old vendor there with a new vendor there and then you'll have a much better visual way to see the differences between the two files that have been upgraded instead of the patch file. The upgrade patch helper generates itself. So, extra tip.
Jisse: Yeah, and it's basically still useful if you want to upgrade sooner or later to this Magento new version of 2.4.1 but you're still a little bit wary what kind of changes are in there and if you agree with those changes, of course, yeah.
Peter Jaap: Yeah, exactly. I could do an upgrade to 2.4.1 in probably a few hours, instead of 10s of hours that it used to be without all these tools. And be certain that I didn't miss anything. Yeah.
Jisse: Yeah. And the challenge is still that maybe the Magento official version is just going up and introducing new, new features, but you don't want to have all of those features all of the time just to be in your shop. So you're bumped into this repository of Magento as well called the Quality Patches.
Peter Jaap: Yeah, so this blew my mind. I didn't know this existed.
Jisse: Oh, me either.
Peter Jaap: And I asked my colleagues and some other-- So this is one of those hidden gems. So it's a Magento repository, it's Magento/quality-patches, quality patches. It's a tool to apply patches to different Magento versions. I haven't actually tried the tool itself but the interesting thing I've found was the patches of JSON file that's in that repository. This lists quality patches, like what the name says. So if somebody did a PR in the Magento repository, and it fixes a bug for certain Magento versions, this is a 700 line long file with, let's see, 67 quality patches for various issues in the Magento code base with a version constraint mentioned in the JSON file itself. So you can pretty much copy-paste this into your project and run a Composer install and let the [final 17:00] Composer patches helper do its thing. And then it will install quality patches for the mentioned bugs, which might have been backported to 2.2 or 2.3 and are now in the latest version. But if you're not running the latest version, this is the next best thing.
Jisse: Yeah. So the gem is still that it's all about the patches, of course, all of those patches are within that same repository as well. But specifically, the JSON file is just ready to go to import by using the [final 17:35] Composer patches tool, for instance, just to get going with it. Yeah, it's pretty cool. But yeah, it's kind of like something we discovered ourselves just now as well, while it has been going already for four months in a row. So it also makes me wonder how many people know about this indeed.
Peter Jaap: Exactly. The repository is four months old. The last release was 13 days ago. I never knew about this. I just happened to run into it, I don't even remember where. But I have a feeling nobody knows about this one.
Jisse: No, but maybe it falls together with another project that I literally have nothing to say about yet, which is the Magento SUT tool, Software Upgrade or System Upgrade Tool, SUT.
Peter Jaap: Self Update Tool?
Jisse: Or self, I don't know, but it's--
Peter Jaap: I don't remember either.
Jisse: It's part of maybe a community engineering or I don't know, but Magento [is] basically trying to make the whole process of upgrading easier. And actually, every episode, we start with a question like, âHey, PJ, did you upgrade to 2.4.1 yet?â And then he answers no, but for reasons, right? And then maybe this is just part of that same thing as well, that theyâre trying to get the upgrade process more under control. But yeah, SUT, the Adobe/Magento SUT tool was announced at MageCONF, and unfortunately, I was unable to attend for that talk. So hopefully, the slides are coming online soon, or the video or the upgrade tool itself, because yeah, Iâm just looking to know whether itâs--
Peter Jaap: This is just one of Magentoâs secret projects.
Jisse: Excellent. Yeah.
Peter Jaap: I think it stands for the Secret Upgrade Tool.
Jisse: Yeah, that might be as well, right? Yeah, but so yeah, cool stuff. Well, there's also a couple of other things that I find are nice to know about also. We talked about Magento 2.4 quite some time ago, and then there are various security packages that came out with 2.4 but they've been also partially in 2.3 as well. So a whole bunch of reCAPTCHA modules with a whole bunch of two-factor authentication tricks. And I think we already discussed this [in] the previous episodes as well, so let's not go into the details of two-factor authentication or reCAPTCHA. Other than that, there's actually a lot of third party efforts in a community going on to disable two-factor authentication again or to disable all those reCAPTCHAs, which I find funny. But yes, so the story I wanted to discuss anyway is on the robots.txt file.
So the robots.txt module that ships now with Magento, allows you to generate a robots.txt file on the fly. And that's kind of nice, as in, I've been explaining actually this mechanism during a training as well, just to show people that the module itself is hooking into the front controllerâs dispatching mechanism. So it's adding a new router on top of the existing routers. And then if you know the front controller structure a little bit, part of because it's also a question on the certification program, but there's this loop going on between all of the routers, so one router is just mentioning like, âI don't want to pick up this request so let's continue to another router.â And the robots.txt is just adding another router on top of it. And then if the request is for robots.txt, the robots.txt router is picking up on it, delegating it into a controller, delegating it into the XML layout, so in the end, the robots.txt file is generated, actually, with a lot of PHP logic.
And the funny thing is actually in there that in most of the sites that I encountered, that single goal for a robots.txt file using dynamic logic takes up about 400, 500, 600 milliseconds. So itâs actually just something that is so overly complicated. Well, I personally have a really golden solution for that. Just navigating to the pub folder, create a robots.txt file, and then actually, the speed of that file will be just awesome. So yeah, it's just a funny thing that Magento sometimes is just adding all of those dynamic modules, while theoretically, having just a simple mechanism of a simple file in place is good enough as well.
Peter Jaap: Yeah, we usually set up an NGINX rewrite rule for robots.txt and place them outside the pubroot
Jisse: Exactly. Well, the only thing that might be still a good thing about that module is, of course, the dynamic nature so that if you wanted to deny or include specific categories for specific store view, then still that PHP logic is okay. But again, it's more or less the same
Peter Jaap: I would have preferred an implementation where it would run a cron and then you could tell it where to save that robots.txt file to.
Jisse: Yeah, yeah. Well, and because of the performance impact, my recommendation would also be just to disable that robots.txt module and just come up with a better, smarter alternative instead.
Peter Jaap: Yeah. All right. Going back to the two-factor authentication disable thing, when I did my 2.4 upgrade, I used the Magento 2 module disabled two factor of package from Mark Shust. That worked perfectly so shout out to Mark for that one.
Jisse: Yeah, and to mention, maybe, that there are more alternatives out there, but I think also that that Markâs module was just the cleanest and simplest approach as well. But it's funny to see that it's kind of like a silly thing to install. It's a module to disable yet other functionality and other modules. But yeah, it's just a nice little thing to have. So yeah, shout out to Mark.
Peter Jaap: Yeah, also shout out to M.academy, Markâs course on Magento development. We use it to onboard our new Magento hires, and it's great stuff. So check that out if you haven't. To make a segue on to a different Magento wizard doing courses, Mage2 TV, Vinai. Vinai has Magento cache clean tool, Iâd call it. It's sponsored by Mage2.tv and the Mage-- I can't live without it anymore. It's a file watcher for your Magento. It's a JavaScript thingy. You just run it by running cache clean.js to access watch, and it will watch all your files that have anything to do with cache. So if you update a PHTML file, it will clear the block HTML and the full page cache. If you update and layout XML file, it will clear the layout cache for you. So, there are also shortcuts. If you press âAâ, it will clean everything. So itâs awesome.
Jisse: And maybe even better yeah, it's not only about the cache, but it's also about the generated code. So for instance, if you're playing around with the console commands or with controllers, then it's also frequently needed to wipe out the generated classes. So the interceptor classes around the controller from the generated folder, and that's being picked up by the Mage2 TV cache cleaner as well. So yeah, awesome tool.
Peter Jaap: It works fast, it works flawless. I'm not even thinking about cache anymore during development when I have this thing on, it's great.
Jisse: That's one of the main takeaways as well, right? So do not develop with all of the caching disabled, unless you're somebody who can live without the developer flow. But if you care about efficiency and productivity, make sure that all of the cachings are enabled, theoretically, the full-page cache is disabled. But then actually, you really need a smooth way to refresh all of the caching. So yeah, that's a good shout out to Vinai. Hi Vinai. Yeah, so other stuff. Maybe it's also nice to mention that if you're playing around with headless, so creating your own BWA, something, maybe, based upon that PWA Studio, or VueStorefront or Deity, or building it yourself, then you might find actually that it's still possible to navigate to the original front end of Magento. So let's call it the Luma front end. And that's, of course, a silly thing. And then maybe you can find a way of disabling that. Maybe you're crazy enough to also play around with the PWA Studio upwards tool. But yeah, there's another tool much better for it - the netz98 headless guillotine. So yeah, the name of the module is a little bit macabre. So it's reminding me of the time of Napoleon where all of the people got their heads chopped off. But the headless guillotine is actually just chopping off the head so that leaves you with just the head or the body, I donât know. Iâm a little bit fuzzy but itâs allowing you to automatically redirect any attempt to navigate through the front end, navigate elsewhere.
Peter Jaap: Actually, it doesnât navigate you elsewhere, it throws an exception.
Jisse: Oh, oh, sorry. Yeah. So I've been there thinking about another module myself, but yeah, it's pretty useful anyway. And maybe to mention as well--
Peter Jaap: That we implemented this and then we got like 1000 Sentry notifications because some bots triggered an exception on it during the night. So I woke up and our whole Sentry quota was depleted because some bot found the back end Magento installation for a PWA shop.
Jisse: Yeah, so do make sure to use it with care. Yeah, and maybe to mention as well, netz98, the creator of this module is also, of course, the creator of Matron, and well, who doesn't know about Matron?
Peter Jaap: Yeah, shout out to Christian.
Jisse: Yeah, so what else is there? There's plenty of modules still to discuss, right? So we always love to keep going and going and going.
Peter Jaap: I have so many.
Jisse: It's too many, maybe as well. So let's maybe just--
Peter Jaap: I do have one.
Jisse: Okay, go ahead.
Peter Jaap: I do have one. Itâs not an extension but actually multiple extensions, but it's one organization. They're called KiwiCommerce.
Jisse: From New Zealand?
Peter Jaap: They're a relatively unknown UK player.
Jisse: Exactly, I donât know.
Peter Jaap: Theyâre from the UK, not New Zealand, unlike what the name suggests. So they have some great extensions on GitHub. We're using pretty much all of them. They have a Chrome scheduler, they have a login and customer functionality, which I hear isn't necessary anymore in 2.4 because it's now a default option.
Jisse: They give you it by default, yeah.
Peter Jaap: Yeah. Okay. So they have a customer password reset extension and admin activity logger. We use that one on pretty much all our stores. That's a great extension. Enhanced SMTP extension, we use that one a lot as well to hook up Office 365, or G Suite or whatever, SendGrid, you name it. And an inventory log extension, which, as it says, logs the inventory mutations. It's very useful if you have an external ERP system that changes stuff. And the great thing about this one is that it will also log stock changes that are done on the database level. So it has a trigger on the table, and that will listen for changes on the table. So if you have a four-party ERP system that hooks into the database directly, which, unfortunately, some ERP systems do, then this extension will also log those. So that's a great feature this one has, which I haven't seen in any other of the competitor extensions.
Jisse: Cool.
Peter Jaap: So shout out to KiwiCommerce.
Jisse: Yeah, but there's only one downside. I noticed actually, that maybe pretty recently, all of the repositories are now archived by the owner. So that means basically that they're no longer with Magento. Or maybe they just change their approach of open source. But anyway, the open source repositories are there, right? So you can just fork it, you can use IDs. And that's maybe also the whole point of open source
Peter Jaap: Yeah, I think they recently archived those models. I don't know why, I guess it's the OSS burden. I don't blame them. So fork it, the initial code is pretty good. We've been forking them into our local repository as well. Maybe someone can stand up and become a maintainer on all of them. So yeah, still great work.
Jisse: Awesome. Awesome. Yeah. So we could keep on going, but maybe that's good for another time as well because we're doing a series, right, so who cares?
Peter Jaap: Yeah, yeah, no, we could go on for hours on end. We did the last few times. Let's do a short one this time.
Jisse: Exactly. Yeah, maybe let's look into the future as well. So we started to mention Willem Wigman on his new project, Hyva, I don't know how that's pronounced
Peter Jaap: We'll add him next week how itâs pronounced.
Jisse: Exactly, but then maybe that's also nice to actually really talk about the future of front-ending in Magento. And not just talk about PWA, but actually also about his work and the opportunities that his front end is going to give us.
Peter Jaap: Yep, excited.
Jisse: Sounds like a good idea to dedicate that whole episode to Hyva, no to Hoova, that's the right pronunciation. Then maybe also the next episode after that, that would make it episode five, do something with CI/CD, testing stuff, gold quality checking, etc. I don't know, but I think weâve got plenty of things to talk about.
Peter Jaap: Definitely. All right.
Jisse: Great.
Peter Jaap: Thanks, Jisse. See you next week.
Jisse: Thank you Peter Jaap. See you next week indeed. And thanks for listening, and I hope you follow us back. Let us know also if you have other interesting topics that you would like us to talk about. We're happy to dive into other stuff as well. So yeah, hear from you soon. See you.
Peter Jaap: See you. -
Full transcript below the show notes.
Show notesAdobe Developer Live
React Spectrum, React Aria, React StatelyPWA Studio: Checkout + PageBuilder, Product Recommendations, internationalizationDevExchange discussionsSUT (Safe-Upgrade Tool)Composer & patch utils
https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helperhttps://github.com/vaimo/composer-patches/https://chrome.google.com/webstore/detail/magento-2-composer-patche/gfndadbceejgfjahpfaijcacnmdloiad https://github.com/szeidler/composer-patches-cliOther extensions / tools
https://github.com/baldwin-agency/magento2-module-url-data-integrity-checkerhttps://github.com/elgentos/regenerate-catalog-urls https://github.com/fisheyehq/module-url-rewrite-optimiser Jisseâs replacement of ElasticSearch under Magento 2.4 - https://github.com/yireo/Yireo_RemoveSearchLesser known Magento repositories;
https://github.com/magento/community-features/issuesNew Config Product - select simples manually - https://github.com/magento/community-features/issues/208 - also note extension https://github.com/PiscesThankIT/ThankIT_ConfigurableWizardDisable modules per environment - https://github.com/magento/community-features/issues/126PHP 7.4 preloading support - https://github.com/magento/community-features/issues/98Transcript
Peter Jaap: Hey, how are you?
Jisse : Good, so this is the day after Adobe Developer Live, but yeah, we just had to admit that we didn't spend the whole night just attending that event, so you didn't do anything at all with it, right?
Peter Jaap: No, I had my day off yesterday, so I was focused elsewhere, I didn't watch any presentation, but I got to use it.
Jisse: Yeah, so actually, the program started at 3:30, I think Amsterdam time, so at that time, I wrapped up a meeting I was in and then just tuned in to the opening keynote, andI had a couple I needed to drop in and out of the whole program, but I think I got a couple of good points out of it. Yeah, so don't we develop a live, the first time actually that it was no longer just a Magento event, but also an Adobe event, so to me that's kind of like the first interesting point about the whole thing that was labeled Adobe developer live and then column Magento Commerce as in maybe there's going to be a lot more other Adobe developer lives, but then focused upon other areas of Adobe. Still, this one specifically was for Magento Commerce.
Peter Jaap: Yeah of course
Jisse: So I think there was the usual talk about the route map not necessarily, or at least I didn't hear about Magento 2.4.1 necessarily, it was just over all what kind of developments were happening. So, I listened to a couple of them, a couple of features were added to PWA studio or are going to be added to the PWA Studio, which is kind of my thing, Product Recommendations and Internationalization GraphQL stuff. It was kind of interesting to see that it was no longer just a Magento thing but also an Adobe thing, and I've been personally intrigued about the introduction of React Spectrum, so I heard about this over a few months ago.
React Spectrum is a react vAriation of Adobe spectrum and Adobe Aria and Adobe Stately. Adobe Aria and spectrum are basically UI component libraries that allow developers to just focus on maybe the features instead of the UI, but its kind of feels like it's all related to the Adobe experience cloud so not necessarily related with Magento but still relevant. I think to anyone who wants to combine Magento and Adobe experience Cloud more and more. So yeah, to me, it was kind of interesting to see the direction instead of the technical details reading from that.
Peter Jaap: So, this all going to be part of the PWA studio or is it separate from it?
Jisse: Well, that's a huge question mark for me, but my feeling is that the React spectrum is separate from PWA Studio. So, it's just a separate Library also developed by a separate department.
Peter Jaap: PWA Studio was implemented.
Jisse : Well, that's one of the bigger questions because in road map of PWA studio, I noticed that there's a checkout coming, and then within this checkout, there's an integration with PageBuilder so that people can use PageBuilder to add in specific content types within the checkout system. I'm not sure how much of that PageBuilder is going to be integrated with experience Cloud, but I was under the impression that on the long run, this integration should be happening. So, PageBuilder picking up on logic and picking up on UI possibilities basically of Adobe Experience Cloud. So, with that, theoretically, React Spectrum and Aria would be part of the possibilities as well, so I dived into the technical part of the react spectrum and react stately as well, and to my impression, it's just another UI component library, it is just another set of collection of hooks. Still, then as a reactive developer, if you're into react, the next thing, it's nice to see that there's some kind of UI components library that you could just use and likewise react stately is all about hooks. I didn't look into the practical application of this yet but the other, theoretically, it could be combined with PWA Studio.
Peter Jaap: All right,
Reitsman: so I was kind of eager also to join the DevExchange discussions, but I think that only kickstarted really in the middle of the night, so, I saw a couple of other community members from Europe joining, So I believe they are still sleeping in today and then there was this other tool which I didn't see myself in a talk. But I saw some tweets about it, the Safe Upgrade Tool which is supposed to kind of like inventor eyes your current Magento system when you're looking for an upgrade, but well, that sounds fantastic that maybe there's a gold scan to check for whether the goal that you're running is compatible with the next Magento person that you want to upgrade to but that's kind of like hearsay because I didn't find anything on the web yet. I didnât find anything concrete about this, so what exactly is the study all about?
Peter Jaap: I did a quick Twitter search on it right now, and I see a tweet from Tadgh Bowe. He tweeted out this diagram for the Safe Upgrade Tool, apparently from the presentation itself from Developers Live, and it shows an upgrade from Magento 2.3.6 to 2.4.1 and then put the Self Ypgrade Tool in the middle. It will compare and validate, it will give you a list of issues and a complexity score and then a big block that says code fix. Iâm hoping it will be automatic, but there's nothing and then a big checkmark with the successful upgrade. So, if we look at this diagram, it's going to be very easy. I don't think so, though. So, it says, okay, quickly by focused efforts in identifying conflicts between a new Magento version based on that description. I'd say it has a lot of similarities with the upgrade patch helper by Ampersand. I don't know how many updates we did for our clients. So, I'm assuming that the Safe Upgrade Tool will work pretty much the same as the upgrade patch helper from Ampersand. I'll explain what that one does. What you do is you upgrade the Magento core within your project, before you upgrade, you move the vendor dir to vendor_orig or whatever you want to call it. Then you run a diff on the entire vendor versus the original vendor dir, then the diff will deal with the updated Magento version. Thatâll give you a giant patch file, and then you install the upgrade patch helper, which is a PHP file, and you point it towards your Magento installation and you give it the patch file you just created, and then it will spit out a list of all the plugins or themes that have changed or touches files that have changed between the two Magento versions. So, for example, it will give you a type plugin. It will say in the block on the page that PHP has a plugin that is in the âŠ. and that touches PHP code that has been changed between the version that is currently running on and the version that you've upgraded towards. So, this might introduce conflict, and then you can walk through the diff to see whether something changed that file that is relevant to the customization being done by either your own or third party module. So, we've done this in the past. I don't know how many, let's say 50 upgrades using this system, and yeah, it pretty much catches everything if you go through the list thoroughly. You check the code of the extension; you might need to install a newer version of the extension if it's outdated, or you might want to fix it yourself. So, once you've reviewed all the items that are in the patch file, then you are good to go. So, we haven't had any big problems with stuff that we missed or something using this approach, so I'm guessing to say itâs going to be the same. So, you'll just generate a patch file, a diff file between your old version, a new version, and then it says ok: these are the files you should check.
Jisse: On top of it, of course, like after such a report has been generated, the nice thing is that you're still being guided on making the real modification. So, theoretically, if you make a certain preference or a plugin Interceptor that needs to be changed, we still could have software that is reporting, which specific line is depending upon a certain class that is spaced out or a certain interface that is no longer there or deprecated code. So theoretically, this software also make reports.
Peter Jaap: You think it will be instead of just saying, hey, look at these files. There's a change in this file. It will go into the file and use tokenization or something to see which method has changed.
Jisse: Well, theoretically, I don't know. Still, it's just that it is kind of interesting that if you zoom into why a certain Magento upgrade would be difficult, step one, letâs say -p2, if it drives your own goals, your codebase, your modules to see like where the pinpoints might be, and that's basically where this composer patch helper might comment that the ⊠sent the link that you mentioned. Still, then on top of it, more things could go wrong. So reporting on semantic versioning, reporting on deprecated code so that I guess them that in the last half-year, we hear or so more of those tools came to light that is simply aiding developers to do their task for operating, theoretically this substitute was trying to combine maybe as many as possible instead of just one. Yeah, I don't know if it's real.
Peter Jaap: Let's see what they come up with.
Jisse: So, we're still to playing judge guys that might be intrigued by news. But well, it's hearsay until now. We simply want to do with wait and see the stuff for real before we can judge upon it.
Peter Jaap: Yeah, Jamie Huskisson from JH tweeted today. They've advised on creating this Safe Upgrade Tool. So, Jamie can give us some more information about it.
Jisse: I just wondered whether we should discuss the upgrades towards Magento 2.4.0 or actually that a lot of agencies out there do not upgrade to 2.4.0 but actually wait for 2.4.1 to be released. Agencies like yours; we discussed not to have that discussion. Well, maybe we shouldn't have the discussion. Still, it's kind of interesting to see that maybe this Safe Upgrade Tool hooks exactly into that pain point that a lot of agencies are scared to upgrade, instead of upgrading to a more stable version, a lot of times the opposite is true. Hopefully, this release of software will be well one of the many steps to come to make it easier to operate or have you given up?
Peter Jaap: We haven't given up. I'm just skeptical that you know, the reason why we skip a dot over it and is because we feared introduces a lot of new bugs, and so there's a regression there, and I don't think the safer bread tool or will address those regression issues. Yeah, it will probably identify any compatibility issues between any plugin preferences, overrides Etc, and not per se yeah bugs introduced in a new data version because there's a lot of new functionality. So, I don't feel like a Safe Upgrade Tool or upgrade patch helper makes it more comfortable for us to upgrade to a dot 0 version. Yeah, simply because it doesn't scope out the bugs.
Jisse: So, the thing that is for me a little bit worried about that approach. I wrote a blog post about this and then last time during episode one. We also discussed a couple of the features that were introduced in 2.4.0, but 2.4.1 is coming out actually with a lot more features, and it seemed to us the last time that most of the effort that was put into 2.4.0. The current release was actually to remove my SQL as a search engine and introduced therefore as well as the only option elastic search that was kind of like the breaking change and the worrying thing for me is that the 2.4.1. is going to introduce more features instead of just the introducing bug fixes. Then actually 2.4.1 might be your 2.4.0. so that you need to postpone upgrading to 2.4.2. and where does it end, I was wondering?
Peter Jaap: Because at this point, we can just install 2.3.5-P2, but if 2.4.1. comes out, we won't have a 2.3.5-P3 obviously, we will only have a 2.4.0-P1.
Jisse: Do you know that for sure there is no patch three coming?
Peter Jaap: Probably no, Magento has never communicated any such strategy, they'll update the security-only release for the previous version and not for another version back.
Jisse: Yeah, sure, except for maybe theoretically, if there's a security update or some giants coming but yeah, we don't know or youâll say out loud that as soon as 2.4.1 is coming out 2.3.5 will be simply just skipped drop Barrel.
Peter Jaap: Maybe they'll create 2.3.6 then just to keep the 2.3-branch alive, I guess they'll do that. So maybe we can upgrade the 2.3.6 at that point if 2.4.1. proves to be another giant update even though it is a patch version of grade. Magento is of course, known to still introduce functionality that will look like a patch upgrade.
Jisse: Yeah, that's basically also my point that many the agencies out there are making that decision upon to 2.4.0 is a major release. Still, then major is meant as in maybe this Semantic versioning kind of major, but it could very well be that with 2.4.1, which is just another marketing release, many other features are introduced. So, with actually new major versions, I think like the difficulty with Magento currently is that we're still kind of like dealing with these major upgrades. So, 2.3, 2.4, 2.5
Peter Jaap: Other major upgrades from 2.3, 2.4 shouldn't be major in terms of the amount of code that's been updated. It could be one tiny change That's not compatible there, for you have a major release necessary to put that out. So a 2.4.1 release could be in terms of code affected a hundred times bigger than the 2.4.0. release versus the latest 2.3 release, so it Just says okay from now on, we're not backward compatible anymore. so you're right 2.4.1. could be potentially a lot more dangerous to upgrade to in terms of regression bugs than 2.4.0 was.
Jisse: You don't know beforehand. So actually, this comes back to the original point this substitute might be really interesting and could have a little indication.
Peter Jaap: You could check the GitHub to see 2.4.1 release line or what is stacked with that, but it doesn't give a good overview of what will be in there.
Jisse: No, I've tried this actually with 2.4.0 coming out and back then also 2.3.0 coming out, and it's just a nightmare to go through all of those catalogs. So hopefully, this is also still something that's going to be improved within the Magento distribution mechanism. Let's put it that we also still looking into that is my little experiment of last week. I worked for about a couple of hours to try basically to remove ElasticSearch from Magento 2.4. To me, itâs kind of like a funny like everybody at Magento was working hard to make sure my SQL full-text search is removed at 2.4 and then the ElasticSearch is the only alternative. Still, I put together this little open-source module simply labeled also remove search because it's not only removing ElasticSearch, but my SQL search as well. It was kind of like a silly experiment, but I'm running a shop myself that doesn't need a search. It doesn't deserve Magento either, but it's just for history's sake that I'm running that shop on Magento but then I felt okay. I just need to remove the search all together instead of just adding the ElasticSearch for a shop with about 50 products. So it made more sense to remove stuff, for me, It was kind of like educational research as well to simply see also how many bindings there are between core classes and the search mechanism, which shows like the stuff that still need to be cleaned up to allow for ElasticSearch to be replaced with yet another search engine
Peter Jaap: But isn't layered navigation also tied to a search implementation?
Jisse: Yeah, in some way. So, what I did in my module was also instead of just going from ElasticSearch to obtaining a collection of products. I simply used the product repository to fetch such a collection, and that's kind of like The same logic that layer navigation would do and I tried to do the same thing for GraphQL as well because underneath the GraphQL product search is also based upon that same mechanism but haven't tested it out there yet but it simply shows that a simple search within Magento is hooking into we left the search at this moment far too often so that it's kind of like really hard to replace ElasticSearch with solar or Sphinx or anything , we're just kind of like a cool little experiment to see how far I could get some. Well, it's a success because I was able to remove the ElasticSearch together.
Peter Jaap: But isn't that layered navigation also tied to a search implementation?
Jisse: Yeah, in some way. So, what I did in my module was also instead of just going from ElasticSearch to obtaining a collection of products. I simply used the product repository to fetch such a collection, and that's kind of like the same logic that layer navigation would do and I tried to do the same thing for GraphQL as well because underneath the GraphQL product search is also based upon that same mechanism but haven't tested it out there yet but it simply shows that a simple search within Magento is hooking into we left the search at this moment far too often, so that it's kind of like really hard to replace ElasticSearch with solar or Sphinx or anything , we're just kind of like a cool little experiment to see how far I could get some. Well, it's a success because I was able to remove the ElasticSearch together.
Peter Jaap: All right, cool. So, the next one on the list. Many people use composer patches, of course, to fix stuff in an older Magento version of which there's a PR and get up. You want to patch it up. So, historically there's a cweagans, composer patches plugin that is used a lot in the Magento world, but it's a platform-agnostic composer plug-in. Basically, what it does is after you install a certain package, it will then run a patch file, which you have placed on wearing your git repository, and the patch file will update the file in your package with the diff in the patch. So, we recently ran into an alternative for the cweagans composer patches plugin, the Vaimo composer patches of Vaimo, a large Scandinavia based Magento agency. They created a composer patches plugin. Well, I think you can use it also platform agnostic, but it's very useful with Magento. It offers a few extra options on top of the cweagans. For example, it will search patches there, so you don't have to place your well explicitly list your patches in the composer.patches.jsonor in the composer.json itself. You just put it in a folder, and it will recursively search through four patches in that, you can also add links to GitHub issues Etc. You can define versions, so only apply this patch when this package has a certain version or is the version is older than a certain version Etc. So, it has a lot of cool advanced use cases. We completely switched to the Vaimo one. It also has some commands to run the patches separately from the composer install command. Also put it on certain platform requirements only apply this when the shop is run on PHP 7.3 or whatever.
Jisse: So you can install all the patches in a certain directory because this is the same issue that I'm bumping into with cweagans, but we are good here.
Peter Jaap: So, with a copy, if we have a patch that is applied to multiple shops we can just copy the file in, and that's it. We don't have to open up the JSON anymore. You'll just use annotations like at level, at the label, at the link. On the top of your patch file, the vaimo composer patch will automatically bring the metadata, and then apply the patch to the package or installed. That's pretty cool. I also created a small it was a grease monkey temple monkey script, and Lewis Voncken, from Experius created a Chrome extension for it. So, you can find the Magento 2 composer patches helper Chrome extension. What it does - if you open a PR in the Magento repository, you'll see a little button next to the edit button that says View patch JSON, you can just copy-paste the created JSON into your composer.patches.json file and if there is none you can take the patch file from the raw patch file from the GitHub repository, you won't need to have the patch file in your repository. You can just point it to the source, to the Raw patch Source on GitHub and then it will pull it in whenever you do a composer install, or a composer patch apply. So, in that case, you edit your JSON file, but you don't have to add the patch file because you will download it from GitHub. So that's you can just copy-paste the JSON. You only have to replace which package it is because we can infer that from the pull request. Sometimes it's a unified diff. So, it touches more packages so then you'll have to edit some stuff, but it will tell you in the JSON, it generates comments itself. So that's a nice little helper that uses the addition of a package from a Magento PR into your installation.
Jisse: Yeah, maybe to explicitly mention on top of what you just mentioned. It's also meant to create exactly those patches used for Vaimo, the composer patches plug-in of vaimo. So it's kind of funny for me to see always that all of these tools are built on top of each other, but we started all story by mentioning that we don't want to upgrade to the latest release; instead of it might be better to implement certain composers patches and then you need a tool for that learning. You need to improve the tool on top of it.
Peter Jaap: So, a little gotcha when you move from the cweagans composer patches to the Vaimo composer patches: the Vaimo composer patches is less forgiving when it comes to extra data in the patch file. So, I usually create a patch with git format-patch and then now you have to add âno-prefix --no-signature to the format patch command because otherwise, we will add this little signature at the end of the patch file and Vaimo composer patches doesn't like that. So, when migrating, clean up the garbage at the end of the patch file to make it work with the Vaimo one. Also, cweagans composer patches tries to apply patch level 1 first, followed by Patch level 0 and then Patch level 2, 3, 4, etc. Vaimo doesn't do this. It will only try that's level one by default, so if it's Patch level 0, you have to define it yourself with that level.
Jisse: So that's again. That's a task that you would typically include in the past file now.
Peter Jaap: Yeah, so beware of the patch level especially when you get the dev contains the a / b / prefix when like GitHub does that,
Jisse : I would say that there's any way for better soon as you download better-created patch level yourself. You always need to be aware of the best level itself.
Peter Jaap: Yeah, if you get the PR from the Magento repository, you'll always need level 5 because it has the app code etc prefix in there.
Jisse: Exactly, that's again something that is Chrome plug-in is automating, right?
Peter Jaap: Yeah, automatically will add the at level 5 in there.
Jisse: That's cool, I also came up with this other tool, the Szeidler composer cli, but you have just looked into the cweagans story again. So well, the vaimo solution allows you to have a compulsion patch folder the cweagan approach requires you to add each individual patch to the composer.json file, and that's actually where this tool also comes in the Szeidler. I think I'm pronouncing its name right as Szeidler simply allows you to do that more easily. Still, if I've now heard about this vaimo approach, I've heard about it before, but I've never implement that myself. It sounds like we just a lot easier than the other
Peter Jaap: So much easier. It's a great tool especially if you work on multiple projects, you can just copy-paste, either the patch file or the JSON patch, which will download it from GitHub automatically, and then it just works, and it's great.
Jisse: Yeah, so anything else you would like to add?
Peter Jaap: Yeah, so I have another extension I ran into, which proved useful in a couple of client projects. So, it's called the Baldwin URL Data Integrity Checker, especially when you migrate from a Magento 1 to Magento2, the URL keys and URL paths, could prove problematic when you know garbage in, garbage out. So, with this extension does the work. Once you install it and has a few commands on the command line. Few commands catalog category Integrity check and catalog product Integrity check, and it will check for duplicate URL keys or URL paths that are out of sync with your URL keys. So empty URL key values all kinds of checks. So, it's a CLI command, you kick it off, it will populate some JSON files, and then you can view it from the back end. You can also configure it or to run it periodically. So, you can just install it and have your clients. Check it once in a while whether your real data is still okay. if it isn't, then sometimes you might have problems with safe and products because to duplicate your URL keys, they can't fix their shit themselves.
Jisse: So, to my understanding there's this kind of Loco hooks into something else you've created earlier. The elgentos regenerate getting more equal. Yeah. Well, right.
Peter Jaap: Yeah. So, they regenerate catalog URL, one is actually, forgot the name. It was forged from ESL, ISL, so it will add a command console that will regenerate your product URLs, and you can give up product IDs and scopes / stores, and it will regenerate these URLs. So, we usually install the Baldwin agency URL data Integrity Checker extension along with our regenerate catalog URL extension along with the FisheyeHQ URL rewrites Optimizer. So those three. We put in pretty much every install, and that will allow us to check for URL data inconsistencies and regenerate them as necessary.
Jisse: Yeah, So in Magento, one of the most horrible things that kind of like often happened was that product URLs and category URL were just regenerated again, and again, and again when dealing with product categories being imported from external resources. In Magento 2.0, I had that issue myself as well 2.1, as well 2.2, but then in 2.2 kinds of like halfway, it disappeared. It was for sure that I had not worked on myself that much, but it was kind of like that. I heard complaints about it. is that still an issue that you bump into or not necessarily?
Peter Jaap: we haven't run into that issue that I can remember with Magento 2. Yeah, I thought it just disappeared. Yeah, since we migrate everything to Magento 2,
Jisse : yeah, it is still possible but then only if there's a kind of like a bar being clumsy import mechanism as well.
Peter Jaap: We sometimes run into it with Magento 2 shops. We haven't migrated, but every single time it was because they migrated the URL rewrites from Magento 1 to Magento 2. So yet again, garbage in, garbage out.
Jisse: Yeah, So cool. it's already kind of like a long list of different ideas, different extensions, different tools to help developers. Do you have anything else you want to mention?
Peter Jaap: Yeah, I wanted to. I ran into the Magento / Community features repository on GitHub. So, github.com/magento/communityâfeatures and that's very interesting repositories just issues with faults for features by the community.
Jisse : In our discussions, it's just perfect for reading through it and get kind of like a glimpse of what the core developers are up to..
Peter Jaap: So one of the oldest issues there with the most comments is one again by Tadgh Bowe.
Jisse: I'm just getting destroyed by this guy if we keep mispronouncing his name. It's âTykeâ.
Peter Jaap: Tadgh, so Tadgh has an opened like the new configurable product. You create a configurable product in the backend, and you want to create variations and but your simple product your children already exists. There's no way to hook them to the configurable product. You have to generate them first by choosing the attributes on which you want to create symbols for and then basically generate them and before you save them, you can manually add the existing ones and then remove the ones that were about to be saved. So, it's a cumbersome, not very logical workflow to attach existing simple products to a new configurable product. So, he opened this issue in November 2015. So almost five years ago. It still hasn't been resolved but and this is the interesting part, somebody named Pisces ThankIT created an extension of his name, I don't think he's called Pisces. But there's an extension called ThankIT configurable Wizard, and this adds once you move through the Wizards to select attribute and then give it attribute values. It will add a step to manually add the products yourself so you donât have run through the entire process and remove the other one. So, this is again small little extension that adds that option show to make that workflow Bliss a little less awkward. They might fix it in future versions, but for now, this extension does exactly what you expect to happen when you go into this workflow
Jisse : There is all kind of interesting to know of right that this repository addition community features repositories full of ideas. So, it's not necessarily features that are going to be implemented in Magento in the next version, it's more that they're sort of specific place for the community to collaborate, elaborate, discuss what kind of potential features there are because yeah, that's another one that you put on the discussion list number 126 disabled modules per environments, and it fell to me kind of like an old story as in well, of course, it's a needed feature. Still, going through that's, I just scan through the whole issue itself. The discussion date back to 2017 and 2018. So, what is your take their own? It's all about how to disable modules for a specific environment. So, development environment, production environment and of course, all of those changes are normally written into the config.php file. There's more to it.
Peter Jaap: Well, right now, if you enable or disable module or an extension, it will be saved in the app ads config.php file, and so it's either disabled or enabled, but for certain extensions, you only want to have it. So, there's a let's say there's a Magento extension that's in your composer require dev, so your composer require dev like the example in the Fred is the HO template hints extension. So, you're needed as then you enable it, so then it will be enabled in your app ads config.php file. So, you commit that to get, and then you deploy your web shop. So, on the production server, the HO template hints extension will be enabled or disabled, but we'll have an entry in the app ads config.php even though on the production server, there won't be any code for that extension present because it's the dev extension. So the proposal in this fret was to have or to move or have the option to move or override the enabling or disabling of certain extension in enthalpy HP, so for example, put app ads config.php that will have a chart template since disabled and then in the efforts and the PHP on your local machine that you will have it enabled.
Jisse: Yeah, maybe you could comment on that as well because there used to be a time that if there would be a module in config.php that was enabled but that module was actually not found by the system. It will generate an exception but that time has long been there.
Peter Jaap: They remove that exception exactly because of this problem.
Jisse: Yeah, exactly.
Peter Jaap: Yeah right now it's not a big problem that is mentioned in in config.php, but it feels dirty .Right now, let's say I enable it locally but we have it in git as disabled. So, then I enable it locally, so every time I have to enable it locally and then run the shadow upgrade maybe again so that there's a the workflow isn't perfect for local development.
Jisse: Yeah, and the annoying thing is in it, like every time that you run the commands within Magento module enable module disable. It will modify the config.php file. So, it will redo or undo the change that you've carefully just crafted together and they are just annoying. Yeah, so that definitely could good discussion, but you simply wanted to mention it because it's be a good discussion as well even though there's no logical outcome
Peter Jaap: I want it and it's been opened in 2017 and mainly because back then it would have thrown an error and not anymore. It feels like such a logical implementation, like a lot of other Frameworks support disabling modules per environment, but Jesse doesn't
Jisse: I don't see a pull request on your behalf.
Peter Jaap: It's not that big of a problem yet, I might as basically become annoyed by it and then spend my Sunday afternoon to do this, but I'm happy to give it an up for grabs level and let somebody else do it.
Jisse: Yeah, then the next be there's another really interesting one, the PHP 7.4 preloader support, so once I started to read about PHP 7.4 I became right away as I think about the preload feature. So, it's something if I say correctly that hooks into the opcache for the next details just to make sure that when the application is being loaded you can just come up with your own preloads file that you need to put together so that all of the relevant files all of the relevant PHP classes for instance for code Snippets that are guaranteed to be call upon are loaded into the opcache. So, once PHP 7.4 came out. I was also one of the few people that then trying to play around with this, Magento 2.4, 2.3 didn't support PHP 7.4 yet. So, it was kind of like working with a half broken installation as well but yet the issue that you basically refer to was also links to I think actually the work of a guy called Kehil who's actually kind of important and I know that he played around with it and also classifying it as a simple but back then actually PHP 7.4 were still not supported yet. So, for me Magento 2.4 would be ideal to play around with this again.
Peter Jaap: They did already implement in 2.4.
Jisse: Yes so they implemented the opcache preloader or because still, you need to configure this preloader in your own PHP configuration to make use of it.
Peter Jaap: Yeah, so it'll probably need some console, command or whatever to generate the file that you need to preload it so that the Kirill has comparison where PHP 7.4 with preloading is 11 percent faster than PHP 7.3 without preloading, of course and then somebody refers to an issue and a pull request that says we've implemented it here and just looking at this giant pull requests and it's giant and I can't find anything that actually generates the preload file for PHP. So, I'm not sure whether it's actually it supports it that's what it says. We supported it in PHP 7.4 we can really see whether the preload file also being generated by now
Jisse: Yes, that is like an interesting thing to take a look at and I think the discussion is anyway interesting to see like what kind of pros and cons are there to consider these features but yeah, so I personally think that the PHP 7.4 preloader is not the serving something that you can just define for all of the Magento installations out there. It seems almost like it's it needs to be custom created but theoretically it could be generated as you see a like usual simple console or command.
Peter Jaap: Yeah, I think you can definitely create something that will do it on a pre installation basis and will generate a file, but I also think that that you can create a default file for the Magento core so it won't necessarily preload everything from the third party extensions for your own custom extensions, but it will definitely then do Magento. So as far as I can see there's now only support for it. So, they updated the classes for PHP 7.4 to make Magento to work with PHP 7.4 and for the preloading part, I think you can generate or create some kind of tool that generates the preload file and then walks through the code in the current installation and generates file specifically for that installation.
Jisse: Yeah, maybe to comments all my own experiments showing in the past what I tried to do was simply just in Instantiate or not instantiate, load all the classes that were to be found in the Magento, so that's kind of like a lot of different classes and all just to generate also those classes as know opcache entry automatically, but that's actually a performance optimization for the worse because then you're just adding classes to the opcache, that actually not going to be called upon and that's kind of like the interesting parts and that it's only really an improvement of the situation if you can say actually that all of those classes are actually going to be called upon in runtime, in real life, on your frontend or develop your backend and that by moving them into the opcache and the memory grows but the speed goes up.
Peter Jaap: Yeah. So, for example if you use the composer dump autoload and then use the class map of furtive argument then used the autoload Class map PHP file as an input for preloader for the preload of the PHP file.
Jisse: So, itâs not optimized
Reitsma: No, better optimizing would be just to create a tempest file system and just prove very true that they move everything into around
Peter Jaap: Well, there's also an approach for it, maybe you could run like a new relic or a Blackfire for a while, let's say for a day or two on your production web shop and then it will generate a list of all the PHP files that have been touched and then create a file based on that?
Jisse: Something similar. Also, just a partial listing of all of the modules that are enabled and then actually try to determine which kind of classes are actually also call upon all the frontends. So that might be and then theoretically just spidering across all the dependencies that are loaded with it, but they have it so it's not that straightforward. So, coming on with the coral listing maybe just loading, preloading most of the classes in the framework because every time when you load something in the BOOTSTRAP, thatâs adding up, there's a requirement for those classes but theoretically, another approach is of course just look at the output, create a simple block class, declared classes and just do rundown of all the classes that are called upon by using a certain frontend block, but it's a little bit more cumbersome. It's a little bit more taking effort than just adding something bluntly to it, but then still like it. It's all about performance. So, the kind of thing that could really cool feature to discuss and to see it and look forward to within a Magento to work.
Peter Jaap: Yeah, definitely.
Jisse: Alright long listing.
Peter Jaap: Let's wrap up.
Jisse: Hmm. Yeah, I have fun.
Peter Jaap: Definitely me too. I have a bunch of things to talk about in the next episode
Jisse: I hope everybody listening is also eager to hear another episode 3. We need to come up with a good listing of what to discuss and what not. The current podcast were kind of like deployments composer patches and everything thatâs flow flew from us but yet we will focus upon the specific topic, specific area of backend developments in the next episode.
Peter Jaap: We could, if any listeners have any suggestions on which topic but I'm just as happy to talk about whatever comes up.
Jisse: Yes.
Peter Jaap: Thank you, sir. Thanks everybody for listening.
Jisse: See you next time.
-
Show notes
(full transcript below show notes)Yireo - The unstable release of Magento 2.4.0
Magento Semantic Version Checkerhirak/prestissimo
Composer 2
narrowspark/automatic-composer-prefetcher
Magento 2.3.5 + Content Security Policy (CSP): A Fool's Errand
Private Packagist
Satis
Magento 2 Marketplace Mirror by Fooman
Ivan Chepurnyi on Twitter
Stephan Hochdörfer on TwitterFull transcript
PJ: All right, everybody. You're welcome at the first Registry podcast. The Registry podcast is done by me, Peter Jaap Blaakmeer
Jisse: And me, Jisse Reitsma
PJ: We're two Dutch Magento developers. I run an agency called Elgentos, and Jisse what do you do?
Jisse: I run an agency called Yireo and what I do is actually I'm not a real agency, but more like a trainer of developers.
PJ: Yeah. I've actually received training from you.
Jisse: Yeah, you did, right? So, sometime back on react. So yeah, I'm kind of busy with a lot of front end stuff, but I think the initial thoughts for this podcast, the Registry is to talk about back end development instead. But yeah, it's your ID so why is it called the Registry in the first place?
PJ: I needed a name that struck a chord with Magento developers and since the Registry is deprecated in Magento too I thought, âLet's just re-live the name if we use it.â
Jisse: Yeah. So the Registry really feels like old. To me, there's also this reminder towards the old Windows age. I'm not sure if Windows is still using a registry. I donât know anymore.
PJ: Isn't it register, like register.exe?
PJ: Well, it's register.xe or it's referred to as the registry, I thought. But anyway, there's a podcast now called The Registry.
PJ: Yep. And we're going to talk about, well, you said mainly back end development and I guess that's debatable. I'm a back end developer first and foremost, you are originally a back end developer, but you've gravitated towards the front-end a bit more lately.
Jisse: Yeah. Well, and that's maybe also because there's kind of a need within the front end developers to discuss, basically the alternatives that you have for Magento 2 front-ending because there's a lot of things to tell about the Magento 2 frontends. I simply just dive into it a little bit more. But yeah, maybe that's the whole idea about this Registry as well, to talk about interesting stuff to either back end developers or front end developers.
PJ: Yeah or front end stuff for back end developers, which is hard for us.
Jisse: Yeah or back end stuff for front-enders.
PJ: I always have the feeling that's easier than the other way around, but that might be my bias being a back end developer.
Jisse: Yeah. Yeah. But yeah, let's keep the current episode one a little bit focused on back end development stats, but also maybe it may be some general news. So I think when discussing what kind of topics to pick up on I think it was kind of obvious to tell at least a little bit about Magento 2.4, which was just released one week, two weeks ago. I don't know anymore, but recently, a little bit longer, right?
PJ: Yeah.
Jisse: Time flies. But anyway, instead of just doing all of the marketing fluff and saying like, âOh, Magento 2.4.0 is wonderful. It's great. You should upgrade. I think in this podcast, we want to be a little bit more developer minded or honest or
PJ: Critical?
Jisse: I think so, yeah. So there are multiple features like the MSI performance that went up by refactoring a lot of things. There was this storyline on Twitter telling basically that the dozens of queries were all reduced back into just a couple of queries needed on the front end. Well, that's of course, good news, but it also makes you wonder whether the MSI package was before 2.4.0, then not just really a performance hog.
PJ: It was.
Jisse: Yeah, apparently. So, it's good that it is fixed. Well--
PJ: Have you worked with MSI a lot?
Jisse: No, actually just a little bit, just trying to integrate things with it. But, yeah, I have to be honest, I'm a trainer, so I'm not really diving into projects myself that much, and if I do, that's always a specific area and unfortunately, MSI is still on my to-do list because I like the codebase. I like the way that things are set up in a clean way, that a domain-driven development is implemented and then IDs, like CQRS come into being, but I have to admit that once I see all of this functionality in the codes, I wonder also how difficult it is to configure everything in a real-life project.
PJ: Yeah. Well, we've played around with it. We did one implementation and it kind of backfired at that point because we had some synchronization issues with an ERP coming in and then you have to disable the stock reservations and they need a separate extension for that. So it got muddy at one point and we decided to take a different approach. So in the end we don't use MSI at this point in time, so I can't really say anything about the performance in 2.4.
Jisse: No, but youâre saying currently then you're using the old catalog inventory?
PJ: So basically, yeah. We pull in necessary information from an ERP when we need it and where we need it, but it's not integrated in MSI.
Jisse: So, what I wonder about all of the new features that come into Magento more and more and more is whether all of those agencies or whether all of those developers and merchants out there actually need all of those features at all. Some people do, and of course, it's a wonderful thing that MSI was developed and that there's so much opportunity suddenly with all of those modules. But there's still, I think also a lot of merchants out there that only need a simple inventory management, so basically the old catalog inventory. And now that's slowly being deprecated, which makes me wonder, like, okay, but is the community then maybe able to pick up on maintaining such a simple inventory for a longer time? I think it should be doable, but there still needs to be somebody to pick up on it.
PJ: Yeah. I'm curious to see when MSI will completely replace the old catalog inventory module. Not sure it will eventually happen at all.
Jisse: No. Well, a similar story that is there, of course, is that MySQL, as a search engine has been dropped in favor of Elasticsearch. And again, I think this was clearly announced by Magento as well in all of the release notes about 2.4. So I'm not blaming them for anything, but it's more that I wonder how many merchants are actually needing this and how many merchants are just frustrated about this because they still want to use the old MySQL search.
PJ: Yeah well, I thought the other way. I thought, âEverybody's already using Elasticsearch, let's just kill off MySQL full-text search anyway.
Jisse: Yeah. So, on the technical side, I think it's a good ID, but I simply don't know how many merchants would still be using the old search.
PJ: I think it's okay because Elasticsearch is very easy to configure. All the big hosting companies have Elasticsearch even in their cheapest packages, so I don't think that's a really big deal. MSI is a bit more complex to implement. So that might be a bigger barrier when you compare it with MySQL full-text search versus Elasticsearch.
Jisse: Yeah, exactly. Well, and other than that, 2.4 also ships with silly things like two-factor authentication, and I've seen already three modules two days disable that again.
PJ: Yeah, well, there's nothing wrong with two-factor authentication per se. The problem is that they kind of hardcoded it in the admin and kind of force it upon you. So a lot of developers who upgraded to 2.4 were unpleasantly surprised by this sudden hard requirement to do a, to have a 2FA.
Jisse: Itâs pretty cool that there are modules out there already to help you disable the stuff again as well.
PJ: Yeah, I figured it's great that Magento bundles 2FA with Magento, but it's not great that they force it upon you. And I get the reasoning behind it, but it's such a big struggle for developers to now get it started even on a clean install, that it might've been wiser to make it an option to enable it.
Jisse: Yeah. And then maybe another thing that is noteworthy is that there's a security text module for, I guess those people that are unable to just create a security built text file public folder. But it's actually leading me into something that was already there in 2.3. 4 or 5 CSP which stands for Content Security Policy, which is also a cool feature if you think about it, but it's just causing so many difference or warnings--
PJ: Horribly implemented.
Jisse: Yeah, itâs horribly implemented as well.
PJ: Yeah. Have you read Max Chadwick's post on CSP in Magento?
Jisse: I did, but I forgot--
PJ: He burned it alive. Yes. It's at maxchadwick.xyz I think it is? Yeah. He has a blog post on CSP and why it is a terrible idea, or not a terrible idea, but why it's a terrible implementation on Magento and how to disable it.
Jisse: So maybe it's a good idea to include a couple of those links that we talk about, and share them with the audience later.
PJ: Yeah.
Jisse: Yeah, so, further than that, I think there are a couple of things that might be related to performance when it comes to 2.4. So for instance, PHP 7.4 came out, or what supported now, MySQL 8 is supported like we mentioned--
PJ: We're running Magento 2.3.5 on 7.4 as well. So I'm not sure if it officially supports it now, but it worked anyway, and in the back end where something weird was happening, but we haven't run into any issues.
Jisse: But with my SQL 8? Are you also able to run that?
PJ: Nope, haven't tried yet.
Jisse: No, I believe that's actually something related to the customer authentication mechanism or password verification mechanism, or I should say password encryption mechanism underneath in MySQL. I thought that had to do something with that.
PJ: It's going to be interesting to see how fast MySQL 8 adoption will be because one of the big things in MySQL 8 is for a pure functional point of view, is the ability to store JSONs in MySQL. Iâm curious to see how fast extension providers will make use of that feature in MySQL 8 and force people to upgrade.
Jisse: Yeah. Well, other than that, like the performance of MySQL 8 is supposed to be a little bit better regarding read statements, so simply just to select queries. However, I saw benchmarks a while back, I think it was at the first release of MySQL 8, that actually proved that MySQL 5.7 was more performant than MySQL 8. So I'm just wondering whether the community indeed is going to adopt this as soon as possible. But yeah, so I'm personally maintaining a couple of modules myself and I think you guys are as well with the elgentos. And from my side, most of the work that I needed to do to make all of my modules compatible with 2.4, was just to upgrade all of the PHP unit tests which was kind of a clumsy thing because the rest of the code was working, but I still needed a couple of hours just to make sure that was compatible. I'm not sure if you experienced anything like any work needed for your own modules?
PJ: I'm going to let you in on a little secret here. We haven't upgraded to 2.4.0 for any of our clients. We tried to upgrade a few, and ran into some issues that everybody ran into. We looked at the growing list of bugs on GitHub, and we decided, âNo, we're not going to do a 0.0 release or a 0.0.0 release in this case.â We're going to wait it out, weather the storm, and we're going to upgrade to 2.35 P2. And then wait until 2.4.1 is released and then upgrade to that one.
Jisse: Yeah. So I'm seeing a lot of different features that are actually postponed to 2.4.1 but you're also saying that there are quite a lot of bugs, at least by monitoring the issue list on GitHub.
PJ: Yeah. And I've heard from Ivan Chepurnyi, that some performance issues, which, you know, everything is slow according to Ivan.
Jisse: He's always finding performance issues. Thatâs his secret power.
PJ: He had some stuff which made me rethink our initial goal to upgrade everything to 2.4.0. And, let's just say that Magento's history with 0.0, releases isn't that stellar.
Jisse: No, I hear this more with agencies that over time they basically learned from it. Well, I was there as well with 2.0, 2.1, 2.2, and I thought, actually with 2.3, that the whole thing improved pretty much. So I actually upgraded to 2.3.0. as soon as it came out and it was a little bit troublesome, but not a huge amount of bugs. And I honestly don't know about the States with 2.4.0, whether it's a lot worse or better or--
PJ: You know what I think the problem is with the 0.0 releases, every once in a while, Magento of course, needs to bump from 2.3 to 2.4 or whatever to do a double release. And they have to stuff it with new functionality, otherwise it wouldn't warrant a minor upgrade. So they focus on new features and I have the feeling that bug fixes are put on a sidetrack in that process. And then they pick up all the old bug fixes for 2.0 for the top of the one release again. That's been my feeling with 2.2.0 and 2.3.0. And, yeah, of course, the platform itself has become a lot more mature and stable since the 2.2 or even the 2.1 or 2.0 era, so there's definitely a big improvement in terms of stability. But stability is always relative, and if we can prevent some of these issues in the double release by just waiting it out for one version for one quarter, then we're okay with that.
Jisse: Yeah, so personally, I encountered issues with bundled extensions, but that again was mostly on the testing side with integration testing and unit testing. I became pretty angry about that and I won't name the vendor anymore, but, to put adults in the specific place, I was a pretty mailer about it. That's a reference to who it was, but anyway I was pretty upset because as a third party extension provider, I'm trying to do all of that work to make sure that the extension is fitting in nicely with 2.4. And actually, because I'm not an official partner, I didn't see any kind of pre-release either. So actually on the day when 2.4 came out, I worked my ass off just to make sure that everything was patched properly. And I prepared things, but I couldn't release my new modules because I didn't know the exact semantic versioning of all of the new stuff. And to me, it was kind of disappointing to hear that basically, some bundled extensions gave issues. So you also encountered issues there?
PJ: I think the bundles extension are the main source of problems. I totally disagree with what Adobe or Magento is doing there bundling third-party extensions in there in a core of Magento. I can see it from a commercial standpoint and I hope they earn a lot of big bucks for itâŠ
Jisse: They do.
PJ: âŠBecause otherwise, it wouldn't be worth the trouble that those extensions are introducing in codebase.
Jisse: Yeah. So I'm personally running a repository with replace packages for some packages from the core, MSI and etc., but also this replace package for bundled extensions. I think that's actually one of my most popular packages out there. And it's not even me because I believe that actually integer.net came up with that original suggestion.
PJ: Yeah, you stole it.
Jisse: Yeah, I simply stole it, but I package it in such a way that it was more useful. But it's kind of interesting to see that such a thing is needed. To me, itâs always funny that Magento as a commercial entity goes that far into bumbling basically all of those bundled extensions in Magento as a core, and then actually all of us community members try to get rid of them again. They make you feel like, "Hey, but is there maybe a different approach?
PJ: Less code is less complexity.
Jisse: Yeah, I think so. Well, the other news was that Magento also released their own semantic versioning checker just a week ago or so. So basically they used this tool internally to prepare the Magento 2.4 release just to determine what kind of Git commits were made on the repositories and how it would translate into new semantic versions for all of the different packages. And I think it's worth just to see all of those tools become open source, and hopefully, actually, that all of the third-party extension developers also stick with those practices. Similarly, like the PHP coding standards, or unit testing, integration testing. Still, it's basically all of those bugs in, theoretically, the bundled extension, but it might also be other extensions, all of those bugs that prevent people from upgrading basically shows also that there's still a strong need for better extension quality, I guess.
PJ: Yep. Okay.
Jisse: Yeah. So, what else is up?
PJ: Composer 2.
Jisse: Yeah, so I've played around with Composer 2 myself already a little bit, but not with Magento because I tried to do this, I don't know, like months ago already. Stephan Hochdörfer, he also communicated with the composer team on how to upgrade to Composer 2 and then make it work with Magento 2. Well, I tried to follow along, but it didn't work out for me and then I just let go for that moment. I haven't tried it since, but, yeah, it's said to be improving the download times tremendously. So that would be awesome.
PJ: Yeah. I haven't tested it with Magento either, but we have tested it on Laravel projects and yeah, the faster download times is of course number one, but package resolving is also a lot faster, the SAT resolving. Plus you can speed up your resolving by setting up - let's see how they call it. I can't remember what they call it, but you can set up like filtered repositories, where you can say, âI don't want this package from this repository, but I want it from another oneâ or you can use only or accept, so it doesn't search through the entire repository for the package you need. You can aim it towards a certain package within the repository.
Jisse: It sounds a little bit like the replace trick that we just mentioned, but now actually more on steroids. And I heard something before that the replace trick would have been removed also in Composer 2, but I didn't check up on that anymore.
PJ: Right, well, Composer 2 has repository priorities. So, if replace doesn't work anymore in Composer 2, you might be able to create your own repository with the exact name of those packages, and then place that repository as your highest priority, and then it will fetch and like an empty file. Let's say, if you replace the MSI module then in the exact pathway, would otherwise be written a file that says, "This package has been removed by the composer repository that's been added for composer notification or something. That's repository priorities. That's pretty useful because we have a third party extension we use from a vendor, we have their composer repository in our Private Packagist, and then we need our own fork of it. So now we have to rename the package and use the new package name, but then we can just assign a priority to our own repository packages-- It's pretty cool.
Jisse: Yeah, that's pretty cool. What does it feels like with Composer 2? they simply just listened to all of the hacks and workarounds that people try to make under Composer 1? So for instance, a pretty common tool nowadays with Composer 1 is prestissimo. But, yeah, that's becoming obsolete as soon as you are under Composer 2, but that's only for the download part, to parallel, the downloads. Yeah, and I read something about this repository priorities and I remember that I thought like, "Oh, this is creating cool opportunities", but I haven't played around with it.
PJ: A prefetcher as well. I didn't know about that one.
Jisse: No, it's actually not. It's not a Composer 2 related, but it's a Composer 1 plugin just like prestissimo, and it's basically trying to do a real prefetch of all of these different packages. So that's kind of like, the http2 caching mechanism is able to prefetch certain resources in faster ways, supposedly. But in Symfony project, I actually have used this and I experienced an improvement in Magento 2. I've already had a couple of times, that the Magento 2 installation, which actually stuck because of some kind of internal thingy that they're trying to do. So, yeah, there are third-party tools basically within composer trying to improve performance. But I think it's all done by just a couple of individual developers maybe, and trying to come up with smart things. But I'd rather just wait for also Composer 2 to come out with.
PJ: Yeah. So I'm looking at the read me and what the prefetcher does is you can tell composer to only look for packages, for instance of packages in a certain version release line. So say 2.X and it wonât look in 1.X. This feels like something that could be added into Private Packagist as well. Do you use Private Packagist or Satis or--?
Jisse: Well, I'm using my own Satis instance and I'm just using Private Packagist because of some companies like Elgentos.
PJ: We're a big fan. We'll Satis does the exact same thing basically, although and Nils and Jordi (from Packagist) are adding some pretty cool features on top of price packages, like security audits. So it will give a security warning if a package has a known vulnerability in a certain version, but prefetching... So this prefetching feels like a perfect addition to Private Packagist where you could say, âOkay, I want to have this package inside my Private Packagist, but I don't care about all the old versions. I just need free 3.X and upwards or some things to really speed up the SAT dependency lookup.â
Jisse: Yeah, exactly or something similar. So I played around with it. I tried to configure it a little bit. So the example in the read me actually goes with the symfony symfony and another package. So I tried this for Magento packages. But yeah, so in my case, it kind of blew up. It seems to resolve things in a loop or something. But yeah, and talking about Private Packagist, I played around with also the feature of mirroring the Magento marketplace, improving download speeds. Now, I thought it would be really like a click click system where you would say like, âOh, but this specific package, or actually all of the packages on the marketplace, let's copy them, download them and use them within Private Packagist instead.â I was a little bit disappointed that it didnât work exactly that way, but yeah.
PJ: I think you can because it will add the package to your Private Packagist subrepository as soon as you require it. I think you can also manually add it by putting in a composer.json or a composer.lock.
Jisse: Yeah. But then still my impression was actually that it would only just do--
PJ: It will do a full copy.
Jisse: Yeah, of a single package, but not all of the dependencies with a package either. So actually--
PJ: The problem arises when you have a username and password combination for a marketplace mirror. We have a bunch of clients with each have their own Magento marketplace username password combination because they purchase extensions in the marketplace sometimes even though we tell them not to, and then we need to get them from composer. So every client needs to have its own unique marketplace mirror within Private Packagist. So if it were the case that it would completely mirror it, then we'd have like thousands of packages. Yeah.
Jisse: Yeah. So how do you solve then this issue of a marketplace performance? You're not or--?
PJ: We try not to use the marketplace for extensions.
Jisse: Okay, but still for the core you're using it anyway.
PJ: Yeah. It does mirror it and catch it on Private Packagist.
Jisse: Of course, yeah. That's true. Yeah.
PJ: Once you've required it, it will create a mirror for the package you have required, just not for the entire market place.
Jisse: No. And it's actually pretty cool that it's kind of like catching on demand without you doing anything for it. So, in the past, Alan Storm wrote a long, long time ago, I believe it was really like five years ago or so, a tutorial on how to mirror the marketplace by using Satis. Then I played around with it myself and I wrote a followup blog on literally what to do to make this happen because Alan Storm is never just saying like, âWell, this is what you should do.â He's always writing a tutorial in-depth and just going as deep as possible. But yeah, the bottom line was that I had my own private mirror of the marketplace and I was amazed with how good the performance was. So instead of actually just hosting a mirror, like with Private Packagist in Helsinki or Stuttgart, or I don't know where the packages the mirrors are, but then I chose basically my own private VPS instead then the download times were just reduced to almost nothing. So that was pretty cool.
PJ: Right. Yeah. So you do know that Kristoff from Fooman has a Magento marketplace mirror, right?
Jisse: Yeah. But, I don't know, again also where his mirror is actually located.
PJ: Good point.
Jisse: The cloud?
PJ: The URL ends on .nz so it might be the exact opposite of the world.
Jisse: New Zealand. Exactly, yeah. And I think the main point about playing around with Private Packagist or playing around with Satis yourself, is that you could theoretically just reduce the download times because the Magento marketplace itself is definitely located in the US, I believe.
PJ: It's here in Kristoffâs blog. The mirror is using AWS infrastructure, including CloudFront CDN.
Jisse: Okay. So that would be pretty good.
PJ: When I traceroute it, it ends up in AMS 54 CloudFront. So in our case, it's actually being served from Amsterdam.
Jisse: Exactly. Yeah. And on top of it what Kristoff solution, Foomanâs solution actually has to offer is of course also removing the authentication of all of the open source free packages. So why authenticate if all of those composer packages are freely available anyway?
PJ: He does warn not to use it in production though. I guess thatâs more for security.
Jisse: Yeah, but that's just a disclaimer. Yeah, exactly. He doesnât want to be responsible for it.
PJ: âWhen I get hacked and somebody injects their own code into my repository, I'm not responsible. â
Jisse: Yeah, exactly. It's just to prevent that the whole community has come to the New Zealand guy.
PJ: He can probably see who is doing it. In access logs or something.
Jisse: Yeah, cool. And also on top of it--
PJ: I think itâs time, Jisse.
Jisse: Oh yeah. So yeah, it's already half an hour, you mean?
PJ: Yeah.
Jisse: Cool.
PJ: We tried to do half an hour but we can easily fill up a full hour, but I think--
Jisse: Or a half-day or something.
PJ: I think we could go on for weeks on end.
Jisse: Yeah, exactly. There's so much in this Registry.
PJ: But we have a ton about Composer left on our cheat sheet, but I think we could just move that to the next episode.
Jisse: Yeah. And I think this is also the goal that we tried to reach, right? Simply to have a nice little conversation between two Dutch guys that among them with the two of them know quite a bit. And then if you combine that all together, then hopefully, it's a nice, interesting podcast that hopefully, some people find useful.
PJ: And if you do, and if you donât, hit us up on Twitter @peterjaap and @yireo, or @jissereitsma.
Jisse: Yeah, but we'll post, I think, most of those details anyway, and let us know as well whether it's interesting, whether there should be an episode 2. It could also be that basically a lot of people are saying like, âHey guys, just don't do this.â
PJ: Another podcast.
Jisse: Not another podcast.
PJ: I have podcast burn out from listening. So that's why I thought, âLet's just create one.â
Jisse: Yeah, exactly. And top of it, I think having a podcast without the bullshit would also be good. So hopefully--
PJ: By backenders is for backenders.
Jisse: Exactly. For nerds, by nerds or something. Yeah.
PJ: Cool. See you next time.
Jisse: Thanks for listening and catch up with you soon.
PJ: Bye. Bye.
