What’s up, everybody? Welcome to the podcast. We have another episode for you here today. We are gonna be talking about choosing the right back end for your applications, which is gonna be a difficult subject and certainly one that folks are gonna have opinions about. Hey, Geoff.
Peter:
How you doing? How’s your week been? How’s your couple of weeks been as we’ve been regrouping and busy?
Geoff:
They’ve been pretty good. I’ve been working on a number of different projects, none of which have shipped. But okay, you know, that’s how it goes sometimes.
Peter:
Oh, well then, life as usual.
Geoff:
Of course.
Peter:
You know? It’s like I could ship or I
Geoff:
could not ship out with the idea.
Peter:
Or I could
Geoff:
ship one thing or I could work on three things and ship none of them.
Peter:
And and fill successful either way. Exactly. So I’ve kind of had a similar thing. So those of you, paying attention, yes, the Groundhog level is still active on endless hurdles, because I haven’t shipped an update because no good reason really. I fixed the bug and I just didn’t you you know sometimes you’re like, it’s not bad enough that I wanna ship a whole new version just for this one thing.
Peter:
Right? So, I’m kind of the same thing. I got a few things going on. None of them are shipped. Maybe one of them will ship at some point.
Peter:
So there we go. Alright. Let’s dive into this. So, yeah, we are we are talking about back ends for your application here. You know, let’s start by defining what we think back end is and make sure that we’re both on the same page.
Peter:
For me, the back end is anything that’s outside of essentially my app. Right? My app bundle. So it could be things, you know, very much like some APIs that I call, a database, some page of content that I pull in. To me that is all back end support for making the app do its thing.
Peter:
Right? That that’s kind of my definition of a back end. What what do you think of that? What what’s your definition?
Geoff:
No. Sorry. Yeah. No. I think that’s definitely a good definition of it.
Geoff:
You know, you kind of have front ends and back ends to your app as a whole. But I think what we’re talking about is more like what is, you know, a client type front end to your app and a server type back end to your app. You’re talking about something that your app or your product communicates with that is separate from the app itself. And so even if you’re shipping like a web app, for example, you’re gonna have the JavaScript client side, and then you’re gonna have some other server side thing. And for the purposes of our definitions, that is your back end.
Geoff:
So the first thing that I kinda wanna bring up is with that definition, your app may not actually need a quote, unquote, back end. You may have something that is a entirely client focused experience. You know, you have some kind of productivity tool that is a solo creation thing. You may have a game that doesn’t have multiplayer or leader boards or anything like that. It may be possible for you to have an app that doesn’t have a back end at all, and that’s okay.
Geoff:
Like, you don’t have to go and build something with a server if that’s not what your app needs. And it is something that is definitely required for certain kinds of experiences. Like I said, multiplayer games, you kinda need to have some sort of back end if for nothing else to get your players to communicate with each other. But it’s very possible to build apps that don’t have a back end by the definition that we’ve been using.
Peter:
I agree. Couple of examples here. You know, anything that you store on the local file system on your platform of choice where your app is, you know, I don’t think of that as a back end. It’s just your local file system. So using that game is is a good example.
Peter:
Right? If I’m gonna store some player preferences or high score something like that and I’m just gonna store that in some kind of file on the device itself, you know, I don’t tend to think of that as a back end. That’s just an integral part of the application, right? So that’s that’s how I look at that and by the same token, like you say, if it’s not required to call out anywhere for anything outside of let’s say a device then that’s pro you know, not a back end. Right?
Peter:
I wouldn’t call talking to APIs on an OS, for example. You know, back end. Right? That’s just part of the the system layer is how I see it. So assuming that you do need some kind of back end, whatever your definition of that may be and the requirements for your application, let’s talk about using existing skills versus new skills and and you know potentially someone else doing it for you.
Peter:
I am very much an advocate for, you know, now is not the time to go do something new unless there’s a reason. Right? So if I’m in the throes of making an app and I’m getting ready to, you know, trying to shift this thing, now is not a great time to say, you know what? I’ve always wanted to go and learn how to do a node server. Nah.
Peter:
Probably not a good point place to do that. You will end up going down that rabbit hole, right, and then you’re gonna get involved with all of that and the next thing you know you’re not working on your app. So I don’t think using new skills there is necessarily the way to go, but I I I know you’ve got a slightly different viewpoint on that. What what do you think about that?
Geoff:
I think by and large, I agree that this is not, you know, you don’t wanna necessarily jump out and be like, okay. I’m an expert at doing this, and I know how to build this front end the way that I want to. And now I’m gonna go grab something completely different. Just, you know, a bill put even more work on getting something out the door, getting something to ship when, you know, what you should be focused on is building your app. Now with that said, definitely focus on using the right tool for the job.
Geoff:
If you are somebody who is is building an app in a language that doesn’t have a great server ecosystem as it is, you probably do want to look a little bit outside of your area of expertise. If you’re building an app in some kind of game maker, a game engine like Godot, for example, you probably don’t wanna try to build a web server in that. If you’re working on an iOS app, but, you know, you’re old school and you’re still doing an objective c, you know, I don’t think there’s a lot of great objective c server solutions out there. You know, Swift has some great server solutions. We’ve talked about it on the podcast before.
Geoff:
You know, Python, Ruby, Node. Js, all of these, there are systems out there that have much better ecosystems. And I would say, find one close to things that you know. Find one that’s simple and which there’s a lot of expertise online for, and go look into something like that. To that same end, like, make sure it integrates with the kinds of things that you want to do.
Geoff:
You know? If you are you if you know you need a database, like, use a language that not just has a server ecosystem, but also has connections to that database, for example. I wouldn’t go looking at a language that has a great server ecosystem but doesn’t have a whole lot of other things.
Peter:
And I and I wanna be transparent here. You know, hopefully, by now, folks know that I’m I’m an advocate of continuous learning. Right? So I’m not saying, hey, you know what? If there’s an opportunity presents to go learn something new or some aspect of something you’ve not done before, go do that.
Peter:
I’m I’m just saying that now is probably not the best time because you’re already trying to ship one product or part of a product and, you know, these back end systems and things like that, they support that. Right? And they shouldn’t be projects unto themselves unless there’s a reason to. So I do agree with you that, hey, you know, if an opportunity presents and it’s not gonna hurt you in any way, go for it. But, you know, don’t don’t jump off into the deep end and next thing you know is like, oh, I got problems everywhere and, you know, I got this back end that I don’t know and, you know, stuff like that.
Peter:
Certainly, a good example I think for there is databases. Right? I mean, that’s another one where there are endless options but there’s also many different ways these things operate and, you know, learning to a database three different ways is probably not the best use of your time while you’re trying to ship this product. So with that, moving on, let’s talk about possible options. And before we dive into these because I I know there’s gonna be those folks out there, no this is not an exhaustive list of everything.
Peter:
We are just gonna list what we feel are some of the more common ones. Certainly ones that have been used a lot so you will find good support out there, good communities of which again I cannot stress enough in my opinion. Finding good support documentation and communities is vital in just about anything you do that’s going to ship to production. So, with that said, right, you know, let’s let’s start with a couple of obvious ones here. If you’re on an Apple platform and you’re developing for an app an Apple platform, two very easy ones to get started with that are essentially connected at the hip as it were, CloudKit and iCloud.
Peter:
Right? I use those in one of my apps and it works great for me. I I know other people have other opinions but it’s pretty darn easy to get working with it and and that instantly gives you cross device support. Right? So for me, you know, that that that’s a great one in there.
Peter:
There are also plenty of platforms out there that you can take advantage of. One of the most well known ones perhaps is Firebase. It’s very popular. I use it in in some apps and I’m very happy with it and Firebase is a collection of services really. People tend to think of it as just, you know, one or two things like an online database and and things like that, but it actually is a collection of services.
Peter:
So if you want to go that route, you could use Firebase for a real time database. You could use it for example in a real time chat application. You’ve got crash analytics, you’ve got performance analytics, all these kind of services in there as well and it just works out of the box, right. Again, very well documented and it works with many different languages. They have pre built libraries for for many of the the most popular options out there.
Peter:
For example, I’ve used it with Android, I’ve used it with native iOS and I have and by that I mean Swift and Objective C and I’ve used it with React Native as well. So and and plenty of folks use it for web apps. So Firebase is a good option there. There are, of course, many other services, you know, we could start streaming off like for example, you know, Amazon has some, Microsoft has some, so on but those are the some pre built ones. However, there is another route you can go and if you want to have some fun doing your own, there are a few options.
Peter:
Geoff, you wanna name a few of the popular ones?
Geoff:
So at the very top level of it, you’ve got building your own thing from scratch. And like I said earlier, there are a lot of different languages that are very good at this. Probably the most popular options out there are Node. Js for the JavaScript ecosystem, and then there are a couple of different server frameworks for the Python ecosystem if it’s what you’re, familiar with. But, yeah.
Geoff:
Just basically taking a server framework that exists out there and building all of your own functionality into it. And this obviously gives you the most freedom. You’re not limited to the services that a company like Firebase provides, but you’re also responsible for all of this. If you need to connect to a database, well, you’re responsible for running that database now as well. So having so this is really building something from scratch and really supporting your own full service ecosystem on your own.
Peter:
I do wanna highlight one thing that you said there that I think is very important, and I think folks shouldn’t underestimate. Anytime you roll anything for yourself, whether it’s front end, back end, whatever, you are responsible for the maintenance and to ensure that it’s running and and that’s super important. If you go with one of these pre built options, there’s a lot less work for you to do. For example, you know, Firebase is not gonna go down and you’re gonna have to fix it. Right?
Peter:
That kind of thing. If your own back end that you you created, I mean, more power to you. I’m not saying you shouldn’t do it, but if something goes wrong with it, you’re the one that’s got to figure it out. Right? Because you own it and you built it and and you got to solve the the problem, which is something to think about because especially if you are building an app for somebody else and you build a back end to go with that, they’re gonna expect you to maintain that.
Peter:
And and it sort of is on you to maintain it. Right? It’s unlikely you’re gonna have a contract that says I’m gonna build this thing and walk away.
Geoff:
That’s right. I agree. Like you said, Firebase and any of these third party systems, you know, CloudKit the same way, these are things that other people are going to maintain, and, you know, it it it’s not a % perfect. They may go down from time to time. You know?
Geoff:
Sometimes things happen and, you know, but it’s not your job to maintain them. If it is your job to maintain them, you have to make sure that you’re working with a service that is reliable. And so, you know, probably don’t host this on the Mac mini you’ve got in your basement. If you’ve got dogs, you know, they’re gonna fall over the power cord and, you know, there’s your app down. You probably want to go with a reliable hosting service.
Geoff:
You mentioned earlier, AWS, Google Cloud Platform. There’s a lot of these, services. There are also some smaller ones out there, like DigitalOcean, Linode, Hetzner. And if you’re more familiar with hosting your own service, if you’re, you know, pretty familiar with running, like, a Linux back end thing, those can be great alternatives as well. But, yeah, definitely use some kind of reliable hosting company.
Geoff:
You don’t wanna be going into app review with Apple and, you know, your service isn’t running because they’re gonna boot up your app and they’re gonna go, it doesn’t work, and they’re gonna reject you immediately.
Peter:
So I’m hoping that the takeaway here is now is not the time to get too experimental. You want to really be going with something that’s tried and tested and been out there. Right? Preferably, as we’ve said, hosted or maintained by some nice big company who deeply vested in making sure these services that they provide you are running and therefore, they are running for your application and hopefully your customers. By all means, go learn new things, you know, experiment with them.
Peter:
But when you’re going to production, I personally don’t feel now is the time to to sort of test my limits. I much rather have something that I can focus on my app and know that the back end is good and solid and not have to worry about it. So I think that about covers it here. Geoff, where can people find you?
Geoff:
As always, I’m on cocoatype.com for links to wherever I’m doing things now. And as always, you can find me
Peter:
at peterwitham.com. That’s it, folks. We will speak to you in the next episode.
