It has been a weekend in the spirit of headless Drupal, front-end optimizations and server side hacks. The result is I updated my blog to Drupal 8. Since you are reading this, it must mean it is live. First let's start with the cold facts (almost chronologically ordered by request lifetime):
- Varnish
- Nginx
- HHVM
- Drupal 8
- Mihtril.js
- Core REST module for all resources
Other front-end technologies used that does not directly relate to the request itself:
So, HHVM, huh?
Yeah, that's mostly just a novelty act. There is no real gain there. Quite the opposite, I have added some hacks to get around some limitations. HHVM does not work very well with logged in users right now, but works alright for serving anonymous content.
When I reload and look at the source code, there is no css loading. WAT?
Yeah, I am just assuming you remember the styles from last page load. Also, I have made it an image to have a 1 HTTP request CMS, right?
No, really. How does that work?
The real magic is happening by checking if you as a user already have downloaded my page earlier. If you have, I don't need to serve you css, as far as I am concerned. You should have saved that last time, so I just take care of that.
OK, so you use a cookie and save css in localstorage. Does that not screw with the varnish cache
Good question. I have some logic to internally rewrite the cached pages with a key to the same varnish hash. This way, all users trying to look at a css-less page with the css stored in localstorage will be served the same page, and php will not get touched.
What a great idea!
Really? Are you really sure you have thought of all the limitations? Because they are many. But seeing as this is my personal tech blog, and I like to experiment, it went live anyway.
Give us the code!
Sure. The theme is at github. The stupid cache module is at github. Please be aware that it is a very bad idea to use it if you have not read the code and understand what it does. And since I am feeling pretty bad ass right now, let's end with Clint Eastwood as an animated gif.
Per André Rønsen•Sunday, Jul 27th 2014 (about 10 years ago)
Genius :)
RainerMaurer•Sunday, Jul 27th 2014 (about 10 years ago)
Congratulations! Very fast :-) Can you write up how you install this all?
eiriksm•Sunday, Jul 27th 2014 (about 10 years ago)
I might do that. And thanks!
mrsinguyen•Monday, Jul 28th 2014 (about 10 years ago)
So cool :D
John_B•Monday, Jul 28th 2014 (about 10 years ago)
Very nice. Tested the page with JS disabled. No CSS or Disqus of course. Serves plain html which is acceptable IMO (and a 'Login to comment' link to /user which does not work). Does the theme works with the native D8 comment system (with plain HTML as fallback)?
Mithril looks interesting.
eiriksm•Monday, Jul 28th 2014 (about 10 years ago)
First of all. Thanks for that. Actually the no-js fallback is even better if you have not first visited the site with JS (you then get the CSS) . Still not perfect though (the frontpage being one example, while individual nodes are looking good) but I have some todos on that for the theme.
No. That was not the intention. I guess I am assuming that if you have no js enabled, you are not a social person, and therefore would not like to participate in (or read) the discussion ;)
Removing those links should also be a todo for the theme I guess.
Oh yeah. It is the slimmest JS framework out there. That is also why I chose it. Obsessed with those KBs.
Tarjei Huse•Monday, Nov 24th 2014 (almost 10 years ago)
Neat! Are you planning to post your Varnish config?
eiriksm•Monday, Nov 24th 2014 (almost 10 years ago)
I might do a follow up on backend configuration (ref also @rainerMaurer up there).
But it is actually really simple. You can inspect the headers of any of the requests on this site and see that I set a different backend URL based on your cookie. So that 2 people requesting the same URL may get different (but still cached by varnish) pages.
Also: fellow Norwegian I see! Thanks for commenting!
Tarjei Huse•Wednesday, Nov 26th 2014 (almost 10 years ago)
A link to a gist or two would suffice - don't bother doing a blog entry if you're short on time :)
Tarjei Huse•Wednesday, Nov 26th 2014 (almost 10 years ago)
I expect you use MongoDB as well? (or is it Postgresql that is most hipster these days?)
eiriksm•Wednesday, Nov 26th 2014 (almost 10 years ago)
While most of this stack is as hipster as possible, the end result is that the database very seldom get touched. So the only reason I would make that hipster would be just for the principle.
OK, joking aside, it's the default mysql you get from apt-get. Which reminds me, I should probably also choose something more hipster than ubuntu next time :p
eiriksm•Wednesday, Nov 26th 2014 (almost 10 years ago)
https://gist.github.com/eir...
Quick outtake of the most important parts. This is varnish 4 by the way, but I don't think any of the parts in the gist is using any other syntax or anything.
If you use it for something some time, I would love to see it!
pxwise•Monday, Dec 15th 2014 (almost 10 years ago)
Great pioneering work here! I actually think this is very close to how D8 will play out in 2015.
I have been wondering if anyone had built headless Drupal with a virtual DOM library and a Google search led me here. I, too am very much a fan of mithril, though I also want to explore what headless drupal will look like with mithril's older brother React. I suppose at the moment with mithril, the M and the C in MVC are a little more clear than with React + Flux.
All implementations and discussions I've seen to date on headless D8 hype angular and Dries himself dropped the A word at his Drupalcon keynote, but I do not see angular as the best fit for headless drupal. IMO, avoiding Angular's tight coupling of functionality stored on DOM nodes, resource intensive & mobile unfriendly $digest cycles and unnecessarily steep learning curve will lead to more successful Headless D8 adoptions. The merits of virtual dom implementations are many and I think the React Component abstraction very cleanly aligns with Drupal Entities. A VDOM implementation may also provide a simple path to isomorphic SPA rendering. If I get time I want to see what I can make happen with V8JS to render react components from Drupal entities server side, to be instantiated client side.
Surprised HHVM had little perf boost.
It would be a dream come true if D8 could also leverage Browserify as a JS dependency manager by default. It is very difficult to track JS load order and sidestep race condition issues in D7 with the open possibility to include JS a million different ways with no clear dependency chain.
Nice work. Keep trying out new crazy stuff. This work is vital to keeping Drupal relevant in the "npm age."
eiriksm•Monday, Dec 15th 2014 (almost 10 years ago)
Wow. Thanks for those kind words.
Just a few quick notes:
- I actually use mithril with msx (https://github.com/insin/msx), which gives me jsx templates in mithril. You should check it out.
- HHVM has little or no effect when I have (about) 2.5 layers of cache in front of it and never allow authenticated traffic. Also, the competition on this server is PHP 5.5. The difference would of course be bigger on a site with a lot of authenticated traffic and older php.
And I think you are spot on in the paragraph about bigger MVC frameworks and headless Drupal. There are so many other nice things we could do. I have a plan myself about leveraging twig.js in some way a day I get the time. But if you ever do something cool with react components server side, I would love to read a write-up (or look at the code) for that!
When it comes to browserify, this site actually uses it. But then again, I just tossed out all Drupal js and included only custom code for the theme. Obsessed with kilobytes, so nothing I don't need there.
Not sure I would want Drupal to do that bundling anyway, but maybe that's because I like to be in control of such things.
Thanks again. And especially thanks for calling this 'vital to keeping Drupal relevant in the "npm age."'. That made my day!