Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I am Dave--having a little bit of a thought crisis--Rupert and with me is Chris--comfortable in the booth--Coyier.

Chris Coyier: Yeah, Chris--been there--Coyier. Yeah. Yeah, this should be good. We have some audience questions we'll get to, like we promised last week, some really nice thought here, I think. I think we'd like to kick it off just with what's hot on our minds at the moment. Dave is going to talk a little bit about spinning down some things, which is kind of a tough subject, isn't it?

Dave: Well, we were talking before the show. I have this thing, this little game, and it's relevant to the show because I made it for the show. We did a live show in Pittsburgh at Web Design Day, Val's thing.

Chris: Yeah.

Dave: Where we made T-shirts for Val. I made a game called "Global Defense." It's available at globaldefense.club. That's a premium domain name, $15. That's no $9 domain name.

[Laughter]

Dave: Come on, son.

Chris: Oh, my god.

Dave: Bought the domain name and I've been paying for it for the last four years or something like that. Then I finally realized. I was like, wait a minute. The domain just renewed, right? I just was like, "How much am I spending on this?" because I have it on Heroku because I need it on Heroku because it uses WebSockets for the multiplayer thing.

Chris: Right, WebSockets. Yeah.

Dave: To get WebSockets on Heroku, you've got to pay the whole $7. That's a $7 feature, so $7 a month, MBD, whatever.

Chris: Yeah.

Dave: But then $7 x 12 is $84 plus $15 = $99 a year.

Chris: [Groan]

Dave: I'm spending on this side project $99 a year.

Chris: Which may not get even a single request a day. There's probably not a little subcult of people playing "Global Defense".

Dave: Yeah.

Chris: Yeah.

Dave: No, no, there's not. Not whatsoever, and that's fair because I don't put that much time into it. [Laughter] I'm in this crisis or micro-crisis. There are big crises going on, but a micro-crisis because, what do you do with this? I have this going. I like the multiplayer thing. I don't think anyone depends on it, but do I just turn it off?

Chris: Hmm.

Dave: Then part of my brain is like, "Oh, I could just remove the expensive piece, the multiplayer, and it still would work and that would be fine."

Chris: Yeah. You could link it to a GitHub account or something and be like, "This is a game that used to exist. Here's the code."

Dave: Yeah. No, I could totally do that.

Chris: Still $15 a year. The number of domains you have is a little bit of technical debt for the pile. Does it feel better to you emotionally to just katana through this thing and just be like, "Good-bye," or are you okay with a reduction in the debt?

Dave: See, I maybe am. I don't know. What I've started doing is I think I want to move all my little side projects to subdomains on my site because that's free.

Chris: There you go.

Dave: Well, I mean, I pay for my site but I bought it for ten years or something. That's free, right? I can always have globaldefense.daverupert.com. I could totally do that and that's free. I'll chuck it up on Netlify. That's free. I could even do the WebSocket stuff through one of those WebSocket services. I forget their name right now. I could have all the features there. I'd just have to do a little bit of code to get there. Then the domain name would not resolve anywhere, right?

I don't know. I'm kind of in a mixed feeling. I think I could let the domain name go away. I don't need that but I do like the little game. I like the, "Hey, I made this piece of satisfaction." But this idea that it has to live forever on a domain name, I think I'm very okay getting rid of, but that's a tough thing, right? Your side projects, you're like, "Oh, it's got to have a domain name."

Chris: Yeah. Right. I like the subdomain thing too. I did that for CSS-Tricks for a couple of side projects and I absolutely don't regret it and would do it. But it depends on how serious you are about the project.

I think, in this case, it was like, let me demonstrate some technology. Let me play around. It'll be this fun little thing. If that's the aspirations for it forever, having that at your subdomain I think is cooler. I think it's kind of like, "Oh, Dave made this cool thing." It's kind of like you're getting some credit for it any time anybody goes there. I think that's cool.

But if your aspirations for this thing was like, "Maybe this thing will take off. Maybe I'll make features for this thing. Maybe I'll make some kind of premium features," you have this grow-grow-grow-grow thing, which I think is fun too. I get satisfaction out of life doing that type of work. I think that's awesome. That can't be a subdomain of Dave Rupert. You know?

Dave: Right.

Chris: But how do you know that and is it possible to shift between those two modes? Should it have started as a subdomain or are you comfortable with the idea that you bought a domain for it to begin with? What was your brain process on day one?

