On static pages and replacing the website

(Victor Nițu) #1

cross post from here

A bit of background would be needed first for anyone who’s not aware of our setup. There’s an Ember app (namely Elvis), running entirely in the client. We have some static pages that have to be easy to manage for non-Ember devs. We also have a Wordpress instance we’d like to remove, because it adds complexity and yet another URL to the project.

I spent some time in the past days looking into killing our Wordpress instance and replacing it with the production instance of Elvis. Some outlines of the plan:

  • remove WP
  • move elvis to tenders.exposed
  • have any kind of blogging / website system somewhere to put static pages in
    • …and grab those pages directly into Elvis UI by using API calls or similar
    • possibility to provide blog posts for when we’d need it would be appreciated

So I started off by installing Ghost, the 1.0 pre-release version. It’s supposed to be a huge release, lots of fixes and features, and I am a Ghost user for about an year now. It really is a nice CMS to work with. But I’m not exactly the lucky kind, so here are a few conclusions:

  • Ghost has an API. Quite a complete one, if you’d ask.
    • Authentication / request authorization system is awful. Couldn’t get past it, even by hacking the database and reading some source code. At least not in the way we want it, to enable CORS for all the possible origins, since our API client would be Elvis, which is an app that runs on the client’s machine.
    • Tried grabbing the raw HTML in a desperate effort of making something work. Failed miserably to produce a half decent implementation, worst hour of my recent programming adventures.
  • Ghost provides a very nice systemd service to start it as a . Awesome stuff, that actually worked out of the box. No complaints.
    • Part of their “out-of-the-box” strategy was also the Docker image. A short while ago, the damn thing wasn’t even booting the framework. Now it does, but having experienced issues before, I’d wait for the final release and some more to even have the courage to upgrade the thing. Docker tags to save the day here.
  • Ghost changed their page/posts editor! I know it’s supposed to make it nicer, but I loved the old one! That was actually part of the reason I was even tempted to use the platform:

So, I decided I had enough of this crap and tried (desperately) to move on. I googled for a while for content management systems exposing an API, of which the endpoints to GET public posts to be left unauthenticated and not fuck around with uptight CORS policies. Guess what? Apart from some overengineered CMSs, I found nothing…

Now read the title of this again. Says something about static pages, right? Well, that’s because I felt like there was nowhere else to go and I hopped on the Jekyll train first. Reasons for going static are probably the most sane in this whole adventure and I’ll probably still try to find a way to do it in the future:

  • we don’t need frequent updates
  • much less vulnerabilities
  • we don’t use the website directly, but mostly as a “bucket of posts and pages” to pull into Elvis
  • having the ability to keep everything in a git repo is exciting (yay, no more DBs)

So I went on to do some more googling and discovered Netlify, which is a nice service, commercial but free for FLOSS projects. Its aim is to quickly deploy static website platforms from any github repository into their infrastructure, then use some sort of management UI to take care of things. You can see builds building, deployments deploying and so on. Maybe even configure it with a custom domain and put some Let’s Encrypt SSL into play. Even more, they threw an API on top and I was already excited for the ride! But unlucky as I am sometimes, I had another string of unfortunate conclusions to draw:

  • their service was nicely integrated with 3rd party platforms, so I could “Deploy to Netlify” a Jekyll, then Octopress instance to the custom domain I had already configured. That’s the nice part about it.
  • the API is okay, but it misses simple GET endpoints for the CONTENTS of the sites. Endpoints are only hitting the Netlify admin, and they’re not at all integrated with the websites they deploy. Which only makes a lot of sense from a technical point of view, but I was kinda expecting this amazing feature from a service that expensive
  • on automated “Deploy to Netlify” procedure, it authorizes with GitHub and creates the repo for you. That’s it, no questions asked, so I ended up with a repo in my own GitHub namespace with a name they wanted. Had to transfer ownership to organization, rename, change the deployment configuration and so on. Just like a “manual” deploy, but with a few extra steps added.

So, if Netlify only hosts static pages and custom domains, doesn’t this sound a lot like GitHub pages already? Why not use the system offered by them, given that we already have a lot of stuff in there? So I gave up on Netlify and went on trying GH pages once again, looking for some light.

But I haven’t found the light on GitHub pages either:

  • easy to set up my Jekyll instance. That’s what it was built for, right? If no, then it totally feels like it!
  • we can have SSL on GitHub pages as well. But as soon as you put in a custom domain, the option goes out the window and there’s nothing you can do about it (oh, now I see what Netlify had in hand!)
  • they say GitHub pages are CORS enabled, so you can fire requests to them from anywhere and be allowed to. In my experience, sending a ember-ajax request ended up in 401 situations, no matter what I did to it. Boom! :boom:

All this time though, I tried to avoid grabbing raw HTML pages. Not necessarily concerned about payload size at this point, but more to do with metadata. What would we do to get blog posts? Write XPath queries to pick them up from the XML payload, then remove the excess markup? Use jQuery on them? Both are ugly as hell, so no.

Turns out Jekyll, being Ruby based, can be hacked in a million ways to do whatever you want, and that includes compiling to JSON. So I looked a bit into altering (or adding another one) the rendering engine so I could easily curl stuff in the format I want. All this while being hosted anywhere, which sounded (at last) like a reasonable approach.

At this point, I took a step back and realised how absurd the situation has become. All I wanted was to be able to write stuff with a CMS (to avoid cluttering the frontend app we run) and just include the managed resources via any kind of doable request from Ember. We had a Wordpress instance we wanted to throw away, also to decrease the complexity level by reducing the CMS needs to a simpler platform. Everything described above is a few levels above anything that’d be less complicated.

So I looked around for any Wordpress plugin providing a JSON API for the thing. There are more of them. I picked the first one. They claimed to be REST-style, which isn’t really, but nevertheless it works! Out of the box, batteries included. Just installed into the existing WP instance, then requested a random page and voilá! I can have some content in, hassle free. And we don’t even have to worry about getting new shit it, figure out how it works, deploys and so on.

Go on, request for example this page. Is it JSON? Yes. Is it CORS friendly? Yes, because I host it and can modify headers. Does it have SSL? Yes, because I host it and have deployed a Let’s Encrypt cert on top of it.

That’s it, really. Next time you’re planning to simplify something, try not to look for answers into a rabbit hole. I learned my lesson (at least for now).


discourse should have a “like” button :slight_smile:

(Chut Ko) #3

well, and maybe it has :smiley: