💻 The State of Full Stack Frameworks

Hey, everybody. I am Jon Kuperman. I am a developer advocate here at Cloudflare and I'm hanging out today with Aisha Blake.

Hi, Aisha. Hi. Hi, everybody. So Aisha is a lead developer relations engineer at New Relic, which is an awesome role at an awesome company.

Would you mind kind of starting us off a little bit with like what New Relic is and what you all are working on there?

Yeah, for sure. So my sort of elevator pitch for New Relic is that it's an observability platform, which means that we ingest data about basically every part of your applications and we give you tools to analyze that data.

Yeah, I love that. And I remember, I can't remember when it was, but I do remember the first time using it.

Like I had never done a lot of observability stuff before.

It's like interesting, like phase in your career, right?

Like, because I think at like a big company by nature, they just do a lot of observability, right?

Like when I started at Twitter, I remember we just monitored everything, right?

It was like monitoring like load times and latency, success rates and like logging.

But before that, we often had like production apps with no, you know, we'd have like unit tests and then maybe we would have like a dashboard for like our servers, like their uptime or whatever, but like no other stuff.

So maybe we could even do like- Yeah, or you might have disparate, or you might have disparate tools that are maybe keeping track of like, maybe you've got your logging over here and you're keeping, you have those dashboards with your uptime over there and all of that.

And what's nice about having this really holistic platform is that not only is it in one place, but you're also, you have information that is holistic, like I said, like you have that data there so that even if you are not sure what questions you're going to need to ask in the future, the data's there and you can formulate those questions later and look at historical data as well.

Right. Yeah. And there's also like, I think a big section of like, and I want to get into this, like maybe a little bit more later, but like you're also measuring a lot of stuff, like real user stuff, right?

Like you're not just necessarily measuring your, you know, like your data center uptime or like, because, you know, like, I guess maybe we could get into like, a question would be like, you're trying to build a production app and you want it to be online and be healthy and all those things.

And like, I think a lot of folks get introduced to code testing in some way, like unit tests or behavioral tests or things like that, but maybe fewer folks right now get introduced into all this real user testing.

Do you think maybe you could talk a little bit about that? Because I feel like that's really exciting for me when you're actually feeling confident that your actual users are having success on your program.

Yeah. So like you said, that testing, testing the parts that you are, that you yourself are touching, I feel like is even, even when you're talking about like a, like a code school curriculum, I feel like that more and more is starting to become part of the normal process.

Part of, part of the normal kind of learning curve. But often from what I've seen, when, unless you are at that really large scale and you kind of don't have a choice, you are maybe not, maybe not thinking about monitoring your performance in terms of real users.

So when we say like real user monitoring, that is like actual data produced by people using your application.

So that might be something like, that might be analytics like page views, but it's also, okay, well, what's, what's the load time?

And how is, and like, how are the different parts of your app performing?

And the observability platform piece of that is that you can kind of layer that information in a way that makes sense for you.

Yeah. I think that's great. And like, I think for me, it was like a level of empathy too, where I was like, I don't know, like you're in San Francisco or New York or whatever.

And you're like on your company's like brand new MacBook pro. And you're like in this major city on like you know, like fiber Internet connection.

And so you like test your app for performance and you're like, it's my app is great.

Like it's super fast, right?

Like everything loads great. And I think that even in some ways it's like a sell for some Cloudflare services where it's like, maybe you even test it from your location.

You have like one server in New York city or something like that.

And it's like loading really well for you in New York on the East coast.

But then you start, you know, layering in some like real user observability and you're like, well, this is a really long way for data to travel if you're, you know, in India or like in the UK, you know, things like that.

So it's like, even there's like this level of like empathy for your users that I feel like tools like New Relic give you, which is like really awesome, right?

Where you're like, oh yeah, I didn't think about that.

You know, it's fast for me, but it's not fast for everybody.

And I think the one that really blew my mind was like the JavaScript errors, like monitoring and like aggregating.

Like I remember like turning on like, so basically what this does for folks that haven't used it as like, and I don't want to misspeak on the tech stack, but I think it does something where it like wraps the JavaScript error object in some way.

And so when a client side error fires, it also kind of wraps it up and sends it to your logging platform.

So this is not like errors you see when you build your site, but it's errors that your actual users are getting as they're trying to interact.

And I remember turning that on a site that was like a hundred percent unit tested.