06:01

Dave: I think my day one process was like, "Oh, a domain name is better than my happyshark.heroku.com or whatever.

Chris: Ah, yeah.

Dave: You know the bad slug. I could have done globaldefense.herokuapp or whatever, but yeah. I'm not attached but I just bought the domain name because I was like, "Whatever. That'll be the easiest way to, like, 'Hey, go check this out,' or 'Everyone, log on at this URL.'" You know? That was the easiest way. But I'm not attached to that.

Chris: But you didn't even think of it, the subdomain. On day one, it was kind of like, meh. It didn't even come up.

Dave: I think it was just, do domain names. But that's probably just like culture, you know?

Chris: Right.

Dave: Like, "Oh, I've got an idea for a side project. I'll buy the domain name first."

Chris: Okay. I see where you're going. It's the new ShopTalk Show mantra. "Subdomains are cool. ShopTalk Show thinks subdomains are underused. Please use more subdomains. They're cooler than you think."

MANTRA: Just Build Subdomains!

[Laughter]

Chris: Even better. I tried to say it in 50 words and Dave gets it in three.

Dave: Well, I just re-appropriated our previous mantra, which is, "Just Build Websites!"

Nah, so I don't know. This is just this small, micro-crisis, but I'm also thinking when I do this in the future, do you do--in any of your projects or side projects--kind of like intelligent feature flagging and stuff like that? If I had feature flagged it, I could just turn off WebSockets and multiplayer on one feature. That would be an if statement, but I could have done that but I didn't. That's where I'm slightly remorseful, but maybe that would just be way too much overhead for a side project.

Chris: I mean it depends. I think if you think in feature flags from day one, it's not that much debt, really. But then to just neuter the game by turning off a flag with a goal that that saves you $7, that seems like a weird architectural choice too.

Dave: I've spent whatever, $400 on this game--

Chris: Yeah.

Dave: --over the last four years, and that sounds even worse. You know what I mean?

Chris: It does.

Dave: I mean it's nothing compared to my gym subscription that I don't use. [Laughter]

Chris: Mm-hmm. To me, I'm like katana style. If I have something like this and it has entered my brain that I would like to remove this debt from my life, both technical and financial, I can't just neuter it, usually. It's got to go. Just gone.

Dave: It's like unpublished. Your publish impulse and you're unpublish impulse are connected.

Chris: Equally strong, yeah.

Dave: Equally strong. Holy moly.

Chris: [Laughter]

Dave: Wow.

Chris: Well, I don't know because it's such a -- I don't know. I don't know. It contributes to embarrassment too. I think if it's just sitting there on GitHub, you get points for that. That's anti-embarrassment points. It's proof that you did something cool whereas if you have a half-broken or not functional thing and whatever that's just kind of sitting there, that's negative points. You're like, "I don't work on this but I still am pretending like it's a thing." I almost think the sunset of it feels better but only if the sunsetting of it becomes zero. It's just like a blog post that just sits there forever and requires no maintenance or cost ever. Yeah, something that costs money like that has kind of got to be sliced away.

I went through a phase in my life like this where I had too many projects and I had to step away from them. I remember getting pushback from people I worked on with those projects. I was like, "Whoa, dude. You don't need to be this official about it. You don't have to be like, 'I am leaving this project. I am announcing it to you.'" Just don't work on it then. I don't care.

But then I had to re-explain it. I was like, "No, no, no. Sorry, it has to be emotional like this, but I just need to declare it."

Dave: Yeah.

Chris: So that it feels done, like a finished chapter and I can free up that mental space. It was just important to me to handle it that way.

Dave: No, I think there's value. Your kind of ceremony for turning off a project, a side project is the good-bye blog post or the postmortem.

Chris: It would totally depend on what it is, but yeah. I mean maybe.

Dave: Say like your power of serverless.

Chris: Right.

Dave: Let's say that's on the chopping block or something. I still find it useful, but--

Chris: Yeah, that's not quite there, but it probably won't last forever. I don't know. That's a really good example, especially because, this morning, I spun up my CSS-Tricks dev environment because I had a few little minor, like a bug to fix, and I had a new thing I wanted to build. But I had a little list, too. I was like, you know those things, the way that you get to that site, because that's always a struggle too, like, how do you get people to these projects too, you know?

