Under the Radar

00:00:00 ◼   ► - Welcome to Under the Radar,

00:00:01 ◼   ► a show about independent iOS app development.

00:00:04 ◼   ► I'm Marco Armet.

00:00:05 ◼   ► - And I'm David Smith.

00:00:06 ◼   ► Under the Radar is never longer than 30 minutes,

00:00:08 ◼   ► so let's get started.

00:00:10 ◼   ► So today we are going to, I guess,

00:00:12 ◼   ► have our third Q&A that we've ever done,

00:00:15 ◼   ► a follow-up to the one we did last week.

00:00:17 ◼   ► Got a lot of great questions that came in from that,

00:00:20 ◼   ► you know, since we recorded that episode,

00:00:23 ◼   ► and I think it was really, it's a good time

00:00:24 ◼   ► to talk through some of these things.

00:00:26 ◼   ► I think this is always an awkward time

00:00:29 ◼   ► for in-apple developer land,

00:00:30 ◼   ► because this is the quiet period before WWDC,

00:00:32 ◼   ► and then in the summer, things will pick up dramatically,

00:00:34 ◼   ► and there'll be a lot more topical and interesting things.

00:00:38 ◼   ► But it's also really interesting for me

00:00:39 ◼   ► just to hear from listeners of the show

00:00:42 ◼   ► and the kind of topics and things that you're interested in,

00:00:44 ◼   ► because as creators of something like a podcast,

00:00:47 ◼   ► it's very often, you know,

00:00:50 ◼   ► it can often be somewhat one way,

00:00:52 ◼   ► and so it's really nice to just hear

00:00:54 ◼   ► what you guys are interested in hearing us talk about,

00:00:56 ◼   ► and so that's really useful.

00:00:58 ◼   ► So we're gonna do another one of those this week.

00:01:01 ◼   ► So our first question comes from Rick,

00:01:04 ◼   ► who asks, "What does your app's

00:01:06 ◼   ► server infrastructure look like?"

00:01:08 ◼   ► And I think we're gonna answer this question

00:01:09 ◼   ► slightly more broadly, just like in general,

00:01:11 ◼   ► having a kind of a high-level talk

00:01:13 ◼   ► about the way we do servers.

00:01:16 ◼   ► It was a question that was asked by many other people

00:01:17 ◼   ► if we didn't happen to pick your question, apologies,

00:01:20 ◼   ► but we had a lot of general questions

00:01:21 ◼   ► about like how do we structure our servers,

00:01:24 ◼   ► how do we kind of, strategies and things

00:01:26 ◼   ► that we take for that.

00:01:28 ◼   ► Maybe getting into backups and scalability and so on.

00:01:31 ◼   ► Like there's lots of questions about that,

00:01:32 ◼   ► and I think getting into the specifics,

00:01:35 ◼   ► like the specific specifics,

00:01:37 ◼   ► is probably not particularly helpful.

00:01:39 ◼   ► I mean, I think there's something to be said for,

00:01:41 ◼   ► you know, the nature of any server infrastructure you create

00:01:45 ◼   ► is that it is immediately sort of obsolete and outdated,

00:01:50 ◼   ► in the sense that I'm sure there's a better,

00:01:52 ◼   ► you know, at the low level,

00:01:55 ◼   ► there's probably always a better approach

00:01:56 ◼   ► or something, some new hotness

00:01:57 ◼   ► that people would recommend or say,

00:01:59 ◼   ► oh, we're doing this wrong or this wrong.

00:02:01 ◼   ► Or even just in general,

00:02:02 ◼   ► that there's a lot of kind of these opinions about,

00:02:06 ◼   ► well, this is the way that I do it,

00:02:07 ◼   ► this is the way that you should do it, and so on.

00:02:09 ◼   ► So I think in general,

00:02:10 ◼   ► rather than talking about the actual specific details

00:02:12 ◼   ► of like I use this version of this package

00:02:15 ◼   ► to manage my servers, or I use this library for this,

00:02:18 ◼   ► or you know, this web host,

00:02:19 ◼   ► it's like this is at a high level,

00:02:22 ◼   ► what we have found, I think, to work well.

00:02:24 ◼   ► And I think that is useful

00:02:25 ◼   ► and probably much more constructive,

00:02:27 ◼   ► and then the details in your specific installation will vary.

00:02:31 ◼   ► So for me, I have a variety of different servers

00:02:35 ◼   ► that I manage as part of my work.

00:02:36 ◼   ► I think I have four apps that have server backends to them.

00:02:41 ◼   ► The biggest one for me is Feed Wrangler,

00:02:43 ◼   ► which is my RSS syncing platform.

00:02:45 ◼   ► And so I'll talk about that one probably in depth,

00:02:46 ◼   ► because it's sort of the superset of everything else.

00:02:49 ◼   ► So I host it with a Linode VPS or a series of those.

00:02:56 ◼   ► In front of those,

00:02:57 ◼   ► like starting out from the client and working back,

00:02:59 ◼   ► I have a, I guess it's like a proxy, we call it,

00:03:04 ◼   ► or a load balancer out in the front.

00:03:07 ◼   ► Requests go to there.

00:03:08 ◼   ► They then go to a variety of web servers.

00:03:10 ◼   ► I always have at least three,

00:03:12 ◼   ► because then if one goes down,

00:03:14 ◼   ► or I need to take one down for maintenance,

00:03:16 ◼   ► then there's at least two others.

00:03:18 ◼   ► And so then you're not falling down