We had never heard complaints on Twitter.

We were doing, we thought we were doing really well. And then we like flipped that on, on New Relic and got just like thousands of these error, people trying to upload formats that we didn't support.

And we just never knew about it because they were just kind of failing silently and there's like a whole world out there and stuff that can happen.

Yeah, absolutely. And I love, I love the point of like, we weren't hearing about it on Twitter.

It's real. And, and especially when, I don't know, the observability term, the more, like the more I learn about this space, the more it makes sense to me.

It's like you, it's you seeing more and deeper about your, your product or your services or whatever it is that you're monitoring.

Yeah. I really like that. Like I think maybe like, cause for me, yeah, it's exactly that.

It's like you getting a better understanding of your app, which is great, but also of your users, which is extra great.

And then like being able to like relate to, or like empathize.

I mean, you're really just seeing this stuff.

Like you're like, oh man, people keep trying to upload PDFs and we only accept JPEGs and PNGs.

Like, should we accept PDFs? Like people really want to do that.

Or should we at least say in bold, you know, please only upload PNGs.

And you know, it's like, you get these insights that are, they're just really valuable.

And like, I think they just help you build. Cause I think people view it like observability is like, okay, yeah, you add it, you do the bare minimum, you eliminate errors or whatever.

But I think it actually is like, like New Relic, especially as like a very worthwhile tool for engineers to spend like significant time at once they have deployed it with their app and just getting like, is it slow?

Is it buggy? What are people trying to do? Like, what are workflows that maybe you should cover better?

Like you just get a lot of insight, which is awesome. Yeah. Like how can we use this to be proactive?

Right. Right. Even now I'll hear from people like, yeah, well, you know, we use it for incident response.

And I'm like, right.

I see, I see where you're at. That makes sense. But also there is so much to be gained from trying to look ahead and say, okay, well, where are, where are we seeing issues now?

Like what, what is actually happening for our users? What is, what does the journey look like to whatever the end goal is?

Yeah. And like, where in the system can we improve things?

I love that. Yeah. And even stuff like trying to get like, like product folks and designers, even to looking at New Relic data and being like, Hey, but do you see that?

Like, I know that you didn't want to cover this workflow, but like people, even though it doesn't work, people are trying it like every day, like maybe it's worth, you know, doing a redesign or maybe it's worth adding a feature.

We're reprioritizing stuff like that. I feel like it's like a, yeah, it's so much bigger than incident response.

Incident response is awesome.

Right? Like you should rest easy knowing that if people just start having a bunch of errors, it'll, it'll flag.

And like, that's awesome, but there's like a lot more to it.

I really enjoy spending time like in the dashboard, just trying to understand the app better.

Yeah, for sure. So switching gears a little bit, I know that before New Relic, you were at Gatsby, right?

And so this is like an area that I just love kind of talking about and like Cloudflare especially.

So the area of being like Jamstack or like, you know, static sites or, or like performance sites and like Cloudflare, you know, we have our pages offering.

And so we do like, we have great Gatsby support there. And there's like, it's such an interesting world for me.

Cause I feel like there's a lot of movement, but it's, it's like really cool in a lot of ways.

Like when I think about the ability to like build a site, deploy it for free to somewhere that's on a CDN.

And that's like, whether it's like Purcell, Gatsby cloud, Netlify, Cloudflow, any of them, right?

Like it feels super futuristic to me just remembering back in the day where I would want my personal site and I'd have to like, like call or like go to like Linode or like, you know, and like get a BPS.

And I did, and I had to learn Linux in order to get like my like NGINX stuff working.

You know what I mean?

It was like, I just want my site online. So like the idea that you can like, not only do it, but then I remember like WordPress days where you get hacked, like if you didn't update the very same day or whatever.

So I was like, nice. Yeah, totally.

Like, so I was kind of wondering like what your perspective is like on, on like this movement, like, you know, from like, from like static buckets to like, you know, WordPress to like Jekyll and Gatsby, like all these cool things.

Like, is it moving in an exciting direction? Do you think there's like just too much movement or like, are you still, do you feel like confident about like kind of the future projections of where things are going?

Just kind of wanted to get your take on it.

Yeah. So for me, my, my, so my introduction into web development was largely through, well, if I'm being, if I'm being truthful, it's, it was through Neopets, but nice.

Professionally, it was actually through some friends on the New York goalball team asking me to build a site for them.

