I've been in web development since 1998. At some point, I'd become pretty fixated with what we would now call a Headless data approach. I started working with Node.js, MongoDB, and Backbone.js and I found that working with enterprise APIs like SharePoint and WordPress were a real pain as they were predefined and often quite poorly designed.
I found that more often than not if I hadn't developed the API myself, the work to get what I wanted out in a concise manner was often too much to maintain and scale at an enterprise application level.
What I needed was something quick, secure and easily consumable. The main problem was, that designing those simple APIs took quite a bit of time, even though it was well worth it in the end.
When I joined AECOM, there wasn't a single point of truth for anything. I started using Angular and React, but I still, needed data endpoints. I was dealing with Adobe and Salesforce, still equally as bad, in my opinion. It was a struggle until at the end of 2018, I came across something that really caught my eye, Strapi.
I couldn't quite find the right project for it to start off with, but in early 2019, I was asked to make an app for some awards. I opted for a React PWA and decided on Strapi as this was my big chance to use it.
Strapi was still in beta, but I had the system up and running locally in a day. I configured the rest, to kick out everything I needed in one corner. I'd never used Strapi before until this project but I was fine.
The front-end was a breeze and I had a functional application working in seven days.
The next opportunity to use Strapi came almost immediately after.
I'd been asked by a client team to create a UX design that essentially converted an environmental impact assessment for a road that was planned to be upgraded near Stonehenge to a digital.
It was a pretty big deal. EIA is a very long and complicated document that is usually delivered in bound books that can contain thousands of pages.
It's never been done before, the project had to be very agile, it also contained potentially gigabytes of data. The one thing that was the easiest choice in the whole project was Strapi.
We could rapidly change and develop the content types. Most importantly, we had a JSON content type where we could store geospatial information in a standardized format, GeoJSON. We could customize the API response so that we only got the data we needed in the right calls.
The site had to be fast and there was a lot of information. So we created web workers to download the bulk of the info to the local cache in the background whilst using the main threads to grab the info people were actually using in order to make a very responsive site, which actually after a lot of compression contained only around 250 megabytes of data.
As far as development was concerned, it was agile. And we were delivering working versions of the site constantly to the client. So we could just clone Strapi at the touch of a button, branching the dev and the data so we could keep working on another version. I think this portability is one of my favorite things about Strapi.
You have a data structure locked in and just by copying the API folder to a new instance, cloning the Mongo DB, and copying the uploads, you're working on a new version instantly.
The dev work we did on that project and the choice of Strapi as the data provider meant that we had the basis for a product in about six months. And it was a pretty complicated product.
We have the server set up from my original awards app and we pushed a blank Strapi structure to a bit bucket repo and wrote a shell script that pulled the React front-end and created a new digitally EIA ready for data entry in minutes.
The only difficulty we found during that project was that with the amount of data and the relational content types, Strapi got complicated.
It was overwhelming for a non-technical user but we already had a solution.
Strapi offered authenticated access controls and whilst the API was opened for read access, it was so easy to configure for the authenticated right access. User authentication was built into Strapi. So after a couple of weeks of creating a front-end, we actually had the basis of a front-end special CMS.
Now we have reusable Strapi instance and several flavors of Gatsby front-ends, both already on bit bucket with default content and configs added in.
We have a Mongo DB that can be cloned from the server with our default content ready to go.
We now have a couple of front-end branches that perform different functions that are all connected to this one Strapi microsite boilerplate.
Again, we have a shell script that creates, clones, installs, and configures the Strapi on the Gatsby files on the server. And we have an Apache webserver also on the same virtual server, ready to serve the preview side.
I originally went headless because I wanted an agnostic data source, disconnected from the various front-ends I might need, be those internally or externally facing, things like power BI dashboards, intranet sites, even ingesting markdown from Strapi into Adobe InDesign for project content.
The fact that Strapi has the ability to utilize both GraphQL and REST also granted me another one of my wishes. It meant that my data was easily accessible from anywhere.
A lot of the content we produce in a company as big as ours has dual uses, both for a client external marketing but also for staff awareness. Using REST along with GraphQL, I could have the best of both worlds.
My intranet sites could pull campaign data from the Strapi site via secure rest and I could use the GraphQL to provide the approved content I wanted for external use. This meant that even if my project hadn't been approved for external use, I could still host it in the same place and surface it for internal use.
These had an unexpected benefit as once my internal stakeholders saw the project listed for internal use only on our intranet, they quickly got the client approval needed for us to push it externally, which as it was all in one place was a real breeze.
The more development I did, the more I realized that what I'd hit upon was the perfect approach for so many reasons. I loved React after Flash and, of course, Strapi, it just made sense but I had to consume APIs using REST.
For the marketing sites, I needed amazing SEO and performance, and this is where another great feature of the fully headless and static site approach really shines for me.
By using Strapi and Gatsby as a static website builder, I now have SEO, I have performance, I have API accessibility, and now I have security (which is a big issue with projects built on WordPress).
I have a totally separate preview site on an Apache web server, on the same server as my Strapi instance. Using the Strapi webhooks, users can build previews, clean the Gatsby instance and publish the Gatsby instance to a very simple app service. The app service is just a scalable web server essentially a glorified CDN, nothing more.
Once that's published in public-facing, it's as secure as the sites I was building 26 years ago. There's no link back to my data and re-published new versions can happen in seconds.
The final benefit from this approach is sustainability. The site I'm currently working on deals with AECOM's move to become a more sustainable and ethically responsible company.
It dawned on me that the approach that I've taken makes the final published sites about as sustainable as a website could get. It's being served as HTML from a pretty dumb web server. The DB is only accessed on the build, not every time someone visits the site, and my virtual dev service leaps when it's not in use.
With the separate micro-sites and the many different flavors of front-ends connected to a unified backend pulling all this so it runs on one Strapi, even the tasks that we thought were impossible now seem to be quite easy.
In the next six to eight months, I'll be using Strapi as part of the main AECOM web estate. And my grand plans of having all of our marketing collateral in one place will start to become a reality and best of all, that one place won't be WordPress.
By using Strapi and Gatsby as a static website builder, we now have SEO, performance, API accessibility, and, most importantly, security.