Interview with Milan and Vojta, Developers from PeckaDesign

Hi Milan, Vojta. I’m very glad you accepted the invitation for this interview. I see PeckaDesign as very close to the Nette Framework and the Czech PHP community in general. I know many of your team participate in Brno's #posobota meetups and often travel to Prague for lectures. For our readers, could you add something they might not know about you in one or two sentences to describe PeckaDesign studio today?

M: PeckaDesign is an agency that has been operating for 20 years now, and for the last 8 years, we’ve been using Nette for our projects. We exclusively create e-shops like Benu, Electro World, Gant, Hudy, Megapixel, Pneumatiky.cz, and others. Our technology stack includes PHP, MariaDB, Elasticsearch, RabbitMQ, and Git. Recently, our team has been working on a new project, which is expanding our company's technological portfolio.

V: I think readers might be interested to know that Pecka focuses mainly on long-term projects. Our collaboration doesn’t end after a project launches; we continue to develop and maintain it for our clients. We’ve been working on the Electro World project since 2015 and Nay.sk since 2014. Recently, our focus for Nay and EW has shifted towards Vue.js, Nuxt.js, and related API development.

Was it a big decision for you between React and Vue.js?

V: I don’t think we really tackled that question head-on. About a year and a half ago, client demands started coming in for implementing new features that were clearly beyond jQuery’s capabilities. Even if we could write it, no one would want to maintain and update it. We began hearing more and more about Vue.js, and we were particularly impressed by how easily it could be used in a “legacy” jQuery environment. We tried it out and stuck with it. Gradually, we added TypeScript and a class-based approach to writing components.

It sounds like an ideal integration of SPA technologies into an ongoing project. Do you remember what the first component you added this way was?

V: I think the first was the implementation of a widget for “Balík na poštu,” where the user selects a post office branch for package delivery. This was implemented in plain Vue.js, while subsequent ones used TypeScript and a class-based approach.

Such a feature might use a third-party API, or were these your first steps in getting some API basics into your application? I see that SPA or just JS components communicate with the Nette application either via data attributes or mainly via API.

V: Regarding communication with Vue.js components, we use both approaches or a combination. We have cases where initialization data and configuration are passed via data attributes, and the component then communicates with the backend via API. We've been developing REST API for several years, so this wasn't the trigger. Often, it's a synchronization API with various third-party systems, but for example, we’ve developed and continue to maintain an API for Electro World and Nay’s mobile applications for Android and iOS.

Do you use REST and PHP for writing APIs, or have you been tempted by the Node.js world and GraphQL? How do you perceive today's wave of JavaScript/TypeScript on the server? Are you experimenting with it? Do you have any JS services in production?

V: We stick to REST and PHP in production for now, as it comes naturally from Pecka's background, which is primarily built on PHP. Some colleagues are exploring GraphQL as part of their self-education. As I mentioned earlier, we’ve been working on an internal project for a client where we’re developing a front-end application with Nuxt.js. In this project, we tackled the distribution of localized texts into the application. Since one application runs on multiple servers, we had to ensure real-time updates for all. The result is consumers running on Node.js, connected to a queue in RabbitMQ. On one side, we have an administration written in PHP, and on the other side, a “microservice” on Node.js. So, this could be considered our first foray into this area.

M: I think Pecka now has a good sense of the stability of the technologies we use. We can't deploy technologies based on current trends; they must be stable and proven. An example from the other end is projects created at Pecka before transitioning to Nette. These are websites and e-shops built on Zend Framework 1 and Smarty, some of which are still running because they still make sense for the client. The libraries used still have support, and they run on PHP 7.1. They have been functioning without significant intervention for 8–10 years. We have one programmer who takes care of them.

On the other hand, programmers are constantly learning and experimenting with current trends and deploying what makes sense. Besides maintaining the current stack of PHP, Nette, Kdyby, and Contributte libraries, this includes frontend matters, as well as server and backend. Locally, we often develop in Docker or Vagrant, have tested several CI servers, and use various ORM frameworks. We also have experience deploying two-factor authentication, using an internal OAuth2 server, or logging in via services like Facebook or Google.

Zend and Smarty are almost like a retro dessert edition, but I understand that some projects aren't worth rewriting. Do you have any Nette projects on version 0.9, or do you try to stay current with Nette 3? I see your open-source monitoring application is still running on Nette 2.4.

