Alberto Corrales Garcia

Introduction Micro-services architecture is becoming trendy since it is a suitable option many projects, specially those that are complex and we want to be able spilt our business logic into different services that can be built and deliver independently. In spite of the fact that micro-services architectures are more complex, they increase the resilience of your system and increase the time-to-market delivery, which can be crucial for many companies. But it is not all about services and backend. With the introduction of single page applications (SPAs), we can build fully-functional user interfaces that can work independently in the browser. And here we should ask ourselves the same questions as for backend applications: Is my SPA becoming a huge monolith? Would I like to deliver functional modules independently? If you using micro-services, is there a relation between my services and your UI? Do we want to have functional teams that can deliver new features (frontend+backend) independe

Introduction Since I started my career in Computer Sciences, I have had the chance to work with a huge variety of frontend and backend technologies. During that period, on the client side, I witnessed how the web has evolved, starting static html, then adding javascript, AJAX, later animations with flash, silverlight or applets, html5 and recently new frontend frameworks like Angular, Vue and React.....or the incoming and promising Blazor, of which I will talk in a future post. So Javascript at the beginning was created to add some scripting capabilities to our static websites, which most of the times led to a lot of spaghetti code difficult to maintain. Ajax was also an important turning point, which allowed us to render our page dynamically, instead of having that ugly user experience produced by server-side rendering frameworks, such as MVC, JSP or PHP. And this fact moved the logic for web pages from server to client, producing a great client experience. However webs become c