Vert.x vs Spring for gRPC

BrownZeus · September 2, 2020

Hello beautiful people,

I'm in an exciting stage at work where we're beginning to architect and design a new service. We a sa team are deciding between vert.x and Spring for a gRPC based service and I was weigthing p[ros and cons between the two.

I've already done my research and I know which way I'm going to favor hopwever I was wondering if anyone had any opinions for the same (and maybe an article that says the same cause I do have to present my favored framework in a professional report)

TIA!

Franck · September 2, 2020

I haven't worked alot with Vert.x but quite a few time in the last couple years with Spring and In general Vert.x will perform faster than Spring in most case by small to a large amount but the amount of work is greater on Vert.x and code is not as read friendly compared to Spring. If i had to choose between the two i would go Spring for the reason of easier maintainability and support you have with it. Personally i dealt with client with new or pre-existing project with either languages and Spring projects are so far much cleaner to work with pretty much no matter the case. But as this is your project you need to check with the people working on it, their experience, learning time and how much you are loosing using either depending on their knowledge level.

That being said after getting a taste of the power of Azure services a couple year back it outweigh either of those choices with the rest api. Even protobuf is a joke to use.

BrownZeus · September 2, 2020

2 hours ago, Franck said:

I haven't worked alot with Vert.x but quite a few time in the last couple years with Spring and In general Vert.x will perform faster than Spring in most case by small to a large amount but the amount of work is greater on Vert.x and code is not as read friendly compared to Spring. If i had to choose between the two i would go Spring for the reason of easier maintainability and support you have with it. Personally i dealt with client with new or pre-existing project with either languages and Spring projects are so far much cleaner to work with pretty much no matter the case. But as this is your project you need to check with the people working on it, their experience, learning time and how much you are loosing using either depending on their knowledge level.

That being said after getting a taste of the power of Azure services a couple year back it outweigh either of those choices with the rest api. Even protobuf is a joke to use.

Yup experience is on the list of things I weighed. None of us on my team have any vert.x expereince but we've found plenty of proofs of concept that Vert.x and grpc are practically a match made in heaven for high throughput applications compared to spring. However the fact all of us have Spring experience and the Vert.x community is still kind of young, from a maintainability standpoint I'm leaning Spring. Spring devs come a dime a dozen, in the long run my arguement that it would be lower cost to go with a framework that we know is maintainable and easy to find devs for and just have more instances of our microservice running than to find vert.x devs with the experience.

I'm a baby developer, literally a year on the job and I've been able to maintain years old code bases for Spring, even singlehandedly performed the uplift from Spring 2.x to spring 3.x with little to no Spring experience. When my director was putting together our team his criteria was litterlly anyone who just even heard about the framework. Outs of the 100 or so under my director, only one small scrum team's worth actually heard of it. Director man isn't married to Vert.x but he feels its the best way to go. So Me, one other entry engineer, and one of our leads are putting together a clear arguement against vert.x the other memebers are arguing for Vert.x. Feels likes we're back in college with this debate haha

Franck · September 3, 2020

14 hours ago, BrownZeus said:

Yup experience is on the list of things I weighed. None of us on my team have any vert.x expereince but we've found plenty of proofs of concept that Vert.x and grpc are practically a match made in heaven for high throughput applications compared to spring. However the fact all of us have Spring experience and the Vert.x community is still kind of young, from a maintainability standpoint I'm leaning Spring. Spring devs come a dime a dozen, in the long run my arguement that it would be lower cost to go with a framework that we know is maintainable and easy to find devs for and just have more instances of our microservice running than to find vert.x devs with the experience.

I'm a baby developer, literally a year on the job and I've been able to maintain years old code bases for Spring, even singlehandedly performed the uplift from Spring 2.x to spring 3.x with little to no Spring experience. When my director was putting together our team his criteria was litterlly anyone who just even heard about the framework. Outs of the 100 or so under my director, only one small scrum team's worth actually heard of it. Director man isn't married to Vert.x but he feels its the best way to go. So Me, one other entry engineer, and one of our leads are putting together a clear arguement against vert.x the other memebers are arguing for Vert.x. Feels likes we're back in college with this debate haha

For high throughput Vert.x IS king compared to Spring without a doubt.

From 3 decades programming and 2 of them professionally the difference won't matter than much. With Spring you can easily make a load balancing with a secondary server and you will nearly double Vert.x performance while costing you what 4K at most ?

Compare that to train the 100 people 15 hours training so 1500 hr at 40$/hr = 60,000$ just in salary doing nothing that brings money to the company + the training cost which is usually 300$ / head + 30,000$. so 90,000$ vs 3,000$. Also you can't train 100 people in 1 go you have to split by group so you have maybe 1-2 month where you team are not at full capacity.