As the eagerly awaited Drupal Developer Days Vienna 2023 came to a glorious conclusion, one name that stood out amongst the many distinguished speakers was Alexander Varwijk. With a decade of experience in the Drupal ecosystem and an instrumental role at Open Social, Alexander brings a wealth of expertise and insights to the table. As the Lead Engineer at Open Social, his contributions have played a significant role in shaping the future of community-driven platforms.

Kazima Abbas, Sub-editor at TheDropTimes (TDT), had the privilege to sit down with Alexander to discuss his keynote speech at Drupal Developer Days. This much-welcomed keynote delved into Alexander's incredible journey with Drupal over the past ten years—a testament to his unwavering dedication to open-source technologies and community-driven development.

You May Like

Interview

Defying Limits: Matthew Ramir's Journey as a Drupal Developer with Cerebral Palsy

Interview

Defying Limits: Matthew Ramir's Journey as a Drupal Developer with Cerebral Palsy

"Drupal is an amazing framework, and our Entity API and module system are incredibly powerful systems to build amazing products... The coming years are going to be exciting and challenge us to bring modern web development innovations to our Drupal projects," states Alexander

Join us as we embark on an enlightening conversation with Alexander Varwijk, exploring his vision for the future of Drupal, the transformative power of open-source technology, and the role of community-driven initiatives in shaping a more interconnected world.

TDT[1]: Can you tell us about your role at Open Social and your responsibilities as the Lead Engineer?

Alexander Varwijk: As a Lead Engineer, I work with product management and leadership to realise our product vision to create digital spaces that empower community members to connect, share knowledge and spread their ideas. I work with our talented design team and provide guidance to engineers at Open Social on topics like code architecture, API design and security.

Some of the projects I've worked on at Open Social include setting up our translation pipeline using POTX and Weblate; improving our GitHub workflows for automated code quality checking and testing; rewriting our Behat tests the right way; and I've been responsible for building our Real-Time chat which uses GraphQL, React and ReactPHP to provide our customers with a real-time communication tool on their community platforms.

One of the things that has kept me at Open Social for over 6.5 years has been the possibility to grow with the company and work on new challenges. I'm always happy to tell people about our client list, which includes many organisations that make a real positive impact on the world. And thanks to the work I've been doing with Drupal and other technologies like GraphQL and React, I've been able to speak at events and meet many interesting people over the years.

TDT [2]: How did you become interested in Drupal, and what motivated you to specialise in it for over 10 years?

Alexander Varwijk: In 2012, I took it upon myself to build a new website for my Korfball association. My goal was to provide a website where we could post-match schedules, results and team information. I wanted to make sure that the website would automatically show the next upcoming matches and hide matches that were completed.

You May Like

Article

Drupal Events Roundup: April 15th - 21st, 2024

Article

Drupal Events Roundup: April 15th - 21st, 2024

I had started programming 10 years prior and did web development with HTML/CSS/JS and PHP, but up to then, I mostly wrote my own code, like form submission handlers and database queries. I knew that for this project, I didn't want to write all those things myself and in my research, I found Drupal, which showed to have a lot of the things I needed out of the box. I will admit that when I built that version of my korfball association, I did not use the entity API but created my own tables and queries, missing out on many of the things that make Drupal great: everything just works together.

One of the things I needed for the website was an integration between the IMCE media manager and the Plupload widget to easily allow uploading a lot of files at the same time. I ended up building that integration in the form of the imce_plupload module, which quickly gained some traction and had 10k installs at its peak.

Seeing this engagement with something I had built got me curious for more of the Drupal community, and I was fortunate enough to be able to visit DrupalCon in Prague in 2013. That's where I met many wonderful people I'm still in contact with today. I also met Taco Potze, CEO of Open Social (then still named GoalGorilla), who said I could contact him if I were looking for work after my studies.

In 2016 when I decided to break off my Electrical Engineering study and pursue my interest in craft beer as a craft beer box subscription service, I emailed Taco to ask whether the offer to work at GoalGorilla still stood. I was lucky enough to get an interview and subsequently be hired. My first project was an agency project for one of our Dutch clients, after which I moved teams a few times over the year from working on the Open Social marketing website, providing support to our enterprise customers and then joining the Open Social core team working on our distribution.

Drupal's ease with which you can build complex things to do cool things, the great community that's eager to learn and share, and see how other developers and Drupal agencies have used the product that I've been a part of making has kept me coming back for more.

TDT [3]: As someone leading the push to an API-first product at Open Social, what advantages do you see in adopting this approach for online community experiences?

