DEV Community

Cover image for πŸ‘·πŸ½β€β™‚οΈ Building the GraphQL API in the Open #1 (March '21)

πŸ‘·πŸ½β€β™‚οΈ Building the GraphQL API in the Open #1 (March '21)

Leonardo Losoviz
Creating GraphQL server for WordPress. Writing for CSS Tricks, Smashing Magazine, the LogRocket blog and Design Bombs. Tweeting @losoviz
Originally published at ・11 min read

This post has been originally published in

Welcome to the very first "Building in the Open"!

This is a channel to share news concerning the development of the GraphQL API for WordPress with the community, sent the first week of each month.

Through this space, we will learn everything that happened during the last month, including:

βœ… What we've been working on, what new features we released
βœ… What we will be working on the upcoming month
βœ… Amount of traffic we got on the site
βœ… How did the plugin do: Number of downloads, newsletter subscriptions, GitHub stars
βœ… Progress on achieving financial sustainability
βœ… Newly published guides
βœ… Summary of our recently published blog posts
βœ… Reaching out / Plugin mentions
βœ… General news

If you enjoy this newsletter, please invite your friends to subscribe.

Let's start!

Heads up: This newsletter is a two-way communication channel. If there's anything you'd like to say, be welcome to add a comment.

A welcome to the newsletter, by your host

What we've been coding on

If you notice the Guides, section "Extending the GraphQL API" is still pretty empty:

Guides for "Extending the plugin" are not yet complete

My priority is to complete these guides. But before I do that, I want the plugin's code to be as simple as possible. The simpler it is, the less documentation is required, and the more anyone and everyone is able to understand it.

With this in mind, I've decided to refactor the code, to have it be fully based on Symfony's DependencyInjection Component.

The idea is that any extension to the plugin (such as a custom TypeResolver, FieldResolver or DirectiveResolver) is simply defined as a service in the container, and the service is automatically configured via Compiler passes.

Fully relying on Symfony's dependency injection has several advantages:

βœ… There is a single, consistent way to create extensions
βœ… Just creating a PHP class implementing some interface does the whole job, and the developer needs not be aware of the nitty-gritty details
βœ… Symfony's documentation is very extensive. By pointing developers to it, that is documentation that I do not need to write

Interested in the code? Check out my latest merged PRs (#453, #452, #449 and several others).

I will keep working on this code for the upcoming weeks, until the migration is 100% complete, and I get to write the missing guides.

Traffic to

Let me be clear on something: I care about how many people visit the plugin's website, as a proxy to know how many people know about the plugin.

I don't have deep pockets to publicize my plugin. And even if I did, I wouldn't spend my money on promoting it, since that goes against the spirit of open source. (This would be different if open source were just a channel to sell some product or service, but that's not my case.)

That means that I rely fully on word of mouth to promote it. For that, I've been devoting plenty of effort in writing high-quality content for the plugin's blog, hoping this content would get shared around, reaching people who would otherwise not know about the plugin.

And so far, I'm pretty happy with the results.

During the past month, I've had 4.5k visitors, with 6k page views:

Show me the money!

Let's break down these stats.

Most of my visitors come from Hacker News, where I managed to pull a few "Show HN" front pages, and Reddit, mostly from /r/PHP and /r/graphql (where I always share my articles).

I managed to rank #1 on Google when searching "wordpress core graphql", and that brought plenty of traffic. Unfortunately, it was a one time-off: after 24hs it went away as suddenly as it arrived. Otherwise, on a typical day I get between 3 and 10 visitors from Google.

Twitter and Facebook bring a sizable amount of traffic, but I don't know from who (not from me, since I am extremely bad at social media). I do share my articles on Twitter, but they seldom get retweeted. And I do not use πŸ‘ŽπŸΎ Facebook.

(Btw, for those of you who share my articles on social media, thanks ❀️)

I get some modest but consistent traffic from the listing of GraphQL servers in PHP on, and from an article I've published on, which ranks #1 when googling "graphql execute multiple queries".

Finally, my articles consistently appear in WordPress' main newsletters (including WP Owls,, Post Status, WP Builds, and The WP Weekly). I don't know exactly how much traffic each of them brings, since the referrer will appear as Gmail and similar others. However, when taken together, these newsletters produce a sizable number of visitors.

My blog posts are by far my most popular content, with the last three (this one, this one and this one) bringing over 1k visitors each.

These numbers look pretty good, more since I barely launched the website less than 2 months ago. However, not everything looks good: At 88%, the bounce rate is quite high. I need to work on that.


Traffic to the site is only a decorative metric, to estimate awareness of the plugin. But far more important to ask is: How many people started using the plugin during the past month?

My reputation precedes me

During the past month, the plugin fared like this:

🎯 Number of plugin downloads: 170
⭐️ GitHub stars: 27

The number of downloads can be retrieved from the GitHub API, passing param per_page=3 to include only the 3 releases created during the last month:

curl -H "Accept: application/vnd.github.v3+json" | grep "download_count"
Enter fullscreen mode Exit fullscreen mode

I am neither happy nor unhappy about these numbers. They are not great (and I wish they were better), but they are a good start.

Concerning downloads, it is said that getting the first user is the most difficult task. Only after a few people start using the plugin, and start talking about it, that its use will become more widespread. I am still within this initial stage of finding the first batch of commited users.

Concerning GitHub stars, I must say it looks pretty flat: around 1 star per day on average. This is certainly nothing great. If you like what I'm building with the GraphQL API for WordPress, and you don't mind showing some ❀️ love, then please consider giving it a ⭐️ star on GitHub.

Financial Sustainability

This one is the tough issue: the project must be financially sustainable. It either generates a bit of money, or it won't make it for long.

In this goes my life

If I am able to make an income for myself, then I can keep working on it, for as long as needed. That's all I need: an income. Not investors knocking on my door looking for millions. Just a couple thousands per month, to pay for the roof above my head.

My goal is to keep the plugin fully open source. For that, I'm currently reaching out to a couple of potential sponsors, asking if they'd like to help fund the development of the plugin. It will be a win-win situation.

Why am I resorting to some "big guns" sponsors, instead of relying on regular sponsorship, by anyone from the community?

Yes, I've been trying that too: I am on GitHub Sponsors. However, it doesn't really work, unless you already have thousands of users, followers, or people subscribed to your mailing list, to whom you can reach out to, expecting many of them to fund you.

For instance, asking for a standard u$d 5 or 10 per month, I'd need several hundred funders for this approach to fund my work. And I'm nowhere near that stage.

But even more, who can really succeed with this approach? I know that Caleb Porzio (creator of Livewire) has made it, and has now reached over 1350 sponsors! But that's more the exception than the norm.

Take Composer, for instance. Composer has fundamentally changed how we develop PHP applications, yet they barely have 90 sponsors. How could I ever expect to get more sponsors than Composer?

That's why my current approach is to create a win-win situation for my project and the few companies willing to sponsor it. Let's hope it will work out, and the GraphQL API is free for everyone, for all the features, and I don't need to lock the good stuff behind a paywall.

(If you'd like to find out how it's a win-win, please send me an email or DM. Maybe your company may be interested too?)

I'll give this approach a few months, hopefully I will make it happen. If I don't succeed, only then I will need to consider building a PRO version of the plugin, and restricting some of the features for the paid version. (Yeah, that would suck, so I hope I can avoid that stage.)

In the upcoming newsletters, I will keep you updated if I managed to get sponsors or not.

Blog posts

The blog posts have been my absolute pride and joy.

Heads up: Did you know there's an RSS feed on the site? You can subscribe to receiving all my blog posts, read them on your favorite reader.

During the past month, I've managed to publish a high-quality blog post every week:

πŸ›  Should WordPress have a GraphQL API in core? makes the case that WordPress could benefit from GraphQL, since the WP REST API was given a new functionality in WordPress 5.6 (batch operations), that a GraphQL API can deliver natively.

πŸ₯Š GraphQL API vs WPGraphQL: the fight! compares my plugin with WPGraphQL, on a clash to be remembered for ages to come, and which will keep boxing fans asking for more.

πŸ‘ΆπŸ» Rejuvenating WordPress through GraphQL demonstrates how a headless WordPress can be decoupled from the WordPress codebase, providing an opportunity to fix (or, at least, bypass) the accumulated technical debt.

🍾 GraphQL API for WordPress is now scoped, thanks to PHP-Scoper! describes a strategy to scope a WordPress plugin using PHP-Scoper, as to avoid conflicts with other plugins.

Reaching out / Plugin mentions

I'm delighted that the plugin has been featured in a few places.

βœ… I have given talk "Intro to the GraphQL API for WordPress" in WordCamp India 2021, doing a demo of the plugin, and (surprisingly from doing a demo) it all came out perfectly! Check out the Youtube video.

βœ… Joe Howard has interviewed me for the WPMRR podcast. The recording will come out soon.

βœ… Chris Coyier featured my plugin in the CSS-Tricks newsletter #239!

This made my day

A bit of everything

Some general news, about anything taking place during the last month.

Jason Bahl goes to WP Engine

Congrats to Jason for joining WP Engine! I hope he'll keep rocking, as he's been doing so far for WPGraphQL.

Btw, the fact that we're competitors (well, I'm the one competing with him, he's way far ahead) doesn't mean that we can't be friends, or collaborate to improve each other's projects. Indeed, we both share the same goal: to bring GraphQL to WordPress (even though we have different ideas on how that should happen).

But I believe that competition is good, and it will benefit everyone.

Yeah, competition is good, as long as you're the one on top

WP Engine launches Atlas, and claims to know everything about headless (do they?)

I also congratulate WP Engine for launching Atlas, their new headless WordPress solution.

Unfortunately, they state some inaccurate information:

Companies that use an entirely headless solution will typically host a separate JavaScript application for the front end, which pulls specific WordPress data via APIsβ€”the WordPress REST API or the WPGraphQL plugin.

Yeah, the GraphQL API for WordPress does not exist, right?

Hey there, I'm here, or am I not?

I would normally not be troubled about this, since I don't expect everyone to know about my plugin. But I do believe that they know about my project, and they seem to be wilfully ignoring it.

After they launched (the "one-stop hub for best practices, tutorials, blogs, and documentation for headless WordPress"), I did reach out to them:

I guess they haven't taken my project seriously. Or well, maybe they just didn't care about it, since they are fully invested in WPGraphQL.

Now, I'm OK if they don't want to mention my plugin. However, stating that the WP REST API and WPGraphQL are the only two options is very misleading. As a consequence, my plugin gets harmed, and the community of developers gets confused.

So then yeah, I must admit I'm annoyed. This is not cool at all. I hope they will rectify their inaccurate information (I sent them an email already).

Wrapping up

So this is the end of the first ever "Building the GraphQL API in the open".

How did you like it? Be welcome to share your thoughts in the comments.

If you did like it, I will appreciate if you can share the newsletter with your friends (or, even better, invite them to subscribe).

See you next month!

Discussion (0)