Transcript

Gina Trapani: Muster my energy here.

Chris LoSacco: (Chanting) Post-light! Post-light!

Gina: (Chanting) Post-light! Post-light! Let’s do this!

[POSTLIGHT INTRO MUSIC]

Gina: Hi, everyone! Welcome to the Postlight podcast. I’m Gina Trapani, I am the CEO of Postlight, and as always I’m joined by my partner in this business, the president of Postlight, Chris LoSacco. Hey Chris.

Chris: Hey, Gina. It’s wonderful to see you.

Gina: Good to see you too. Is it too late to say happy new year?

Chris: Yes.

Gina: Yeah, we’re mid-January recording this, it’s going to come out late January, what’s your…

Chris: I mean, that’s way too late. I feel like it’s first week of January, and then you’re done. You get, like, two days.

Gina: (Laughing) First week of January always? 

Chris: Yeah.

Gina: I… whenever I send that email to that person I haven’t spoken to since, like, well before the holidays last year, I always wanna type “Happy new year.” And then I’m like, it’s January 13th! That’s… is this weird?

Chris: You gotta let it go.

Gina: (Laughs) Gotta let it go? 

Chris: In my opinion it’s weird. 

Gina: Okay! I like being opinionated. It’s…

Chris: I’m just saying, time moves on.

Gina: (Laughing) Time moves on. It’s not new anymore.

Chris: (Laughs) It’s not new anymore. We’re just in the year.

Gina: We’re just in the year.

Chris: You can say happy year.

Gina: Happy year. It’s 2023. First episode with the two of us in 2023.

Chris: That’s right.

Gina: Good to see you.

Chris: Good to see you too. I wanna… here’s what I think we should talk about today. We have been having a lot of conversations, you and me, and internally at Postlight, about how we help our clients do better, especially when they are in environments that are less than ideal. And one of the ways an environment can be less than ideal is when you get saddled with a bunch of legacy technology on the backend. How many times have we been in a situation where we designed a brand-new, really great customer-facing experience, and we get told early on in a design review or in a planning session, “I’m really sorry, but we can’t do that. The backend doesn’t support it.”

Gina: This happens a lot, right? ‘Cause…

Chris: It happens a lot!

Gina: People come in, they’re like, “We need to modern… we need a better experience, our competitors are killing us, people hate using this platform, it just needs to be easy to use,” right? And easy to use, in a modern, you know, web or app world, means that the experience is alive, it’s interactive. Data gets filled in quickly, and it’s responsive, and all of the goodness, right, that we’ve come to expect in 2023 from our apps, right?

Chris: (Laughing) Yeah.

Gina: But that front of the house requires the backend to, you know, enable that.

Chris: Yes. 

Gina: But we often get brought in to do the front of the house and then the back of the house is like “No no, we can’t serve that food.” (Laughs)

Chris: Right.

Gina: “We don’t have that.”

Chris: And it’s completely backwards. The backend exists to enable what the experiences are that we want on the frontend. What the users and the customers and the clients are actually seeing and touching and experiencing. And if we don’t prioritize those things, and make sure that whatever’s happening on the server side and in the database to enable those is catching up to the experiences that we want to enable, we’ve got our priorities wrong. And we’re thinking about it the wrong way. And it is so frustrating… I mean, certainly, to us it’s so frustrating, but I think to a lot of teams out there it’s really frustrating, when it’s like “We know we could do it better but we can’t, for X Y or Z reason.” And I think we should talk about how to get around that, because the conversation should not stop there. That is not enough of an excuse, you know? So, I think the relationship between the great frontend experience and a powerful backend technology is similar to how Apple redefined the relationship between hardware and software. Because what Apple really introduced was that great hardware and great software have to work together. There is a symbiotic relationship where, if you’ve got great hardware with subpar software, the experience is going to feel bad. Even if the physical device feels really good in your hand, and the buttons are good, and, you know, you’ve enabled or you’ve designed the right kind of, sort of, physical experience that you want people to have, if the software is not lighting up that experience… like, say hypothetically the keyboard in iOS was really glitchy and slow. The whole thing wouldn’t feel right! 

