Choosing and using the right backend system for your app
16:08 Share

What's up, everybody? Welcome to the podcast. We have another episode for you here today. We are going to be talking about choosing the right back end for your applications, which is going to be a difficult subject and certainly one that folks are going to have opinions about.

Hey, Jeff. How you doing? How's your week been? How's your couple of weeks been as we've been regrouping and busy? 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. Oh, well then, life as usual, right? Of course. You know, it's like I could ship or I could not. I could ship one thing or I could work on three things and ship none of them.

And Phil's 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 know, sometimes you're like...

it's not bad enough that I want to ship a whole new version just for this one thing, 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. So there we go. All right, let's dive into this. So yeah, we are talking about backends for your application here.

Let's start by defining what we think backend is and make sure that we're both on the same page. For me, the backend is anything that's outside of essentially my app, my app bundle. It could be things very much like some APIs that I call, a database, some page of content that I pull in. To me, that is all backend support content.

For making the app do its thing, right? That's kind of my definition of backend. What do you think to that? What's your definition? Yeah, no, I think that's definitely a good definition of it. 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 application.

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 going to have the JavaScript client side, and then you're going to have some other server side thing. And for the purposes of our definitions, that is your back end.

So the first thing that I kind of want to bring up is with that definition, your app may not actually need a quote unquote backend, right?

You may have something that is an entirely client-focused experience. You have some kind of productivity tool that is a solo creation thing. You may have a game that doesn't have multiplayer or leaderboards or anything like that. It may be possible for you to have an app that doesn't have a backend at all, and that's okay. 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 kind of need to have some sort of backend 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 backend by the definition that we've been using. I agree. A couple of examples here. You know, anything that you store on the local file system on your PC,

of choice where your app is. You know, I don't think of that as a backend. It's just your local file system. So using that game is a good example, right? If I'm going to store some player preferences or high score, something like that, and I'm just going to store that

in some kind of file on the device itself. I don't tend to think of that as a backend. That's just an integral part of the application. So 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 not a backend. I wouldn't call talking to APIs on an OS, for example.

you know, back end, right? That's just part of 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 potentially someone else doing it for you. I am very much an advocate for now is not the time to go do something new unless there's a reason. So if I'm in the throes of making an app and I'm getting ready to try to ship 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. Now, probably not a good place to do that. You will end up going down that rabbit hole, right? And then you're going to 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 know you've got a slightly different viewpoint on that.

What do you think about that? I think by and large, I agree that this is not, you know, you don't want to necessarily jump out and be like, okay, I'm an expert at doing this and I know how to build this run in the way that I want to. And now I'm going to go grab something completely different. Just, you know, put even more work on getting something out the door, getting something to ship and,

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. If you are...

Somebody who 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 want to 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. Um,

You know, Swift has some great service solutions. We've talked about it on the podcast before. 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. 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. And I want to be transparent here. You know, hopefully by now folks know that 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. I'm just saying that now is probably not the best time because you're already trying to ship one thing

product or part of a product. And these backend 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, if an opportunity presents and it's not going to hurt you in any way, go for it.

But, you know, don't jump off into the deep end and the 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. Certainly a good example I think 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 know there's going to be those folks out there no this is not an exhaustive list of everything

We are just going to 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 shift to production.

So with that said, right, you know, let's start with a couple of obvious ones here. If you're on an Apple platform and you're developing for an Apple platform, two very easy ones to get started with that are essentially connected at the hip, as it were, CloudKit and iCloud, right? I use those in one of my apps and...

It works great for me. I know other people have other opinions, but it's pretty darn easy to get working with it. And that instantly gives you cross-device support, right? So for me, you know, that's a great one in there.

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 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 one or two things, like an online database and things like that. But it actually is a collection of services. 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 services.

And it works with many different languages. They have pre-built libraries for many of the most popular options out there. For example, I've used it with Android. I've used it with native iOS. And by that, I mean Swift and Objective-C. And I've used it with React Native as well. And plenty of folks use it for web apps.

So Firebase is a good option there. There are, of course, many other services. We could start streaming off, for example, Amazon has some, Microsoft has some, so on. But those are 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. Jeff, you want to name a few of the popular ones? So at the very top level of it, you've got building your own thing from scratch and creating

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 that's what you're familiar with. But yeah, just basically taking...

No.

So this is really building something from scratch and really supporting your own full service ecosystem on your own. I do want to 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 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, Firebase is not going to go down and you're going to have to fix it, right? That kind of thing. If your own back end that 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 you've got to solve the problem, which is something to think about. Because especially if you are building an app for somebody else and you build a backend to go with that,

they're going to expect you to maintain that. And it sort of is on you to maintain it, right? It's unlikely you're going to have a contract that says, I'm going to build this thing and walk away. 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's not a hundred percent perfect. They may go down from time to time, you know, uh, sometimes things happen and you, 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. Um, if you've got dogs, you know, they're going to fall over the power cord and you know, there's your app down.

You probably want to go with a reliable hosting service. 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 pretty familiar with running like a Linux backend thing, those can be great alternatives as well.

But yeah, definitely use some kind of reliable hosting company. You don't want to be going into app review with Apple and, you know, your service isn't running because they're going to boot up your app and they're going to go, it doesn't work and they're going to reject you immediately.

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, experiment with them. But when you're going to production, I personally don't feel now is the time to sort of test my limits. I'd much rather have something that I can focus on my app and know that the backend is good and solid and not have to worry about it. So I think that about covers it here. Jeff, where can people find you? As always, I'm on kokotype.com for links to wherever I'm doing things now and...

As always, you can find me at PeterWyden.com. That's it, folks. We will speak to you in the next episode.