Alexander Varwijk: If we compare what websites looked like 20 years ago to the kind of online experiences we have now, then this is a night and day difference. With these changes, users have grown accustomed to certain UX patterns and are increasingly more demanding of how a site should respond to their inputs. Gone are the days when it's acceptable to take multiple seconds to reload the page upon a form submission; instead, users expect instant gratification and on-page updates.

I believe it isn't easy to provide these kinds of experiences in the traditional model, where an entire page is rendered by a server and shipped to a user. Instead, we need smarter and more powerful clients that can request just the data they need and provide real-time updates to our users.

Additionally, people are using more different devices than ever to access the web and its information: desktop and mobile browsers, apps on tablets and mobile devices, as well as voice and AI assistants. All these clients will have different needs for consuming the data than as an HTML document.

By building API first, you're enabling yourself to provide the data in a way that each of these clients can request it and transform it in the way that best suits their users.

For online community experiences specifically, a community is at the heart of what mission-driven organisations do. It's an important tool to interact with stakeholders and communicate about the organisation's work and value. The digital landscape of these organisations is increasingly complex, and we can not assume that all the data they want to share with their community members is already available within the online community platform. Additionally, it's not feasible to build and maintain integrations with the myriad of different services these organisations use. An API-first approach shifts how an online community platform works and enables these organisations to integrate the platform into their digital landscape better.

TDT [4]: You mentioned introducing React into the Open Social codebase. What led to this decision, and how has React enhanced the development process and user experience?

Alexander Varwijk: This decision was already made a few years ago now. If you've watched my Drupal Developer Days keynote, you'll know that some more choices have been created. However, I would probably choose React again.

The component-based nature of React works very well in a lot of different contexts, for example, with our designers who use Object Oriented UX. It's a very mature library at this point, where a lot of the traps are known at the outset. A large pool of developers has React experience, making hiring easier. Finally, adding GraphQL to React makes it a breeze to design components that have their data needs declared right next to the component. This makes it easy to build very large systems.

One of the things that has really helped us has been the ability to use tools like Storybook to visualise our components and how they're used in other components. This makes changes a lot easier, whereas in a traditional Drupal theme, you often have to hunt for different places where a certain element might be used. Even within Drupal, the introduction of Single Directory Components (SDC) has made life much better here.

TDT [5]: With the emergence of technologies like React, GraphQL, and Rust, how do you see them shaping the future of front-end, API, and application development?

Alexander Varwijk: I gave a longer timeline of this in my keynote, but I think the JavaScript ecosystem will slowly shift from constantly introducing new front-end frameworks to coalescing around a set of meta-frameworks that will more directly compete with Drupal. This can already be seen in the React ecosystem, where newer developers are unable to see the difference between Next.js (a meta-framework) and React.

The Rust community is a few years behind in this journey, but the question they've consistently asked themselves, "Are we web yet?" is currently being answered by a resounding "Yes!". Current web frameworks can already do a lot of things at high speed, and there's a large investment being made in UI libraries that run on the web (among other platforms). The current iteration of web frameworks is coalescing around some common ideas and focusing on the developer experience specifically. I expect that in a few more years, we'll see a similar shift of focus from building blocks (the web server or UI library) to meta frameworks which let you focus on getting things done rather than wiring everything together.

TDT [6]: In your keynote at Drupal Developer Days, "Keeping Drupal competitive on the modern web." What are some challenges Drupal faces in staying competitive, and how do you propose addressing them?

Alexander Varwijk: Developer surveys such as the ones held by Jetbrains and StackOverflow show that the popularity of PHP is declining, and I believe this directly impacts Drupal. As people who use Drupal, we know that there's a lot to love about the framework. However, the requirements of the web are moving goalposts, and end-users expect vastly different things now than they did 10 years ago. This change in expectations causes developers to re-evaluate their tools.

I think PHP is declining for two primary reasons: PHP has been around for a long time, which means that the image of PHP in a lot of people's eyes is still that of PHP 4 or PHP 5.6. Secondly, with the move of Javascript to the server to allow people to use a single language across their stack, there have been a lot of new developments in the JavaScript space, which is shiny and new and attracts new developers.

Of course, the PHP that we write now in PHP 8.1 and onwards, aided by tools like PHPStan, is vastly different from what we built with PHP 5.6, and the developer experience is similar to using any other strongly typed language, with early feedback on bugs and ergonomics by properly architected types.

Besides the trends of tooling getting better in the JavaScript and Rust communities, we can also see more and more SaaS services popping up to help developers with problems that are not core to what they're trying to offer, like authentication and data management. These services are always big sponsors at conferences like React Summit and JSNation, which suggests there's definitely a market there.

