Showing posts from December, 2020

2020 Retrospective

 2020 the year that we were not expecting. The world did not end in 2012 as the Mayan calendar ended, but 8 years later, it felt almost like it. Jan, Feb, March was normal: Traveling, Going to Office to Work, Going to Restaurants, Pubs and Bars. Life was good—them after march never-ending lockdown and self-quarantine for +9 months and counting. Only going out for groceries and to take the garbage out(which surprisingly was one was the good real moments of the day).  I thank God for being alive and have work and food, and air condition appliances (3 to be precise). 2020 was bad, we lost so many people, and it still looks like 2021 won't be so easy; my bets are high for 2022, but some scientists say that normal only would be back in 2025 . The year was nothing but bad, awful, and I never want to go back to it for lots of people. For me, personally, it was not that bad. I mean, dont get me wrong, I had friends who got COVID, and thanks to God, they are good. I know people had a bad ti

Hibernate Reactive with Spring Boot 2

Reactive programming is not a new thing. Thanks to reactivex and rx-java it's a reality for almost 10 years. There are other implementations like Project Reactor  and even Vert.x . However, for Databases, we are still not there. Some databases have better support than others like Cassandra and Redis have decent support in drivers but JDBC and JPA are not quite there yet. Hibernate just went reactive. There is a hibernate-reactive project now(still beta 1.0) but looking promising. So today I want to share some simple POC I made to make Hibernate Reactive work with Spring Boot 2.x using webflux: using Netty of course. So I made a video going throught the code and explaining how it works. I personally worked with all sorts of persistence on the last +17 years on technology but not an ORM fan nowadays. However I always appreciate performance and better APIs, so I think this is promising even if is for legacy application modernization.

Monorepos with Buck

So this is the second post about monorepos. The first post was about Google Bazel, this one is about Facebook Buck . IMHO Monorepos makes all the sense for Mobile(Ios and Android) since it's all about the same application. Of course, if you have libs that can work across multiple platforms(built-in C) or similar which make sense have generic repos outside of the app monorepo. At least one app should have a monorepo. I also believe a similar strategy can be applied for SOA and Services where we could have one monorepo per business domain. In that case, we would reduce the number of microservices drastically but still work with modules. For this post, I want to share another post. We will build a monorepo with Buck and Java. Facebook Buck is very similar to google Bazel on usage and principle. So without further due Let's get started. 

Monorepos with Bazel

So this is a hot and problematic subject: Monorepos. IMHO there are good use cases for mono repo when your project is really one thing such as angular. However, there are good use cases for microservices. IMHO we should avoid extremes and just have one big monorepo for the whole company and at the same time avoid having microservices for everything. There is a need to strike some balance between maintenance, isolation, and organization. This is the first post about the monorepos, today I will cover the solution from Google called Bazel . In the next post, I will cover the solution from Facebook called Buck. All posts will have practical videos building mono repo with Java.  IMHO the IDE integration is not ideal for both Bazel and buck. There is some support for VSCode and IDEA but is far from being ok. So Let's take a look at the video.