Angular Universal and PHP, first adventures in V8Js

Submitted by mrjmd on Fri, 05/20/2016 - 22:57

There have been multiple rumblings in the last few months surrounding Drupal and Angular 2 integration, as well as more generally PHP and Angular Universal integration. While some discovery work and even some sprinting around these efforts have occurred, as of yet there is not a whole lot to showcase. But let's have a look at what has been done so far, and where these efforts are attempting to go.

Back in February of 2016 there was a joint effort between the Angular team and some prominent Drupalists to make twig (the template engine used in Drupal 8) work seamlessly with Angular 2. This largely boiled down to using twig.js and a six line patch to Angular 2 in TemplateNormalizer that brought the whole thing together:

var _isTwig = template.templateUrl.endsWith('.twig');
if(_isTwig) {
  templateContent = twig({
    data: templateContent
  }).render(new directiveType.runtime());
}

There is some pretty cool potential that this points us towards. I mean, being able to use a regular twig template that ships with Drupal as your template in an Angular 2 component is an awesome notion. It means a Drupal 8 themer can write their templates just as they are used to for consumption by a progressively decoupled Angular 2 application.

But ultimately this method has some major drawbacks as well. Primarily, since it is leveraging twig.js, this implementation is moving work to the client side (processing twig templates) that is already being done server side by Drupal. Processing templates isn't really something that should be done client side, and even Angular 2 itself is moving toward an offline template compiling that was announced a couple of weeks ago at ngconf (it's not quite ready yet, though I've played with it a little and it is exciting). I'll come back to offline compiling at a later date.

There was also some parallel work done to make a custom Twig decorator for use inside Angular 2 apps. This too, has some interesting potential, but without a node.js backend to at least accompany your Drupal stack, it still keeps too much templating work in the client to be desirable from a performance standpoint. To be clear, all of this was done as purely proof of concept work, so in terms of planting signposts for us to know where to head next, I think these exercises have been a success.

What would be ideal is direct integration with Angular Universal, which is Angular 2's isomorphic initiative. This would allow us to move not only template processing, but where desirable full component rendering to the server side, so as much initial state work as possible can be done before handoff to the client.

Repeatedly in my discussions with the Angular and Drupal folks working on these topics, another possibility has been raised: V8Js. What is it exactly, why do extremely intelligent people keep bringing it up in these discussions, and why don't any of them seem to know anything more about it than the fact that it exists?

V8Js, to quote directly from the link above, is a PHP extension that "allows you to execute Javascript code... from PHP." It does this using V8, Google's open source JavaScript engine. It is a strange idea, and the first time I looked at the example code associated with it I was left somewhere between curious and offended:

$v8 = new V8Js();

/* basic.js */
$JS = <<< EOT
len = print('Hello' + ' ' + 'World!' + "\\n");
len;
EOT;

try {
  var_dump($v8--->executeString($JS, 'basic.js'));
} catch (V8JsException $e) {
  var_dump($e);
}

Yes, you're reading that correctly - it's PHP running a basic javascript print and dumping the results. Is it an abomination or a stroke of genius? Well, frankly I haven't entirely made up my mind yet, but there's no doubt that people have been doing interesting things with it like running server-side react components using PHP instead of node.js. I want to play with it myself and see just what could be done here. After a couple of failed attempts and with the help of a dev ops colleague, I finally got the extension running using the following method:

$ sudo add-apt-repository ppa:pinepain/libv8-5.2
$ sudo apt-get update
$ sudo apt-get install libv8-5.2
$ sudo pecl install v8js

Then by adding a line to the end of my php.ini, "extension = v8js.so", and restarting apache, I was ready to test it out.

I'm not entirely sure where this is headed, but there is a working group forming now to continue this effort, including Jeff Whelpley and PatrickJS. Our first meeting is next week. My plan of attack is to keep working with V8Js and studying the existing Java integration proof of concept, which also leverages V8 using J2V8. This should help me understand the integration points with Angular Universal.

All of this work is being done in parallel to my ongoing work on the Decoupled Blocks module, which would be the main direct Drupal implementation I'd like to incorporate these efforts into. But obviously this type of integration could benefit all kinds of PHP / Angular 2 applications. In the meantime, as showcased in my presentation last week at DrupalCon New Orleans, as well as the Angular 2 session, right now you can use Decoupled Blocks module to drop Angular 2 components onto your Drupal 8 pages.

I'll post a follow up on integration progress soon. Until then, from javascript executed server side by PHP in Drupal, "hello world!"

V8Js hello world

 

Comments

Member for

46 years 5 months

Rabith Kuniyil (not verified)

Thu, 06/02/2016 - 10:05

Good Article.

Thank you.
Rabith Kuniyil

Member for

46 years 5 months

jonathan daggerhart (not verified)

Tue, 06/14/2016 - 18:40

Great post, thank you for laying all this out.

It seems that the options are very limited if you don’t have control over your servers. Without some amount of control, you can’t install V8Js, node, or ngular Universal.

What I’m most excited about is Angular Universal. Nothing smells better than official support for a chosen approach.

V8Js definitely seems a strange bird. It’s telling that the react components article ultimately abandoned it for a node server. I think that when using it I would always be wondering, “What have I done to deserve this?”

At the moment, the node server approach seems like the most flexible concerning future stack pivots. Paired with twig.js, I’d be interested to know what else it would take to make this happen. You may even be able to use the official angular universal starter kit to guide a temporary raw node.js implementation https://github.com/angular/universal-starter

If the real problem is the hosting companies don’t offer the level of control you need for the implementation you think is best, then maybe they aren’t the right host for a progressively decoupled site.

Very interested to see where this goes next! Thanks again

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.