11 Comments

  1. Alex
    · Reply

    Thanks so much for publishing this! I’ll be jumping in here occasionally to answer any questions y’all have.

    Report

    • Travis
      · Reply

      Some questions: How are the REST API implicit limits handled? Like if there are more items than max. number of returned items in one call? Are X-WP-Total, X-WP-TotalPages etc. headers taken care of? Are data of several subsequent necessary REST API calls combined in session storage? How is expiry of data handled, e.g. if new content is available but not yet in session storage?

      Report

      • Alex
        · Reply

        Are X-WP-Total, X-WP-TotalPages etc. headers taken care of?

        Nope. Not yet. The request doesn’t use a traditional REST call, it creates a different endpoint that fetches data that is otherwise not easy to obtain in the context of REST. Check out This directory.

        Are data of several subsequent necessary REST API calls combined in session storage?

        Yep. Session storage stores the data from the REST calls in session storage, and then the entire system actually loads the data from session storage instead of the API call. The app itself determines what local URLs need to be cached, and only requests the URLs it does not already have.

        How is expiry of data handled, e.g. if new content is available but not yet in session storage?

        I’m so glad you asked this question!

        A piece of session storage data is set for the last time the cache was cleared, and there is a piece of middleware that will validate the cache every 5 minutes. If the date of the cleared cache does not match, all of the session storage data is wiped.

        The cache is cleared every time a post type is updated, or if you manually clear the cache in the settings.

        Report

  2. Vitor Spencer
    · Reply

    This approach sounds really interesting, I’ll be exploring this, seems to have a huge potential!

    Report

  3. Dominique Pijnenburg
    · Reply

    This is a cool initiative. I’ve been looking into headless for the better part of this year, mostly with Atlas from WP Engine. But so far I haven’t rolled out any ‘real’ projects with it.

    The statements in the article about having to reinvent the wheel are totally true. Having a contact form with something like Gravity Forms is an absolute drag. Figuring out routing is difficult.

    I’d have liked it more if this boilerplate would’ve used GraphQL instead of the Rest API. It’s so much nicer to work with when things get more complex! The biggest downside to GraphQL is that most plugins have no built-in support for it yet, although the community it quickly spewing out extensions to add that support.

    Report

    • Alex
      · Reply

      I would love to use GraphQL instead of REST, and it’s not impossible to move it over to use that, it would just take some effort.

      All of the REST endpoints are baked-in here: https://github.com/nicholas-wordpress/underpin-module

      Since the boilerplate does not include these files directly, it’s possible to create a GraphQL version that could be swapped out instead of the RESTful version if it were to be built.

      I think an SDK for the actual REST calls would be useful too, since you could then make it so that the function calls from the SDK dynamically choose if it’s using GraphQL or REST to help keep compatibility in the core functionality, but then you could extend it to do whatever you need it to-do on your own.

      Report

  4. Martin
    · Reply

    Is there some SSR/SSG part in there as well? If not, JS disabled / low computation possibilities for JS is a killer for this kind of SPA, or am I misunderstanding something?

    Report

  5. Justin Ferriman
    · Reply

    Over my head, but I enjoyed reading about it and the innovation you’re pursuing, Alex. Well done! 🙂

    Report

  6. Quamruzzaman
    · Reply

    Seems interesting! For the past couple of months I was thinking about such an eco-system that acts like headless but offers the freedom of using majority of WordPress plugins and does not require an additional nodejs server to run for the decoupled front-end.

    End users aren’t heavily tech-savvy so making the process as smooth and simple as possible should be the ultimate goal. Like the process should be the same to install and activate a theme that they’re used to.

    I’ll surely spend some time with this boilerplate.

    Great job ! Keep up the pace.

    Report

  7. VibeThemes
    · Reply

    We’re using similar partial headless approach for our commercial theme WPLMS. The core WP architecture comes with inbuilt Redux store creation which makes it really easy to create applications, small which can also talk to each other on the same page. This is an immense opportunity by as it transforms WordPress into an Application framework. We’ve also also released a addon for AffiliateWP plugin which works in same headless framework.

    Report

Leave a Reply to Alex Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: