Introduction

So as far as I've seen most developers have there own website but for me, sadly I'm yet to do this so I've decided It's time to embark on the time honoured tradition[1] of a dev building there own personal site!

But I thought I'd make it interesting by over-engineering it on purpose.

My reasoning is several:

• I can put to practice the knowledge I've accumulated on systems architecture
• I can build using interesting technology I've been wanting to try
• I can learn how to use new things
• Fun!

So, I've decided to plan out what I'm thinking of doing here, any discussion or ideas would be and are welcome!

This document is also to act as a kind of repository of useful links with context that are related to the things I've chosen.

Checklists

Selections

• Basic Architecture
  • [ ] Message Queue: Kafka|RabbitMQ|AWS SQS
  • [√] Message format: Message Pack
  • [ ] Routing: Nuster|Nginx
  • [√] Deployment: Docker & Chef?
  • [√] CI: Travis


• Front end
  • [√] View framework: Marko
  • [√] State: Vuex
  • [√] Visual: Materializecss


• Back end
  • [√] Ruby: Rack + Custom Middleware
  • [√] Rust: tokio-serde-msgpack
  • [√] API: Roda

Features I may add

• [ ] dev.to post feed

Services

• Front end (I'll Add to this as I think of more services)

  • [ ] Front End app distro
  • [ ] Routing/caching (Nuster/Nginx)
  • [ ] Front end App distro-service (maybe Node but what ever works best)



• Front Facing Back-end (I'll Add to this as I think of more services)

  • API (I'll add to this as I add API's)



• Rear Facing Back-end (I'll Add to this as I think of more services)

  • [ ] Message Queue (maybe, maybe not)

Usefull links

• Docker
  • Kubernetes on Macos
  • Getting started with micro-services and Kubernetes

The Plan

My idea for my plan is to list things that I think of and what I can do for that item the idea is to fill the list, some of them I'm not sure about I'll put two or more items, I would appreciate some input on them!

I don't know if I'll ever get around to completly building this, but at least if I have a plan I'll have something to work towards.

Lastly, I might put somthing in the plan but this is also for fun so If somthing becomes to annoying or beyond the scope of fun I'll probably not do it.

Basic Architecture:

Host

I've decided to go with AWS, whilst it might be fairly close to the metal it will allow me to get to the nitty gritty

Code

I've decided to go with ruby and rust on the backend, since I'm building with micro-services I can build small services in which ever language I like, or build in ruby first to get somthing running then migrate to rust or hybridise and build with ruby and use FFI for rust.

Infastructure

I decided to go with micro-services becuase it's always somthing I wanted to try doing to that end I need to some infrastructure to go with it.

if I decided I can't be arsed with this I'll just go with a standard monolith and then add micro-services on the side or start as a monolith and then migrate to to micro-services instead.

• Message-queue

  I was thinking about going with kafka or RabbitMQ but In thinking about it, I've decided to go with SQS. As much fun and as interesting as it would be to set up, I really don't need somthing with that much throughput as Kafka or as heavy as RabbitMQ and SQS is supported by Rust, Ruby and Javascript.

• Message-format

  I've decided to go with message-pack, somthing I've had my eye on and should interesting to implement and use across Ruby, Rust and JavaScript(front end).

• Routing

  I've decided to go with trying Nuster as it looks interesting and I've never used it before. But if I can't get it to work as I want I'll go with Nginx as I've used it in the past

• Deployment

  I've decided to go with Docker as I've never used it before so It will be interesting to implement, I'm not sure if I'll need somthing like Chef for deployments though or if I should combine them as i'm a little confused if I need both of them or not.

• CI

  I've decided to go with Travis, again becuase I've never used it and it's free.

I think that's about it for Infrastructure beyond using S3 for assets and stuff, Postgresql (or amazon aura) as my DB

Website structure:

Front end

• View framework

  I've decided to go with Marko becuase Marko's Syntax is just so nice and is highly performant and honestly Marko just looks more interesting.

• State

  Vuex, no competition, it just looks easier to use then redux (and honestly, mutations is a lot easier to understand then reducers in terms of understanding it & context)

• Visual

  Materializecss, honestly this is my second choice, my first is fluent design but the only thing I can find is a React component framework which whilst nice looking (I would say sexy) Is still React when I want to use Vue or Marko. Materializecss is still nice and if I wanted to I could do some acrylic effects to add some to it. As framework however I do like it, way more then bootstrap.

Back end

• Ruby

  Rack + Custom Rack Middleware: In most cases be using Rack to mount apps with some custom built middleware. Since I intend to Build this as a front end JS app with an API backend, if someone knows how to distribute the base HTML + assets without needing somthing like Sinatra then please point in the direction!

• Rust

  tokio-serde-msgpack

• API

  I've decided to use Roda for API stuff as it looks interesting, I'll then use a messaging library to pass messages to the message queue and then any MS will then pick up the appropriate messages, send a response and then the API service will respond. To be honest though I'm not sure, as I've said I'm doing this as learning experience as my knowledge is currently almost zero, once I get a better understanding I'll change this section.

Features

• dev.to post feed

  Instead of building a blog I'd much rather just post dev.to and have links to my posts appear on my site. To that end I can use the dev.to articles api dev.to/api/articles?username=thermatix, there is an RSS feed but I'd much rather just use the API.

For now This is all I have, I'll add more sections as I think of them or decide they should be added, once my plan is complete I'll create a list of things I'm going to build as a separate document, publish it and then update it with any appropriate links and info.

Authors Notes

[1]: building a dev site is probably not a time-honoured tradition but I thought it fit.