00:03:20 ◼   ► to just one at any one time.

00:03:23 ◼   ► So I go out to three.

00:03:24 ◼   ► I have a main database server.

00:03:26 ◼   ► I have a variety of utility servers.

00:03:28 ◼   ► For an RSS syncing system,

00:03:29 ◼   ► you have a lot of scrapers and things that are,

00:03:32 ◼   ► these sort of task-based systems

00:03:34 ◼   ► that are being spun up and spun down all the time.

00:03:37 ◼   ► So I have a couple of utility servers,

00:03:40 ◼   ► which I have a memcache server

00:03:42 ◼   ► that's just basically just sitting there

00:03:43 ◼   ► to be a big pile of memory to do basic caching.

00:03:46 ◼   ► And I think that's it.

00:03:49 ◼   ► That's sort of at a high level,

00:03:50 ◼   ► the way that I structure things.

00:03:52 ◼   ► I do backups at multiple levels.

00:03:54 ◼   ► I have a continuous backup of my main database

00:03:59 ◼   ► that is always running,

00:04:00 ◼   ► that is just sort of doing this binary log streaming version

00:04:03 ◼   ► of that to take all of the data in real time

00:04:07 ◼   ► and doing a backup,

00:04:08 ◼   ► as well as taking advantage of a variety

00:04:10 ◼   ► of other kind of more snapshot-based snapshots.

00:04:14 ◼   ► So if, for whatever reason,

00:04:15 ◼   ► my binary logs or things got corrupted,

00:04:17 ◼   ► I can fall back to a less precise snapshot

00:04:22 ◼   ► for a particular point in time.

00:04:24 ◼   ► That's sort of my general approach.

00:04:25 ◼   ► - You know, I've done servers big and small,

00:04:29 ◼   ► and at a high level,

00:04:32 ◼   ► the biggest piece of advice I can give anybody

00:04:35 ◼   ► when doing server work,

00:04:37 ◼   ► especially in the context of iOS apps,

00:04:38 ◼   ► where your job is not to be the coolest server developer

00:04:41 ◼   ► in the world, your job is to make an app

00:04:42 ◼   ► that happens to include a server as part of how it works.

00:04:45 ◼   ► My best advice I can possibly give

00:04:48 ◼   ► is to have your server side stack be as boring

00:04:51 ◼   ► and established as possible.

00:04:53 ◼   ► And you never wanna be on the cutting edge

00:04:56 ◼   ► of anything server side, like anything,

00:04:59 ◼   ► the software, the hardware, anything.

00:05:02 ◼   ► You want to be as boring as possible.

00:05:04 ◼   ► So this means using tools in your stack

00:05:08 ◼   ► that have been around for a while,

00:05:09 ◼   ► that are well understood,

00:05:11 ◼   ► that other people are using,

00:05:13 ◼   ► way more people than you are using at scale,

00:05:16 ◼   ► and so everyone else can run into the bugs

00:05:19 ◼   ► who's on the cutting edge.

00:05:20 ◼   ► Let them fix things, let them patch things,

00:05:23 ◼   ► let them find the limits and fix them,

00:05:25 ◼   ► or at least document them.

00:05:26 ◼   ► You should not be doing that on your server

00:05:28 ◼   ► because you can't afford the time.

00:05:31 ◼   ► Simple as that, that's a whole different thing

00:05:34 ◼   ► that honestly I think nobody should be doing.

00:05:36 ◼   ► But if you, maybe if your entire career

00:05:40 ◼   ► is gonna be cutting edge server side stuff,

00:05:43 ◼   ► maybe you can consider it then,

00:05:44 ◼   ► but in the context of what listeners of this show

00:05:47 ◼   ► are doing and need to do,

00:05:49 ◼   ► and the context of what I've always needed to do,

00:05:51 ◼   ► boring established server side stacks are best.

00:05:54 ◼   ► So in my case I use PHP,

00:05:57 ◼   ► which is pretty much the definition

00:05:59 ◼   ► of boring established and battle tested,

00:06:01 ◼   ► and I use MySQL for the database,

00:06:04 ◼   ► which again, boring established tested.

00:06:06 ◼   ► Google and Facebook use tools like this,

00:06:09 ◼   ► and if they don't run into problems with it,

00:06:12 ◼   ► I know I won't run into problems with it,

00:06:14 ◼   ► or at least any problem I run into will be well documented,

00:06:17 ◼   ► will have tons of people online.

00:06:19 ◼   ► If you search for it, if you run into a problem,

00:06:21 ◼   ► you can figure out a way around it,

00:06:22 ◼   ► or you can figure out what you're doing wrong.

00:06:24 ◼   ► Anything cutting edge is gonna have problems with this,

00:06:27 ◼   ► 'cause it's just newer.

00:06:28 ◼   ► There's less help, it's moving more quickly,

00:06:31 ◼   ► it's changing more quickly, it's gonna be less stable,

00:06:33 ◼   ► just by definition of being newer,

00:06:35 ◼   ► and so keep things boring and old and stable.

00:06:39 ◼   ► Other than that, I structure things similarly.

00:06:42 ◼   ► I have a load balancer through our sponsor this week,

00:06:45 ◼   ► Linode actually, I use their node balancer

00:06:47 ◼   ► in front of things now.

00:06:48 ◼   ► I do software load balancers, things like HAProxy,

00:06:51 ◼   ► but I just don't need them anymore.

00:06:53 ◼   ► I have web servers behind that, all hitting databases,

