Diego Pacheco Tech blog

SOA it's all about Services. Services are the first-class citizen and there is no mistake in that decision. Some problems requires shared libraries and thats fine, however, I would say most of the internal shared libraries are not needed and they only cause trouble and little benefit. There is plenty of abuse of shared libraries and we need to start to recognize that we need to reduce the number of shared libraries and do fewer libraries and accept more code duplication and others from os package solutions. Shared libraries tend to spread and as a side effect, they create lots of binary coupling, complexity, and maintenance issues that kill any real Service/Microservice benefits. Services require flexibility and freedom to upgrade and release in different schedules. You might not realize but Shared Libraries are killing services and making them just a big complex distributed monolith . That's not the first time I blog about, but I still think the industry still did not get this...

So this is 3rd part of the series of BFF Dilemma. If you did not read part 1 and part 2 I highly recommend read them before continuing with this one. GraphQL is a kind of BFF I would say. BFFs then to be more flexible and allow all sorts of programming models and techniques. GraphQL is Data-Driven and has fewer options in a sense of flexibility. However, GraphQL is an interesting solution that could be used as a BFF solution or in conjunction with a standard BFF solution. Several people wonder if GraphQL is the natural replacement of REST. There are all sorts of comparisons with SOAP vs REST vs GraphQL. IMHO GraphQL is not the REST replacement I would not expose APIs only with GraphQL ONLY for all sorts of reasons. 

Testing is important. However, not all designs are testable and somethings we end up not being able to test things. A good design is always testable but not all testable code means you have good design. Sometimes we need to deal with old libs, old systems, 3rd party, or some active lib that is used a lot in your company that you cannot refactor. Not all tests have value however we need to be to test things which sometimes can be very very challenging.  Powermock helps us to test things that were impossible before.  Today I made a short video to show Powermock in action. So let's get started. 

Previously I was blogging about the BFF dilemma . I want to continue to explore the subject because I find it very interesting and I believe they're still a lot of things to explore on the subject. BFFs are super popular nowadays, for several reasons, mainly I would because of the nature of modern products.  If you have a digital product is very likely you will need to ship your problem in at Least 3 platforms (Web, Ios, Android) somethings even more platforms and specialized devices like TVs, Tablets, IoT, Arduinos and much more. Also, microservices were a big force pushing for BFFs since the services are "micro" and code need to live somewhere. It's really interesting when we think about them since we have so many options and places where our code can live. 

I always had mixed feelings with Agile. Mostly like it but I think some disciplines were always left behind like Architecture and Design. There is another discipline which often times I think we need to do more which is analysis. There is a huge relationship between Analysis and Being Data-Driven. Amazon is a Data-Driven company. There is no sense to just collect data and do nothing with it. So analysis is an old and yet important discipline. But what being data-driven means? Well, it means a bunch of things it could be from a Deep Dive analysis or simply rely on industry data or evidence of someting rather than just opinion.  So you might be wondering why we dont do more of that? That's a good question and I believe there are a couple of reasons. 

Engineering means coding. However how many times do we consider proper error handler? Most of the languages like Java, .NET, Python, C++ can be a very trick in the sense of handling errors. Business validations are like tests but they are hardcoded on the software and run part of the main flow of our applications. We need to worry not only with the "Happy Path" but also with the "What if" moments where things might not happen as we expect. There are many different opinions and options around in sense of validations, exceptions, and error handling especially in a language like Java. Error handling, Exceptions, and validations are a critical part of making systems more reliable and hardening production I would argue. Amazon Builder library talks about that in the context of avoiding Circuit Breakers and hardening the main execution path and make running code more reliable. 

The software industry is always becoming more specialized. We have backend engineers, frontend engineers, edge engineers, cloud/DevOps engineers and I'm sure we will have more specialization in the future. With specialization and growth on systems, we end up having more layers or places that we can put software. Microservices often end up making a huge proliferation of services at the backend(check out Uber case for that).  There are so many places that you can "put" your software but one particular place that is growing a lot is the BFF(Backend for Frontend)  place. Often we have different stacks for backend and frontend. Frontend often is on JavaScript or TypeScript. Backend is often in Java, .NET or Go. So the first dilemma is, is BFF a frontend thing or a backend thing? IMHO it's a frontend thing where frontend means consumer. So how different BFF is from a driver or client? Well if you look into drivers and clients they often dont have network logic like routing,...