M: The first version of Nette we started with was 2.0-dev. In 2012, this was the current version before 2.0 and 2.1 were released. All dependencies in Composer were on master at the time. From today's perspective, it was quite punk, but it turned out to be a good choice. It was easier to upgrade projects to the stable 2.1. It would have been worse from version 0.9. The very first e-shop built on Nette, Megapixel.cz, which several Nette community members worked on, still sets the direction. It was the first on Nette and still gets new versions of Nette and PHP first. We test library compatibility on it and then migrate other projects that share the same core. So, we’ve tested PHP 7.4 and Nette 3 in production, prepared some Kdyby libraries we maintain, and submitted a few pull requests to Nette. Our team is now preparing to migrate the common core to PHP 7.4, and then Nette 3 will follow. Most projects are on Nette 2.4, but they’ll soon move forward.

How do you see this with the JS world? It seems like there's a need for updates almost every day. Nette has established a pretty comfortable upgrade policy after years of development. To defend the JS world, Vue.js also seems to come with a calmer and more backward-compatible approach.

V: We only had one issue with a library for form validation, where the transition between versions wasn’t entirely smooth, but otherwise, it feels comparable to the PHP world. We try to choose libraries that are high-quality and widely used.

M: The first reason for deploying JS outside the browser was compiling LESS, I think around 2014. Initially, we chose Grunt. Shortly after, Gulp became popular, and we rewrote it. Now, Webpack is being deployed. Meanwhile, we moved from npm and Bower through Yarn back to npm. Compared to the PHP ecosystem, it's certainly more complicated. But as Vojta said, it depends a lot on the libraries you choose. We’ve also had to abandon some PHP libraries because they never got out of the unstable version, even though they did useful things. It’s essential to choose widely used libraries with a broad or stable community.

On another note, are you considering cloud services? AWS? Azure? Or are client policies still primarily keeping you on your servers? I see PHP as stable, and from what I observe, it’s mostly evolutionary rather than revolutionary (depending on your perspective), but the Docker/k8s world and now SPA/JS are definitely lively. What about a serverless approach?

M: We currently run everything on managed servers. We have various configurations: multiple projects on one server, one project per server, application + database server, or different servers for different services for one project. It depends on the size of the e-shop. This managed server solution is currently the most cost-effective and efficient for maintenance. The hosting provider performs updates upon our request. Essentially, we have PHP and other necessary programs updated every few months and the entire system once a year or two. Serious issues have been minimal over the years, and we can rely on it.

Migrating to newer PHP versions is somewhat limited by running multiple projects on one server. But it’s not that bad because we try to keep all active projects up to date. So, we migrate all projects around the same time. If we left one project behind, it would be challenging to bring it back to the forefront.

Luckily, PHP migrations between versions work well, allowing code to be compatible with both versions. We rarely have service outages, mainly during OS updates.

Two years ago, we started considering moving to Kubernetes and Docker in production. We haven't yet resolved the ecosystem, whether to move everything to one cluster or multiple clusters, which services to keep on physical servers, and which to virtualize. It’s quite a financial issue because all solutions are more expensive than the current state. Our

projects have demanding operations practically all day with ERP imports, with significant peaks in traffic occurring only 2–3 times a year. We’re comparing offers from pure clouds like DigitalOcean or AWS, as well as managed K8S, while staying with our current hosting. It’s still open, and we’ll see how it develops.

It makes sense to wait a bit for the ground to stabilize and be tested by time. We’ve covered questions from frontend, backend, to servers, and my last question is how you experienced the COVID situation? Was it an opportunity to change any processes in the company? How do you see working from home in the future?

V: As a company, I think we were very well prepared. We didn't have to change processes or implement new technologies. As for working from home, I think it’s about half and half in my team. Some prefer working from home, while others like coming to the office. Personally, I’m more productive in the office. From a team communication perspective, nothing beats having everyone in the same office. There's nothing easier than looking up and throwing a question into the room when you’re stuck. I think once the corona period is over, we’ll return to a home office as needed.

M: In our team, I was used to working from home because one colleague regularly works from home a few days a week. After two weeks, I also got used to it. You simply close the laptop and spend time with your family. No commute. I think more colleagues liked it; they started biking more, and the area around Brno is perfect for that. But I missed what Vojta describes. I couldn't get immediate advice; I had to write on Slack and wait for a response.

The company wasn't affected at all. We had the same amount of work because e-shops continued to operate without exception. Meetings switched to video mode, so we occasionally saw each other. Now we’re back in the offices as it suits each person. Working from home has never been an issue; we just never had so many people doing it at once.

We only had to cancel the last two Péhapkaři meetups (https://www.peckadesign.cz/pehapkari-brno). We’ve been hosting them in our offices almost every month since 2018. We’ll see when the next ones will be. But we will definitely continue the tradition.

Thanks to both of you for an inspiring interview

Thank you, Honza, for the opportunity.