June 22nd Side Project Checkin

fastflowz profile image Dakota Lewallen ・1 min read

Side-project Checkin (9 Part Series)

1) April 28th Side Project Check-in 2) May 2nd Side Project Checkin 3 ... 7 3) May 6th Side Project Checkin 4) May 14th Side Project Checkin 5) May 21st Side Project Check-in 6) May 30th Side Project Check-in 7) June 8th Side Project Check-in 8) June 15th Side Project Check-in 9) June 22nd Side Project Checkin

Howdy Dev.to travellers!

Hope you're doing well and getting a good start to your week. But how was your weekend? Started on a new project? Have an idea you'd like to mill over with someone? Let's chat in the comments below.


markdown guide

I've been working on versioned RPC: github.com/pj/vrpc, its basically version control for types and service stubs and is intended to make it easy to build backwards and forwards compatible services and clients. Not sure whether it's actually useful or not, but would welcome any feedback.


I don't know a whole lot about RPC. However I would like to think I know a bit about TypeScript. Just after a quick glance through the project, something you commonly do is define a class and then in the constructor function you define all the parameters needed for the class then spread them across the class with "this.thing = thing". I also see you've written some with OO languages where this is standard practice, and while what I have to recommend can clean-up the amount of code you have to maintain, it doesn't make large functional changes. The change I would recommend, would be to pass objects to the constructors, define interfaces for those objects, then finally use the spread operator to combine the passed object with the class your defining. So now when calling new Class you should pass it an object with your parameters now named rather than positional and you have to write less boilerplate in your definitions. I wrote a small gist here that's untested but has the general idea.


That's a good point about the positional parameters. In general I'm trying to be as dumb and readable as possible, e.g. avoiding functional programming idioms and generally excessive cleverness, even at the expense of much more duplication. I tend to come and go on this project so it's more important for it to be familiar and very explicit to avoid the "Wait... I wrote this code a month ago and can't remember what it does" problem. YMMV

Fair enough haha. It's always something you can come back and clean up later if its warranted. Other than that it sounds like a really interesting concept. Have you written at all about it elsewhere?

"Brevity may be the soul of wit, but it's the armpit of code readability" - William Shakespeare.

Haven't written anything about the recent changes though.

Who knew good old billy could be so insightful when it came to software practices lmao. Personally I'd love to see a tutorial or something around this, considering I (along with a lot of newer developers) probably aren't overly familiar with RPC. Either way best of luck with the project :D


This weekend I made leaps and bounds of progress on my personal site. I wrote a small article about it here... 👇

I'm super happy with it, but I'd love to hear your guys' thoughts.