Dave: Yeah.

Chris: The eternal problem. In the current design, as I speak right now, if you scroll all the way to the bottom of CSS-Tricks, there is almost like a footer and then a post-footer and then a double-double-triple footer and the quadruple footer.

Dave: Yes. Yes.

Chris: Okay. That's become a little junk drawer. It was kind of embraced for a little while.

Dave: The triple-decker-doo.

Chris: Yeah. [Laughter]

Dave: Triple-decker.

Chris: Because sometimes it's kind of fun, you know, like you get down there and you're like, I don't know. I'm all the way down here. I might as well explore a little bit. It's not like it costs me anything. It's not like I'm paying by the square foot in my footer. Go big. Who cares?

Then sometimes I have the exact opposite opinion. Just this week on CSS-Tricks, I killed a whole footer section. We had this bar of stuff out there and it was kind of a drunk drawer. It was like, "The CodePen Radio Podcast is cool!" We were like, "Here are the latest three jobs on the job board!" and "Pro is cool!"

It was just like these modules. Now that I look at it, they were just junk. They complicated the page in a not that useful way. I just removed that bar. Now I'm the "remove the bar" mode. At the way bottom of CSS-Tricks, there are two boxes. One of them says, "Go to our conference's website and go to their serverless website."

Well, the conference's website, not very hot in the conference space right now. Maybe once that world opens up, I'll spin it up.

Dave: The world is a little icy. Yeah.

Chris: I'll just remove it. I'm not going to spin down the site but I'll remove the big link to it. The serverless site too is, you know, it's in the mode right now where it gets a pull request a week, maybe, which is still cool. It's not like it's going away but I'll probably just kill that too, the link in the footer. It just cleans up the page a little bit and whatever. I'm not going to exactly spin it down. I'd spin it down when it's truly out of date. It's like, now the world has moved on from these things.

At that day, I can't tell you right now what I'll do. I don't know exactly. You know?

Dave: You don't have a standard procedure.

Chris: No, not really.

Dave: I think it's available at a subdomain, serverless.css-tricks, or something.

Chris: Yeah.

Dave: Right?

Chris: Maybe a splash page that says, "Hey, this hasn't seen attention in a long time but click here and you can view the site," or something.

Dave: View the archive. Yeah, go to the archive.

Chris: Sometimes it's different. Here are two other little stories. Yeah, the GitHub will there forever because I don't think there's any cost to leaving things on GitHub except for that, if this was -- this is a whole other conversation, which you should get to, like the idea of sunsetting a project on GitHub is a whole interesting thing.

Dave: I've got a few jQuery plugins. [Laughter] I'm very curious.

Chris: Well, isn't there a button you can click now on GitHub that says, "I don't take issues on this thing anymore," so you just can't even leave an issue?

Dave: Yeah. I think you can do that. Yeah. Then there's -- yeah.

Chris: That speaks volumes.

Dave: You can even archive it, like, officially.

Chris: Oh, right. Yeah, I've seen that.

Dave: It's just like read-only at some point.

Chris: See, that's good. Thank you, GitHub. Those are good features. That's an important thing but it's still there, like the URL is still there. People can still look at the code. That seems totally like a nice death for a project.

Dave: You'd think--I've done a lot of side projects--I would have a standard operating procedure, but I think it's really just atrophy on the vine. It's just death by atrophy. That's sort of how I unmanage projects, sadly.

Chris: No. Everybody does. That's part of the stage. It's like the stages. It's almost like you should leave it there for a while. You have to go through that little stage to kind of prove it. It's kind of like -- I don't know. What was that book with Zaphod Beeblebrox? Hitchhiker's Guide to the Galaxy?

Dave: Oh, Hitchhiker's Guide. Yeah.

Chris: Remember? They come and bulldoze Earth or whatever?

Dave: They give you a 30-day notice or something.

Chris: The notice was posted on some other planet that humans can't even get to, or whatever. [Laughter] I don't know why I thought of that.

Dave: [Laughter] That's a good opensource analogy, yeah.

Chris: It's kind of like you posted….

Dave: You posted it on our wiki, our internal wiki.

[Laughter]

Chris: Awaiting comments, 30 days. You have to say, like, what if something significant happens during that time of atrophy? I don't know. You can't skip the atrophy. [Laughter]