00:06:57 ◼   ► and then a couple of servers that are neither web servers

00:07:01 ◼   ► nor databases that are just doing other app related tasks,

00:07:04 ◼   ► things like crawling or processing or generating backups

00:07:07 ◼   ► or things like that.

00:07:08 ◼   ► That's about it.

00:07:09 ◼   ► Again, it's not something you should really be overthinking

00:07:13 ◼   ► or overdesigning.

00:07:14 ◼   ► I wouldn't suggest doing anything that requires

00:07:18 ◼   ► fancy scaling things like, say, database sharding,

00:07:21 ◼   ► for instance, is one thing that I've found

00:07:23 ◼   ► is almost never worth doing for almost anybody

00:07:25 ◼   ► until you get to a very, very large scale.

00:07:29 ◼   ► Crazy kind of distributed tools, things like Cassandra,

00:07:32 ◼   ► really usually not necessary for anybody operating

00:07:35 ◼   ► at our scale or even much bigger than our scale.

00:07:39 ◼   ► If you use boring things like MySQL or Postgres,

00:07:43 ◼   ► if you use them well and properly,

00:07:47 ◼   ► you can get very, very far with them

00:07:49 ◼   ► without going to anything crazier.

00:07:51 ◼   ► Keep it simple, keep it old, keep it boring,

00:07:53 ◼   ► because you gotta keep in mind,

00:07:55 ◼   ► your job is to make this app that you're making

00:07:59 ◼   ► or to make this service that you're making.

00:08:00 ◼   ► Nobody cares how fancy your server-side stuff is,

00:08:04 ◼   ► and if you're working by yourself

00:08:07 ◼   ► or with a small group of people and listening to this show,

00:08:10 ◼   ► no matter what you think, you are not at the scale

00:08:12 ◼   ► where you need to be using cutting edge

00:08:15 ◼   ► or less commonly used things.

00:08:17 ◼   ► You're just not.

00:08:19 ◼   ► Google AdWords ran on MySQL for a very long time,

00:08:22 ◼   ► long after all of us heard of it and started using it.

00:08:25 ◼   ► Twitter ran on MySQL until, I think,

00:08:28 ◼   ► at least about 2009 or so, and probably even past that.

00:08:33 ◼   ► Facebook used PHP until they kind of developed

00:08:37 ◼   ► their own weird offshoot of it.

00:08:40 ◼   ► Wikipedia still uses PHP.

00:08:42 ◼   ► These are tools that, anything that you think,

00:08:45 ◼   ► X or Y doesn't scale, if you've heard that

00:08:47 ◼   ► or if you think that, you're probably not right

00:08:50 ◼   ► about that here, like, almost everything scales

00:08:53 ◼   ► if you learn how to use it responsibly.

00:08:56 ◼   ► The only thing I would also say about that, if possible,

00:08:59 ◼   ► is to basically make all of your requests stateless

00:09:03 ◼   ► so that any request can go to any server

00:09:07 ◼   ► and it still works just fine.

00:09:08 ◼   ► So basically, that doesn't take that much

00:09:11 ◼   ► to avoid just avoiding session state, basically,

00:09:14 ◼   ► being stored server-side.

00:09:16 ◼   ► That's about all you need for that.

00:09:18 ◼   ► And be very, very careful when going to database

00:09:22 ◼   ► replication setups, where you'd have kind of like

00:09:25 ◼   ► a master-slave kind of setup.

00:09:27 ◼   ► I use those, I use them a lot.

00:09:30 ◼   ► They are extraordinarily prone to weird caching bugs

00:09:35 ◼   ► if you're not careful.

00:09:37 ◼   ► And I've built up my own framework over time

00:09:39 ◼   ► to make it a little bit easier, to make it more automated,

00:09:41 ◼   ► where I'm not caching stale data from the read slave

00:09:44 ◼   ► or anything else, but just be careful

00:09:46 ◼   ► when you do that kind of complexity.

00:09:48 ◼   ► In general, it is much better to scale up

00:09:52 ◼   ► a single master database or to split it

00:09:55 ◼   ► between multiple master databases with different tables

00:09:58 ◼   ► in one, different tables in the other

00:10:00 ◼   ► before you go to replication setups,

00:10:01 ◼   ► because replication just introduces so many

00:10:03 ◼   ► subtle little bugs and little problems.

00:10:06 ◼   ► But yeah, otherwise, again, just keep it simple,

00:10:08 ◼   ► keep it old, and this is a really good time to tell you

00:10:10 ◼   ► about our sponsor, which is Linode.

00:10:13 ◼   ► Linode is my favorite web host.

00:10:16 ◼   ► It's where all of my servers are.

00:10:17 ◼   ► I have something like 20 servers there,

00:10:20 ◼   ► something in that ballpark.

00:10:21 ◼   ► With Linode, you have access to a suite

00:10:23 ◼   ► of powerful hosting options, with prices starting

00:10:25 ◼   ► at just $5 a month.

00:10:27 ◼   ► You can be up and running with your own virtual server

00:10:29 ◼   ► in the Linode cloud in under a minute.

00:10:32 ◼   ► Whether you are just getting started with one server,

00:10:34 ◼   ► which is where you should probably start,

00:10:35 ◼   ► or whether you're deploying a more complex system,

00:10:38 ◼   ► like what me and Dave have,

00:10:39 ◼   ► Linode is the right choice for you.

00:10:41 ◼   ► Linode has the fastest hardware network,

00:10:43 ◼   ► fantastic customer support behind it all.