Often successful companies have significant growth. Meaning: grow in structure. More people, more departments, more managers, more coordination and often more overlaps. Enterprise companies always end up having some form or governance issue. I remember at the beginning of the SOA world "Governance" was a very bad word and there was abuse. After 3 waves of Agile manifestation, we are with much less "Governance" look like we still have plenty of abuse. Abuse can be also called WASTE(Lean Concept). Some rules can really promote best practices and better software like: Do not share your internal data stores, Expose data via Common Interfaces like (HTTP / gRPC).  Systems tend to grow and get more complex as companies grow with them. Every single improvement(refactoring) often means more investment($$$) which also can be saying as business entropy as the time passes it only gets worst(more complex and more expensive). When we analyze refactorings individually(business imp...

So before the COVID-19 every single company out there was seeking to be digital and to transform the way they operate and improve the products. Right now I'm sure lots of companies regret their investments in the past however several companies dont have money to invest and improve things right now and thats fine. I'm and I always was a big fan of new technologies, new languages, new servers, new approaches to problems. However, new shiny things have issues  and drawbacks and sometimes take time to figure them out, look microservices for instance. However we tend to think we always can innovate, we always can do new things. But before we jump to new things, are we doing the old things right? Are we sure there is space for more innovation? So basically we can see innovation as a gold rush, there some much gold you can mine. That thought I was blogging about 6 years ago . There are lots of technology floating us with several applicability issues Blockchain for instance. 

Building products(software) is hard. There are so many things that can go wrong. At Scale, everything becomes more laborious. More people, more coordination needed, more things that can go wrong and more pieces and more dependencies. To scale, we create team structure and software, often in the form of SOA Services. Any architecture or Design should survive a set of hard questions; otherwise, the idea or solution might not be good enough. Having people thinking into different dimensions, with varying points of view and various schools of touch, would create disagreement with could be an excellent and healthy thing. However, not always thats is the case.

Github is an amazing platform. Today I want to show in a video 2 super killer features which is: Pull Request Template and also Branch protection with CODEOWNERS. This feature makes the PR Reviewer life much better and improves documentation, learning, save time, and just push the team to a much better direction. Sometimes people might create too much bureaucracy, however, the other extreme to have no comments in chaos and not good. So we need to look for some sweet middle ground. So Let's get started. 

I really like blogging. I believe everybody should blog, it's really good to learn and improve skills and also share with others. I talkd with several people across the years that always have doubts about blogging, like OH I dont anything interesting to say or I did not perform anything unique.  I believe people have different experiences and always can add value therefore there is value in expressing those experiences. Today I made a video and I want to share with you guys a bit more about my writing process.  Video Cheers, Diego Pacheco

Terraform is a great DevOps tool. Terraform has support for Custom Module which is a killer function. Functions allow you to take much more advantage of Terraform and avoid the right custom code in bash or other languages. Today I made a video showing some functions in terraform like how we can work Custom Module. So Let's get started.

Terraform is a great DevOps tool. Terraform has support for Dynamic Provisioning which is a killer function. Functions allow you to take much more advantage of Terraform and avoid the right custom code in bash or other languages. Today I made a video showing some functions in terraform like how we can work Dynamic Provisioning. So Let's get started.

Terraform is a great DevOps tool. Terraform has support for Dynamic Resources which is a killer function. Functions allow you to take much more advantage of Terraform and avoid the right custom code in bash or other languages. Today I made a video showing some functions in terraform like how we can work Dynamic Resources. So Let's get started.

Terraform is a great DevOps tool. Terraform has support for functions  which is a killer function. Functions allow you to take much more advantage of Terraform and avoid the right custom code in bash or other languages.  Today I made a video showing some functions in terraform like how we can work with external JSON files and use functions. So Let's get started.

Line by Line coverage can be very tricky. Many companies rely on line coverage as metric signals however you can easily have waste with that kind of metric like Getters/Setters, Database Calls, etc. The other issue is that kind of tools can be easily gamed.  The mutation test is not a new idea, it appears in the 70s. The main idea behind mutation testing is to test your Tests. Therefore harden your application solution and tests. The mutation test has the concept of mutators . Mutators are bugs and they should be KILLEd if they SURVIVE it means you have bugs in your code that your tests are not catching. Mutants are much harder to fool unlike line coverage tools. Today I want to share a hands-on Refactoring video I made using Pitest .  So Let's get started.

Java is an old language. 25 years now. Java has several limitations and issues however java is the robust and pretty well-stablished solution for backend, databases, Caches, Search Engineers,  IoT, and much more. Today I want to share some patterns about object creation. I highly recommend you read Effective Java book, which was a huge inspiration for this blog post. So I want to show you guys some useful patterns like Static Factories, Builder, Singletons and Immutable Objects.  So I made a quick video with code, let's get started. 

Design Systems are pretty popular nowadays. As you company grows and has multiples apps/sites and products you new have a consistent experience across your brand. Having components is a great architectural pattern to help you to deliver the design system to code. However coding tests for a design system component can be very time consuming and super expensive.  IF you are using React, Jest is really your natural choice. Jest can let you do both Example based testing but also Snapshot testing. Snapshot testing can be amazing or complete waste really depends on what you use for. For Error messages snapshotting testing be super useful but for testing design system components is IMHO the killer use case. Jest has great tooling and make you life as an engineer, dealing with snapshots super easy and fun. So I made a video about Jest and React. Let's get started. 

Software Design is a super important discipline. However, Design is often made by accident. Software Design is really needed because there is a huge cost associated with some changes further down when you have a scale and lots of software. Lots of engineers dont understand design or understand it on a superficial level. Software design is on the core of everything we do in software and I believe we need to talk bout this super important discipline. So I made a slidecast talking about the subject. Let's get started. 

Testing is important. Unit testing makes a lot of sense for Backend where we have business logic, however, for frontend, I would argue the value is not exactly the same. There is a concept called Property-Based Testing that comes from functional programming which is super useful. It makes the engineering life much easier and not only saves time typing but also makes your tests more robust with really not much more effort. So today I made a very short javascript / nodejs video talking about JSVerify . So Let's get started. Video Code https://github.com/diegopacheco/Diego-Pacheco-Sandbox/tree/master/scripts/node.js/jsverify-fun Cheers, Diego Pacheco