Dave: Well, you know, and then I have all this, like, remorse for URL permanence, you know. I can hear Jeremy Keith just being mad at me. Then talks or something where I referenced the URL, that might be out of date, or books because everyone is writing about my little game I made, you know. Everyone is doing that, you know. All these URLs, but I guess I could, in that atrophy phase, I could set up a 301 to my site that eventually Google will pick up on, so all the Google Guice will redirect to my site at some point but that's a lot of work. That a lot of--

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by ACF, that's Advanced Custom Fields, advancedcustomfields.com. Nice URL. It's a plugin for WordPress. You've probably heard of it if you use WordPress that much because it's kind of like the quintessential WordPress plugin. So many sites use it because it's the thing that unlocks WordPress, to me, really feeling like a CMS. It's like you deciding, okay, on this post type I want--

This is how we use it on ShopTalk Show. The title of the show, fine, but I don't really need the description field because we're going to have all this other stuff. We're going to have running time and the MP3 URL and the links for the timestamps of the stuff that happens in the show and the transcript and the guest, but the guest is going to be a repeater field because there can be multiple guests, and a sponsor. The sponsor is going to be a repeater field because there are multiple sponsors. Then it's nested so the sponsor has a URL, a title, and a description. The description is in Markdown.

You're making these decisions based on the data needs of your site but you don't have to be a data scientist to do it. You're kind of like, this is a beautiful UI. You're like, "Yeah, I need this kind of field and this kind of field." It's almost like a form builder but you're not building a form, necessarily. You kind of are, I guess. That's how it turns into, but you're designing the CMS for you.

Now, fine. Now, the block editor comes along in WordPress land. They're like, it's this whole other way of building content and blocks kind of like have data too. They can have their own kind of metadata associated with them. Is it lights out for ACF? Heck no because they answer it with ACF blocks, which work in the Gutenberg world and they unlock developing for Gutenberg or the block editor in a way that, to me, feels somewhat more comfortable.

I've built traditional blocks as well. The ACF blocks are just way easier to build. I'm telling you, totally easier. You just do it with kind of traditional PHP development and particularly in a way that feels really natural with the way that you program for ACF anyway. But now you're building these custom blocks and the way that they look and behave in the editor is really good. I'm using them in production on the CodePen site for stuff. It's really a nice approach.

High five, ACF. Thanks for being a sponsor.

[Banjo music stops]

Chris: So, there are two conflicting other spin-downs I've done recently. One of them was this year. There were forums on CSS-Tricks, which has been a fascinating journey. It was like PHPBB in the early days. Then I ported it to some other thing that was hot for a minute but then atrophied and wasn't developed on. Somehow, miraculously, have saved the content through all these transitions, ported it over to bbPress, and that was the final nice transition for me because it brought it inhouse into the WordPress world in which I live in already. I did that same thing with e-commerce at some point. It was nice to move things. One, there's this arm-stretching movement of technical freedom when you've gotten rid of some old technology and you've moved it. Even though the stuff is still there, it's in a familiar place that you feel like you have more control and all that.

I loved moving to bbPress. That was a nice move for the forums and it felt strong for a while. Up until the day they died and, by died, I mean I literally turned them off, there was usage of them so it was kind of a painful one. It wasn't zero page views or anything. There were still a handful of people in there but the problem to me was that it was nobody on our team's responsibility in there, so it was kind of like "the parents are away" forums.

Nobody is watching for tone. Nobody is yelling at people being jerks. Nobody is watching for racism or whatever. There is just no parent to these forums, including me, which the buck has to stop with me. That's terrible that I have this public forum on my site. I would once in a while, but just not regularly. I think, if you have a community forum, I think a daily scrubbing is the minimum that you should be doing it.

Dave: Oh, yeah. Yeah, I think the Internet is way too laissez-faire about it. You need moderators. You need shadowbans.

Chris: Yeah.

Dave: You need all these tools.

Chris: Yeah. The online community is no joke - no joke. Blocking and stuff. Even the technology of it wasn't that exciting. It was kind of like, did people care about forums anymore? Obviously, usage had dropped way off because people think of Twitter in that way now or there's other technology or whatever. It just didn't feel good to me anymore and it didn't feel good to me for lots of years. Then spam started getting worse. I was like, spam is something that can't be ignored. Bad community stuff is even worse than spam, but there wasn't a lot of that. It's not like there were people I had to ban and terrible behavior.