00:10:45 ◼   ► It has never been easier to launch a Linode cloud server.

00:10:48 ◼   ► And they guarantee 99.9% uptime for server availability.

00:10:52 ◼   ► Once your server is up, they intend to keep it that way.

00:10:55 ◼   ► And they now also have block storage out of beta.

00:10:57 ◼   ► This is available in Fremont and Newark,

00:10:59 ◼   ► and they're expanding it to all data centers by June.

00:11:02 ◼   ► Linode is great for things like hosting large databases,

00:11:05 ◼   ► running mail servers, operating VPNs,

00:11:07 ◼   ► running Docker containers.

00:11:08 ◼   ► I really intend to actually learn Docker soon.

00:11:12 ◼   ► It's one of those things that like,

00:11:13 ◼   ► it's kinda like flossing, like you know you should do it,

00:11:16 ◼   ► and I just still haven't really gotten into the habit yet,

00:11:18 ◼   ► but I really gotta learn Docker.

00:11:20 ◼   ► Hosting a private Git server, you can do that there too,

00:11:22 ◼   ► and so much more.

00:11:23 ◼   ► And Linode's even hiring right now.

00:11:25 ◼   ► If that interests you, go to linode.com/careers.

00:11:28 ◼   ► So Linode has fantastic pricing options.

00:11:31 ◼   ► Plans start at just one gig of RAM for just $5 a month.

00:11:35 ◼   ► And they have all sorts of plans that go up from there,

00:11:36 ◼   ► including high memory plans.

00:11:38 ◼   ► As a listener of this show,

00:11:39 ◼   ► if you sign up at linode.com/radar,

00:11:42 ◼   ► you will be supporting us,

00:11:43 ◼   ► and you will get $20 towards any Linode plan.

00:11:46 ◼   ► So if you choose, for example, the one gig plan,

00:11:48 ◼   ► that's four months free.

00:11:49 ◼   ► And with a seven day money back guarantee,

00:11:51 ◼   ► there is nothing to lose.

00:11:53 ◼   ► So go to linode.com/radar to learn more,

00:11:56 ◼   ► sign up and take advantage of that $20 credit,

00:11:58 ◼   ► or use promo code radar2018 at checkout.

00:12:01 ◼   ► Thank you so much to Linode for supporting the show.

00:12:05 ◼   ► - So related to server development,

00:12:07 ◼   ► another question that we had

00:12:08 ◼   ► that I think has come up many times, Brad Payne asks,

00:12:11 ◼   ► our thoughts on when if Swift server development

00:12:14 ◼   ► will ever become a thing?

00:12:16 ◼   ► And I struggle to answer this question,

00:12:20 ◼   ► because I feel like it both feels inevitable,

00:12:23 ◼   ► and it seems like it's never going to happen,

00:12:26 ◼   ► both at the exact same time for me.

00:12:27 ◼   ► It seemed like Swift, if I felt more confident

00:12:32 ◼   ► about Swift as a general purpose,

00:12:38 ◼   ► like this is going to be the language of the future,

00:12:41 ◼   ► then it would seem inevitable

00:12:43 ◼   ► that it will eventually be used for server development.

00:12:46 ◼   ► I think that is just part and parcel

00:12:49 ◼   ► of whatever the most dominant languages

00:12:52 ◼   ► that are being used by the most developers in the world,

00:12:55 ◼   ► because web development is such a significant part of that.

00:12:58 ◼   ► And inevitably, frameworks and things are going to spring up

00:13:01 ◼   ► that let you use those skills in those places.

00:13:05 ◼   ► The thing that is awkward, I think,

00:13:06 ◼   ► is at least at this point,

00:13:08 ◼   ► Swift doesn't quite feel like it has that broad appeal yet.

00:13:13 ◼   ► And in a weird way, Swift sometimes still feels

00:13:17 ◼   ► like it's still in its infancy and still growing up,

00:13:20 ◼   ► and they're still making so many changes to the language

00:13:23 ◼   ► at such a pace and level that it's,

00:13:27 ◼   ► if you aren't an iOS developer,

00:13:29 ◼   ► I could see it being difficult to want to dive into it

00:13:33 ◼   ► and use it as just a general purpose language.

00:13:35 ◼   ► And so I think at some point it might,

00:13:38 ◼   ► but I think it seems very far off at this point.

00:13:40 ◼   ► And I think if Swift Server is your jam, then go for it.

00:13:45 ◼   ► That sounds great.

00:13:47 ◼   ► I'm certainly glad that there are probably people

00:13:49 ◼   ► who are driving that forward.

00:13:51 ◼   ► But I think in general, my advice at this point,

00:13:53 ◼   ► for most iOS developers is,

00:13:55 ◼   ► just like you were saying earlier,

00:13:56 ◼   ► is to use boring tools for your server side

00:14:01 ◼   ► and use things that are kind of old and battle tested

00:14:04 ◼   ► that the benefits you would get from reusing,

00:14:07 ◼   ► you're using the same language on your client and your server

00:14:10 ◼   ► are probably fairly minor because at the end of the day,

00:14:13 ◼   ► it's just gonna end up being JSON being passed back and forth

00:14:16 ◼   ► between these two apps or between these two things.

00:14:18 ◼   ► And once you've gotten through the translation part of that,

00:14:21 ◼   ► what they actually are speaking is only useful

00:14:25 ◼   ► on the server in very specific cases.

00:14:28 ◼   ► If you have some kind of specific business logic

00:14:30 ◼   ► that you want to replicate in both places,

