Way back in January 2012, when I started a new role at Amazon, I needed to learn how to code using Ruby and Rails. As a personal exercise, I decided to put together a simple blog platform using the language and framework not only to get my feet wet, but also because I didn’t like the idea of using another platform like Wordpress; I wanted to have intimate knowledge of how it worked and be able to make changes to it on a whim if I wanted.
The requirements I had were pretty straightforward: * Written entirely in Ruby and Rails. * Learn something new to bolster my “tool box” of skills. * Be able to create, read, update and delete posts. * Be able to tag posts so they’d be able to be categorized. * Use a single blogging platform for multiple domains and have the posts that are shown for each domain be relevant for only that domain, including being able to show the same post across multiple blogs. * Use media wiki to format the text. I used this format on a daily basis so it made sense at the time to use this.
Thus, my blogs were born: one for personal stuff (family and friends), and another for more technical stuff that I want to share with the world. Let’s be honest though, it’s usually just for me, apart from the occasional recruiter that contacts me on LinkedIn that mention my blog. I haven’t written to them very often (my last post was in September of 2018, and before that it was 6 years earlier), but I do aspire to write more often than I do, which has caused me to give more thought into my blogs lately.
There are a number of things that get in the way my writing posts, the least of which is having many commitments in my day-to-day (work and family mostly). It’s also the lack of accessibility in writing them, however. Like every other hobby-like thing in my life, I need to be able to maximize the little time that I have which means planning and being able to make gradual progress; sometimes a few minutes here and a few minutes there. In a nutshell, being able to write posts where ever any free time presents itself. In order to do that, I would ideally have an app on my phone that would let me keep track of post ideas, and put them together and post them whenever I can.
Another, perhaps more important thing, is having something compelling to write about. You don’t just start a blog for the sake of doing so. You do it because you have some knowledge or experience to share. While I’ve been able to write a thing or two over the years that satisfy that requirement, I’ve never been able to do it consistently, both because I wasn’t spending a lot of my free time doing things that I felt like sharing, and because I wasn’t in and found it difficult to get into the habit.
Finally, there are constantly so many cool things being done in the tech space, and being able to experiment with those things and do things that generally take me out of my comfort zone, will help keep me fresh and not stagnate in my career. The urge in me to continually learn new and interesting things is enough that rolling my own software is the best option. Being able to share those things with people is really exciting to me. If I can help show somebody the ropes, or to help plant a seed in somebody’s head for their own ideas, then I feel very rewarded.
While putting together a blog with Rails was a great exercise for me at the time, my career has been heading in a different direction the last 3 years or so. While my current role does include some front-end work, it’s minimal at best. Most of what I do is back-end work, and it’s starting to move into the pure AWS space, as opposed to some AWS, and some internal Amazon stuff (though there’s still a lot of that). With my team starting to head in that direction, I’d like to be able to learn more about AWS services and how they can help solve the problems I’m keen on solving (personally and professionally). This seems like a good opportunity to rewrite my blog platform using AWS services and other frameworks, languages, etc. to put together the full stack. This is not going to be a small amount of work, but I think it will be interesting enough that it will keep me engaged through to the end, and I’m hoping that my experience can help other people putting together similar projects. I’d also be keen on putting all the source code up on Github so others can benefit as much as possible.
I’ve already started on some of this work, and the rabbit hole is a bit deeper than this, but I’ll get to the other details in subsequent posts.I should note that I’m trying to design the full stack in such a way that it can essentially scale infinitely, though I realize that my blog in particular doesn’t need to. As this point, most of the stuff that I have planned should be easily accommodated by the AWS free tier. To that end, here’s my high-level plan for putting this all together.
Except where otherwise mentioned, I’ll be writing most of the code for this project in Java, which is the language I’m most comfortable with. When using Java, most of the new stuff I’m learning will be related to AWS services or different frameworks. There will be other components later on that will provide new learning in different languages. I’ll also be using Maven for dependency management.
The AWS CDK (Cloud Development Kit) was introduced in July, 2019. It’s a framework that allows you to write code in Java, TypeScript, and others that generate Cloud Formation configuration to deploy your CFN stacks. It takes care of a lot of the heavy lifting for you, and adds very user-friendly APIs to manage permissions and other aspects of CloudFormation, not to mention the ability to auto-complete your code in whatever IDE that you use. I’ve used this a bit for a small project at work and am smitten.
I’ll start by defining the APIs that will be needed to create blogs, articles, tags, etc. via AWS API Gateway. Defining how you want to interact with a system is a great first step, which will help define the implementation details more formally. I want to use the OpenAPI specification to define the APIs and create the API Gateway end points to make the process as easy and maintainable as possible. While the group that defined OpenAPI has tools to generate code based on those specifications, I wasn’t able to find one that works with API Gateway, and certainly not the CDK as it’s fairly new. It’ll require writing some custom code to generate the APIs using the CDK.
I’ll be using DynamoDB to store all the data needed for the blogs. While I’ve thought about blogs from a relational perspective, pushing the data into Dynamo will force me to think in a non-relational way.
Ever since SwiftUI was announced at WWDC earlier this year, I’ve been really excited to jump into it to build an app. I think the blog platform will be the perfect opportunity to do so as it should be fairly straight-forward once the API is defined and implemented.
Along the way, I’m willing to wager that there are several other tools or technologies that I’ll need to learn in order to implement the platform as effectively as possible. The fact that I already have a blog platform in place means I don’t have to rush through this, but rather I can do it right. Beyond that there may be some other not needed but nice to have things I could learn such as setting up a continuous integration environment using AWS Code Commit, Build and Deploy. As the project grows, any sort of automation that I can implement may help save time in the long run (help me utilize my time as best as possible), and also be far more fun than doing things manually.
This is a pretty big project, and has a lot of bits and pieces that need to come together in order to make the whole. Turning anything into a habit can take quite a while; not the 21 days that I’ve previously heard. I don’t want to overcommit myself, which I’ve shown is something I typically do, especially when it comes to writing. To that end, I’m going to commit to writing an average of 12 articles over the next year that will gradually document the effort I go through to get all this stuff setup, including migrating all my previous posts from my Rails/PostgreSQL stack. Some of them will be longer than others, and I may even do more than that as I run into problems, or new tech that I want to take a stab at to solve a particular problem. Expect some tangents as I go.
As a final note, since I’m most comfortable writing in Markdown, but my current blog implementation only understands mediawiki, I’ll be using Pandoc to convert to that format, until I get the current platform up and running. I’ll likely also use it to convert all of my existing articles over to Markdown. We’ll cross that bridge when I get there.