26 Comments

  1. Roy Sivan

    Decoupled WordPress is a great use of the REST API, particularly when it comes to using a JS framework. The REST APi really does give you the ability to take data from WordPress, put it into a bucket, and then do whatever it is you want with that data (thanks @mor10 for that analogy).

    The best part of this, is once people realize that you can decouple your web application (or website) from WordPress almost completely, they will start to think about what else can be decoupled (maybe there is a better template engine, or better route engine, etc. )

    Report

  2. David Green

    An important consideration is what benefit this brings to people other than the developers making it. In cases where the WP REST API and decoupling WordPress brings a real benefit for the client then that’s great. Go with it. But too often the developers I’ve seen and talked to want to bring in AngularJS or another JS framework, decouple WordPress, and over-engineer a solution that results in the front end experience for users having no improvement yet introduces more complexity behind the scenes. The developer gets a nice piece for their portfolio, and likely gets to charge a premium for the project, while the client gets…to pay more and require more specialized developers in the future to give their users an experience no better than their competition who went a more traditional route.

    Don’t get me wrong. I’m not against the WP REST API or anything along those lines. It’s a powerful tool, but use the right tool for the right job. I’m tired of seeing people using the newest, shiniest tool on every job whether it brings a benefit or not, just so they can brag about it, while other people invent newer, shinier tools to accomplish the same thing so they get to brag instead. But that’s the state of front end development right now. Advancement, yes, but with lots of reinventing the wheel and selling clients a bill of goods.

    Report

    • millemrEmily Miller

      David – Great points. I agree that a decoupled build isn’t right for every project. If there’s not a compelling reason to decouple, you’re likely making the project more challenging and expensive than it needs to be. However, I think as frontend trends evolve, more and more site requirements will call for a decoupled build, and I hope that as a community we can share what we learn to make the whole process a bit more approachable :)

      Report

  3. Jack Beauregard

    I would rather like to know, how to decouple WordPress instead of reading, who’s dunnit and why.

    Report

  4. Andreas Nurbo

    There are other ways to decouple as well. Ive experimented with having a node.js front and managing content with WordPress. Not made anything production worthy etc but it was fun setup.

    Report

  5. wpezdeveloper

    It’s going to be interesting to see how WP transitions from its DNA as a every man / woman tool, to a position in the market that requires a much more robust set – depth & breadth – of skills.

    That said, as these higher end of devs – new to WP with potentially higher dev expectations – flirt with WP, will WP be up to meeting those expectations? The technology is manageable. That’s not really the friction. However, this fork of The WordPress way? Perhaps not so much so.

    Some have suggested WP might be on the cusp of having its Microsoft moment.

    We’ll see. Exciting times ahead for sure. Great article. Thanks.

    Report

  6. Peter Knight (@peterrknight)

    I think a compelling use case is an offline capable WordPress site. I think one thing that is missing from the toolbox is a way to sync local changes (made offline) with the server.

    Report

  7. Connor Rickett

    A lot of this is over my head, but I have to say that losing “preview” would be a bit of a blow, since the visual editor very rarely reflects the output on the front end accurately.

    Report

  8. Brandon Bowersox-Johnson

    For more details of the “Why” decoupled question, check out our blog post ‘Why We’re Decoupling Drupal’:
    http://www.pixotech.com/decoupling-drupal/

    For more of the “How” to decouple topics, watch for updated how-to’s on the Outpost site:
    http://www.getoutpost.org/

    Outpost is an open source framework for decoupled websites. Also, the “How” question really has multiple answers, and two good case studies are covered in-depth in the Webinar video Emily linked to above.

    Report

    • Emily Miller

      Thanks for the extra resources, Brandon! There are some great Drupal case studies out there that could be useful for those who want more real life examples of decoupled CMS.

      We’ve begun aggregating a lot of these resources for both WordPress and Drupal here: pantheon.io/decoupled-cms

      Report

  9. intriguingnw

    Interesting thanks re de-coupling. I. The days before WP our Dev teams were doing this with SQL as a back end and our primitive version of an API with front-end separated. Tools have improved and that’s good but it also underlines the restrictive nature of many themes. For me I am looking for more design front-end freedom too but need that front end layer to be able to be readily maintained.

    Better design/front-end tools beyond relatively primitive Customizer menu options etc that an organisation can rely upon but enhances creativity is what I believe the community needs. Vital Dev work in De-coupling needed to innovate with leaders in theme development path to next gen visual tools a must. Demos and examples please in follow-up would be much appreciated. There are framework type themes with their own front-end visualisers but surely a more creative front end is vital for all. Not everyone will want to code the front end. Interesting times ahead and we should keep an eye on other platforms where emphasis has already been on the front end. It maybe unpopular to say this but I am concerned how slowly the core front end is moving forward.But I can see decoupled tools and libraries maybe critical to solving this problem. Thanks lots to think about! Look forward to hearing more.

    Report

    • Emily Miller

      I’m glad you found the post interesting. I look forward to learning more about the different builds and use cases for decoupled WordPress, and will share what I find!

      Report

  10. Sarah

    This sounds like a very interesting way to do it. Is there any other examples apart from Pixo Tech and possibly Mashable?

    Report

    • schady04

      New York Times is decoupled – Scott Taylor who is the wordpress 4.4 lead works @ NYTimes and gave a great architecture layout example of the build they use this summer at word camp Maine. Very Modular so that pieces can be shifted if needed on their front end.

      Report

  11. R. S. Harding (@JoomFlix)

    I’ve used the decoupled paradigm very successfully on two totally different production applications.

    They both use the WP-API with the WP-JSON and PODS plugins to provide data to Node.js servers. The front ends are native JS for a set of content sites and Angular.js for a form generator. This architecture has proven to be a very flexible and powerful solution for us.

    Report

  12. andrewfielden

    We build business oriented tools for BuddyPress and are using the REST API with backbone to manage the entire thing. This works very well indeed for the elements we are currently concerned with. Whilst this is not fully decoupling by any means it is a large step in that direction.

    Report

  13. Paul Fernhout

    I have spent the past year implementing such a “decoupled” multi-user single-page TypeScript/JavaScript application called “NarraFirma”. NarraFirma is based on my wife’s work on “Participatory Narrative Inquiry” explained in her free book “Working with Stories in Your Community or Organization”. The application (designed by my wife) has more that forty “pages” all defined in TypeScript (and some JSON) using Mithril and D3 for the front-end GUI, which communicates to a backend using AJAX with JSON. The application backend can be either WordPress (via a PHP plugin) or via a small NodeJS server application in JavaScript. The backend code is maybe 1% of the frontend code in size. Data is primarily stored as messages consisting of triples in the WordPress database (one table per project, with one message per row, with database indexes) or as flat files under NodeJS (one directory per project, one file per message, with indexing and caching in memory). This message-oriented approach supports several users collaborating at once to modify the same “page” and reasonably quickly see updates without a page reload. Pages can include editable tables and editable 2D clustering diagrams. I’m currently working on improving the admin GUI for the WordPress plugin also using Mithril to make it easier to create multiple projects with various different access permissions. We plan on announcing the official release of the first major version in a few weeks. This project has been mostly a labor of love, although we hope in the long-term it will increase the demand for my wife’s consulting services related to her book.

    We have released all the code for the NarraFirma application under the GPL here:
    https://github.com/pdfernhout/narrafirma

    It’s exciting to see WordPress improving as an application platform supporting JavaScript applications. It’s hard to beat the “one click” install process of a web app that WordPress makes possible for tens of millions of users. While the NodeJS backend is more “efficient” than the WordPress backend as far as throughput per CPU cycle, the NodeJS backend is much harder to install and maintain for most people than the WordPress plugin and thus is “inefficient” of people’s time in that sense. The stand-alone NodeJS version also does not leverage an existing community’s or organization’s user base in terms of people who already have signed up for an account on a WordPress site and who can be authorized easily to use the plugin rather than having to create yet another account on some new system. So, we expect that most of the application’s users will install it via WordPress. I expect other developers may make a similar choice in the future for deploying JavaScript and mobile apps that need an easy-to-install-and-upgrade backend — especially if that backend is intended to support projects for a specific community or organization.

    Report

    • Paul Fernhout

      In case anyone is interested in trying out the NarraFirma WordPress plugin as an example of a significant “decoupled applicaton”, we have just put up an interactive demo version of it here.

      A big tradeoff so far has been that the application can take twenty seconds to load (while staring at a please wait message). That loading time is due to two things. About half of that load time is due to loading dozens of unbundled JavaScript files which could be reduced by packaging (I’ve just not gotten to that yet) and maybe some other clever on-demand loading. But the other half of the loading time is due to loading the project data (about 1000 transactional messages), and that time probably can not be reduced much as the app already bundles 100 messages at a time (other than a faster server and more bandwidth) with each round trip (plus 100 database record loads) taking about a second. That part of the loading time would go up with even bigger projects. However, once the application loads, it is snappy, including generating charts and graphs and scrolling through lists of hundreds of experiential stories and related metadata.

      We also have put up some more background information of the NarraFirma app effort in an entry to a Knight News Challenge on: “How might we make data work for individuals and communities?”

      It could be interesting and worthwhile to enhance the WordPress platform in ways that meet the needs of many of the other 1000 or so entries to that challenge.

      Report

  14. Branden

    We are experimenting in de-coupling with pretty encouraging results at http://theinformr.com.

    First we migrated our legacy app’s front-end route by route from Symfony to Symfony2 + JS and are iteratively migrating parts of the backend to WP with help of the REST API.

    The motivation is that WordPress + ACF is just works. It gets content into the db where we need it without re-inveting the wheel.

    WordPress is familiar to most anyone we onboard and we free more time for our devs for front-end work which Emily points out as an advantage in her article.

    Report

Comments are closed.

%d bloggers like this: