"The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times." — Robert C. Martin

I'm afraid I have to disagree with this statement. Let me tell you why.

There seem to be many opinions surrounding clean code. Some people have an entire architecture of how code should look. Others stick to the actual layout of the code, or length of a class while even others vaguely point towards Robert C. Martin's books.

One thing is clear; it's something that's really on a lot of developers mind. Clean code makes projects more comfortable to work with and improves shelf life. It's the antagonist of vile legacy codebases that are unmaintainable.

Then why does business always treat it as a secondary objective? Do they just don't get it?

Clean code and architecture indeed allow businesses to have a more maintainable product. But I'm sure you would agree that before you can have a maintainable product, you should first strive to have an actual product.

The foundations of a product are undoubtedly essential; they dictate the mindset of the months/years to come, but they also take a tremendous amount of time. Time in which the project isn't moving. If the project isn't moving, we are not generating revenue. Every start indeed requires a startup cost, but we also need the lights burning and the espresso flowing.

This entire mindset was partly the start of the agile movement. Build a minimal viable product, get it to the market fast; see if there is a demand, iterate.

It's where that horrible motto from Facebook comes from: "move fast and break things".

It seems we've come to an impasse: the tech side wants a well balanced and nutritional dinner, while the business side wants fast food

So yes, that mindset results in those paymentsService god classes that are 5000 lines long and nobody dares to touch. Controllers that speak directly to databases; in short, technical debt.

It seems we've come to an impasse: the tech side wants a well balanced and nutritional dinner, while the business side wants fast food. But it's essential to realise that it's not a tug of war. It's better to look at it as a process that needs some leniency from both sides.

As said in the previous chapter, you can't build a product in a vacuum. You need to stave it against the market. Otherwise, you risk much capital against untested ideas. Investing a third of your budget before you even can think of a front-end might be a bit risky from a business standpoint.

On the other side, keeping acquiring technical debt is also not a way forward. You will indeed have a quick start. Implement features in days instead of weeks. ... till you can't anymore. Just like financial debt, technical debt will eventually catch up with you. And it can end your business just as quickly. It's great to have a product that's a perfect market fit, but if you can't keep up with your competitors cause your application is too slow, or features can't be implemented quickly enough due to the technical mess, you will lose out.

So treat that technical debt as you would financial debt. Use it to invest it into your project. But keep track of it and pay it off. I would recommend this post from Mathias Verraes on how you can do this.