00:14:33 ◼   ► but then you have to start wondering,

00:14:34 ◼   ► do I really want to replicate this in both places

00:14:36 ◼   ► or should this really be maintained in one place and so on?

00:14:40 ◼   ► So I think at some point it seems possible,

00:14:43 ◼   ► but it doesn't seem like for me anyway,

00:14:45 ◼   ► something that is likely in the short term

00:14:47 ◼   ► or something that I'm putting much interest and attention on.

00:14:51 ◼   ► - Yeah, I would love to have Swift on the server

00:14:55 ◼   ► be a big thing that takes off

00:14:57 ◼   ► because I'm not that into the idea

00:15:00 ◼   ► of necessarily sharing a bunch of code

00:15:02 ◼   ► between client and server

00:15:03 ◼   ► because for the reasons you said,

00:15:04 ◼   ► I don't think I'd actually be doing that very much, if ever,

00:15:08 ◼   ► because the needs are so different

00:15:09 ◼   ► and what you're dealing with is so different.

00:15:10 ◼   ► But I would like to only master one language

00:15:15 ◼   ► as my next language for client and server.

00:15:17 ◼   ► Right now, the languages that I actually use in practice

00:15:21 ◼   ► are basically Objective-C, PHP,

00:15:25 ◼   ► and a very small amount of Go for a few server things

00:15:29 ◼   ► that PHP just didn't do that well

00:15:31 ◼   ► and Go just does a better job of that kind of task.

00:15:33 ◼   ► So that's about it.

00:15:35 ◼   ► And I don't like Go that much, it's fine.

00:15:39 ◼   ► I would love for PHP, I mean for Swift,

00:15:42 ◼   ► to replace everything everywhere

00:15:44 ◼   ► because the kind of, just like the style of ProgrammerAM

00:15:47 ◼   ► is I don't learn every single language out there.

00:15:49 ◼   ► I learn a small number,

00:15:50 ◼   ► I try to master them as much as possible,

00:15:52 ◼   ► and I try to be very productive in those

00:15:54 ◼   ► until it's not possible anymore to be productive in those,

00:15:57 ◼   ► like until I'm forced to go do something else

00:15:59 ◼   ► because learning new languages and starting from zero

00:16:03 ◼   ► at my skill level is just not something I find fun.

00:16:06 ◼   ► Although that's very different for every programmer,

00:16:08 ◼   ► so you might be one of those people.

00:16:08 ◼   ► Anyway, so Swift on the server,

00:16:12 ◼   ► it goes against everything we just said

00:16:13 ◼   ► about do things that are old and stable and established.

00:16:18 ◼   ► I don't know who's using Swift on the server

00:16:21 ◼   ► at any kind of scale or for any kind of complex code base.

00:16:24 ◼   ► I have no idea, there might be people out there doing that.

00:16:27 ◼   ► I think it's fairly unlikely

00:16:29 ◼   ► and it's so new right now.

00:16:31 ◼   ► So maybe in five years,

00:16:34 ◼   ► that might be a more established thing to do

00:16:37 ◼   ► and there might be a lot of people doing that.

00:16:38 ◼   ► Maybe there would be great library support and everything.

00:16:40 ◼   ► The thing is, on the server side,

00:16:43 ◼   ► the language matters a little bit,

00:16:44 ◼   ► but what matters a lot in practice also

00:16:46 ◼   ► is just what kind of built-in libraries and functionality

00:16:50 ◼   ► and good third-party libraries are available

00:16:52 ◼   ► to do things that people commonly need to do on web servers.

00:16:55 ◼   ► So that's one of the reasons PHP took off so well

00:16:58 ◼   ► because it had a whole bunch of very common web stuff

00:17:01 ◼   ► just built right into the language

00:17:02 ◼   ► that was super easy to use.

00:17:04 ◼   ► And anything that you'd have to do on a server,

00:17:07 ◼   ► various form processing things, image operations

00:17:11 ◼   ► for processing and generating images,

00:17:14 ◼   ► obviously tons of string processing, some network stuff.

00:17:17 ◼   ► There's all sorts of stuff that you need to do on the server

00:17:19 ◼   ► that you don't always,

00:17:21 ◼   ► that usually aren't built into a language,

00:17:24 ◼   ► that usually have to come

00:17:25 ◼   ► by some kind of third-party library.

00:17:27 ◼   ► And there's a reason why certain languages

00:17:30 ◼   ► take off on the server, and most don't.

00:17:33 ◼   ► Objective-C on the server never really went anywhere,

00:17:35 ◼   ► except I think that's what WebObjects is,

00:17:36 ◼   ► or was it Java?

00:17:37 ◼   ► Anyway, certain languages just make server tasks easier.

00:17:41 ◼   ► Swift, I don't think, is inherently one of those languages.

00:17:44 ◼   ► So for it to become really awesome on the server,

00:17:47 ◼   ► it's gonna have to have a very large library

00:17:50 ◼   ► developed for it that becomes

00:17:53 ◼   ► either an official standard library

00:17:54 ◼   ► for web serving type needs,

00:17:56 ◼   ► or a very, very, very popular third-party one

00:17:59 ◼   ► that effectively becomes the platform,

00:18:01 ◼   ► similar to how Rails kinda did that for Ruby.

00:18:03 ◼   ► Rails is not made by the guy who made Ruby,

00:18:05 ◼   ► but it basically became the de facto platform

00:18:10 ◼   ► for writing web apps using Ruby.

