This course will cover building a JSON-based API with the following back-end stacks:
‘raw’ Symfony 4 (PHP)
Symfony 4 with FOSRESTBundle (PHP)
API Platform (PHP)
Behat will be used to test all of these APIs. One Behat project, four different API implementations – in two different languages (PHP and JS).
We’re going to be covering the happy paths of
PUT , (optionally)
PATCH , and
We’ll also be covering the unhappy paths. Error handling and display is just as important.
Where possible we’re going to try and use just one Behat feature file. It’s not always possible – the various implementations don’t always want to behave identically.
There’s a ton of good stuff covered in these videos. But the back end is only half the battle.
Whether you want to “catch them all”, or you’re working with a dedicated front-end dev, it’s definitely useful to know the basics of both.
With that in mind, you can pick and choose whether to implement the back-end, or front-end, or both.
If you don’t want to implement a back-end yourself, cloning any of the projects and getting an environment up and running is made as easy as possible by way of Docker. But you don’t need to use Docker. You can bring-your-own database, and do it that way, too.
The Front End
Whatever back end you decide to spin up, the front end should play nicely.
We’re going to implement a few different front-ends. The two I’m revealing today are:
I have plans for a few others, but each implementation is a fair amount of work and I don’t want to over promise at this stage. There’s definitely at least two more coming, but let me first get these two on the site 🙂
The benefit of working this way is that there’s really no extra ‘stuff’ to get in the way. We can focus on making requests, and working with responses.
Again, as mentioned we will cover more than just raw JS and React. Currently each implementation is between ten and fifteen videos. Each video takes a couple of hours to write up, and another couple of hours to record on average. I’m going as fast as I can, and will upload and publish as quickly as possible.
Behind the scenes over the past 10 weeks I have been working on integrating CodeReviewVideos with Braintree.
This is to enable support for PayPal.
I tried to create a ticket for everything I could think of ahead of starting development.
And I added a new ticket for any issue I hit during development. I’m not convinced I tracked absolutely everything, but even so I completely underestimated just how much work would be involved in this feature.
Being completely honest, I have never been more envious of Laravel’s Spark offering. For $99 they get Stripe and Braintree integration, and a whole bunch more. Staggering.
There’s a bunch of other new and interesting features in this release.
I’ve taken the opportunity to migrate from Symfony 3 to Symfony 4 for the API. There’s a bunch of new issues that arose during this transition – I hadn’t given it much prior thought, but with the new front controller (
public/index.php) totally broke my Behat (
This work is also enabling the next major feature which I will start work on, once PayPal is live. More on that in my next update.
I appreciate that from the outside looking in, there doesn’t seem to have been a great deal of activity on the site over the last few weeks. I can assure you that behind the scenes, there has never been more activity.
I love React. Thank you to everyone involved in getting this new release out of the door, and thank you to everyone in the React community for making my time with the front end a heck of a lot more enjoyable than it used to be.
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.
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
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:
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.
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.
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.