Back when I was a server room techy there was a line my old boss used to say whenever I got wind of something new and shiny:
There are no new ideas in IT, just the same ones on repeat.
Of course he was being tongue-in-cheek, but there was a truth in what he said.
For example, around the time I was in this role, the IT industry was moving from distributed to centralised. That is to say we had a bunch of servers dotted all over the county, and the plan was to bring them into just two central server rooms.
This, I was assured, was very much like “the olden days” when individual desktops were replaced with “dumb terminals”, which relied heavily on a centralised Mainframe.
At some point, someone (likely an army of well paid consultants) espoused the failings of such an architecture (oh my, single point of failure!) and likely sold them a bunch of high powered standalone desktops.
This worked well for a while, then companies like Citrix came along and sold a different spin on “dumb terminals” using your existing high powered desktop, and so on, and so on.
What the heck does any of this have to do with Web Development, I hear you ask.
Good question.
As you may recall, I have been getting quite excited about launching the new, shiny revision of CodeReviewVideos.com. I had my zip lock baggy of party poppers at the ready. Things were looking super.
Then, over the previous weekend, it dawned on me:
How’s the SEO on this new site then?
Seeing as about 70% of the incoming visitors to CodeReviewVideos arrive via Google, I figured I should probably – ya’ know – give this some consideration.
I checked, and it turned out that I had, ahem, neglected to set any of the head information.
Yes, I felt quite the chimp.
But not to worry, I have all the SEO data just sat ready and waiting in the DB. After all, it’s exactly the same as for the existing site.
What happens with the existing site is what happens with pretty much any PHP site I have ever worked with:
- A request comes in
- The relevant data is fetched from the DB (thanks, Doctrine)
- This data populates a template (thanks, Twig)
- The response is returned to the end user (thanks, Symfony!)
It doesn’t matter if the request is from Google Bot, or from a real person. The process is always the same.
What this means is that the response contains everything needed to make a full page representation.
Google Bot can look at the page and see all the expected “stuff”: the header tags, and body content, it’s all there.
Sure, we can then augment this with a snazzy bit of JS here and there, but largely, it’s good to go.
Web 2 Point… Oh?!
Then sometime a few years back, Single Page Applications (SPA, and not the relaxing kind) became popular.
Fast forward a few years and boom, I’ve done a few of these here SPA’s with React and Angular, and I’m thinking: yeah, this is awesome, let’s make CodeReviewVideos all snazzy using all this wicked tech.
So I did.
The new version of the site uses React, and Redux, and Redux Saga, and it talks to a Symfony JSON API, and it’s all lovingly tested and fills me with warm fuzzy feels whenever I work with either code base.
Unfortunately, all this awesomeness does make the architecture more complex. Let’s revisit how a request / response works now:
- A request comes in
- The user gets sent this:
<!DOCTYPE html><html lang="en"><head><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta charset="utf-8"/><meta name="viewport" content="width=device-width,initial-scale=1"><title>Code Review Videos</title><script type="text/javascript" src="https://js.stripe.com/v2/"></script><link rel="shortcut icon" href="/favicon.ico"><link href="/main.0c31c168e455a7de8ecee02d7d21798e.css" rel="stylesheet"></head><body><div id="app"></div><script type="text/javascript" src="/main.bf614c9bf38e83f9d4e0.js"></script></body></html>
- We are done, let’s go to the pub.
If you’re a bot Yahoo, Bing, or Yandex, you’re now done.
By all accounts these bots do not process JavaScript, so forgettaboutit.
This may very well be of no major consequence.
By way of some hard figures, the combined total visitors that CodeReviewVideos received over the last 7 days that came via a search engine that isn’t Google was:
11.
Fixing the world for the sake of these other search engines probably isn’t worth my time right now.
But Google… well, we must do better.
Now, it turns out that maybe Google has already solved this problem.
My guess is they have. I mean, this is Google. They are super smart, and it’s their job to get this right.
But can I risk killing the site on a maybe.
No, definitely not.
What Happens Next?
Back to the HTML from above. Thinking about the request / response sequence, what happens next?
Well, on the client side – which is to say in your visitor’s browser – assuming they have JavaScript enabled, the JS is read and run (or parsed and executed, if you’re a CS text book).
This is where all the cool stuff happens!
- React builds the page from my components
- The components instruct the browser to make requests to the back-end API for the real content
- The real content is received
- React renders the content into the right place(s)
- The visitor is completely indifferent
By the way, if the visitor doesn’t have JavaScript enabled then they are going to have a bad time. But, ya know, 2017, etc, etc.
When I realised my mistake about SEO last weekend, my first thought was to simply grab my Helmet and populate the head tags using the API response.
Alas, as we have now seen, this simply will not do.
So I figured I would be a Smart Guy ™ and put a caching layer in front of my web server. Maybe I could trick the bots by returning a fully cached version of each page.
Yeah, that didn’t work.
At this point I had a short breakdown.
Fortunately, PHP North West happened which took my mind off of the problem.
Ultimately though, it meant I had to postpone the scheduled launch. And that sucks.
Server Side Rendering anybody? No? SSR? No?
Of course I’m not the first person to have experienced this problem.
There is already a solution:
Server Side Rendering.
The idea here is rather convoluted, but stick with me:
We already have our shiny new React site, right? Yes, yes we do.
So, let’s get a Node JS instance to sit in front of our React site, and uses some of the stuff we learned in the Dark Arts class at Hogwarts to run this code, then convert the response to a string, and write the string to a template, which is turned into another string which is sent back to the browser so that we now have the necessary HTML to please Google like in the olden days.
Oh my.
It seems like we’re repeating ourselves here.
But now with more layers. More bug filled, confusing, maybe unnecessary layers.
Anyway, that’s where I’m at with CodeReviewVideos right now. Trying to migrate my existing front end code from client-side only, to this SSR setup to essentially reproduce the outcome I already have with plain old PHP.
What this means is right now I have no ETA on the next version, and once it is again “ready”, I will need to go back through a phase of testing before go-live.
Video Update
This week saw three new videos added to the site:
#1 – [Part 1] – Twig Extensions – How to add a custom CSS class to an invalid form field
Between this, and the next video we look at a question I got asked late last week:
How can I add a custom CSS class to the `input` / other form field when validation fails for that field?
This video explores one possible solution to this problem.
What happens however, is that we end up with a bunch of repeated logic living in a Twig template.
Generally, if you find yourself repeating yourself… or you end up with complex logic living inside a Twig template, you can probably extract it into a better location – a custom Twig function.
#2 – [Part 2] – Twig Extensions – Create a Twig Extension Function to Keep DRY
As such we look at extracting this repeated logic from our Twig template into a Twig Extension.
It’s one of those topics that sounds like it might be hard, or too nerdy, or whatever.
It’s just a strange name for a very useful concept.
If you use Twig in any seriousness, and you don’t yet know about Twig Extensions then this video should help you understand how to use one, and why it’s not as hard as you might think to do so.
#3 – Docker Elixir Phoenix – Part 1 – The Web Server
In my personal experience there has been no better way to improve my overall knowledge of software development than by learning another language.
Elixir, in this case, is the language.
Phoenix is somewhat akin to Symfony, or Rails, or what have you. It’s a framework for web applications.
In this series we are building up a small but functional (ho, ho) JSON API using Elixir and Phoenix.
In this video we cover how to set up the Web server by way of docker-compose.yml. This series is a little more advanced than most of the content on CodeReviewVideos, but I hope you’re finding it enjoyable all the same.
That’s It, That’s All
That’s just about it from me this week.
As mentioned last week I spent the previous weekend at the PHP North West conference.
You can read about my time there right here.
There are pictures 🙂 and also a lesser spotted Rasmus found in his natural habitat.
Have a great weekend, and happy coding.
Chris