And so, yeah. So goalball for anyone who isn't familiar is a sport for blind athletes, like specifically developed for, I think, blind veterans originally.

That's awesome. I'm going to look it up after this.

Yeah. It's a lot of fun. It's a lot of fun to watch. But because this site was specifically meant to be not only consumed, but updated by blind people, I was like, okay, well, how does that affect the way that I build the website?

Because honestly, I hadn't thought about it before that. I had not seriously considered how people accessed websites before that point, other than, you know, my own way, which is pointing and clicking.

And so for me, I am, I am excited personally by anything that makes building accessible, usable websites easier.

That's my, that's my take. Yeah. I thought it was funny. Obinna said something like this in his talk a little bit earlier, about an hour ago.

And it was something along the lines of that we are constantly improving without actually doing anything new.

I feel like we're in this cycle in a lot of ways. And it's sort of like looping.

Yes. Up into the right. That was up into my right. No, I got it. That's awesome.

So yeah, one thing that I love with the story is like, so I do a lot of like workshops and like classes on accessibility.

And one of my like first slides is always, and I wish I could remember it.

My memory is terrible, but it's always about how like the goal is not only building websites that can be like consumed by a diverse group of folks, including folks with disabilities, but building websites that can be like contributed to by a diverse group of folks.

So I love the idea that like, it's not only about like, yeah, you have a forum and the, and the forum lets you use a screen reader to read the posts.

Like the forums should also have an awesome experience for folks using assistive technologies to, you know, write their own forum posts or like in your case, like get on the web app or whatever you're using and like build new pages, things like that.

I just love that. Like, I think that's like a really, that's like the, that's the gold star.

Like that's where we should be heading towards. So I think that's just awesome.

Yeah, definitely. It's, it's all about access for me. Like if we are, the more that depends on applications and, and code and all of that, the more like life functions that are, that we involve, the more focus, well, really in an ideal world, of course, this is like universally accessible to everybody, but because it's not, the more we should be focusing on like, how do we involve as many people from as many different perspectives as possible in every stage of, from, from like ideation to development to all the way to the actual users of a product or system.

Yeah. I love it. Yeah. Like not, not just one piece, like not just consumption or not just a certain assistive technology, but like the whole thing should be awesome.

The whole process for everybody should be great.

Um, so yeah, I'm really interested because I love the static site technology. Like I still am like very excited about it all the time, but I do feel sometimes like we might be causing some user strain with like, I don't know, like jumping back and forth or like things that are like, I don't know.

Like I w I always am like wondering, like if we look back one year, two years, five years, like are things really better?

Like did we do, did we improve things? So I do feel like maybe setting aside the static site technology themselves, I feel like the deployment options are just exceptional right now.

Like I feel like I have sites on, uh, Netlify and Cloudflare pages and they, they're like the get integration is incredible like that.

You can just upload data repo and it updates. And then the idea like that each commit generates a unique URL.

So you can like send things out to your friends or to your team to be reviewed.

I feel like that area is like really, truly improving.

Like, I feel like if you took someone from five years ago and sat them down with Cloudflare pages, they would be like, Oh yeah, this is a lot better.

Um, but I, but I do worry a little bit and I was wondering, I know this is like a big question, but like, do you have ideas for like how folks can iterate and like be excited, trying new technologies, trying to approaches without kind of exhausting everybody or like feeling like everyone has to jump on this thing or like, you know what I mean?

Like, yeah, that's, that's tough. I, I've absolutely struggled with that myself.

I'm like, I want to be up on, you know, the next thing.

And especially because so much of my, not just my role, but so much of my identity, I feel like is wrapped up in like teaching.

Like I want to, I want to be able to at the very least make recommendations, even if I am not the foremost expert on everything possible.

And so how do I balance that with like my need for personal stability?

Yes, yes. Absolutely. Um, for me, I try to, in my, in my like actual work.

So when I am, when I'm writing a demo or when I am, um, when I am like making actual recommendations to people, I'm like, hey, this is, this is something I have a decent amount of experience in.

I can, I'm like, I can answer questions intelligently about this, this stack.

Uh, and I'll, I'll stick with that for, you know, a decent amount of time for a while.

That was, I was an Angular instructor.

And so like, so it was the mean stack for me. And I was like, okay, well, this is, this is what I know.

And like, this is what I'm comfortable with.

And when I go to build something for a client, it's that, or it's WordPress basically.

