>> Good morning, as she said, I'm Elyse and I currently work at Vevo and one of the things
that my team is responsible for is the website, and we have a lot of need for having great
SEO, and so several years ago, we decided to build a universal app, sometimes called
isomorphic, and so I have a lot of experience building universal apps for SEO purposes and
as she said, I wrote a book about it.
So if you're interested in learning more after this talk, then you can come talk to me later
about the book.
So what we're going to talk about today.
We're going to go over what it is at a high level.
I'm going to tell you about why you might want to build it, tell you about how you might
go about building it and what some of the added complexity that comes with a universal
app is and I may alternate between universal and isomorphic.
It's pretty much synonyms for the same thing.
We need to talk about the current available web architectures, so first we have server-side
rendered applications and a server-side rendered application, your user comes to the browser,
gets directed to your web server, fetches some data, renders a page and returns it to
the browser.
The down side is you have to hit the server on every user interaction.
So then we had single page application and in a single page application, your user comes
to the browser interacts with your API, and the UI is updated.
This is pretty cool but now I have to wait for your site to load when I first come to
the browser and it's also not very crawlable by bots like Google.
So why don't we just do both of these things?
So when we do both things, your user comes to browser, gets directed to your web server,
some data gets fetched and now your page gets rendered, but importantly, we also send down
the current state of the application as it was rendered on the server.
This allows us to rehydrate your app in the browser and then enter single-page app flow
and then you get all the benefits of real time user interactivity within the browser
without having to hit your web server, but Google can still crawl you really well, share
bots can crawl you really well.
So why build it?
I've already mentioned this, but let's say, you have a site and you have a lot of cat
videos, and these cat videos, you want them to show up first when people search.
To do that, you need Google to be able to crawl your content and so in a universal app
you're able to serve your content to Google quickly and completely every time and also
serve the needs of your users.
There's also perceived performance.
Often when we're building single-page applications we have to use a lot of loading spinners,
we have to wait to go fetch data after we load things in the browser.
This is not a great experience.
So when you first server-render your website, people get to see the content immediately.
There's still a little bit of a lag to actually interact with your site, but often the user
won't notice if you do this right, and so you get the benefits of perceived performance.
There's also developer benefits.
You get to write everything in JavaScript.
So that's cool, because instead of switching contexts to go to my web server, maybe it
was written in Rails or Java and now I get to go to my Node server and in fact, if you're
setting this up correctly, like 90% of your code should be identical, so it should run
the same in the Node server as it does in the browser.
So how do we go about building this?
Well, the goal is we want to write code once and run it in two environments.
So thankfully, pretty much every major web framework that exists today supports this.
So this is great.
If you already have an app, say you have an app that was written in Ember or Angular,
as long as you're using the latest versions of these frameworks, you can go ahead and
make it universal.
React and Vue.js both have virtual DOM which makes this process really efficient and even
new things like Ariala this too if you just want to go out of the box then you can use
these solutions.
Like Next and Nuxt. is Vue.js and ... so let's take a moment and talk about the sort
of magical part of this, why this is different than other things, so when you come on your
server, you're going to fetch your data, here we have an example, we have a user and the
user has a cart and some products.
And we need to get this data to the browser to be able to use it when we build the UI
in the browser.
So we create a string from this data and then in the browser we deserialize that back into
some kind of variable here called the initial state and we use that initial state to go
ahead and start up our app.
So this way, we create our app in the browser and have the exact same state and therefore
the exact same HTML as we did on the server.
What's cool about this is like with React and view.js where you use more like the virtual
DOM concept, you can avoid like doing any repaints in the browser, so it's really fast.
So here's a visual example of this.
So I've set a break point right before my app hydrates, and this is a React example
and on the left, you can see, here's my UI it's already displaying to the user and on
the right, you can see where it will bootstrap and in this example, once React updates, it
will be like, hey, there's no differences, that's cool, I'm not going to do anything.
>> So let's talk about some of the added complexity here.
Why is this maybe a little bit harder than what you do normally?
So first you have two environments, and these two environments don't work the same way.
On the browser you have a window and a document object and Node doesn't know about those.
It has different concepts, global environment variables, things like that.
So you can deal with this in a few ways, you can use something like WebPack to set environment
flags so your browser and your server can both know which environment is which.
That way, if you have like a social widget which needs the window object, then you can
not render it on the servers.
Make sure you always use a single source of truth for your user session info, so when
you load off of the server, you should respects that state that comes down to the browser,
don't try to recalculate that state on that initial load.
And then always make sure that your NPM packages are isomorphic or universal, so they need
to work in both environments.
Performance can also be a problem.
This really depends on which framework you're using and how complicated your UI is.
React 16 made a huge difference here for server renders, but you might run into problems regard
Les.
So you can use caching strategies.
Or explore technologies like streams.
Finally and I think this is the hardest part, is when you're testing, there are always two
states, right?
There's always a state where you load it from the server and you need to make sure that
works, and there's always a state where you navigate to this feature or experience in
the browser and you need to make sure that works, and I've seen people, very experienced
people come into this kind of app and still get confused by this, until they internalize
it, and so even though this has a lot of cool benefits in terms of SEO and performance,
I think you need to be aware that this can really be a challenge and a problem, and something
you're going to have to, like, give your team time to learn and understand before it will
be easy to work on something like this.
So hopefully you now understand the universal architecture may add some complexity but gives
you clear benefits for SEO and performance and hopefully you can use this information
and decide whether you might want to apply this to real problems that you have.
Thank you.
[applause]