Posts

Showing posts with the label backend

Frontend / Backend Distributed Monolith

Image
The current trend in front-end development is to be full stack. Being full-stack, has advantages from an efficiency point of view. However, having people proficient in both the front and backend can be challenging. The trend is that many javascript frameworks, initially only client-side, are moving to the backend and becoming full-stack frameworks. Backend change is happening gradually, probably starting with server-side rendering ( SSR ). Now, it is possible to have react code in the backend, which is referred to as react server components ( RSC ). Such an approach is not new. PHP , Rails , and Django have been doing that for decades now. Within similar timing, we saw the rise of HTMX where the backend levering HATEOAS returns HTML rather than just returning JSON. Interesting times. React is not the only framework (because it's not a lib) doing such a thing; we also have  Next.JS (on top of React), Svelte , Nuxt  and here is a good article on server components if you wan...

Strangler Pattern Done Wrong

Image
Some years ago, every backend engineer wanted to be doing microservices . There was absolute hype. A vast majority of the market joined the microservice bandwagon without previous expertise in SOA. Some companies were successful. Still, several companies ended up in the worst place they were before. Therefore we see the Death of Microservices . IMHO there are many reasons why that happens to name a few: Lack of proper architecture skills in SOA , Lack of Isolation, Lack of Analysis, and jump to solutions too fast. Once you start distributing code across several code bases with multiple contracts, it is better to be correct because the rollback is a multi-year migration project and not easy to sell. How does that kind of thing happen exactly? In Microservices, the way to go is to use the Strangler Pattern, however by applying the pattern in the wrong way, thats where we arrive at the worst outcome: A distributed monolith. 

gRPC with Java

Image
gRPC is a high-performance universal RPC framework. gRPC has support for interoperability between several languages such as Java, C++, C#, Go, Dart, Kotlin, NodeJS, Objective-C, PHP, Python, Ruby, Rust, and many more. gRPC has a schema for service definition and it can generate code based on that schema. gRPC also supports bi-directional streaming and authentication with HTTP/2 protocol. gRPC is battle-tested by Square, CoreOS, Cisco, CockroachLabs, Netflix, and many other companies. gRPC is also part of the CNCF project. Today I want to share a video made with gRPC and Java. So Let's get started. 

BFF Dilemma

Image
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,...