But at the same time, I am pretty intentional about setting aside time to learn new things.

And those projects are not dependent, or rather other things are not dependent on those projects.

So when I say, you know what I would like to learn next, nevermind that I don't know Vue.

I'm, I'll go and I'll do that and I'll make, uh, and I'll, and I'll build an app, like a real application that nobody else is worried about.

Like no one else is depending on me for any functionality.

There's no timeline. I am doing it because I enjoy learning and I feel like I want to have at least some knowledge of this space.

I, and right now on an, in my capacity on the New Relic DevRel team, that job actually is great because it allows some of, for some of that time.

So like I've been learning Rust on stream for a couple months and it's, it's great.

Yeah. I get to begin. Yeah, that's awesome.

Yeah. I think it's so tricky because I feel like, yeah, from my, like as a consumer, I try to do a lot of the same things.

Like, like first of all, like not sweat everything.

There's just going to be too much going on or whatever, but like pick a couple of things.

And then, um, I also have like a really bad habit of being like, Oh, okay.

Like you, like kind of you hit on it. Like I want to learn next.

So that means that I need to learn. And then I'll make this big list of like a thousand things I need to learn, which is like not healthy.

Right. Um, but I, I also think that like, it's cool for like creators to be like, Hey, this is like experimental or we're like just trying some things.

Like if you're excited, you should check it out.

But like, like, so I think a good example is like, there's all this iteration and like JavaScript bundling going on right now.

Right.

So there's like, uh, you know, web pack is doing cool stuff and parcels doing cool stuff.

And then, uh, there's like Vi and ES build and there's like all of these different things.

And I think that if you're not someone who really cares, it just feels really overwhelming.

Um, but I think it's really great when I see authors being like, Hey, you really don't need to like, worry about this too much.

Like we're all, we're experimenting, we're shipping stuff.

It'll settle like, um, like ideally this will all be abstracted away anyway.

Right. So like when you're using, like, when you deploy a Cloudflare worker, like you don't need to really care that much what bundler gets used under the hood or whatever.

So I do think that there's like also some onus on us as we create things and put them out there to be like, not that we have to like preface everything we create, but just like a general tone of like, Hey, if this interests you, I'd love for you to come check it out.

And if it doesn't, that's like, you're not, it's not like this is what would affect your career.

If you don't like learn my library that I created this month or whatever.

Yeah. I think as an individual developer, it's okay to admit to yourself that like, you don't, that you don't care to be constantly on everything.

Like, like I am interested and I am, I am inspired by people who are like pushing the envelope, but that's not my job.

And I, if I'm going, I know myself and I know that if I am going to get anything done, I can't constantly be chasing everything that I'm interested in because I am interested in too many things.

Same. Yeah. Yeah. So then I was also curious, your thoughts on, so kind of going back to like Gatsby and static sites a little bit, and this might be an oversimplification, but my feeling is that things kind of went from the older days where you, you basically had to be like full stack.

If you're going to make a website by yourself, right.

You had to have like some PHP or like Ruby on rails or like, you know, some knowledge of like an app.

And then we got this really cool wave of like these like jam stack stuff happening where it's like, you could just kind of do client stuff or maybe you would do client stuff and you would like plug it in with a few services like discussed for comments or, something like that.

But it was like really cool.

And now I feel like we're entering like this new wave where it's like kind of encouraging folks to still do like mostly static content, but then trying to make it really easy with like platforms like workers for you to be like, but if you want to build your own, like, I don't know, like geolocation service or something like that, like, and then make a sun if it's daytime for the user and a night, if it's nighttime for the, you know, something really cool like that.

We're trying to get more folks in, right. Like trying to lower the barrier to like creating services and things like that.

I was like kind of wondering your perspective on like, is that a good direction to be heading in?

Like trying to make it way more accessible to make those services or do you think that maybe more like pushing like pre-made services that folks can just opt into is like a kind of a better call?

That's a great question. And personally, I love the idea of lowering the barrier.

Full stop. I love the idea of lowering the barrier and making it possible for people who think of themselves as front-end engineers to, to get more, to get more visibility into the rest of their application.

I do see some amount of shifting expectations though, in that same vein, where it feels like now folks feel like they must have this, this skill set, which I don't think is true.

Honestly, like there, you could, I, and I in fact have had a job that was entirely CSS.

