What’s up, everybody? Welcome to another episode of the podcast. This week, we are gonna be talking about a follow-up here to a blog post by Geoff. He was talking about swift data and separation of concerns came into play. And we thought, you know what?
Peter:
This will make a good episode. So so let’s start by saying, Geoff, how are you doing, buddy? How how’s your week been?
Geoff:
I’m doing great. Little behind the scenes. We are actually recording this episode, like, three days after the last episode. So, there actually hasn’t been a whole lot of time for anything to happen.
Peter:
Yeah. Spoiler alert. Right. Yeah. Yeah.
Peter:
Nothing got better in three days. Right? That’s that’s basically Alright. So let’s get into this. So you you did a blog post that you put out there.
Peter:
And, of course, folks, we’ll put a a link in the show notes. And, you know, for those who don’t know what separations or concerns are, I think this is gonna be interesting and probably spark some conversations, right, based on what I saw in the Discord. And, again, we’ll put a link in the Dev links. So go for it, Geoff.
Geoff:
So, yeah, this all came about. The blog post was kind of heavily demanded by people in, the Discord because I had spent a rather decent amount of time railing against the query property wrapper in Swift data. And people were really like, hey. You know, if you hate queries so much, like, why do you hate queries so much? Explain why you hate it, why you think it’s bad, yada yada yada.
Geoff:
And so out of that came a blog post that was essentially, you know, a little over the top opinionated, but, you know, that’s that’s how you
Peter:
That’s what we do.
Geoff:
Blog these days. Right?
Peter:
Yeah. That’s what makes us people tune in for for us to be opinionated.
Geoff:
They don’t care about the truth. Exactly. Yeah. Basically saying, hey, don’t use the query property wrapper in Swift data because it makes your code more fragile. It makes your code less flexible, and it’s easier to work with Swift data if you’re not using it.
Geoff:
And the reason for that is the idea of this separation of concerns. And so I think what we’re gonna do is we’re gonna we’re gonna pull out the bits of that that are generic, the bits of that blog post that apply no matter what language you use, no matter what frameworks you’re using, and really kinda talk about, like, why does this matter, how can you implement it, and what are the benefits you get from implementing something like this?
Peter:
Yeah. Now, first of all, I do wanna say, right, I use that query in my Swift data. Not that I’ve extensively used swift data, and I’ve not had a problem. So, you know, I guess I’ll I’ll be on the other side of that.
Geoff:
Shipped an app with it?
Peter:
That was a good question, actually, because I was thinking about that today. And
Geoff:
Have you actually finished shipping?
Peter:
Have did I did I I’ve this came up actually at the weekend because someone asked me about JobFinder tracker. And I JobFinder tracker does actually use some swift data. So, yes, I guess the answer is yes. I have. And Good.
Peter:
And I have successfully sold to someone, some peoples. So I guess it’s okay.
Geoff:
Yeah. Yeah. No. I mean, if it’s not like if you are using query right now and you you you’re not having any problems with it, you gotta go out and tear it all pieces right now. But, I I definitely think it encourages some bad behaviors, and I think it should more or less be avoided even though Apple really kinda tries to push it because it makes their code look pretty on WWDC slides.
Peter:
It’s all about looking pretty.
Geoff:
Yeah. I think what I’m gonna do here on this episode is kind of provide, like, a a sample example, one that I can discuss in audio form, and kind of work through and explain what you might have done before, why this can cause problems, and how you can avoid these problems by using the principle of separation of concerns, and some of the benefits that you’re gonna get through doing that. For this example, let’s imagine you’ve got your your standard, default, what what’s a project that you’re gonna build, and we’re gonna talk about a task list app. And in this task list app, you are syncing this with some kind of remote API. Could be a server, could be iCloud, could be whatever.
Geoff:
We don’t care. Now, what you would do, like, kinda the the the simplest, most straightforward approach that you’re gonna do, is you’re gonna write some kind of type that represents, say, your task. And with that type, you’re gonna say, okay, in Swift, you might make it codable in, Android sorry. Kotlin. What’s the language that that thing’s called?
Geoff:
In Kotlin, you might have the, like, Kotlin serialization and mark everything with the serializable, encode and decode them from from your API. And then you might use that same type directly in your view. You’re gonna say, okay. Well, I’ve got a list of tasks. I’m just gonna take these tasks that I got from the API, and I’m just gonna put them in a list.
Geoff:
And that works great once. You kinda just go fetch that data from the API. Here it is. Display it in the list. Not a problem.
Geoff:
Well, imagine that you, as a developer, don’t control the API, or you do control the API, but you can’t you know, you’re you’re a mobile app developer. You can’t deploy them at the exact same time the way you can with a front end web app or anything like that. And now the API has to change for one reason or another. And if you think this doesn’t happen in the real world,
Peter:
you would
Geoff:
be wrong because this happens all the time.
Peter:
I was gonna say, this this actually for me may be the one thing right here because, this happens all the time. And anyone that has ever said, oh, this will never happen. Life will be fine. Or if some API builder promises you it won’t change, run. Run for the hills.
Peter:
Yeah.
Geoff:
Yeah. And so, yeah, this has been something that I’ve seen at a number of different jobs where it’s like, okay. The documentation said this value will never be null. And all of a sudden, it’s null. And then your app is throwing errors, crashing, silently failing, whatever, depending on what exactly your language is and exactly, how type strict it is, that kind of thing.
Geoff:
But yeah. Imagine that the API has to change, and now a field is nullable when it was not previously nullable. So now okay. Fine. You’ve got to go through there, and it’s like, okay.
Geoff:
I marked this field nullable. It’s now decoding properly. But now, everywhere in my view, I have to handle this case that it might be null. And now I’ve gotta change every single view where I’ve displayed this task to make sure that this value is not null, or if it is null, then I’m doing something with it. You know, I’m I’m converting it to an empty string.
Geoff:
I’m I’m doing something like that. And this is the problem, is that you’ve now had things that are entirely part of the API contract now kind of affect how you build your views. The solution to this is the term that I’ve been using throughout this episode, and that’s separation of concerns. Now separation of concerns, it’s an old old old principle. It, was first coined in 1974 by a very prolific computer scientist named Edgar Jijkstra.
Geoff:
I’m sure I mangled that name. It’s close enough.
Peter:
And it’s in the show notes because there’s there’s no way I’m gonna try it right now.
Geoff:
We will Yeah. We will link to the Wikipedia page for separation of concerns. It’s got his name on it.
Peter:
Don’t blame us. Yeah.
Geoff:
Yeah. If you if you’ve seen the name, you know who we’re talking about. Anyway, the idea that he kinda put forward is that each piece of code, and one piece of code is a little bit nebulous, but we’ll just come come back to that, should really only have one thing that it’s concerned about. It’s the separation of concerns. And if you have multiple concerns, you should separate them into multiple pieces of code.
Geoff:
And that can happen at a couple different levels. You can have that, you know, like, oh, I’ve got multiple types. I got, you know, different classes. I’ve got different constructs. I’ve got different whatever.
Geoff:
Or it can, like, level up, and you can talk about it at, like, a process level. That’s the whole UNIX philosophy that you’ve got individual small programs, and they all do something well. And so you can, like, pipe them all together on the command line. But that’s the general idea is that something has one thing that it does, and it does that thing well, and it’s not concerned with other things. Some other people may recognize this as the s in Solid.
Geoff:
That’s single responsibility, but, Jekstra got there first. So yeah. So what we’re seeing is our code is not following this principle. It it is concerned with two different things. It is concerned with how it’s represented on the server.
Geoff:
It’s your API contract. And it’s concerned with how this data is going to be displayed in your front end, in your view. And that’s really already causing us problems, because if one of those things changes, now, necessarily, the other thing also has to change. And so the solution is, let’s separate those into two different types. And the terms that I’m gonna use for these types right now, they’re not necessarily universal terms, but, I’m gonna use the terms data models.
Geoff:
You may also hear these called DTOs or data transfer objects. It’s not necessarily the case that they have to be objects in every single language. That’s why I’m using the term data models. And domain models. And there are a specific subset of domain models that you’ve probably heard of later.
Geoff:
We’ll we’ll we’ll get into that. But, those are the terms that I’m gonna use right here. Data model, this is what you use to pass data around. And domain models, this is the version of it that you’re using in your app because it is specific to your app’s business logic. Any questions so far?
Peter:
No. No. I I mean, I agree with everything so far that you’ve said. Yeah. Hey, folks.
Peter:
If you like what you’re hearing in this podcast and you wanna help this podcast to continue going forward and having great guests and great conversations, I invite you to become a Patreon supporter. You can go to patreon.com/compileswift, where you will get ad free versions of the podcast along with other content.
Geoff:
Okay. So let’s start with the data model, the the DTO. In my mind, this should ideally encode your API contract and no more, no less. Obviously, that’s not always a % gonna be the case, but that is the ideal. That really, all you’re doing is you are kinda just saying, this is what I am speaking to the API, and, really, I I don’t want to be any more complicated than that.
Geoff:
There’s this idea out there in computer science, called Postel’s Law. It’s also called the robustness principle, which kind of goes by the wording, be conservative in what you send, be liberal in what you accept. That is, you know, try to take in whatever you can without throwing an error, without without really having any problems, and try to limit what it is that you’re actually sending out. Take in everything that you can without errors, without any other problems, and, you know, kind of limit what it is that you’re sending. You know, you be consistent even if what you’re receiving is not consistent.
Geoff:
And so to that end, I think that you want to have your data models kind of be as accepting as possible. In a lot of cases, I think unless you are absolutely 100% certain that it absolutely never ever ever can have a nullable there, you should just default to all of your fields except null. That that’s that’s fine. Just go ahead and accept whatever you can because that way, if something suddenly starts becoming null, you’re not, you know, suddenly failing decoding because you didn’t expect that.
Peter:
Okay. I do wanna jump in there. Just to clarify, though, just just wanna make sure I’m understanding what you’re saying because, I’m always drumming into folks, you know, allow for the outcome to be something other than you expect. Right? Of which a null is a perfect example of that.
Peter:
Right? What just just because someone tells you, look, this piece of data will always be there for you. You. That is the first sign to say I’m gonna code for when it’s not there. Because they more than they the more they promise it’ll be there, the more I tell myself it won’t be one day.
Peter:
Right? Yep. So, you know, make sure you cover your bot on that. Right?
Geoff:
The other thing I think that you should do in accepting, things as they are from the API contract is don’t have any sort of type that you’re decoding to that is not something that your transfer protocol can represent. So let’s use the example of JSON. Everybody knows JSON. Everybody knows what’s in JSON. You’ve got objects.
Geoff:
You’ve got arrays. You got numbers. You got strings. You got whatever. What you don’t have in JSON is dates.
Geoff:
That’s not a thing. You can represent that as, say, a number that’s your unit set box. You can, have a string that’s like an ISO eighty six zero one string, that kind of thing. Don’t try to encode in your API contract the idea of a date. Just take in a string if that’s what your system is gonna send you.
Geoff:
If it’s gonna send you a string, keep it as a string. I know that some languages again, we’re gonna go back to Swift. That’s kind of our bread and butter, have things like, oh, well, you know, you can put a date in your a p in your codable struct, and you can have some setup there that that go ahead and decodes it for you on on the fly. Don’t use those. You should take in a string.
Geoff:
If it’s a string, we’ll figure out whether or not it can be converted to a date later. Accept what your API can give you. Don’t accept anything else.
Peter:
I do I very much agree with that because, you know, okay. I get it. Folks have varying opinions on this for sure. Right? But I always, you know again, I think to myself, look.
Peter:
If something’s coming in, the the most the if something’s coming in, the easiest thing to always handle is gonna be a string. Right? Get your string, convert it or or check that you can convert it to what you need, but just by sending string back and forth simplifies the whole thing. Right? The amount of times that I’ve spoke, you know, had conversations with API engineers and it’s like, look, I want a date and it’s like, well, we’re gonna send you a string.
Peter:
But that means I gotta convert it. Well, that’s a good thing. It means I can test that and and ensure that this string will convert to some kind of sensible date. Right? Yep.
Geoff:
We have a person in the chat right there, saying one other one that I I forgot. In a lot of cases, your API contract will specify a kind of pseudo enumeration type, where it’s just like, oh, it can be one of these three values. And in a lot of languages, you have this idea of, like, on the fly decoding, you’re gonna say, this is the enum value that it can be, but what that actually is in the JSON is just a string. Again, take that as a string now. You’re gonna run into a point where, oh, the you had handled the three enum types that you had, and now the API is sending a fourth enum type.
Geoff:
And now your decoding is broken. Don’t do it. Take it in as a string. You can always convert it later. We’re we’re gonna we’re gonna get to that point later in the in the podcast.
Geoff:
Your data contract, your data type there, it should handle a string.
Peter:
Done. Agreed. Yep. And and let me say because I know folks out there who know me, they’re gonna say, but, Peter, you’re always saying how much you hate, you know, string using strings for things like string matching and and so on and so on. Yes.
Peter:
That is true. But this is this is a different thing we’re talking about here. Right? This this data coming in needs to be as simple as it can be, and I don’t think you get simpler than a string.
Geoff:
Yeah. And we we we have other options coming up. So let’s talk about those now. The other side of this is your domain models. In your domain models, you can do all of these things.
Geoff:
This is what you want here. This is a representation suitable for your app. This is this is what you’re gonna use in your app. This is how you’re gonna pass data around throughout your app. So you can have the things that you want.
Geoff:
You can have non optional values. So you know that, like, if I’ve if I’m dealing with this at all, it’s not optional. It it’s going to be there. We’ve we’ve guaranteed in the type system that it is there. You can have these more complicated representations, such as dates.
Geoff:
You can say, like, okay. This is a real date. This has a time zone associated with it. We can do date math on it. We can do whatever we want.
Geoff:
It it’s it’s handled there. You can have your enums so that you’re not doing the the stringly typed, stuff that Peter was just railing about, where you’re you’re comparing strings or you’re comparing any of the other things. You can have all of these nice things inside of your app, and they’re not connecting to the the API. They’re not part of your API contract. Now the version of domain models that I think a lot of people are going to be familiar with and may not have recognized this quite yet, but, will click as soon as I say it.
Geoff:
One of the most common types of domain models are view models. So this is a case where you’ve got a version of data as it needs to be represented in the app, and it is explicitly set up in a way that it is meant to be displayed at at this point. That that is your model as it is done for a view view
Peter:
model.
Geoff:
Fairly straightforward name there.
Peter:
Yep.
Geoff:
And I think in a lot of simple apps, this may be all you need. You need your data model, and you need your view model. And those two things are your connections. I think the reason that I use the term domain model here is that I think it’s a little bit limiting for more complicated apps to say that those are your only two models, and that in a lot of cases, it almost makes sense to have an extra layer there where you have your data model, you have your internal business logic domain model, and you have your view model, and you kind of map between all well, you kind of go through the center of domain model. And so you can go from data model to domain model.
Geoff:
You can go from domain model to view model. You can go from view model to domain model. You can go from data to domain, but you don’t you don’t ever go from view to data. You you always go through that central domain model.
Peter:
I do wanna jump in and and point that out because, it kills me that I still come across folks who will take that incoming data, push it straight into a view, do whatever, and send it straight back out through the data again. And it drives me crazy. Not the good way to go, folks. Right? Just like we were saying those APIs change.
Peter:
Well, if that data changes, you got a whole bunch of rework, and I just think it’s a it’s a bad practice to not have that middleware layer with the view models. That’s that’s just my 2¢.
Geoff:
So let’s talk about the implementation. How would you actually go about doing that? How how do you actually go about, you know, maintaining these two separate models? So I think the core of what you have in your app is you have one type that is responsible for actually doing the communication with your API. And one thing to look up that may not be the solution for everybody, but is definitely a good starting point, is the idea of the repository pattern.
Geoff:
And that is basically a way of saying, like, I have one thing that handles communicating with my data, and what I send to and receive from that is just my domain model. The repository, internal to itself, handles the data model, and it references the data model because it needs to con talk no. Sorry. Because it needs to talk to the API. But outside of the repository, you should never see that data model.
Geoff:
You’re only dealing with the domain model at that point. And the way that you handle that is through the use of data mappers. What those are are specific types for saying and data mappers are for converting between your data type and your domain type and vice versa. And, really, what they’re there for is for handling all of the complexity there. And stuff like, okay.
Geoff:
We have this date as a string. We need it as an actual date. Oh, we can’t parse it. Now we’re able to say, here is the specific error. Here is the specific object.
Geoff:
Here is the specific cause of this failing. And so all of the complexity of error reporting is there in your data mapper. And your data mapper can really, like, do all of whatever complicated finagling it needs to do. Your data mapper can handle, oh, we’ve got, like, multiple different versions of the API. If we see version one of this thing, well, it’s, you know, ISO eighty six zero one string.
Geoff:
If we see version two of this, it’s, oh, it’s got, you know, a time zone associated with it where it didn’t before, that kind of thing. All of that complexity goes into your data mapper type. That way, you don’t have to have it in your domain model or in your data model. You don’t have to have it in your repository. Everything’s just kind of centralized.
Geoff:
This is what converts from this thing to the other thing. Time for a break.
Peter:
Hey, everybody. It’s Peter Whittam here from the Compulsory podcast. I’m gonna tell you about Setapp. Setapp is a service that provides a subscription fee of just $10 a month, and you get access to over 200 Mac applications and it’s also available now on iOS as part of that deal. I use the service because it just has a ton of really good first rate apps that I use all the time.
Peter:
And for me, it’s invaluable as a developer to have access to tools for things like APIs, for planning projects, writing emails, writing documentation. And you get all of these things including database apps, all of that kind of stuff right there on the setup service for just $10 a month. You can use as many or as few applications as you need. If you’re interested in checking this out, go to peterwidham.com, p e t e r w I t h a m Com forward / set app, s e t a p p. And you can see the details there, and it’s got a link that you can go over and start using the service and see how it works out for you.
Peter:
I strongly recommend this to every Mac user.
Geoff:
Break time over.
Peter:
Okay. Great. Now everything you have said so far, this may be a unique episode because I completely agree with you. So write that on the calendar, folks. Alright?
Peter:
It’s not gonna happen very often. But one of the things that I think is a good example here is testing your code. And like you said, like finding bugs and also when the when the APIs change, when your business logic changes, all of these things, the separation of concerns are a great way to say, great. I’m only rewriting this small chunk of my code. I’m not rewriting some massive refactoring of my app.
Peter:
Right? But I I think that it one of the important ones is it does make it, in my opinion, very testable as and hey. That that should be a huge benefit right there. So, you know, let’s talk about some of the benefits of doing this offset again because I’m sure there are folks that are like, oh, but this is so much work. So let’s talk about the benefits of why this is important.
Geoff:
With each of these pieces kind of handling just a small section of it, it makes it much easier to test because you don’t have to build up this kinda, like, full pipeline. So for example, I just discussed these data mappers. Having something where you were previously saying, okay. You know, if if I’ve got this version of this, I need this. If I’ve got this version of it, I need this.
Geoff:
That’s gonna be really complicated if what you’re dealing with is, like, your end of view. You’re gonna have to pass a bunch of stuff to it and and make sure that you’ve got, like, just data. And I’ve seen so many things where people are just like, oh, we’re mocking out our entire networking stack because, you know, we’re we’re getting rid of, of everything because, you know, at the end view, like, we need to be able to say what the JSON was. And it’s like, this is this is too much. Like or what’s worse is people are just saying, that’s too much work.
Geoff:
We’re just not gonna do it. Whereas with this, where it’s like, okay. You’ve got one small part of this, and you can say, I am passing this very specific data into here, and I expect this very specific data back out. It makes it very easy to test. It also means that you have, like we said earlier, the ability to handle changes without having to really have that cascade between the rest of your app.
Geoff:
So that’s the small changes that we discussed, like, you know, nullable fields, or non nullable fields being suddenly becoming nullable, things like that. But, also, like, I’ve seen just gigantic migrations that went awry because of a lack of separation of concerns. You know? At a past job, we had a a case where, the entire app was built on gRPC and protocol buffers. I’m not gonna explain what those are.
Geoff:
But just generally, like, that’s the the way that we communicated with our API. And then it went to GraphQL, and and we were suddenly speaking GraphQL. Now the problem was all of our gRPC objects, were being used directly in the UI. So what does that mean when we switch to GraphQL? Well, that means not only do we have to change our networking layer, we have to change every single piece of our code
Peter:
Yep.
Geoff:
To make sure that it’s it’s now handling this new GraphQL. And if I recall correctly, like, it didn’t even, like, all move over at once. So it was just like, oh, we’ve got, like, protocol buffers over here, and we’ve got GraphQL over here. And they don’t really communicate with each other, and it was just a nightmare. And and this is a case where having that all kinda separated away in the the first place would have saved us a ton of headaches.
Peter:
Yeah.
Geoff:
If this was something where it’s like, once you hit that repository layer, you don’t have to worry about whether it’s protocol buffers or GraphQL anymore, that would have been great, especially in a, like, a larger company where you may have separate teams. You’ve got, like, a platform team. You’ve got feature teams dedicated to specific parts of the app. Why do your feature teams need to care about what’s going on with the network? Like, that shouldn’t matter.
Geoff:
They should be able to build that kind of stuff without it. And then to that to that same extent of, like, the separation of teams, like, if you are building something like this and you know that you’re able to rely on some kind of internal business tool, what that means as well is that you as the front end team, you as the mobile app team, you as the whatever team, you can go ahead and start building your features to these internal types without the back end being available yet. That was another thing that I’ve seen a lot in a lot of different companies is people going, well, we need to build this feature, but we can’t build this feature yet because the back end team, they haven’t finished the back end yet. And, you know, it’s great to use that as an excuse when you don’t wanna actually do anything. But you can actually build these things.
Geoff:
You like there’s no reason why you necessarily need to wait on the back end team for something like that until what you’re building is that data mapper, that repository side. You can build out your entire feature against these internal domain models, and then all you need the back end for is that conversion between the two. And you can go ahead and be on your merry way without having to be blocked by this other team.
Peter:
I I would like to say, and and I get it. Maybe it’s controversial. I think that if you find that you are saying, I can’t do, you know, let’s just take a date. Right? Okay.
Peter:
I can’t do this build this part of the app yet because I don’t have this the the data this date that I need to put on here and see how it’s gonna look. That should be your number one sign. You have not thought this through or you’re doing it wrong because
Geoff:
What’s the process equivalent of the code smell?
Peter:
Exactly. Right. You know, because I agree with you completely. Yes. Okay.
Peter:
There is a benefit to having everything you need at a certain point as early as possible so that you can code and test and and everything else. But if you are in some way saying you are dependent upon that to build out part x of the app, I would go so far as to say, well, then you’re probably the problem, not where the past experience at
Geoff:
a company where the back end that we were waiting for was a piece of hardware. Like, we were communicating with a
Peter:
piece of hardware that had to be manufactured and prototyped and all of that.
Geoff:
And it’s, like, a piece of hardware that had to be manufactured and prototyped and all of that. And it’s like, if we had sat there the entire time and said, well, we actually can’t build any of the app yet because we need this hardware to happen, like, we wouldn’t have had a job for six months. Yeah. And so, yeah, you you need the ability to kind of have internal things that you can deal with and then be able to just mock out just that last little bit. They’re like, I know that I need this feature.
Geoff:
I’m gonna need this data. And then, like, you can build your domain model that has the data that you need and work with that. And then it’s like, okay. At some point, probably before the back end is actually, like, up and running, then you get the spec doc, and then you can kinda start building the mappers together. The you know, you you’ll have your mapper like, you can build the mapper, and you can go like, okay.
Geoff:
This is what we know the API contract is gonna be. This is gonna deal with that. And then, like, that last little bit is just, like, the URL session connection. Like, just hook it up to, the actual network. But, yeah, like, because you can you can have different levels of that.
Geoff:
You can have, your repository just then, the the the final result to you. That’s normally what I do when I need to mock out the repository is I just say, like, okay. It just does this. But you can also mock out, like, the network layer above the repository and say, like, okay. This network layer is vending me the data models, and then that’s going through my repository, and that’s going through the mappers, and then it’s going through the, domain model.
Geoff:
But, honestly, most of the time, I just I just mock out the repository and say, yeah. Just go ahead and return these domain models. And I I kinda skipped that other little bit. So, yeah, I think that’s basically all I have to say about this for now. You know, the there’s a lot of benefits you get from this.
Geoff:
It does take some extra work upfront, but I think it allows you to be much more explicit explicit about everything that you’re trying to do, and it obviously has a lot of these these upfront benefits. So, I definitely recommend, definitely look at the links that we’ve included, do some more, in-depth reading about this. But really start to think about this the next time that you’re building out any of these kinds of things in your app. And it really makes it so that it’s it’s easier to continue to expand, to continue to test, to, you know, react to changes, unexpected changes in in your your back end. You get a lot of nice wins from this.
Geoff:
And so, I I I definitely recommend, you know, taking a look, see where you can improve your apps that way.
Peter:
Yeah. And I think it’s I wanna point out here, I personally believe it is better to spend this time thinking about these things upfront and avoid incurring that technical debt later on when you have to deal with these problems because you didn’t go through this process. And I think that when you are designing your app and by designing I don’t mean the UI and everything. I mean when you’re architecting it and then have these at the forefront of your mind. Right?
Peter:
This is what this looks like now. What if this changes next week? Because as we said earlier, next week, if you if you’ve ever worked with teams in a company and big products or things like that, next week always happens when they change it or six months from now when they pivot to some new thing or you get bought out and it becomes something else. So plan for it now. Right?
Peter:
Stop the technical debt before it happens. It’s not gonna completely solve all your problems, but it’ll compartmentalize some of your problems with smaller refactoring. That’s
Geoff:
that’s a that’s a great way of putting it. It it compartmentalizes your problems. The when you have problems and you will have problems, that’s the nature of software development, you limit the area of impact that you have. You know? If something changes, you really have, like, this firewall of the repository and saying, it’s not gonna spread beyond this because everything else, like, it’s cut off from that.
Geoff:
That is that is your break point, and and you’re not really gonna have to, rearchitect your entire app because one other thing changed.
Peter:
Yeah. Agreed. And also as as we know, you know, developers, hey, they they hate having to go back and redo things. They like to do new things and cool things. Well, if you do this, guess what?
Peter:
You’re gonna be going back less and and spending time on this. Alright, Geoff. Well, thank you so much for this. Folks, we will put links in the show notes to the article. Go read it and keep it at the forefront of your mind.
Peter:
Geoff, where can they find you?
Geoff:
You can find everything I do at cocoatype.com, even though that’s not actually where the blog post is this week. There’s a link to it from cocotype.com.
Peter:
So Yeah. Cocoatype.com is is the Geoff starting point. Right? And for me, the starting point is peterwitham.com. Folks, if you like what you’re hearing here, right, come and join us on our dev club Discord.
Peter:
Again, there’ll be links in the show notes for this. This is the kind of stuff, we talk about this a lot. We talk about many different topics related to development, but these are the key areas, that come up a lot and, you know, we get asked a lot of these questions. And going in our Discord where these conversations are taking place, not only do you get to be part of it, but there’s all these fantastic references. You can cause it.
Peter:
Yeah. You can cause these problems. Yeah. Cool cool cool sort of the infighting about compartmentalization. Alright?
Peter:
But that’s it, folks. That’s what we got for you. I hope this has been helpful. Let us know. Leave us a review.
Peter:
If you wanna go the extra step, hey, there’s the link for the Patreon. We greatly appreciate that. Thank you, folks. We will see you in the next episode.