00:18:12 ◼   ► And so we need basically the Rails for Swift.

00:18:15 ◼   ► I have not been following that community at all,

00:18:18 ◼   ► so I don't know if that exists yet,

00:18:20 ◼   ► but it's probably too early in its lifetime and usage

00:18:25 ◼   ► to really have a clear winner there,

00:18:27 ◼   ► even if some appear to be front runners right now.

00:18:30 ◼   ► And when you're developing server apps

00:18:32 ◼   ► that support your iOS app,

00:18:33 ◼   ► and your heart's really in the iOS app,

00:18:35 ◼   ► and you're kinda doing the server apps

00:18:37 ◼   ► kinda the same way you do your taxes,

00:18:39 ◼   ► because you have to,

00:18:40 ◼   ► that's not a great reason to pick Swift for the server.

00:18:44 ◼   ► And I hope someday that it will be a more responsible

00:18:48 ◼   ► and boring and old choice, but we're not there yet.

00:18:51 ◼   ► - Yeah, and I think the reality too is

00:18:53 ◼   ► it's going to have to be better than everything else

00:18:56 ◼   ► that it currently exists.

00:18:58 ◼   ► Like, the problem that a new web platform has to overcome

00:19:03 ◼   ► gets harder and harder over time,

00:19:06 ◼   ► because there are so many very reliable,

00:19:09 ◼   ► well-trusted established players.

00:19:12 ◼   ► And so one day it may happen,

00:19:14 ◼   ► but it's going to have to be incredibly compelling

00:19:16 ◼   ► in the way that Rails was compelling to learn Ruby,

00:19:20 ◼   ► because it was a totally,

00:19:22 ◼   ► at the time it was a totally different

00:19:24 ◼   ► sort of paradigm for web development

00:19:26 ◼   ► that is superficially super powerful

00:19:29 ◼   ► and straightforward and simple.

00:19:31 ◼   ► And so that's what allowed it to overcome it.

00:19:33 ◼   ► And so I think something similarly would have to come along

00:19:37 ◼   ► that made it just that much more compelling.

00:19:39 ◼   ► - Yeah, and also with server-side languages,

00:19:41 ◼   ► the language is only one,

00:19:43 ◼   ► as I was saying earlier,

00:19:43 ◼   ► the language is only kind of one part

00:19:44 ◼   ► of why you want to use it.

00:19:45 ◼   ► There's all these built-in libraries and everything too.

00:19:48 ◼   ► There's also a third part of that,

00:19:49 ◼   ► which is how easy it is to administer and run servers

00:19:53 ◼   ► that use this language.

00:19:54 ◼   ► So that includes things like how easy is it to install it

00:19:56 ◼   ► from the most common Linux package managers?

00:20:00 ◼   ► Do you have to build it from source?

00:20:01 ◼   ► Do you have to update it frequently?

00:20:03 ◼   ► Can you use just apt-get or yum or something like that

00:20:06 ◼   ► to automatically install it with one line of code

00:20:09 ◼   ► in your config script,

00:20:09 ◼   ► and can you have it updated on a regular basis

00:20:12 ◼   ► and not break things?

00:20:13 ◼   ► Things like that.

00:20:14 ◼   ► And then when you're administering the servers,

00:20:16 ◼   ► are you getting woken up in the middle of the night

00:20:18 ◼   ► with pingdom alerts because the app server process crashed,

00:20:23 ◼   ► or it was leaking memory and it ran out of memory

00:20:26 ◼   ► and the whole server's now down,

00:20:27 ◼   ► or something like that?

00:20:28 ◼   ► Are you dealing with stuff like that on a regular basis?

00:20:31 ◼   ► Why bother doing that when you can use something,

00:20:36 ◼   ► like I use PHP,

00:20:37 ◼   ► and PHP, the server just doesn't crash.

00:20:40 ◼   ► That is never a problem I have,

00:20:44 ◼   ► and it hasn't been for a decade at least.

00:20:46 ◼   ► (laughs)

00:20:47 ◼   ► The web server just doesn't crash.

00:20:50 ◼   ► I have other problems,

00:20:50 ◼   ► things like, oh, there's a huge flood of traffic

00:20:53 ◼   ► and MySQL is starting to back up

00:20:55 ◼   ► and connection's starting to back up,

00:20:56 ◼   ► like that could be a problem.

00:20:57 ◼   ► But the actual server processes for the server language,

00:21:02 ◼   ► like if you choose an old boring thing,

00:21:04 ◼   ► there's problems you don't have to deal with.

00:21:07 ◼   ► Where any of the newer things, just by being newer,

00:21:10 ◼   ► you're gonna probably be dealing with things

00:21:12 ◼   ► like memory leaks and occasional crashes,

00:21:14 ◼   ► and that just adds to the burden of running your own servers.

00:21:18 ◼   ► A lot of the automatic, more abstract cloud platforms,

00:21:24 ◼   ► like various app engines and stuff like that,

00:21:27 ◼   ► the reason people go to those a lot of the times

00:21:30 ◼   ► is that they don't theoretically have to deal

00:21:32 ◼   ► with annoying little problems like that,

00:21:35 ◼   ► but that isn't the only option.

00:21:37 ◼   ► And going to a platform like that has a lot of downsides.

00:21:40 ◼   ► Number one, they're usually proprietary,

00:21:42 ◼   ► and so you can't move off of them if they start to suck.

00:21:44 ◼   ► And number two, they're usually way more expensive

00:21:46 ◼   ► for the computing resources that you're getting.

00:21:48 ◼   ► So if you can do something like Linode,

00:21:50 ◼   ► and I'm saying this because I do,

00:21:51 ◼   ► not because they sponsored this episode,

00:21:52 ◼   ► if you do something like Linode,

00:21:54 ◼   ► where it's just a Linux VPS, and if Linode starts to suck,

00:21:57 ◼   ► you can move to any other Linux VPS service.

00:22:00 ◼   ► It's fine.

00:22:01 ◼   ► You're doing something standard that you can put anywhere,

00:22:04 ◼   ► or you can move to dedicated servers,

00:22:05 ◼   ► or you can move to a Raspberry Pi in your basement.

00:22:07 ◼   ► It all works the same way

00:22:08 ◼   ► when you're on a regular Linux server.

00:22:11 ◼   ► And so anything you can do

00:22:13 ◼   ► when thinking about running servers for your business,

00:22:15 ◼   ► anything you can do to make it more likely

00:22:18 ◼   ► that you will stick with the regular Linux server path

00:22:22 ◼   ► instead of going to something weird and custom

00:22:23 ◼   ► that's gonna be more expensive and proprietary,

00:22:25 ◼   ► I think will serve you well long term.

00:22:27 ◼   ► So one little quick thing I wanted to hit

00:22:31 ◼   ► from Jacob Tomlinson, who asked about server stuff,

00:22:34 ◼   ► and asked, "How much server code

00:22:35 ◼   ► "do you write compared with app code?"

00:22:39 ◼   ► And this I thought was an interesting question to answer,

00:22:41 ◼   ► because just to give some idea

00:22:43 ◼   ► for people who were starting out, what to expect.

00:22:46 ◼   ► And the answer is, between app code and server code,

00:22:49 ◼   ► the answer really is it depends a whole lot on the app.

00:22:53 ◼   ► Instapaper really didn't have that much server-side code.

00:22:58 ◼   ► Overcast has more, but still not a ton.

00:23:02 ◼   ► Something like Tumblr had a ton,

00:23:04 ◼   ► because that was a way more complex web app

00:23:06 ◼   ► that happened to also have iOS APIs.

00:23:09 ◼   ► But if what you're mainly making,

00:23:11 ◼   ► like in the case of Overcast and Instapaper,

00:23:12 ◼   ► if what you're mainly making is an iOS app

00:23:16 ◼   ► that has a web service to do some auxiliary tasks for it,

00:23:21 ◼   ► the iOS app is probably gonna be way more code

00:23:25 ◼   ► than the web app.

00:23:26 ◼   ► But again, it depends so much on what you're doing.

00:23:29 ◼   ► I would say if your web app is that much code,

00:23:32 ◼   ► you're probably not listening to this show.

00:23:35 ◼   ► - Yeah, and I think too, something that I have found

00:23:39 ◼   ► really useful in my career of independent development

00:23:43 ◼   ► is the understanding that the more I can make

00:23:47 ◼   ► my client do, the more logic I can push down

00:23:51 ◼   ► into the client, the easier things like scaling

00:23:55 ◼   ► and navigating, the problems that you will hope to have

00:23:59 ◼   ► of having lots of users get, because you have a,

00:24:04 ◼   ► modern iPhone is incredibly capable

00:24:07 ◼   ► and can do a tremendous number of things.

00:24:09 ◼   ► And there is something that is just so nice about,

00:24:13 ◼   ► if you try as much as you can to not have huge reliance

00:24:18 ◼   ► on your web server, on your server,

00:24:20 ◼   ► and instead push that logic down into your client.

00:24:22 ◼   ► Say you get featured in the App Store,

00:24:24 ◼   ► and one day you have 10,000, sorry, sorry, sorry,

00:24:27 ◼   ► if you have 10 times more downloads than you normally do.

00:24:30 ◼   ► If you're very server-based, your best day

00:24:35 ◼   ► just might have become your worst day,

00:24:36 ◼   ► because now all of a sudden you have to make sure

00:24:39 ◼   ► that you're scaling all of your infrastructure

00:24:42 ◼   ► to manage that, and it may be a very bursty thing,

00:24:44 ◼   ► it may not be long-lived, and it's just becoming

00:24:47 ◼   ► really complicated, whereas if, for most of my applications,

00:24:51 ◼   ► they have no interaction with the server whatsoever,

00:24:54 ◼   ► and if they, the ones that do, they try to try

00:24:56 ◼   ► and minimize that as much as I can,

00:24:58 ◼   ► just because then I don't have to worry

00:25:02 ◼   ► about those problems, and I think in general,

00:25:04 ◼   ► from a broad business-y kind of perspective,

00:25:08 ◼   ► I find that to work well, that my,

00:25:11 ◼   ► if my user base scales, my costs don't scale up,

00:25:15 ◼   ► they are exactly the same no matter what,

00:25:18 ◼   ► I don't have, I don't need as much of the kind of

00:25:22 ◼   ► infrastructure-y kind of management,

00:25:24 ◼   ► in terms of theoretically, if your servers

00:25:29 ◼   ► are the absolute essential part of your business,

00:25:32 ◼   ► you're probably gonna wanna have not just you

00:25:34 ◼   ► being the person who's getting alerts when they go down,

00:25:36 ◼   ► you wanna have coverage for when you're out of town,

00:25:39 ◼   ► or when you're on vacation, and things start

00:25:41 ◼   ► to get much more complicated if that's where your goal is,

00:25:43 ◼   ► whereas if you can keep a lot of your code,

00:25:46 ◼   ► and your logic, and the value that you're providing

00:25:49 ◼   ► to your customer in your app, then you don't have

00:25:52 ◼   ► to worry about nearly as many of those problems,

00:25:54 ◼   ► and you can just take advantage of the fact

00:25:56 ◼   ► that everyone who downloads your app is running

00:25:58 ◼   ► a computer that is perfectly capable of doing

00:26:00 ◼   ► a tremendous amount of computation for them,

00:26:02 ◼   ► and so it's like, it scales so nicely in that way,

00:26:06 ◼   ► so that I would always kind of push,

00:26:08 ◼   ► whenever I have an idea, it's like, oh man,

00:26:10 ◼   ► that's gonna take a lot of, it could be very server-dependent

00:26:14 ◼   ► I become very cautious about if I should really

00:26:17 ◼   ► go down there, or if it's like, is there a way

00:26:18 ◼   ► that I can just do this client side?

00:26:21 ◼   ► And maybe it's like, I don't know if that's better or worse

00:26:24 ◼   ► for applications at large, but I can say for being

00:26:28 ◼   ► a one-man developer team, that is fantastic.

00:26:32 ◼   ► I can put all of my resources in one place,

00:26:34 ◼   ► there's less area for bugs, there's less maintenance

00:26:37 ◼   ► overhead that I have to manage, and it just works

00:26:40 ◼   ► really well to de-emphasize that down.

00:26:43 ◼   ► That you servers, they're a powerful thing

00:26:44 ◼   ► and allow applications that you couldn't build otherwise,

00:26:48 ◼   ► but the less I can do there, the better,

00:26:50 ◼   ► and trying to make my web services,

00:26:53 ◼   ► moving largely, they're just like, sort of dumb repositories

00:26:56 ◼   ► for data that just gets shuffled back and forth.

00:26:59 ◼   ► They're all, the actual logic and processing and things

00:27:01 ◼   ► is happening client side, and that makes

00:27:03 ◼   ► just everything better, I think.

00:27:06 ◼   ► - Although I will give one counterargument here,

00:27:08 ◼   ► is that if you are currently using,

00:27:11 ◼   ► if you're currently avoiding a feature,

00:27:13 ◼   ► or using some kind of external service to do things

00:27:17 ◼   ► that are very, very easy to do server side,

00:27:19 ◼   ► but you just don't wanna set up a server,

00:27:20 ◼   ► 'cause either you don't wanna manage it,

00:27:22 ◼   ► or you are inexperienced in that area,

00:27:24 ◼   ► and you don't know what you're doing,

00:27:25 ◼   ► and you're maybe a little intimidated by it,

00:27:26 ◼   ► or scared to do it, I would say two things.

00:27:28 ◼   ► Number one, running servers is easier

00:27:31 ◼   ► than you think it is.

00:27:32 ◼   ► It's like, if you can write an iOS app,

00:27:33 ◼   ► you can run servers, and it's really,

00:27:36 ◼   ► if you do it conservatively, and just use basic Linux stuff

00:27:39 ◼   ► and package stuff, it's super easy.

00:27:42 ◼   ► And B, things like setting push notifications.

00:27:46 ◼   ► There are certain things that apps need a lot,

00:27:49 ◼   ► or verifying in-app purchases, or verifying subscriptions,

00:27:52 ◼   ► stuff like that, very common things.

00:27:54 ◼   ► There are a million services out there

00:27:56 ◼   ► that are happy to take large amounts of your money

00:28:00 ◼   ► to take these problems away from you,

00:28:02 ◼   ► so you don't have to worry,

00:28:03 ◼   ► because they make it sound really hard.

00:28:05 ◼   ► Spoiler, it's not really hard to run services,

00:28:08 ◼   ► to do things like verify in-app purchases,

00:28:10 ◼   ► or send push notifications.

00:28:12 ◼   ► Those are extremely easy things to do.

00:28:14 ◼   ► You can do that on that $5 monthly node server.

00:28:17 ◼   ► And so, don't jump immediately to going

00:28:20 ◼   ► to other crazy enterprise-y services

00:28:22 ◼   ► when you don't have to.

00:28:23 ◼   ► Try it on the server side first.

00:28:25 ◼   ► It really isn't that big of a deal to do stuff like that,

00:28:27 ◼   ► and a lot of apps need things like that,

00:28:29 ◼   ► and your app can be way more powerful

00:28:33 ◼   ► with a little bit of server-side support.

00:28:35 ◼   ► So I encourage you, if you're intimidated,

00:28:37 ◼   ► or if you haven't done it yet,

00:28:39 ◼   ► learn the basics of it.

00:28:40 ◼   ► You'll be surprised how far you can get.

00:28:42 ◼   ► - Yeah, and I think the best advice for,

00:28:44 ◼   ► like the theme, I think, in all of our discussions

00:28:46 ◼   ► is just keep it as simple as you can,

00:28:48 ◼   ► and simple, thoughtful code will go a long way

00:28:51 ◼   ► with any of this stuff.

00:28:52 ◼   ► And that's, you know, don't be scared of it.

00:28:55 ◼   ► Just keep it simple, and you'll be fine.

00:28:57 ◼   ► - And keep your stack boring.

00:28:59 ◼   ► Thanks for listening, everybody,

00:29:00 ◼   ► and we'll talk to you next week.

00:29:02 ◼   ► - Bye.

00:29:03 ◼   ► [ Silence ]