Why hosting more than one service on a single host in production can be a big problem

Strange — Wed, 06 Sep 2023 13:36:57 +0000

In the ever-evolving landscape of infrastructure management, one topic often sparks spirited debates: the practice of hosting only one service per server in a production environment. It's a mantra chanted by many, a design principle considered gospel by some. But what if we challenge this conventional wisdom, just a bit?

Recently, I found myself in a conversation with a new client, discussing the intricacies of infrastructure design. The client confidently asserted that having more than one service on a single host in a production setup is a cardinal sin of modern architecture. While I've always been an advocate for the scalability and elegance of the one-service-per-host approach, I couldn't help but wonder: does every rule have exceptions?

This discussion left me intrigued and yearning for a deeper understanding. What if there are scenarios, like the symbiotic relationship between an API and its caching companion (Redis or Memcached), where bucking the trend makes perfect sense? As I delved further into this topic, I began to wonder if I'm not alone in challenging the status quo.

If you're an engineer who has, at least once, contemplated the idea of cohabitating services on a single host, this post is for you. Let's explore the reasons, scenarios, and justifications for this approach, and engage in a discussion that may very well redefine some of our long-held beliefs about infrastructure.

Leveraging Conditional Properties Type Checking with Discriminated Unions

Strange — Mon, 04 Sep 2023 20:49:48 +0000

Strict type checking feels like a privilege ever since I encountered it in my career and i'll give anything to have it in any part of my code. So i decided to write this short post (for strict type checking fandom😌) to share a trick for type checking conditional properties of an entity .

I am just going to go straight to stating the problem so you can better understand what we are dealing with, (actually Its because I fear boring you more than anything). And also to stick with the goal; keep the post short.

Problem statement

The first thing I'll like to note is, this example is super contrived and there are better ways to go about this in a real world scenario. It however complements what we are trying to achieve so, here we go.

In our application, we have a createUser function that takes the properties of a user as described in the CreateUserAttr type. We have two types of users (Admin & User). The two variations of CreateUserAttr have some shared props and differences which are marked as optional props of the CreateUserAttr because we want to pass admin only props when creating an admin and vice versa. Hence the problem; the role prop when creating a user type of Admin is not optional (as seen below), we have to provide role and all other props related to the Admin type (super contrived 😉) likewise the verified prop when creating a user type of User.

Solution 😋

The solution is to take advantage of typescript's union and intersection types to create a type known as discriminated union or tagged unions. We first create our base type which has all the shared props between the User & Admin type. Then we intersect it with a block that has two union type where we'll add the admin props and the user props. Putting everything together we have a type that has our shared props AND either the Admin props OR the User props.

Now we get the yelling when we don't pass the all the required props relating to the type of User we are creating, SWEET!

Hooray🎉! we now have type checking to make sure we are passing the required props of the user type being created, and also check that we don't pass a prop that doesn't belong. The example we have explored is intentionally simple to illustrate the core concept, but in real-world applications, the benefits become even more apparent. You can explore more examples here.

Conclusion

In the world of software development, the privilege of strict type checking is indeed a treasure for those who have experienced its benefits. The added advantage of this approach is, our code becomes more readable (it's clear which property belongs to which union) and autocompletion (depending on the IDE). Our Types also become easy to extend because adding new types to the union is straightforward. So, whether you're tackling simple examples or navigating the complexities of real-world applications, discriminated unions offer a potent tool to make your code more robust, reliable, and enjoyable to work with.

And don't hesitate to drop a comment if you have any specific topics you'd like me to cover in future content❤️.

DEV Community: Strange

Why hosting more than one service on a single host in production can be a big problem

Leveraging Conditional Properties Type Checking with Discriminated Unions

Problem statement

Solution 😋

Conclusion