Introduction

I am Vish Desai, dabbler in code, fledgling entrepreneur, software engineer, middle-aged man, son, husband, dad, Indian, etc. - a normal person based out of Bangalore, India. You can find me on social media here - LinkedIn, Github, and Twitter

So what do I do on a day-to-day basis? My morning job is to be the CTO of a company I co-founded. Which means that I do everything from product management, to project management, to people management, to architecture / design, to code review, to... you get the idea.

What am I planning on doing?

I am authoring a series of blog posts - approximately one every two weeks or so - that walk-through the process of building a secure, reliable, scalable, server - step-by-step - and tips on continuing to maintain it. Easier said than done, I know, but...

Caveat Emptor:
I want to make it clear that this goes without saying - there is no "one size fits all" for servers. There are hundreds of problems that software systems solve, and not all of them can be reasoned about and coded in exactly the same way.

On the other hand, the most common software systems developed on a daily basis have fairly similar goals - collect input, execute a workflow / process, apply business rules at each step, persist in a store, run reports, display dashboards, etc. And, simultaneously, perform well, perform reliably, and scale up/down as needed

This "most common software" slice of the server pie - "business software", as opposed to "infrastructure software", if you will - can be reasoned about in a fairly consistent manner at an architectural / design level; and the workhorses of such systems - the servers - can be developed from a cookie-cutter-ish template with a high degree of efficiency.

So, just to reiterate, my aim for this blog is to put my thoughts down on how to start from scratch, and develop a robust business software solution, and how to maintain it after that.

Basic FAQ

Q. What will "The Server" actually "do"?
Short Answer: "Hello, World".

Longer Answer: It will respond to a couple of different user queries - Return a standard "hello, world" to one query, and echo back whatever is sent on a different query, i.e., ping-pong.

Q. That sounds completely useless. Really?
Yes, really. I want to walkthrough the process of thinking about architecting / designing / developing a server for the most common type of software - business software. As we will see, most business software servers are fairly typical - so what they "do" is also fairly typical. Depending on the business application, and the commands / queries associated with the specific business problem, the actual data signature (its "shape") will, of course, vary, but...

Counter-intuitive as it may sound, worrying about what the server will actually do is counter-productive at this point. I will get to it a bit later - when I demonstrate how my "toy" server can be used to build a real-world application.

Q. So... will the final "Server" be the "ultimate" be-all/end-all for all servers?
Short Answer: Absolutely NOT! See the first paragraph of the caveat emptors above.

Longer Answer: Absolutely NOT! My aim here is to highlight all the different ingredients that go into the making of a server, and put across ways and means of thinking about each one of them. I want to present a way of thinking that puts a decision framework in place - and helps managers / architects / leads / developers come to a defendable conclusion without getting into analysis paralysis.

How will your sponsorship help?

I'd like to dedicate a set amount of time every week to think about and write long-ish blog posts (and, of course, the accompanying code where applicable) on authoring servers for now - eventually turning them all into a book. In order to do that, I need to take a step back from my startup, and focus on my writing.

Your sponsorship will go a long way in helping me do that, and finishing this project in a reasonable amount of time. So if you are interested in helping me, please do so - and thank you!