Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Used in microservices architecture (a method of designing software applications that is rapidly growing in popularity), the publish-subscribe messaging pattern is a form of asynchronous communication where messages are published to a topic and received – in real-time – by consumers who subscribe to the topic.
Now, what does that really mean? What are the advantages of publish-subscribe? How can you explain it to someone non-technical?
A component architecture is a type of application architecture composed of independent, modular, and reusable building blocks called components. When designing an app following component-based architecture principles, developers combine, reuse, and version these objects, rather than building every inch of an app from scratch.
Let’s be honest: in times of uncertainty where speed is paramount, meeting the increasing app demand while maintaining complex technology is a herculean task for any development team. The value proposition of a component-based architecture is that it boosts application development time and reduces code fragmentation.
Have you ever heard the saying, 'architects hate spaghetti?' As software architects, it is our responsibility to envision and design systems capable of supporting the cutthroat business models of this era. In that sense, it's fundamental to develop ways to evolve our application architecture to match business concepts and processes correctly. Otherwise, the architecture won’t be structurally sound, and we’ll have to deal with a dreadful 'spaghetti architecture.'
In this blog post, I’ll share some of the best practices you should follow to build a structured and scalable application architecture while avoiding turning your systems into a spaghetti bowl. This article is based on a recent Tech Talk on the same topic, Web and Mobile Architecture with Architecture Dashboard. For a more detailed discussion, I invite you to take a look.
The Mule Connect 2020 virtual conference is over and we got to see more details on MuleSoft’s vision for GraphQL, and it shows MuleSoft is working aggressively to fill a gap in GraphQL. Let’s review what GraphQL is, its challenges, and how MuleSoft is addressing those challenges.
GraphQL is an API specification for querying data across other APIs. It originated at Facebook in 2012, released as open-source in 2015. It allows API clients to tell the API what it wants rather than the API assuming it knows what the client wants. This is particularly useful for APIs that support UIs. A challenge with UIs is that they may need data from many sources. Calling all those sources can make the UI complex. It can also add too much chatter for mobile apps, which are sensitive to bandwidth. We often solve this by aggregating lower-level business APIs with a composite view-model API or by using the backend for frontend (BFF) pattern.
Kubernetes is a powerful container orchestrator and has been establishing itself as IT architects’ container orchestrator of choice. But Kubernetes’ power comes at a price; jumping into the cockpit of a state-of-the-art jet puts a lot of power under you, but knowing how to actually fly it is not so simple. That complexity can overwhelm a lot of people approaching the system for the first time.
You may also enjoy: Get Your First Application on Kubernetes
I wrote a blog series recently where I walk you through the basics of architecting an application for Kubernetes, with a tactical focus on the actual Kubernetes objects you're going to need. The posts go into quite a bit of detail, so I’ve provided an abbreviated version here, with links to the original posts.
I have been working on some single page web apps’ UIs for several years and want to share some of my experiences.
In this article series, I will divide the content into 3 parts: ”UI Architecture Level Thoughts,” “Large Scale UI Design,” and “UI Testing and Automation.”