What always amuses me, though, is that many of the features that these SaaS services promote are things that Drupal has for years! For exact examples, I suggest checking out my keynote. However, it leads to me wondering why people are paying for these SaaS services but not using Drupal.

I think that a large part of it is that people will not host Drupal themselves if they don't have PHP experience within their organisation. At Open Social, we've experienced something similar with the adoption of Weblate, which is a great translation tool, but it's written in Python. Even though we don't need to extend Weblate, we need some Python knowledge to fulfil what is essentially a site builder role within the tool.

With that in mind, I think we're missing a large audience by focusing on site builders because we're excluding a large developer community that might not want to run a PHP project. On the other hand, they might be more than willing to pay for a SaaS service that happens to be built on PHP. Making Drupal and its module ecosystem usable as a SaaS service does require some tweaks, though. Site builders are assumed to have more rights and more control over hosting than SaaS customers, so we'll need to split up permissions to provide more granularity: a site builder can have everything, but a SaaS user will not have access to screens that change hosting-related settings. Similarly, we'll have to change screens to reflect these different levels of access. However, I believe these are relatively minor changes, and the mindset change among module maintainers will be the most difficult to accomplish.

A bigger challenge than rethinking how we allow platform configuration is making sure that Drupal has a compelling async story. As an example use-case, GraphQL subscriptions provide ways of giving users a real-time experience by pushing new content or notifications to them. However, because Drupal can not currently be run as a long-running process that handles multiple asynchronous connections, building this experience is usually a lot simpler in a language like JavaScript or Rust. At the cost of missing out on Drupal's great module system, entity API, and access system.

By making these changes, we empower developers and organisations within the Drupal ecosystem to build services that can be adopted by developers who might not be willing to use PHP themselves. By showing those developers that these kinds of experiences can be built with PHP we can enthuse developers to pick up PHP and contribute to these applications.

TDT [7]: As a Lead Engineer, what are some key considerations you keep in mind when creating reusable extensions for Enterprise customers?

Alexander Varwijk: Creating an extension for an enterprise customer is not very different from creating a Drupal.org module. We still have to think of how the feature the customer requests, or the feature we're building for our customers, fits within our larger vision of what a community platform can do.

This means we have to think about what kind of fundamental systems we might need from the core Open Social distribution, what kind of additional systems we need to build, and how we might extend that in the future.

Kristiaan van den Eynde, the maintainer of the Group module, held an excellent presentation at Drupal Developer Days on "How to maintain large-scale software" which covers a lot of things that we think about when building any part of Open Social.

TDT [8]: How do you stay up to date with the latest trends and innovations in web development, and how do you incorporate them into your work at Open Social?

Alexander Varwijk: There are a lot of things in the tech world to keep up to date with. For Drupal core development, we subscribe to the "Change List" RSS feeds for Drupal Core and contrib modules that use them (such as Group), which come into a channel in Open Social's Slack. This allows us to quickly discuss what is coming up in new features, things that make our lives easier, or things we need to adjust code for.

Beyond that, I'm a member of Drupal Slack, where I see a lot of things that people are working on, and can be reached for questions about GraphQL, decoupled, or Open Social (please ask in public channels rather than DMs, since it allows other people to learn from your questions too!).

For broader tech news, my primary source is Mastodon, where I follow a lot of very insightful people in the Drupal, Rust and wider web development space. To keep up to date with the Rust and JavaScript ecosystems, I attend conferences like EuroRust, JSNation, and React Summit, which are always a lot of fun.

The number of things that happen and evolve in the web ecosystem can be challenging to keep up with, and it's okay to accept that you'll miss things. Millions of people are out there building new things, and we're usually trying to keep up alone or with a hand full of people. Drupal Developer Days recently was a great reminder that even though after 12 years, I'm quite deeply embedded in the Drupal community, a lot of things have been created, improved and fixed in the last six months that I'd missed, and it was through talking to all the great people in Vienna that I now feel all caught up again.

TDT [9]: Any closing thoughts? Where can people find you?

Alexander Varwijk: Drupal is an amazing framework, and our Entity API and module system are incredibly powerful systems to build amazing products. However, being over 20 years old also means that new ideas and innovations have to make sure they work with a huge amount of existing code, something new frameworks in other web development areas don't have to think about. The coming years are going to be exciting and challenge us to bring modern web development innovations, like persistent WebSocket connections for real-time communication, to our Drupal projects.

All my talks are listed on my website: www.alexandervarwijk.com, where I also irregularly post blog posts. You can find me on LinkedIn if you want to contact me for professional inquiries. If you have anything Drupal you want to chat about, find me in one of the many Drupal Slack channels I inhabit. For random thoughts, follow me on Mastodon.