Software Architecture Patterns and Your Project

There are lots of different architecture patterns for web and app software. The main question is determining what your business needs are first, then applying the best architecture for your needs.

Full Transcript Below:

Cody:

What are we actually architecting?

Cody:

Which I feel is just a loaded statement, and maybe a weird ambiguous thought. So-

Cody:

Yeah.

Cody:

Is it the back end or is it the front end?

Cody:

What for you is architecture patterns? What does that mean?

Cody:

So, Cody today we are back in the studio talking about architectural patterns, which I feel is just a loaded statement and maybe a weird ambiguous thought. So what for you is architecture patterns? What does that mean?

Cody:

So, I think the first thing to define within architecture patterns is what are we actually architecting, much like someone who let’s say was building a structure, the architecture of a mall is going to be very different than a single family residence, right? So we need to define what we’re talking about and the main difference, at least in the realm of web application programming is: is it the back end or is it the front end or some other territory thing going on around that?

Cody:

When it comes to the front end, we’ve got a couple of things. I’m just going to shout off a couple types of architectures that exist. There’s the single-page app, the SPA, there’s progressive web applications, which are a blurring of the line between an actual mobile application and a web application. So it functions a little bit like both, and then there’s the classic static site, and those are pretty much the most popular ones to work with nowadays.

Cody:

On the back end, we’ve got MVC, if you’ve ever done any work in backend programming, you’ve heard the MVC thing. It stands for model–view–controller. It’s a type of layered architecture that has business logic, separated from viewing logic, separated from the data logic and it’s just a good way to containerize and what they call encapsulate the different areas of function. That’s a monolithic approach, which kind of getting into another sub subcategory is-

Cody:

Sub, subs. Okay.

Cody:

Yeah. Sub subs, subscribe. Sub subcategory would be monolithic approach versus a distributed approach. The difference would be MVC falls into the monolithic category, which means you have everything in one giant code base basically. It’s like a tower, a pyramid almost of sorts. That’s actually how it’s described often when you come to backend programming is you want to have everything structured up to a point like a pyramid, you got a lot of logic on the bottom in the database, middle tier on that business logic in the center-

Cody:

Kinda thins as you build up.

Cody:

Yeah. Then as little logic as possible on the display layer. Whereas distributed programming, which has another buzzword associated with it, which would be microservices a lot of the time and there’s definitely a lot of other types of distributed coding.

Cody:

We’ve talked microservices a little bit on another video, but yeah.

Cody:

Yeah, absolutely. But microservice are basically, instead of encapsulating the different functions of your code base in the same code base, but just in disparate layers that are all linked together as one unit of code running, it is an entirely separate code base for each function. They are all link together through a common communication topology, which would typically be like REST, or I guess, GraphQL or SOAP, even if it’s an old school code.

Cody:

Mm-hmm (affirmative). So good. Why would you go with one of these particular kind of architectural patterns or models? Why? Why would you implement this versus that?

Cody:

Well, I think a first thing to ask yourself would be for probably how do you want to scale? Certain things are going to be better at that than others. If you have a huge amount of data to process and you need kind of a very adaptive elastic system, microservices are great for that. But what they aren’t great for is actually managing your code base, because you have a bunch of different things going on.

Cody:

Oh, interesting.

Cody:

So there’s really pros and cons on a lot of different stuff. Same thing goes with MVC. It’s easier to manage because you have one team and one knowledge base working on one architecture, but your only option for scaling that is horizontally scaling it with servers, which is actually very complex. So you kind of have to pick and choose what your goals are as they relate to your business goals because certain businesses will be totally fine just pulling an out of the box, MVC type monolithic classic code and applying that to what they need to do.

Cody:

For most medium sized businesses, that’ll probably be enough unless you have a really high processing requirement. Now that said, it scales. Same thing on the front end, if you have, let’s say an experience that is better suited as an app and I guess we’re not really quite getting into the idea of mobile apps, but that’s actually more of a monolithic thing, but if we’re talking about like a progressive web application, a PWA, if you want it to be sort of a mobile app experience or versus a web application experience, and you really want to fuse those principles, that would be your answer. Versus the single-page application, which is more like, okay, this is actually an application with a user experience. They have to do stuff and you don’t really want muddle with that mobile application complication, so to speak yeah. Bit of a rhyme there. That would be a good answer to that.

Cody:

Then of course the most simple approach on the front end would be the static site. You’re just an informational content page or something similar in that realm. It’s just nothing too complex. So I guess doubling back and boiling that all down because there’s a lot of phrases and verbiage to go along with that is you really have to choose what you need before you know what architecture you need. You need to kind of roadmap as they may say and plan along that to figure out what the best choice of architecture is. Are you going to build a house or are you going to build a mall? You need to know that first.

Cody:

Got you. Or even thinking of your project as a journey because it is, you’re going to start and you’re going to end somewhere knowing where you have to start, where you’re trying to get to, that’s going to determine, are you taking a plane, a train, an automobile, a bike, very different methods and ways of getting there, determining the distance and time and all that.

Cody:

Absolutely, cool.

Cody:

Other final thoughts or conclusions that we either take into account when we’re architecting out these projects and trying to find the patterns or good questions that customers could ask when they are trying to figure out what the best architectural pattern for their project is?

Cody:

Well much like a lot of things within technology or when you’re building anything is you got to plan. A lot of times the plan for your project is your architecture, but the plan for your architecture is your roadmap. That’s the first thing you need to jump to is to understand your own business principles and how they relate to technology before you start choosing just, oh, I want to be a distributed application. I want to be a monolithic MVC. I want to have an SPA. You really won’t know until you’ve actually gone through and assessed your own business goals and that I think is the biggest takeaway.

Cody:

Yeah. And that’s not to say that you can’t get from point A to point B in the airplane, but you may not need to. A car might be just fine.

Cody:

No one takes an airplane just downtown. Well, I guess very rich people might.

Cody:

Very rich people might.

Cody:

But generally not. Generally not for most people.

Cody:

That’s good. Well, I appreciate Cody, you coming in here in the studio, kind of talking through architectural patterns. I hope that we… again, we threw a bunch of buzzwords around, but I hope the takeaway for the viewer is that they have a better understanding of why it is important to go with a particular pattern over another and also have some good questions to ask when they start architecting out their own project.

Cody:

Absolutely.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday. I hope you enjoyed that conversation with Cris and Cody as they kind of gave a broad overview with a lot of lingo about software architecture and the different ways that a project can be structured and how they might relate to your business goals. If you have any questions at all about what we talked about today, go ahead and leave them in the comments section down below, and don’t forget to check out the description box down below.

Alexandra:

We have a couple of really helpful links down there for you guys, including a link to our free custom software guide that will give you a lot of tips and tricks about how to plan out your own app or website idea. You can also check us out at bixly.com and right at the top of the website is a big button that says, get started on my roadmap. That will actually get you a free 60-minute conversation with Cris about your app idea and he’ll give you his advice, his feedback, and his expertise in that time. So we hope you’ll check that out. And until next time, this has been an episode of Bixly Tech Tuesday.