Image courtesy of XKCD (https://xkcd.com/844/)

You also have to keep the scope of the project in mind. Some people build systems with the mindset that it might blow up anytime and we're going to need to support this for years to come. Other people start big projects without tests and pretend that they're going to write them in the future, "when there is time".

It's critical to strike a decent balance here and reevaluate the scope and market position of the product at regular intervals. This evaluation should not be only on the business or technical side; this is a team effort and should also be communicated that way.

It's essential to realise what you are building and the impact it will have in the near and far future. Keep the short time roadmap concise and don't over-invest (financially and technically) but also don't try and outrun the liabilities you are taking on along the way.

Keep communication of the status and impact of the project open towards the entire team, and reevaluate these values on a regular timeframe. Adapt your level of technical investment according to these projections.

Clean code makes projects more comfortable to work with and improves shelf life. Its the antagonist of vile legacy codebases that are unmaintainable. Then why do we see it all the time?

You have probably already heard the horror stories of code interviews where they ask you to reverse a binary tree on a whiteboard. (if not check this blog post that I profoundly disagree with)

Well, a few days ago I was in that exact situation. And I had no idea what the interviewer was talking about. So what are these binary trees and why is it so critical that you know how to inverse them? Let’s find out.

A binary tree is a very simple data structure that as the name suggests looks like an upside-down tree.

This structure is mainly used for searching. For example, if we needed to find 4 in this structure quickly, we would need only to make 2 binary decisions. If we scale this up to 1000 nodes, we would only need about 10 choices. There are other options still, like self-balancing binary trees but let’s keep it simple at the moment, and just focus on balanced binary trees.

Ok so now that we know what it is let’s start with inverting a binary tree. What do we mean by that? It’s actually very straightforward. We turn this:

      4
     /  \
    2    7
   / \  / \
  1  3 6   9


     4
    /  \
   7    2
  / \  / \
 9  6 3   1


We flip the entire structure horizontally. So 7 and 2 are flipped, and the 2 children are also flipped. All the way down.

As we are good OOP developers, we are first going to start with our tree. A binary tree is nothing more than a collection of points, called nodes, with 2 children: a left and a right one. So first we are going to create a Node object.

Binary1.php

(I’ve added value to the object as well, just to give it a practical use)

Now that we have the Node object it’s time to create a tree.

Binary2.php

At this point we have a data structure that looks like this:

This is all set up, time to move on to the swapping. If we break the problem down to its core, we just want to swap the children of a node. Like this:

Binary3.php

We take the Node and create (and return) a new Node with the children swapped. We now have:

At first, glance that looks like we completed the task, but if you look a tiny bit deeper, you might see that we only inverted one level. The lower levels are in the same place (but on the other side of the branch).

To switch those we actually just have to repeat this process till we run out of levels. Now that sounds like a recursive function.

Binary4.php

The first thing to note is that our function signature changed. We now also accept null values. Why? Well once we hit bottom, there aren’t any children left. getRight() will return null. This null will indicate that we are at the end of our loop.

Binary5.php

This is that check for when we run into a null value as described above.

Binary6.php

This is the recursive method. Every time we pass this, we go one level deeper. If we hit bottom, that if will take care of it and it stops. If not, we swap the values and bubble it back up to the level above.

That’s it. Inverting a binary tree is 10 lines of code. It’s actually pretty simple.

Cool, so when would I actually want to inverse a Binary tree? 

I have no idea. I’m sure some brilliant people on Reddit or Twitter will have a trove of useful functionality, but I sure can’t think of one.

In my opinion, this is just one of those job interview questions that solely exist so the interviewer can feel smart. You could argue that this is a simple test to see if the candidate can think recursively, but I believe that an open conversation about the interests of the candidate + maybe a small take-home test would give way more insights.

What is a binary tree and why would I ever want to reverse it

Monday morning. Your previous project just wrapped up, and they are going to assign you a brand new one. They even promised you the lead on this project. Who said Mondays couldn’t be great?

A few hours later and you are staring at the most dreadful code you have ever seen — controllers of more than a thousand lines, PHP that injects jQuery in the views, raw SQL statements that could challenge a Dostoyevsky novel in size. The list goes on and on. This Monday is going to need a ton of coffee.

The previous few lines might sound very familiar to you. You might even be working on a project like this at this very moment. If that is the case, … lucky you.

Why do these horrible applications exist? 

Most applications don’t start like this. As you know, greenfield applications start full of hopes, dreams and rainbows. A new business idea gets launched. It does something small, pretty good. People like the application. They like it a lot. More and more customers flock to the application. You excitingly add more functionality to your small idea. Soon, one of your more prominent clients asks for a very valid use case.

Hmm, you haven’t thought about this particular flow in the application. To be honest; the application doesn’t support it. However… it’s a big client, and it’s a great idea. You know what, this small little hack won’t make the difference. We’ll document it, so everyone knows about it.

Fast forward a few months. You have a dozen developers working for you, and your Kanban feature board is filled to the brim. The strange thing about the board, however, is that most of the features on that board don’t come from your hand, they come from customers. Moreover, they all want concrete things very tailored to their workflows. That little hack that’s been made a few months ago is now not even considered a hack anymore; it’s just how the application works. Moreover, if you take a step back, most of the application is now a collection of these small little hacks.

You might think that this is a horrible product, and from a code perspective you might be right. However, from a business perspective, this is a vital process. The product has a ton of customers, and they are invested enough to want to tailor it to their workflows and they even reach out to you with suggestions. Granted, not all of these suggestions are great, but they wouldn’t come forward if there weren’t a need for them.

However, now where does that leave you, It’s entertaining to have a company with many customers, but at the end of the day, you’re still the one that is in the trenches of despair.

Not necessarily; Having a product like this tend to generate income. The most significant part of that income is invested back into the project. Once the legacy code hampers the production of new features or generates too many bugs, the discussion surrounding refactoring parts of the code tend to start getting more and more speed.

Once you start refactoring, you suddenly notice that you have so much value in front of you — a ton of use cases already implemented, a wealth of user behaviour and data, metrics and most important of all: the budget and infrastructure to match.

Most refactorings tend to start with the question from management that is frequently a variation of: “what are the worst parts of the application, and how can we make them better”. This sentence is poetry to a developer’s ear. A great chance to go over the entire application note down the pain points, look at technologies that might ease trouble, have lengthy discussions with colleagues about the architecture of the pesky service classes. Not only are you going to learn a ton on the technical side of things, socially you’re going to improve in ways of persuasion and proposing ideas.

After a while, the most significant part of the spec will be done. Moreover, I can guarantee you that you’ve never been so excited to work on a project before. You can now look at the project and see a road to be walked, where before it was just an end to a means.

Now comes the tricky part, refactoring one of those huge files. The first time you read over the class, you might get some doubts about this whole refactoring stuff. Luckily you stick to your means of attack and write your first end to end tests. Once you’ve established a safety net, you regain a big part of your courage.

Ok you think, this piece of code I might be able to extract to a separate class. You write the unit test. You extract the code, and everything is green. Ok, great start! Let’s do it again.

A few hours later you stare at the construction you’ve made. It’s a vast improvement of what it was before (every single indentation you fix is an improvement), but looking at the loose classes, you can see some definite improvements still. You could leave it as it is, and that would be great, or go further. Either path you chose, at one point you’re going to create a PR, and sit back and stare at the diff screen of your favourite git hosting service … what a beauty.

Working on applications like this is all about responsibility. Every decision you make as a team will impact you in the future, in a good way and sometimes in a not so good way.

This kind of pressure might sound like a burden, but in reality, it is indeed a blessing. It forces you to slow down and think about your actions as a team. Should I write a test for this? The answer is going to be yes, cause once it has a test, it’s going to part of the test coverage for maybe years to come.

So that’s the beauty of legacy code: You get a rough stone that you can shape into a gem. The pressure of delivering new features won’t be lower on a legacy application over Greenfield, but management often understands the need for refactoring and architectural meetings better.

Moreover, all the technologies and paradigms learned in the refactoring of legacy code are invaluable when you move on to Greenfield projects as you now have the context for the need for value objects, testing and decoupling.

So yes, if you’re about to start on a legacy codebase. Lucky you. You’re about to have one hell of a ride.

Controllers of more than a thousand lines, PHP that injects jQuery in the views, raw SQL statements that could challenge a Dostoyevsky novel in size. This Monday is going to need a ton of coffee.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and I were discussing some code that we refactored earlier. Not so long in the conversation the words "Integration Operation Segregation Principle" casually got dropped by Pim.

Now I'm going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

ISOP1.php

As you can see, we have a small piece of code that calculates the price for a few days of rental.

The code itself is pretty straightforward. We gather the start date, the end date. We calculate the number of days and later on multiply those days by the price + the km's driven. A small piece of code, that does a lot.

ISOP2.php

It mocks a few things, then calls the calculator and asserts the results. All in all a very simple unit test, but not a fun one to write.

If we take a look at that PriceCalculator class you can see it structurally does 2 things: it fetches data and performs actions on that data. Or in other words: it integrates and operates.

At this point, you probably already figured out when the Integration Operation Segregation Principle is all about: splitting these up. Let me show what the previous class looks like with this principle applied:

ISOP3.php

ISOP4.php

ISOP5.php

ISOP6.php

"Frederick you devious hack!" you might shout, You've turned a small method into a 4 class method that more than doubles the lines of code.

Well, you're not wrong. It's way more code. And on first glance, it looks way more complex. But let's take a step back and go over it.

if you strip away the dependency injection etc, you're left with

ISOP7.php

There is nothing complex going on here. Everything perfectly describes what is happening. That $dayPrice? Oh, it's been calculated, how is it being calculated? Who cares. No need to worry about it. Someone with almost no programming knowledge can read this method and fully understand what's happening here.

ISOP8.php

I would argue that the logic in there is even more simple.

In the future, there might be some business logic changes (we might need to do something with tax?). We now know where we can do that, everything is contained in this little class.

This is also a nice illustration of the Open–closed principle.

So yes, we do have a lot more code. But it's all very simple code, easy to read, easy to debug and the coolest of all: Easy to test.

ISOP9.php

Now that is a nice unit test. No mocks, easy to write, easy to read. (compare this to the unit test at the top of this article).

As you can see the Integration Operation Segregation Principle is just a long and complicated term to describe something very simple. This all might seem like a lot of work, but it's worth it. Your code and especially your tests will thank you later

If you want to read more about this, do check out this incredible blog post: The Incremental Architect´s Napkin - #7 - Nest flows to scale functional design

Not so long in a conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim. What the hell is IOSP?

The integration operation segregation principle

I work in many legacy codebases, and in fact, I’ve made it a big part of my career. I love diving into big monoliths that have grown out of proportion and tidying them up. One of the best parts of that work is rewriting a God class into a collection of small reusable classes. Let’s take a look at what makes a simple class great.

One of my favourite types of classes is a value object. For those not in the known, a value object is a small class that holds a value with a tiny bit of extra logic surrounding it. Sounds simple enough right? I think a nice way of looking at these classes is implementing them as an extension of the type system of your programming language. Let take a look at an uncomplicated example.

VO1.php

This small class doesn’t do anything really, and it just holds two strings. The only tiny bit of function (at first glance) is that it concatenates the two strings. However, for the minimal amount of code in this class, it does offer a ton of value to your codebase.

Once we start replacing every occurrence of the first name and last name with this simple class, you will quickly begin to see the value. First of all, every time you come across this class in your code, you know that it has a first name and the last name in it. You also know that both of these values will be strings. And that you have an easy way to display the first name - last name combination.

You can now also add this as a safety in your new classes. You could, for example, do something like this:

VO2.php

Here you easily guard your method from all kinds of extra logic. You know that the variables that enter the method are of the type Email and Customer class.

There is however still a major issue with our values objects. We could still trick our system into accepting empty strings. Let’s take a look at how we can make these classes just a tiny bit more robust.

We know that our values in our object will always be of the typed string, but “” is also a string. so you could do

new CustomerName('', ''); or even new CustomerName('\$', '!');

You could allow that last one if you are building a platform for rappers, but in most cases, you would want to guard against that.

If you are using PHP (like the examples are), I would suggest using a package like webmozart/assert.

VO3.php

(you could add a private validation method to the class that is called on the first line of the constructor if there are many validation rules)

The class is now a lot smarter; it validates the values that come in and will throw an exception when they don’t meet the expectations of the class.

Now you can be sure that whenever you encounter this class, the values within will be usable.

Adding more means of production to the classes 

It might be very tempting to start now adding more and more logic to these classes. However, I would caution restraint here.

A common thing you see is people adding getters and setters to these classes. You might notice we already have getters (we just not named them getters), and I would strongly recommend against adding setters.

If you need to update a value in the class, create a new instance of the class. Value objects are meant to be built and discarded. By creating new value objects you also make sure you pass the constructor every time, and therefore including the validation.

If you really feel like adding setters, make sure they create new instances themselves:

VO4.php

Another thing to touch upon is named constructors. A named constructor allows you to create the value object under different circumstances. I feel like it is easiest to explain with another example.

VO5.php

(this example is to demonstrate the function of a named constructor. This method assumes that a name is always in 2 pieces with the first name as the first piece. If you want to implement this, please add extra logic)

These constructors are a small convenient way to create the value object. Named constructors allow for great flexibility. However, like always, you should not take this flexibility too far.

You should always ask yourself, is this method solving a real problem, or am I just adding this for a one-off small convenience?

Named constructors are very useful in a “Time” class, where you can create the class from a string format, or from the hour, minute and second parameters as further explained here by Mathias Verraes.

There is still a lot to be said about value objects. We haven’t touched upon testing, logging, naming…

For more information about these topics, I would advise you to look into some DDD books or even better check out Matthias Noback’s book “Style Guide for Object Design”. A book that prompted me to write this article. (I get no personal benefits for advertising this book, I just think it’s a great book)

If you haven’t implemented Value objects into your codebase, I would greatly advise you to give it a try. You will wonder how you ever lived without it.

A value object is a small class that holds a value with a tiny bit of extra logic surrounding it. Sounds simple enough right?

As you might know, I co-organised a PHP meetup called: PHP Antwerp. Some time ago we had one of our talented speakers: Joeri Sebrechts talk about “What every developer should know about time, no excuses“ (If you ever have the chance to see it, I wholly recommend it). In this talk, he mentions briefly the Y2k38 problem. A bug that will wreak havoc on systems that store time in Unix epoch timestamps.

For those of you who weren't fully sentient around the time, everyone partied like it was 1999 (for the second time). The big problem around that period was the Y2K bug. Quickly summed up, the Y2K bug was due to people storing years in a 2 digit form like 88 or 67. Now when the year ticks over to 2000 (or every 100 years) they would reset to 00 or 01.

At the time there was a lot of media buzz around the topic. Planes would fall out of the sky, hospitals would shut down, society would collapse. When the clock eventually ticked over to the new millennium, everything seemed to be still fully functional (including the bleached spiked hairstyles). The media quickly resumed the new hot topic and it all quickly died down. The entire event would be remembered as a hoax.

But it absolutely wasn’t. In Gary Hockin’s talk “Using Open Source for Fun and Profit” (One of the best talks I’ve ever seen) he briefly talks about working together with other engineers to check applications for the bug and mitigating the issue (yes he is that old). The truth is that it cost a lot of hands and a lot of capital to sort out.

And even then we didn’t make it out without a scrap. Credit card machines stopped working, 2 unplanned abortions ensued, An alarm sounded in a nuclear powerplant in Japan and even the US Naval Observatory was touched.

So yeah, Y2K happened because of a logical problem, but 2038 sounds a bit random… That’s because we are looking at the date in a “human-readable” form. If we store the data as a Unix epoch timestamp, a form of timekeeping that counts seconds forth from 00:00:00 1 January 1970, we would get 2147483648.

Again, for some people, this might still look like a very random number, but that is more than half of the maximum range an integer can take on a 32-bit system. An integer has a positive range and a negative range. This allowed us to go to dates before the year 1970. Half of its range is negative and half of its range is positive. If you count these two halves up, you might see that we are dealing here with an integer overflow. More precisely after 03:14:07 UTC on 19 January 2038.

It is possible to change the positive and negative range of the data. However you can not extend it, but you can shift it forward or backwards. For example, a company that deals a lot in old data might have shifted the timestamp further back. Giving it less reach in times after 1970.

This means that the Y2k38 might not appear for everyone at the same time. Or even in the year 2038.

Mostly the same situation as Y2K, but in this case, we don’t go back to 1900 but we go back to 13 December 1901. The good news here is that we jump from a Tuesday to a Friday. The bad news is that banks might calculate negative interests, airports might send wrong routes to planes, basically, everything that has a critical function related to timekeeping might be in trouble.

When we look back at the Y2K bug, it all seems kinda silly. Why would you store a year in a 2 digit form … why couldn’t you anticipate this issue … The same question arises for Y2k38, you know the integer will someday run out in your 32-bit system. So why use it?

There is a bit of survivorship bias going on here. Take for example the project you are currently working on. It can be a long term legacy project, a cool new startup idea or a small advertising project. Will that be around for 5 years? 10 years? 30 years? It’s very hard to tell right now, technologies change, the product changes. Preparing your code for an issue that might show up in 30 years sounds irrational. Yet somehow some systems keep running without that refactor for years.

premature optimization is the root of all evil (or at least most of it) in programming. - Donald Knuth

What software is at risk at the moment? 

It is very fussy to give a full list of all systems at risk. But it is safe to assume that almost all systems that count on Unix timestamps in a 32-bit environment will be at risk.

This includes operating systems, databases, embedded systems …

Should I start digging a fallout shelter? 

Yes, yes you should. Would be a kick-ass ice breaker. “Did you know I have a fallout shelter”? Actually, scrap that, sounds kinda creepy. You would at least not need one for this bug. Just as with the Y2K bug, this one will pass. There will be a lot of money spend. A lot of people will earn a lot of money. But in the end, it will mostly be resolved.

In the meantime, it seems best to not store your dates in Unix timestamps if you're on a 32-bit system. For all, you know your software might still run on some old machine in 20 years.

In 2038 a bug that will apear that might trigger a strong feeling of déjàvu to the Y2k craze. The Y2k38 bug seems to come at a very random moment, but it all makes sense if we apply a bit of computer science to it.

The y2k38 bug: the biggest news craze of the year 2038

Microservices are all the rage these days. Luckily underneath the hype, there are some great use cases for them. If you’re splitting up a monolith codebase into smaller specialised chunks, extracting a long-running queue to its own system, or even using particular pieces of code in a different programming language. You always have to solve one architectural problem. How do I make these things talk to each other?

Your first reflex might be a collection of REST API's. Put them in a network with filtered ip’s, or any other way to secure it, and call it a day. But if we take a step back and look at this setup, is REST really the best way to go about it?

Don’t get me wrong, I love REST. But in this case, should we be thinking in terms of resources? If we take a system that crops avatars for example. You would get something like this

GrpcPatch

This doesn't really feel right. We aren't dealing with resources here but more with actions on data.

Fortunately, we aren’t the first ones to ponder on this.

Some of you might have had a shiver run down your back when reading that title. RPC is commonly linked to older systems and even worst: linked to SOAP (shiver nr.2).

The reason you might not have great experiences with these setups is, ironically, for the same reason we described above. They have been misused to fit the architecture they aren’t designed for. RPC is actually perfect for the use case above.

For the people not familiar with RPC, let me give a quick overview: It stands for the Remote procedure call. And is, as the name suggests, a way to call procedures on a remote system. The REST call we made earlier would look like this:

GrpcPost1

GrpcPost2

You treat your external API as an internal API. Parameters for the endpoint are attached in the body of the call. And that gives some weird results sometimes. In the case of RPC, Verbs don't really matter. If you want to fetch a user for example, it could look like this:

GrpcPost3

GrpcGet

If you’re an avid REST supporter and never worked with RPC before, this all looks very strange. Maybe even dirty. I personally don’t like public RPC API’s, but in very specific cases they might be useful. If your API is more like an application that does actions on data, instead of managing data, it can make sense. (Just remember that this is not an excuse for letting your internal architecture bleed into your API).

Knowing this, we can look at our microservices in the same light. Here we have small applications that might benefit more from the RPC style of calling methods than the REST style of altering resources.

A nice end goal for our microservices might be to use them in our code, without knowing that they are remote. Let me better explain this with an example.

GrpcPhp.php

It would be great if we could use code like this to communicate to a remote service. The Mailservice would be an abstraction that takes the method SendToUsers dynamically from the microservice.

In that way, when you update the API of the microservice, you would not need to update the Mailservice code. The client would automatically have access to the new methods.

Of course, that would take a lot of work to create. You would have to write some sort of transformer, create something that can login to the service, and eventually POST the data…

There is another company with the same issues as us. Ok maybe not exactly the same issues as us, cause they are maybe a bit bigger. Google created a system called Stubby that connects most of their services together. When Stubby got a rewrite, Google decided to create a new system. Not closely matching their infrastructure and even made it open-source. This new system is called GRPC.

GRPC is an RPC framework that does a lot of heavy lifting for you. First of all, it handles all the load balancing, tracing, health checking and authentication functions you would otherwise have to write yourself. It can even go full async. But that is not even the coolest part. It also writes all the code for the connection.

If you want to execute methods on a remote system as if they were present in your current system, you will have to transform the data. You have no idea what the server is expecting. The server on the other side would want to have that data serialized as well. This is also a great place to add some validation to that data.

To tackle serialization and validation Google created something called protocol buffers. These protocol buffers rely on proto files that tell them what data is coming in and out. This system is somewhat comparable to systems like Swagger and Blueprint. Unlike these, proto files are less human-readable and look a bit more like code. And pack a lot more functionality than just documentation.

Here is an example of one of those proto files:

GrpcProto.proto

As you can see they have a C/Java style and more importantly, are strictly typed. The numbers that are assigned to these variables are ids for the system itself. Please note that these files are allowed to have a bit of logic in them making them very flexible. You can look at them as value objects.

Once you have created the Proto file, the real magic happens. Now you are able to generate the connection between the systems. I say generate because it is exactly like that. GRPC can now automatically generate an SDK that you can import into your client and server. This SDK uses the mapping to act as regular methods call in your current codebase.

You can find some examples of generated code on the GRPC github

Why would I want proto buffers over something like JSON? 

We now know on a high level how GRPC works, but we still haven’t talked about how the data is actually transmitted. The downside here is that unless you dive really deep, this will all be a bit black box-ish.

Protobuffers aren’t really designed to be human-readable, they are compressed binaries. I know this might be a huge turn-off, but it does have its advantages. These come mainly in the form of its small footprint and speed.

Yogesh Shinde posted an article on Dzone on the comparison between JSON and proto buffers that suggested that the latter are almost double as fast.

Bruno Krebs’s article Beating JSON performance with Protobuf even sported cases that were up to 6 times the speed.

Everything comes at a price, and GRPC is no exception. The biggest downside is obviously the black box connections. They are hard to debug and you’re not ever really sure about what’s transmitted.

The generated code is also a bit of a double-edged sword. Lots of people have had some bad experiences with generated code (for good reasons). But to be honest, I feel that in this case, it’s not that bad. The generated code is mostly value like objects that sometimes are little more than getters and setters and it does allow you to generate SDK’s in loads of different languages with a single click, so that is a decision you have to make for yourself.

I also found the set up a bit hard. In the case of PHP, they suggest you install using PECL what is not really ideal (There is a composer option as well). You also need to run a Node server so that might not jive all that well with your current setup.

This might all seem a bit daunting to set up if you only have 1 or 2 microservices in your domain. But if your product is a collection of different microservices, you might save some time and performance with this technology. Especially if there are a few different programming languages mixed in.

But be sure to create a pilot project before you take the plunge.

Microservices can solve a lot of architectural problems, and sometimes create a few fun new ones. A big problem however is connecting these services to each other.Can GRPC lend a hand here?

Connect microservices with the help of GRPC

So an API, that's just output of some JSON code right? No problem, my framework does that automatically.

Or if you just want an overview on some best practices, conventions and nifty ways people have done stuff before, this post has you covered.

We won't go into much detail about source code here. This article is language agnostic, whether you use PHP, Ruby, Velato or some obscure Javascript framework you can happily follow along. Please note that not everything here is law, some parts (maybe everything) are open for discussion. Lastly: some of this may be pretty obvious, you are probably right. But I rather cover all the bases.

Frederick Vanbrabant's

delirious rantings

The economics of clean code

What is a binary tree and why would I ever want to reverse it

A love letter to legacy projects

The integration operation segregation principle

The simple class

The y2k38 bug: the biggest news craze of the year 2038

Connect microservices with the help of GRPC

A bird's eye view on API development