Dave: But that all contributes to the signal versus noise problem, right?

Chris: Right. More noise.

Dave: Spam and violence are both noise.

Chris: Yeah. But I can control this. Fortunately, it was a thing where the spinning of it down wasn't that hard. I could kind of go in and flip a couple of switches and just say that new posts are not accepted. I changed the design of the post a little bit. I removed stuff like posting rules and the login thing and stuff like that and then put a banner across the top of it that just says, "These forums ran for these years to these years. They have spun down now. Thanks for all the fish," or whatever, to tie it back to Douglas Adams again. That was easy to do and I can be responsible with the URL, so Jeremy Keith doesn't have to be mad at me. The technology of it is spun down but the URLs live on.

Dave: It's just a non-active state. All the URLs, all the bbPress links would still be active.

Chris: Right.

Dave: Okay.

Chris: But it does mean that, like, "Hey, Chris. Why don't you move to JAMstack?"

Dave: Well--

Chris: There's, like--I don't know--hundreds of thousands of URLs in there. That's not happening.

Dave: Yeah.

Chris: It's not the only reason. There are a million reasons, but that's one of them. Forums aren't good, generally. I'm sure someone will prove me wrong, eventually, because forums can have data in a database and it's not like every single page of a JAMstack site has to be prebuilt. But there is not a great JAMstack solution for forums yet - not really.

Dave: Oh, somebody, get on that.

Chris: Yeah.

Dave: JAM Forum.

Chris: That's an example of spinning something down in a way that kind of felt okay. I'll tell you; I feel good about the decision. I'm sorry to anybody that didn't like that or preferred or put a lot effort over the years. Your work is still there. It was too much for me. We're not a big team.

The value proposition in forums is very low. I don't think you can get the page views and advertising stuff right, generally, on forums to make money. I think forums need to be in support of something else that makes money. The support wasn't there. The business metrics of these forums were just not there and it feels good to turn it off.

Here's a worse story, though. Not worse, but just--I don't know--interesting. There's this thing called Spectrum, spectrum.chat. Have you ever seen that?

Dave: Oh, yeah. Yeah.

Chris: This is this spin-up a community easily kind of thing. Ultimately, GitHub bought them. The thinking is, "Oh, maybe there'll be a Spectrum community per repo or who knows, you know." I think just nothing happened with it after they were bought. It was always a little janky and I feel like it's gotten jankier and GitHub is certainly not doing anything with it. It felt like, "Oh, wow. That sucks." You know?

We used it at CodePen. We were compelled. We would love to have more community, have a community platform, have a place for people to show off, ask questions, all that kind of stuff, in a way that we haven't been able to hit on, on CodePen itself. But it just didn't take off. There was some action there but not very much. Then the spam started to come. Part of the idea with Spectrum is, in their early text, they were kind of like, "We'll moderate for you," like "We're going to stop the spam. We're going to stop the bad behavior," so that we don't have to essentially hire an employee to be the platform manager, and with zero technical debt. None at all. You just spin it up.

Dave: Yeah.

Chris: If everybody is over there, if this is the beginning of this little phenomenon, which it was for a minute and it has died down, that maybe we'll be early adopters of this thing and be in a good spot. It did not pan out that way and it became this daily, you know, Marie and I both would have to hop over to Spectrum pretty much every day, at least once a day if not many times a day, just to make sure it's okay. I feel like the CodePen brand is even more important to me than the CSS-Tricks brand. We have to be really careful about the community that's happening and building there. At some point, I was like, "We're spending time here and there's no value."

Dave: Right.

Chris: We've got to spin it down and the way that you spin it down is you just turn it off and it's just gone. Any URL to it, you can redirect to one URL, but all that content that people built over there is gone.

Dave: Ooph. Well--

Chris: Just instantly.

Dave: That's hard stuff, right? That's where good and bad deprecations happen, not that everything has to be a good one. I don't want to require somebody to be like, "Think about how this is going to die one day," you know. Yeah, that's too bad but I definitely understand. How do you focus on this thing? I'm having the same problem with side projects. I don't have time even to focus on this little app about shooting down asteroids. I just don't have time for it. Should I just spin it down and stop it or archive it, delete it, or what?

Chris: Have you decided?

