Dear Tim,
No visible work today, it’s been more research. I bet you’re already wondering, if I’m building a react frontend for Kalmany, why am I writing a blog in wordpress and not building my own fancy website for collating my thoughts? The answer is simple: I don’t feel like spending hours building what is essentially the equivalent of a word document that’s committed into my repo next to my code to journal my thoughts. I just want something to write in, and my girlfriend’s suggestion when she gave the idea was WordPress. And heck, I’ve used WordPress before, why not?
When I started the site however, I was given the jolly pleasure of selecting themes, building the page, customising every facet like I’m the next kitchen culinary genius or world-renowned travelling influencer. As if I really and truly thought that my blog will be visited by tens, if not dozens, of fans or curious individuals. My thought at the very onset was, ‘I want to write a blog. I want it easily navigable, and easy on the eye.’
Oh sure, it’s easy enough if you stick with the standard theme but everyone knows that’s not what you do. Else I might as well bring up Notepad++ and start writing out a basic HTML with my interests, likes, and astrological sign. And let’s not forget that most modern day bloggers need pictures and links because they need to picture that latest recipe presented on its plate with a garnish of parsley and a glass of wine, or the most beautiful spot in Majorca they came across last summer. Me, I want just a block of text because the amount of time I want to give my blog thought should be as small as possible – this is the side-project. The journal. It’s a log file. I am not putting time into.
It’s a good segue though. The reason WordPress seems to slather a thick layer of hipster-looking modules and pizazz over their blogs is because the majority of its demographic is the kind of people who want an easy way to start paving their way as a lifestyle guru. Good for them! And it’s not as if it doesn’t provide the tools to tweak your blog’s functionality as much as you require, oh you could overhaul the whole interface sure, but again I’m not looking to spend hours perfecting a blog layout.
Tools are often built by those with a very specific need. And larger companies that take these tools and generalise them will align to the userbase and the largest demographic of users. Thereby there always seems to be a “proper way” to use these tools; these technologies and alike.
How does this relate to me? Well I’ve already said, I’ve got a React frontend, a MySQL backend, and I’ll obviously have a REST API between the two being my middleman. I started my project with a few things in mind of how it would turn out; a list of features to tick off. One of the prominent items is to have the whole thing live. Live! Live on the web. Accessible to the public.
Now how the hell do you do that?
Ask me ten years ago, I’d have attempted to set it up on my home computer, and with a combination of DynamicDNS and some firewall routing, I’d have had public traffic streaming into my home network. Nowadays, not only would that be silly and incredibly inefficient, it’s also impossible with the lack of static IPs and the levels upon levels of subnetworks in a building’s networking. And so dedicated hosting is the next step. Luckily, we’ve existed long enough to see the rise of cloud hardware and the powers harnessed within.
When I started thinking of going live, I knew of GCP, Azure… and I picked AWS. Because I had heard more about it. And in my eyes, I knew very little how any of them worked and I would need to get my hands stuck in before I emerged with any real knowledge on how such platforms would cater to my needs. Am I a professional? Any qualifications? Nope. I have a wish to spend little to no money (£30 a month might be my upper limit on sustaining a project), and I want to host a database, an API, and a react static website. Easy right? Well, yes and no.
When I started the project almost a year ago, I had envisioned creating separate EC2 instances to host each part of my platform and operate on each individually. But then I read into the services AWS provides and realised I could cater it much more finely. That’s when I popped my database up into AWS RDS, the dedicated AWS database service to manage databases and database instancing. Bam, instantly sorted that! Then I had my API and my frontend, both written in Node. Now I could have two EC2 instances running node…But then we have AWS Elastic Beanstalk! A service to collectively managing applications and taking care of your instances without worrying about setting them up, keeping them up to date, setting up VPCs and yada yada yada man, they love their acronyms.
I originally did put both my frontend and API into this, until I realised that my frontend was effectively a static website. So I closed that down and the frontend went onto S3, which has a built in way of supplying a website in the general storage functions it provides.
Okay, Lambda is perfect for python operated system operations – I had originally designed for an EC2 to run my scripts on a schedule, but why have a constantly running machine for doing operations on a schedule when I can set-up serverless Lambda instances to do it for me on timers AND save me money by only costing however long they run for? Perfect solution.
Now Lambda functions also are powerful in that they hook into AWS’ API Gateway – an easy way of building an API. Well hey, I thought, if I can scrap my node app and just build the API up into the gateway, I don’t have to worry about versioning or maintaining my node app. Just write some python functions that I already have to pull out MySQL data and run them in lambda, and have the API Gateway return the results in JSON for my frontend. Solid plan, a good idea.
And then AWS suggests Amplify to me. I read about it, seems to fit my design spec closely – frontend, API, backend; it’s the exact set-up? You see my problem here. If a solution poses itself as a better method, I’m almost instantly won over at the prospect of doing it the “right” way. The way that a solution is built for. As soon as I read into Amplify and tested it with deploying my frontend, finding it was so easy to hook in my github and then just deploy? I was clapping at how easy it was! Until I found the website did not load. Crap.
The point I’m getting at is that each of these tools: S3, RDS, Lambda, API Gateway, Elastic Beanstalk, AWS Amplify, EC2, were all built with very specific functions in mind. And if I read about them worked with them for years, their differences, their strengths, would become very apparent to me. However, I’ve been using them for about a fortnight; I don’t have that experience. And do I care? Do I really care if I use them properly? Or do I care if they just work?
It’s the same thing as I have with WordPress; I have a specific function and design in my mind of how I want Kalmany to work. I have put six month’s work into that design. And so far I’ve been able to maintain that design but the further I go into the rabbit hole, the more I’ll consider stripping and rebuilding my project into the new solutions. Kalmany is currently on its second strip down as its very initial formulation I was running Express for both my frontend and API, and using a simple mysql connector in my python scripts. Now it’s React for frontend, and sqlalchemy doing my SQL operations. Both feel better for me, but its not as if I didn’t have something working before? Was it worth it?
I think the question is very prevalent in businesses. If you’re spending money, often you just pick a solution and stick to it, and only overhaul if you can actual make a saving after the extra work. Luckily my project is still young so I have this freedom, but I can easily get caught up in a cycle of trying to find the right tool for what I want to do. Yet, such a thing is fruitless because I don’t think anyone’s tried making a political simulator with a database and a bunch of python functions; it’s a unique problem! So I just need to find what works and stick to it.
What do I need, and what do I want to do: I need an easily deployable infrastructure for my rapid changes to frontend, backend. I want to supply it publicly. That’s it. And honestly, it’s achievable with S3, Lambda, API Gateway and RDS. Amplify is a tool catered to a need that I simply don’t have; someone trying to whip up an easy to make blog, or simple data modelled app.
I did this exact same thinking with WordPress without thinking about it. Sure, maybe in the future I’ll run into a limitation, but the future isn’t now so why waste time and motivation on that when I could easily drop the project when I get bored in a month anyway?
So the research has been fruitful – I’ve determined it’s not for me. Not many tools out there will be built for me, and that’s okay. Because AWS and many other tools out there are just as you want it, sometimes, but other times you gotta work with what you got.
Anyway, I hear you’ve hit the Alps in Italy so make sure to stay warm. I don’t know how you’re going to get rid of the tail, but I heard there are myriads of small passages you could take to shake them. Hopefully you don’t get another murder attributed to your name. Think of you!
Yours,
Stan
WoodenSocks 