So for various reasons I decided to write my own blog engine and because I think AppEngine is such a fantastic platform (especially for hosting multi-tenanted apps) that is what the initial runtime implementation uses.
I now have a few blogs setup which demonstrate the multi-tenancy working so I thought it was a good point to do some back-of-the-envelope math to figure out how much it would cost to host or how many blogs I could host for any given price.
Remember - one of my motivations for doing this is that I’m too cheap to pay for someone else to host my blog and I also want to host blogs for friends and family without ending up on the endless treadmill of maintaining servers, database backups and WordPress plugins.
So how’s it looking so far?
I’m an avid user of AppEngine and just discovered that it turns 9 years old this week.
9 years! That’s almost as close to infinity in Internet Time as you can get without tearing a hole in the fabric of the universe.
The amazing thing is that despite its age it’s still way ahead of it’s time in many ways and I think that is why it doesn’t get as much attention and fanfare as it really deserves. I remember the first time I came across it I didn’t really “get” what it would do for me so it was a couple of more years before I switched to it.
So in case you don’t know, here are some reminders of why it’s so brilliant …
Just a quick snippet for integrating Google Analytics with Polymer Single Page Apps.
As well as tracking ‘page’ views anytime the route changes, it also uses Google Analytic’s Exception Tracking feature for cheap-as-chips error reporting - handy to check on any browser compatibility issues you might have missed.
I saw this data from a Polymer product manager buried in a GitHub issue comment and thought it was worth highlighting to show just how amazing Polymer 2.0 is when it comes to framework-size. Many JS frameworks have made grand promises about the small size of their apps but it’s usually only after an inordinate amount of work and effort that you even get close to the promised values, if at all (my Angular 2 app was never anything buy huge).
Polymer is very different to many of the JS-first frameworks in that it builds on the web platform instead of trying to reproduce and replace so much it - because browsers are actually very good at parsing HTML and rendering it quickly if only you let them get on with it (yeah, who knew!).
Here are the individual + combined sized of the different Polymer versions together with the Polyfills required in each browser …
One of the really great things about Polymer 2 beyond the framework itself is the well thought-out tooling with the polymer-cli helping you with project templates, local dev-serving, testing, linting, build and packaging.
The only thing it doesn’t do for me right out of the box is create the information needed to add http/2 server-push. It will actually generate link prefetch tags that go into the index.html page which does speed things up but what I really wanted was to push the dependencies for a view on first load with the first request.
It turned out not to be too difficult at all …
It’s the result of constant and seemingly endless changes, reinventions and releases of tooling and frameworks that you feel you need to keep up with.
But things are going to change …
Because everyone should write a blog engine at some point in their life …
This is the story of how I went from WordPress, to Jekyll, to Hugo, thought about going back to WordPress, briefly considered Ghost but ultimately decided to write my own multi-tenanted blog engine instead, powered by Google Cloud, Go and Polymer.
Dependency Injection or ‘DI’ is a mechanism used within Angular2 to provide instantiated services or other objects to the components (and other services) that need them. It allows a class to ask for just what it needs without needing to know about the entire tree of dependencies in order to create them itself.
The idea of DI is based on design principles intended to help us write better, cleaner and easier to maintain software. Unfortunately, there are certain limitations in the implementation of the Angular2 DI system which mean it’s not always obvious how to get all the benefits we should.
So, we’ll explore these principles using DI with the
Http and an
implementation as an example to show how it is still possible to achieve.
What makes a good client-side router? What do we even want a router to do? What is Angular2’s Component Router like and should you plan on using it?
I’ll share my own thoughts on this based on my experience of using it so far.
Once you move beyond the quick-starts and examples and start building a real app with Angular2 you soon find you need to handle things that the examples often leave out or pass over.
Securing routes with the new component router is one of these and it can be difficult to figure out. Here’s the approach I’m using which seems to be working well for me and has been reusable across multiple projects.