Dave: I think I'm going to do the subdomain thing. I think, in general, Dave Rupert as a brand wants to -- we were kind of talking about that. What's it for your brand? Not like I think of Dave Rupert as a brand all the time, but I just like this idea of subdomains and I really want to lean into it.

Instead of being the, "Oh, mister, I buy a domain for every bad idea I have," I want to just start doing subdomains. That's my new plan forward. Decrease my domain bill by a few hundred bucks a year. [Laughter]

Chris: Yeah. Cool. Well, you'll have to let us know. I'd like to hear other people's story, too, about spinning down things. There are so many ways to do it. What feels responsible? What doesn't feel responsible? What feels good? What feels bad?

Dave: Yeah, I would love--

Chris: And what level of responsibility do you have?

Dave: Yeah, I would read a blog post or even like a chart. Give me a chart like the three pathways, like what you do about users, what you do about old content, URLs, so the nuke it option. We just came up three options: subdomain it option, the nuke it option, the archive only option. Those would be kind of interesting spin-down paths you could explore. Then think about how that affects users and the community or those could be the same thing or URLs, permanence, stuff like that.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Netlify, you know the hostess with the mostess. This is a little feature of Netlify that they've had forever. In fact, I'm looking at a blog post from 2015, explaining how they do this and I love it.

Chris Bach wrote that instant cache invalidation is definitely part of Netlify's rocketjuice. I couldn't agree more. This isn't a feature that's fresh off the rack here but it's one of the most important ones.

I love it because I barely ever even think about it. If you have a site hosted on Netlify--I have a whole bunch of them--and you change some CSS, you don't have to worry about what you're naming that CSS, how you link it up, and how it's deployed and all that. When you deploy it in Netlify, if that file has changed, the cache is invalidated and the new CSS will be there. You don't have to worry about your own fingerprinting of it or pending query string in your build process or anything like that. You just link to the CSS file. You change the CSS. You deploy it and it's been changed on the CDN. That's amazing because it's so hard on every one of the other sites I work on. Not that it's hard. It's like a chunk of technical debt that I don't relish. It's not important. For example, on CSS-Tricks. Even in the ShopTalk Show's, it's a WordPress site and we're not building it heedlessly. It's just kind of delivered that way so it's not on Netlify. You know, maybe someday we'll get there.

I have a build process so that we can write in a CSS or whatever and it processes the CSS, makes a CSS file, and then when we link to it I have to link to it with a unique query parameter that changes when the file changes so that when we deploy, when the CSS is linked up, it knows if it's a different version of that asset or not. I had to write that code to make that work. It's not a ton of code, but it's something I have to think about and maintain and make sure it's part of the build process. It's just one way.

There are all kinds of different ways to deal with cache and validation of an asset. There'd be JavaScript files too, images, and all that. But it's like BYO, you know. That's a bummer, to me.

On Netlify, you don't even think about it. You change some assets, you ship it, and it's done for you. They've been doing that for half a decade. Good job, Netlify. Thanks for your sponsorship.

[Banjo music stops]

Dave: Hey. We said we would do questions last week, so we should get into some questions.

Chris: Yeah, let's do a couple of them, for sure. I like this one by David Fitzgibbon.

David Fitzgibbon: Hi, guys. I was wondering how you might deal with trying to educate colleagues across teams. We have a back-end team and a front-end team. The back-end team calls all the shots on the API structure.

Their experience is very Java-based and their knowledge and experience with the front-end is limited. It pretty much stops at HTML and CSS. They see jQuery as the new hotness. Deploys are still done with FTP. While all this doesn't limit the front-end team from using our modern framework of choice, we can work with all deploy processes as well. The real issue is their understanding of how APIs are used in a modern framework.

Where we hit trouble is when we want to do things dynamically. The APIs we have access to are based on templates rather than data structures. As a template changes, the data no longer matches that template, so we have to reach for other APIs to try and get any new data into a template.

For example, if we want to user's name and their address, we might have to load an API based on a user being logged in to get the name and one based on billing for the address. Now, imagine we want a page where the user can change their settings, their personal preferences, and things like that. We now need to load maybe 10 to 20 APIs to get all that data, which is killing performance not only because of all the requests but because some of those APIs are returning lots of data we don't need.

With the two teams, we're kind of at a stalemate. They believe that they're doing things perfectly well because their APIs are returning very quickly or their stats show that, when a request is made, the API returns fine and that we're at fault on the front-end team because we're just using too much JavaScript, too much of this new fanciness. We tried to explain that the amount of time we have to wait for all of these APIs is part of the issue. But their belief, again, is just that we're typical developers looking to play with new technology.

My question is, how can we try and educate the backend team? How can we bring them along with us? There's very little crossover between the two teams. We don't really work side-by-side. Yeah, just wondering if you might have any tips on how we might communicate with them and maybe start to make a change. Thanks.

Dave: Yeah. This is a tough question. I know I've had this experience while on a Java project before. It just was like, "Hey, we want to get pricing." They're like, "Oh, well, that's a couple computers away." [Laughter] That's like an API call to an API call to an API call. You're just like, "Okay, wow. All right. Let's see how we do this," you know.

Unfortunately, yeah, those kind of technical debt choices do pile up. I know Java is pretty old. I'm not poo-pooing system choices or anything, but Java tends to be pretty old. Then there was kind of a heyday of Java where XML would power the HTML because, like what's the difference? You know? There's just kind of a big tie together. It's all kind of coupled pretty hard, like the templating in the Java and stuff like that.

Sometimes, the API change is really just XML spitting our JSON so then you have to hard code that JSON to spit out and stuff like that. There's no JSON response object. You'd have to code that in, so that's tough.

I think the way we kind of handled it, we kind of figured it out. It was a hard process, but you just kind of have to keep working on your API. If you can version the API and have V1, V2, V5, or whatever, that makes a big difference so that no one's cheese gets moved and people on the old stuff can still use the old stuff.

Chris: Yeah. Right.

Dave: I think, unfortunately, you're probably in that situation.

Chris: To me, it seems like there's some poking across the aisle already. You were saying they are a little behind on their knowledge, so you're poking at them, which is kind of fine and understandable, but it doesn't seem like there are heaping piles of empathy happening here. You know what I mean? I'd be careful with that. They don't sound like your friends and you might want to start treating them like your friends, in a way, to make stuff happen.

Dave: Yeah. Instead of anonymity, more positivity.

Chris: It sounds like you're describing the use case for GraphQL. I assume that's the answer that you wanted here is that you don't have access to the right data and stuff. Then Dave is like, well, maybe versions. All that stuff leads right to the GraphQL case. Just get some GraphQL in front of that stuff. Have the data be whatever you want the data to be. It seems like that could be a way to go for you. In fact, I don't see any reason it wouldn't be. I don't see any particular downsides here, without knowing your stack, but it seems like if you want freedom as front-end and they kind of are sick of being bugged about API stuff that this is going to solve a lot of problems for you.

Dave: Well, and that could be it too. It would be an interface they could put on top of it and that's a very Java word, like an interface. You're just saying, "I need another way to get data," and this GraphQL stuff can kind of layer in. It can kind of be a separate thing. Again, back to turning features on and off, that could be something.

I don't think it has to crush their work, I guess is what I'm saying. It'll be more work for them to implement because they control all the back-end computers but, yeah, GraphQL would be a great kind of solve. This is why Facebook made it, right?

Chris: Right. It doesn't mean like, "Oh, we have to turn off our Rest APIs." It's almost like, no, this middle layer. Your GraphQL is built from the Rest APIs you've already built.

Dave: Yeah.

Chris: It's like a new technology you're layering on, not ripping out something old and adding in something new.

Dave: I have heard some stories that GraphQL is pretty bad for performance. [Laughter] Again, not to poo-poo technology choices, but I think the idea is it's very easy to make an O-N-squared query.

Chris: Yeah. Sure.

Dave: Where you're, "Give me all the users and, for every director--" or "Give me all the movies and all the directors. For every director, give me their siblings or their children."

Chris: Yeah. But then it's like a different problem. The back-end people then can focus on that problem.

Dave: Mm-hmm.

Chris: It's kind of like keeping their expertise in place. It's a good point, though. But if you're saying, we've got to make 10 to 20 API calls from the front-end, from the data that you want, well, if it's one GraphQL call and then it happens to spread out a little bit and it has to make 10 to 20 API calls on the back-end, at least it's happening on the server. Your super-fast server is making those API calls and the front-end is making one API call, so you're putting that server load, network request stuff in a better place.

Dave: Yeah. Definitely because, I mean 20 APIs calls -- let's do ten because it's a round number. On 3G, that's about 400 milliseconds per call. You've added four seconds of load time just for getting data. That does have monetary issues. If you could half that, that would be awesome.

Chris: That's too many API calls on the front-end - too many. I don't know what the right number is, but it's under ten.

Dave: Never more than three. It's three.

Chris: Yeah, it's three. Yeah, that's a good number.

Dave: It's three. Always three.

Chris: Yeah.

Dave: Yeah.

Chris: Because it's not one either. That's not right either because sometimes--I don't know--intelligent stuff has to happen. You could make one API request because you know it's fast and then it'll get the data. You can render some stuff and some of it can be deferred a little bit. It doesn't have to be one but it can't be ten.

Dave: I think it's like user and content would be your top two on most.

Chris: Sure.

Dave: Like any user data and that's often cached.

Chris: Yeah. Well, that's pretty rad. Let's see if we can do a super quickie here. None of these are quickies, so let's just do to the top one. Steve Polito writes in, "I'm a sucker for old tech."

Dave: Hey, Steve.

Chris: "It's stable, reliable, battle-worn, tested, well documented. Specifically, I reach for Jekyll, WordPress, Rails, whatever, on any greenfield project. I always reach for Bootstrap for the front-end. I feel like I can accomplish anything with these technologies.

"However, I'd be naive to think that these will last forever. My problem is that I don't want to reach for something new when I know I can use battle-tested tech that I know will work. Have you ever dealt with trying to break away from the tech you're comfortable with in favor of something more modern?"

Steve, you're just -- you're good. You're good. You're in a good place. You're reaching for tech that you know you can get stuff done and kind of thinking about it and thinking about your decision-making. That's just a healthy place to be, I think.

Dave: Yeah. Can you break away from Jekyll, WordPress, Rails, and use RedwoodJS? Oh, yeah, you can. You're not going to be productive for a long little while.

[Laughter]

Dave: I mean because the paradigm is very different. That said, there is a lot of value in spinning up little projects in these little languages.

Chris: You need to be able to point at something that you're going to get for doing it. Even if you're like, "Oh, this is going to suck." I'm going to make an app. Well, what should I use? I'll just make a Web app. K

I can look at the audience and be like, "Would it be obviously better if I could ship an iOS app, an Android app, a Windows app, a Mac app, and all that stuff?" If the answer is super obviously yes, maybe Flutter you should look at. Maybe that's the thing.

Am I going to be productive in Flutter right away? No. Absolutely not. But at least I can point to the benefit.

Whereas, if you're like, "I'm going to spin up this thing that I'd use WordPress for with Redwood," that's cool. Can you point to why? If you can't, then why? I think people are using Redwood because they know why. They know they want to work in that world. If you don't know why, then don't do it.

Dave: That's an excellent point. The thing I always come down to, if it doesn't make instant sense to you, it's probably not for you. It wasn't designed for you, in a way, so I wouldn't do it.

That said, don't be somebody who just eats McDonald's every day of your life. You know what I mean? Get out there. Try new things. Try new foods because it might taste good. That's a Daniel Tiger's thing. You've got to try new things because it might taste good.

Use Redwood. Play with React. Then leave all those and use Vue [laughter] because it's the best. There are a lot of things out there that might wet your whistle, if you will.

I've been using Vue and Nuxt and having a lot of success. I come from a very WordPress, Rails, Jekyll. I come from that stack and I'm loving Vue and Nuxt and having a great time in that stack whenever I get to work on it. I kind of--whatever--put my foot in the door and say, "We're using this," and it works.

Chris: [Laughter] That's nice. Just to wrap it up with Daniel Tiger, we could be like, "Do you know what it is? You might feel better." He says, "You know, if you can see what it is, you might feel better. See what it is. You might feel better."

It's about being scared about being in the dark. Then you shine your flashlight on it and see that the monster is actually just a blanket draped over your fan. You feel a lot better.

Dave: Aah! See. Man, we should do a Daniel Tiger for Web developers coffee table book. That's my new book coming out on A Book Apart. [Laughter]

Chris: It's definitely confirmed, I've heard.

Dave: Yep. Yep. So, there. All right.

Chris: All right. See ya later.

Dave: Well, on that, we should wrap it up. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

Of course, if you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you. Maybe like this company.

Chris, do you got anything else you'd like to say?

Chris: ShopTalkShow.com.