Gina: Ugh. The whole thing falls apart. Yep.

Chris: The whole thing falls apart, right? And the opposite is also true. If you’ve got really amazing software and you put it on subpar hardware, whether it’s slow or it’s, you know, it’s not optimizing for the right things and animations don’t work and scrolling feels awkward, and these sort of basic things that the hardware is gonna enable, that doesn’t feel good. And so you need to think about these things in concert with each other. 

Gina: Right.

Chris: Now, they can evolve independently, and they should, and we’ll talk about that. But this idea that you have to think about the holistic marriage between the two is really, really important. And I think Apple really showed us, when it’s done well, how incredible it can be, and so many companies don’t think of it that way. They think of it like, “Well, we’re just going to… you know, we have the back end we have, and it was built 25 years ago, and it’s been battle-tested, and it would take a lot to change, and so we’re just going to continue to push out experiences that we’re not super happy with because we don’t want to address the underlying concerns.”

Gina: The fact that Apple coupled hardware and software so closely together… it’s a really great point that you’re making. And it’s funny, because, you know, like on the Android side, part of the reason that Android wasn’t quite as good at experience was that the hardware market was so much more open, and there were all these different handsets, and the software didn’t always sing on those handsets, right? It’s why I almost exclusively bought Google Android phones, which were, like, the spec phone for, like, here’s… every time a new version of Android came out, it was like “Here is the Google phone,” ‘cause I knew that was how they intended for it to run, you know? And it makes a lot of sense. But you had a lot of bad Android experiences in lower-end handsets and handsets that had different features. I want to just stop and pause and talk a little bit about what we mean when we talk about the frontend and the backend. This is just part of modern development now, is decoupling parts of the platform…

Chris: Right.

Gina: …in this case hardware and software, but in our case we often work on web and mobile. It’s the backend and the frontend, the backend being the databases, the servers, the business logic, the place where backups are happening, all the sort of… the piping, right?

Chris: The piping.

Gina: And the frontend being the place where, you know, humans are interacting, right? And those two things have to talk to one another.

Chris: Right.

Gina: It’s good practice to separate the concerns of those things, right? ‘Cause it used to just be a big monolith. So anytime you had to make a change to anything, it affected the entire monolith, right? Everything could fall down. But in a world where they’re decoupled, you can make changes separately to the different areas. That’s a good thing.

Chris: It is a good thing.

Gina: But that separation often means that there are different teams, there are different resources, there are different costs associated with the two different… and they start to sort of separate, and development happens kind of in parallel. And a lot of what we see is, sometimes it’s just like, “Well, we’ve invested all this into this particular backend, we’ve got a bunch of people keeping it up and running, right? But we need a better customer experience, so can you just fix our customer experience? You know, our user experience?”

Chris: (Laughs) Right.

Gina: “Can you just do that? We’ve got this great backend.” And then it’s like, actually, it doesn’t… you know, I don’t have the data that I need. Or it’s really slow. 

Chris: Right.

Gina: Like, if the backend is slow to serve me this data, the front end is going to feel bad. It’s not gonna be a good experience, it’s gonna be a bad experience, right?

Chris: Right.

Gina: But it’s hard, it’ll be like, “Well, I don’t have budget for that,” right? “Well, that’s not what we’re doing, that’s… the backend is over here in this other shady basement data center…” (Laughs) “…at the company, and I don’t know anybody over there, so can you just do what you can do with what we have?” It’s very limiting.

Chris: It’s very limiting. Right. It has been, I think, fully embraced that if you want to work on a part of the platform where your interface is a programmatic interface that is enabling frontends, like, you can have a very fulfilling job, a very great career, actually, thinking about how to invest and involve… sorry, evolve, backend technologies. You know, there’s a whole area of expertise around how to build, especially great services-oriented architectures, and make sure that they are… you know, they scale well, they’re sort of well-deployed, all of this kind of thing. But the best backend teams are constantly asking themselves, “How are we enabling more functionality for our frontends to take advantage of?”

Gina: Yes.

Chris: And the orientation is always around, what is the customer going to see? What is the user going to see? What are the people who are actually clicking buttons and interfaces, or touching their phones, how are they going to interact? And how do we make sure that we are evolving our platform to service those needs? Rather than the other way around, rather than saying “This is what we are able to do, please do the best you can,” which is kind of what you were saying before, right? And the most success that we’ve had as we go into clients when we are doing a forward-looking, you know, design effort, where we’re thinking about, how do we do the next big point release? Or how do we do the next big major feature on a platform?, is saying “Let’s make sure that your backend team is involved from the very beginning, so that we can be thinking about how to upgrade what exists today, so that when the frontend is ready to make use of those features, they’re good to go.” They have been independently developed and tested to the best of our abilities, and maybe we use, sort of a sample or a prototype interface, or prototype calls to make that happen. But there’s a way to say, the customer experience is not just the job of the frontend. The customer experience is the job of the backend, and we need to make sure that those leaders and those teams feel connected to the experience that they’re enabling.

Gina: It is incredibly, incredibly rare to find a backend team, particularly in a large organization in a large team with a very complex and deep platform, that are thinking about the pipes. They’re thinking about the database structure…

Chris: Right.

Gina: …they’re thinking about optimizing queries. It’s a different, you know, and their day-to-day work isn’t the user experience. And this is why, you know… I mean, Postlight, I think, is perceived as a design agency or product design agency or product agency, and that implies frontend. But truly, we very much prefer, and we do our best work, when we can deploy a full-stack team.

Chris: Yes.

Gina: Where we’ve got the backend engineer working closely with the frontend engineer working closely with the designer, like literally elbow to elbow, being like “The API doesn’t give me this, I need this, in this view I want to be able to show this here.” Or like, “I’m getting a spinner here.”

Chris: Right.

Gina: “Why is there a spinner? Why is this API call so slow?” That kind of thing. So that cross-functional team. And that’s a very different setup. You know, we often staff relatively small teams. 5, 6 people, right? That’s a different setup than most, especially in big organizations. Very rare to find that backend engineer and that backend engineering team that the frontend team has access to, and that are prioritizing the experience. I have a friend of mine who, you know, is very good at this. He’s one of the best backend engineers I ever worked with, he’s a mentor of mine, I worked for him years ago. And he was telling me this story, I was catching up with him a couple years ago, and he was telling me this story about, you know, he’s working at a small company, and the website wasn’t converting visitors into users, into registered users. So, you know, the marketing folks came to him, and was like “If somebody comes to the website and they just enter their email address, we need them to be logged in. Like, we need to give them the full logged-in experience right away.” Right? Because people aren’t clicking the email and verifying and all that stuff.

Chris: Sure. Yep.

Gina: “We need to remove as many barriers to get to the logged-in experience as possible.” And so, you know, my friend who’s the leader of this engineering team brings it to his team and says “Okay, so this is the request, the feature request, the change request.” And his team, you know, the reaction was just like “That’s not possible.” And it’s like, “Why is that not possible?” It’s like, “Well, the whole notion of a logged-in user is that they’ve verified their email address, that they’ve set a password, and we need their information, and the whole database is structured around… you know, the entire application, backend application, just… it won’t understand this! We can’t do that, that’s just not how it’s designed.” And my friend was like, “Alright,” kind of… “So what should we do?” And the engineers were like, “Well, we should just go back to marketing and tell ‘em we can’t do that.”

Chris: (Disapproving) Mmm.

Gina: And my friend was like “Wrong answer.”

Chris: Wrong answer.

Gina: Wrong answer. What do we have to do? The business depends on this. This is a business need, and databases can be changed. (Laughs) The platform can be changed.

Chris: Yes.

Gina: The backend can change to service the frontend the way the frontend demands. That is a very rare, rare leader. And I think… What I sense from my clients when there’s a need for the backend to be faster or better or more efficient is just like we’ve seen, just being like “(Sigh) We can’t, that’s a whole other thing. Like, I don’t… we don’t have access to that, so we just can’t… like, what can we do without doing that.” Right? This is, there’s this…

Chris: Resignation to…

Gina: This resignation. There’s this, like, “This is just a foregone conclusion. This is what we’ve got to work with, so what can you do with it?” That’s just not how full-stack whole-platform development is done best. Right?

Chris: That’s right.

Gina: And ideally, those requirements are driving the changes to… the modernization of the backend, right, is like… the frontend is driving that. The experience is driving that.

Chris: A hundred percent.

Gina: Versus the other way around.

Chris: Right. We love great engineering. What you’re describing, this orientation, is not, does not preclude a lot of thought and investment and really good… what’s the word? Like, optimization maybe? On the backend. Like, it doesn’t mean that you can’t sort of do things the way you want to do them as a backend engineer. It just means that you have to be doing it in the larger context, which is that there are business choices that are always going to defer to what customers and clients and users want.

Gina: Yes.

Chris: And that’s correct. Like, that is what we should be thinking about, and we should always be thinking about, the backend can’t be holding the frontend hostage. The backend can’t say “You can’t do these three things because we don’t support them.” It has to be, okay, if something is challenging maybe we need to talk about how to get creative, or compromise, or take a phased approach towards getting there. But we’re going to figure out how to enable it, because that’s where we’re all going together. This, to me, highlights the importance of good programmatic interface design, and making sure that you are investing in your APIs, your interfaces between the frontend and the backend and the various services that are involved in your platform. The more that you can put energy into getting those right, the more you’re going to be able to enable, with great frontend teams, thinking about “Okay, how do I light up these designs,” ‘cause they’re going to have more at their disposal. They’re going to have more power and capability because the investment was put in on the API. I mean, you made this great point about Facebook coming up with GraphQL for this exact reason.

Gina: I mean, I love this story because it just… it speaks to a real-world user problem, right? So it’s like 2011, and smartphones are becoming a thing, and Facebook wants people to use Facebook on their smartphone, right? But networks are low-bandwidth…

Chris: Mhm.

Gina: …phones are low-powered. And if you think about the Facebook newsfeed, loading up the Facebook newsfeed, it’s actually a very data-rich…

Chris: Oh my God.

Gina: …bit of information, right? You’ve got posts and links with images, and users, and likes, and comments…

Chris: Comments and users, avatars.

Gina: Right. I mean…

Chris: It’s a ton of stuff!

Gina: It’s a lot of nested data, right? And if the experience is good, you know, you tap and you see more comments and that kind of thing. And Facebook could see that in order to load, you know, the newsfeed on a new smartphone in 2011, the newsfeed had to make dozens of API calls, right? Which was a network request from the phone to Facebook servers, right? All happening in parallel, getting sequenced up on low-bandwidth networks, and the newsfeed was slow as molasses.

Chris: Right.

Gina: And people didn’t stick around, right? The fastest way to lose users and say “Ach! I can’t deal with this” is just be slow, right? Really slow.

Chris: (Laughs) Yeah.

Gina: And so you can imagine this happening. And they weren’t just like “Oh well, let’s redesign the newsfeed so it has less interesting data,” or “I guess some people just need to update their networks.” They didn’t do that. They didn’t throw up their hands, right? ‘Cause they knew that the future of their business depended on people getting the newsfeed and using the newsfeed.

Chris: Yeah.

Gina: So they invented GraphQL, which is this one API request that gets all the nested data, no more and no less than exactly the nested bits of data that the newsfeed required, and they opensourced it. To their credit, they opensourced it. We use GraphQL on a bunch of our projects ‘cause it’s incredibly network efficient. Very, very fast. The payloads are, again, no bigger and no smaller than they need to be. And that was an innovation on the backend or on the API side that happened because the user experience was just bad on, you know, on phones.

Chris: That’s right.

Gina: That, I think, is just a great example of the frontend really driving innovation on the backend. I mean, of course on the backend you’re optimizing queries, you’re always sort of looking at the – hopefully – you’re always sort of looking to optimize the performance of your API. But that’s a great example. Can you talk about, Chris, when we work with clients and the backend and the frontend are… we’re doing a whole stack thing where we have to build both the backend and the frontend? We have to deliver both those things. We get the chance to do that, we really love to do that. How does that work? How do you design a backend if the frontend is getting defined and developed at the same time? How do they talk to one another?

Chris: How do the teams? Or how do the pieces of the platform talk to one another.

Gina: Like, in one case we had a client where we actually had, there was another partner who was working on the backend and we were working on the frontend, right?

Chris: Mhm.

Gina: And we had to… the two had to talk to one another, the teams weren’t working together, they were working in parallel.

Chris: Right.

Gina: And, you know, that was an interesting interaction, right? (Laughs) Because…

Chris: Yeah! I love that case, actually, because that’s… we, you know, we didn’t have control over the backend, and we did have to acknowledge that there were, you know, these perceived limitations about what we could and couldn’t do, but we didn’t want to be limited by them. And we had agreement from our key stakeholder that we didn’t… we wanted to push the envelope with what the existing platform could achieve by defining new and better and next-generation features on the frontend. And so the way we did that… I mean, two things. Number one, we did include a representative from the backend early on in our discussions, and I want to emphasize this, ‘cause it’s really important. A lot of people think, you know, when we’re in the design phase, engineers doesn’t matter. 

Gina: Right.

Chris: You just need to be thinking about how do we get designs, and you know, they’re going to do user research, they’re going to do user testing, and then once it’s all done and dusted and baked then we’ll put it in front of the engineers and we’ll get level of estimates, and that doesn’t work. Or it doesn’t work as well.

Gina: Right.

Chris: Because when you have engineers in the room you can make trade-offs, you can spot things that are going to need to be accounted for earlier on. Like, everything gets a lot smoother 2, 3, 6 months down the road if you spend that time and energy upfront. And it doesn’t have to be a ton of time, it can be a little bit of time. So that’s point number one. The other thing I would say is, again, coming back to the importance of APIs. APIs are a contract. They say, you know, “I as a frontend developer am expecting that I can make these calls and get this data back.” And, “I as a backend developer am expecting to receive these requests, and will deliver out these responses.” And it allows the parallel pathing that you were describing to happen, because you’ve got agreement on what the connection point is. And we’ve used that to great effect. The project that we’re thinking of, you know, we agreed on an API very early on, and the API was based directly on the designs. That means we pulled up mock-ups and said “How do we make sure that we have all of the data that is available for a given view or a given screen? Let’s make sure that we’ve got that accounted for in the API.” We’re gonna be thoughtful about how it’s designed, so that there’s some semantic importance to the resources that are being represented here in this API. But then the backend team was free to figure out, okay. I need to figure out how to light this up. And the frontend is free to think, okay, I’m gonna rely on this data. And there’s one step further you can take, which is, you can actually mock this out on both sides.

Gina: Yes.

Chris: So you can have the frontend team working off of mock data, where they are pretending, so to speak, to call an API, and they’re just getting back a flat file of data, right? 

Gina: Right.

Chris: JSON, XML, plain text, whatever you want to send back. Whatever the API contract says that you’re gonna get, assume that you’re going to get that back and then build the frontend off of that. And the frontend developers don’t have to be… they can be writing react code or whatever they’re gonna write, and they don’t have to be blocked by waiting for this new, you know, newer modern V2, whatever, backend to be developed. And the same thing for the API developers. They can make a mock request that assumed that the frontend is hitting them for, you know, new data that they are… they’re making the same queries that they’re going to get when the new frontend is in place. And they can make sure that they can respond in an appropriate way with the right data. You can write automated tests against this, you can do performance testing, you can do load testing. There are some really great load testing tools that are out there that will say, if you want to make sure that your… the new version of your API is going to be just as performant, or more performant, as what you have today under load, you can do that in an automated fashion and spin up, you know, 1,000 or 10,000 nodes against your new API using mock data. So being able to agree on the contract and then letting these two teams, or, you know, N number of teams, run in parallel assuming that those are true is an incredibly effective way to move the whole platform forward without having to work as one big monolithic group, even if the code bases are different.

Gina: That’s right. And these contract… I mean, it’s very specific, right? It’s like, I want to get user information, so me, the front end, I’m gonna send you an ID. It’s gonna be an integer between 1,000 and 10,000, right?

Chris: Right.

Gina: And I’m gonna send you an authorization token, right? ‘Cause this is private information. And then the backend is gonna accept that integer and that authorization token and it’s going to check, is this authorization token good? If not, it’s gonna send back an error. If not, okay, let’s take this user ID, now I’m gonna send back a username. That’s gonna be a string. It’s gonna be 20, up to 20 characters. Right? Like, these, it’s very very specific. And every single field that the API accepts gets defined, like, what kind of type of data it is, and what gets returned is defined, and so that the front end can expect, okay. The designer’s like “Alright, I’m gonna have an English word that’s up to 20 characters, and here’s where this is going to fit.” So this stuff takes time, it gets super super specific, but yeah, just like you said. If you can set up that mock data, if you can set up those automated tests, and you know exactly what’s going to happen if the user isn’t authorized, if the ID isn’t actually an integer. (Laughs) You know?

Chris: Yep.

Gina: If the user doesn’t exist. All those things. This is… I could go on about this. APIs are so fun.

Chris: No, I know.

Gina: They’re the best.

Chris: And I feel like, this is not a revelation, like this is not a new thing that we’ve stumbled upon.

Gina: Right. This is…

Chris: This is something that I feel like…

Gina: Been a best practice for years, yeah.

Chris: Has been a best practice for years. 10, 15, 20 years, we’ve known that the separation of concerns, and being able to agree on a programmatic interface is a great way to just enable teams to run in parallel, and really dramatically speed up your pace of development. And yet, here we sit in 2023, and I know for a fact that there are several clients that we’ve worked with in the recent past who don’t take this approach. Who, it just… it’s very hard to change your way of working, and to acknowledge that yes, this means that your backend team is going to have to get a little uncomfortable, because they’re going to have to keep pace with what the frontend is requiring and what the frontend is asking for. So, it’s just something to constantly sort of think about and talk about and put out into the world, that we need to do more of this kind of thinking, and make sure that our backend teams are continually oriented around enabling great user experiences. And then figuring out how to do that is the work.

Gina: Is the mindset. Exactly.

Chris: Is the mindset.

Gina: Right. If our businesses and organizations exist to serve our customers, right, then your platform, backend, should serve the user experience, right? And I think that good product development, the teams really internalize that, right?

Chris: That’s right.

Gina: That you’re not building around a database, right? (Laughs)

Chris: That’s right.

Gina: That you’re building the database to service the app. We are very passionate about this, we have strong opinions. I wrote a very dramatic headline, I’ll put it in the show notes, I’ll link to it in the show notes, it was “End the tyranny of a limited backend”!

Chris: I love it.

Gina: So we’ll link that in the show notes. This is a cultural, this is a political shift. This is a different way of thinking, because so many software platforms are just, you know, these big systems that have been running for years, and we start to, we orient around them. Especially big companies, orient around just making sure that they’re running and going and user experience is kind of either equal or lesser than, right? Just the priority of making sure the system is running and it’s compliant and it’s, you know, all those things. So this is something that we’re happy to evangelize and talk about anytime. So, we would love to talk to you about this. If you’re facing this problem of the backend team just saying, like, “That’s just not possible!” (Laughs) “You’re expecting too much, doesn’t work for us.” Give us a call or send us a note. We’d love to hear about this and talk to you about it. You can always get in touch with us at hello@postlight.com, Chris and I read every message that comes to that inbox. Yeah, and we’d love to talk to you, even if it’s just to kinda commiserate and help you make the case for thinking full stack, and for really thinking about that, prioritizing that user experience.

Chris: Absolutely.

Gina: That felt good, that’s a good… I felt like a good vent to start the year with. 2023, baby. User experience should drive the whole thing.

Chris: We’re off on the right foot. 

Gina: (Laughs) Yes. Well, I won’t say happy new year, I’ll just say happy day, Chris. So glad to be back on the show with you.

(Both laughing)

Chris: Onwards and upwards, Gina.

Gina: And thanks for listening, everyone. Onwards and upwards. Thanks for listening, everybody. 

Chris: Bye, y’all.

Gina: Talk soon. Bye.

[POSTLIGHT OUTRO MUSIC]