I did nothing but CSS and it was, and it was challenging and it had, it was challenging and it like filled my days.

And it was not only, you know, it was not only, it not only required knowledge of CSS and like markup, but I was architecting out a system that would then be used on this whole family of sites.

And so like, I think that the ability to specialize in that way is, it's still there.

I think that still exists and there are rules that maybe don't require it, but that encourage it.

We often are sort of, we often allow ourselves to be sort of bombarded by all of the, all the different options.

And we end up thinking of the, the full stack engineer as the sort of ideal.

Yeah. And I, and I don't know that it is.

I totally agree. Like, I remember like, just for example, like working on twitter.com and like, it sounds silly, but like we would have like a double border on some tweets and that was like a day's work sometimes, right?

Like where it was like, where is this?

Like, why do we get two borders on this thing? But you're reading this, you know, whatever, like 10,000 file, you know, code base, like trying to figure out.

And again, like you said, like creating CSS systems, like a class naming structure based on compile names, you know, just trying to create something that scales.

Like, but I totally agree. Like I, on the one hand, I just love this idea that like, if you are a front end person, you can pretty easily make these jumps.

Like you can use electron and make a desktop app.

You can use react native and make a mobile app.

Like you can use a call for workers and make backend services, like really, you know, scalable backend services.

But my worry is that people feel like you have to do all those things.

Like I want people to be able to be excited that they can do all those things, but I also think it's like super reasonable to be like, I actually really like UI stuff and I'd rather just, I'd rather do this and it's really valuable and like, everybody needs that.

So I think for me, I'm always like trying to walk that line between like getting you excited that you can do things without ever making you feel like you have to do things.

And that's like a little tricky.

Absolutely. So my last question, I just kind of wanted to talk New Relic for a little bit.

Like it's got so many tools. It can do so many different things.

If you had to pick like one or two favorite things and like, maybe it's not even favorites, but maybe it's like lesser known things, but like, what are some like awesome things that you can do with New Relic?

So this is a newer thing that folks might not know about.

So New Relic acquired CodeStream. And I, prior to that, I had not heard of CodeStream, but essentially it is a collaboration tool so that you can combine, this is again, combining a whole bunch of different types of tools, one thing into like a sensible workflow inside of your code editor.

And so you can do everything from like choosing an issue to actually getting like submitting a pull request and getting feedback on your change, all from your code editor.

And in addition, the connection to New Relic is that you can jump from your New Relic dashboard.

So let's say you do see an error, you can potentially jump straight to the code that is affecting that issue.

Right.

And open, there's like an open in IDE button. Oh, that's so good. The end is relevant straight there.

And it's so nice. I just, I haven't played with it as much as I would like to yet, but the bit that I have seen, I'm just like, oh, this is, this is actually really, it's like, I am genuinely like really excited.

Yeah. Yeah. One like thing that I, as a high level, I'm so excited about is like, I want PRs in the future to be so full of context that everyone can review them.

So like, I want them to have like, and I want it to be automated.

So like you put up a PR with your code change, great.

And then I want it to like link to any applicable New Relic errors, if those are a thing.

And then I want it to like, there's like some cool start.

Like I was, did some work for the startup called like replay, where you can make like an interactive video of the error that it links to the code too.

I wanted to have one of those in there.

And then I wanted to have like, you know, any type of like comments and I want it to have like a lighthouse PR, like score put in.

And I just want it to have like every PR automatic. So I feel like every step we take towards this like super contextual PRs and work is like awesome.

Awesome. For sure.

I love that. That's something that was instilled in like one of my very first, in me and from one of my very first like engineering teams was like, there, because this did happen sometimes where like someone in QA would have to like, step in.

Yes. And it's like, you want, you want them to be able to do that to just walk into a PR and not have to ask you questions, basically.

Yeah. Yeah. Unique generated links for that PR.

So you don't have to build it locally. You don't have to be at your work computer.

You can just like, yes, I love that's like, we need to keep heading in that direction.

That is awesome. Well, sweet. I'm trying to think, I think you answered all my questions.

Yeah. Thanks again so much for coming on. Did you want to do any shout outs like where folks can find you or find more info about New Relic?

Oh yeah, sure. So you can go to trynewrelic.com. That'll take you straight to the signup page.

I am Ayesha Codes on Twitch. Ayesha Codes on Twitch. Everywhere else.

Awesome. Thank you so much. Yeah. Thank you.