472: Good Meetings. Is This Data? Front End vs Back End.
Sarah Drasner's got a new book and we talk about her article on good meetings. Are front end problems more difficult than back end problems? GitHub's got an upgrade issues feature. How would you design a database for a new project? And where and what is data in 2021?
Guests
Chris Coyier and Dave Rupert
Time Jump Links
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'm Dave--in the shed--Rupert and with me is Chris--in the booth-Coyier. Chris, how are you doing today?
Chris Coyier: I'm doing pretty darn good. Um... Let's see. What do I have at the top here? I do kind of want to give a shout-out to our friend Sarah Drasner who has a new book coming out: Engineering Management for the Rest of Us.
I heard about it because I happen to share a cool channel with Sarah, but then you all should have heard about it because you're obviously subscribers to CSS-Tricks and she wrote an article called "Good Meetings," which I'm not sure if it's a chapter from the book. I don't think it is. I think she just wrote an article about what makes for a good meeting.
Dave: Mm-hmm.
Chris: Then at the bottom of it it's like, "This is the kind of writing I have done for my book, Engineering Management for the Rest of Us." I like everything Sarah does, but this shift to talking about management stuff has been really interesting to me. This is the best article I've ever read about meetings.
Dave: [Laughter]
Chris: She just has a great style about writing about it, really incorporating personal experience, and using language that feels like, "Oh, yeah, that is actually how we kind of talk at work." You know? I don't know. It's good.
It's not this, like, "Abstractly, meetings are a sharing of the minds and should follow a structure." You know? It's just not stodgy writing. It's really good.
Anyway, high-five, Sarah.
Dave: Yeah. No, this is good. I'm looking forward to her book. I've learned a lot from Sarah over the years, so this should be another banger.
I was going to say, I read that "Good Meetings" article on my vacation.
Chris: Mm-hmm.
Dave: You know it's funny. She says "agenda," like maybe don't have one was sort of like her feel.
Chris: Yeah, or that it's loose-ish because the point is talking, not going over bullet points. Right.
Dave: Right, which I agree and I disagree. [Laughter]
Chris: Mm-hmm.
Dave: The older I get, the more value I get out of, "Just tell me what we're talking about," you know? But I've also been in meetings where it's like, "Okay, we have six bullet points and now we all feel behind and rushed. Now we're going to not talk about this one. Good enough, you know, because we're hitting time."
Chris: Right.
Dave: I don't know. Maybe we have her on the show and talk about it, but it would be--
Chris: Mm-hmm.
Dave: I'd be curious because there are so many -- I think we all hit this shift slammed into remote work. You have a remote company. I have a remote company, so we're actually pretty good at it, probably. But we all kind of hit this remote life, and my meeting quality definitely went down, so I'd love to know good meetings. You know? Especially in a remote context. You know?
Chris: Um... Yes.
Dave: What do you do at CodePen? Do you daily? Do you dailies?
Chris: No!
Dave: One-on-ones?
Chris: No. Yes.
Dave: Weeklies?
Chris: Weekly. We do a weekly and we call it "all-hands," which is, of course, everybody come to that one.
Dave: What day do you do the weekly? I feel like that factors into the week.
Chris: Monday, and that's been forever-forever, and I think it's been questioned a little bit recently. But it has changed time to later in the day Monday, lately, rather than kind of the first thing that's appropriate for time zones. I don't mind it because Monday is kind of like -- I'm always fresher in the morning, right? But I don't need to be wildly fresh for a meeting.
I'd rather use my freshest brain for whatever the most important task at hand is, whether it's some planning, coding, or something. I can go in a little later in the day to a meeting and that's fine. It almost feels like a break then (in a positive way). So, having it later in the day, but it still needs to be early in the week to set the week going - kind of thing. I think that's pretty cool.
I think Sarah mentioned some days in this article, too, that were interesting to me. It was like Monday and Wednesday, and then that's it - or something.
Dave: Yeah.
Chris: Kick the week off but then check in, but not too late in the week.
Dave: Yeah. You know my coworkers; I think they all sort of buck against the idea of a daily. But I'm fine with it. Whatever, dude. We just need to get work done. [Laughter] I'd be fine to check in every day. You know?
Chris: Yeah.
Dave: Because we could have four 15-minute meetings instead of one really gnarly hour meeting where we just look at a board for an hour.
Chris: Right.
Dave: Anyway, I understand the--
Chris: If you're going to do that, then would you have less impromptu check-ins? For example, we do the one meeting a week thing. But there's also one-on-ones. But those are -- they're not for work, really. You know what I mean?
Dave: Right.
Chris: They're like, I just want these two people to talk because I want to make sure that every two people are talking.
Dave: Okay. Okay.
Chris: So, we set those up. Those are mandatory for everybody to do. But then there's--
Dave: Where is that?
Chris: Yeah?
Dave: How are--? Are you matchmaking?
Chris: Yeah.
Dave: Like you want these two people to date and smooch, or no? You're saying you want these two people on the same project to have a set time they--
Chris: They don't even have to be on the same project.
Dave: Okay.
Chris: They're just any and every two people. The point of that is, maybe they're not on the same projects. I want them to share their screen, show what they're working on, give a little context of what their work life is like, and maybe even -- like in my one-on-ones, I ask you how you're doing. You know what I mean? That kind of not -- it's work-related, but it's like, "Are you feeling okay about the direction of things? Is there some particular stressors you're having?"
It's more like personal stuff than, like, "Let's just talk about the immediately active obvious project that we're working on together." I'd rather lift up from that and talk about something else - for the one-on-ones, because there are so many--
Dave: Because we can talk about work all week.
Chris: Yeah.
Dave: Right.
Chris: We do an impromptu meeting, so those are probably the common meetings is, like, "Hey, can I grab you, please? We need to work through this together. Can we pair program?" That type of stuff, that happens all the time because we're remote and I like it.
Dave: When did you shift this? Because it was you, Tim, and Alex for a long time, right?
Chris: Yeah.
Dave: Years, I'd say, right?
Chris: Right.
Dave: Then you brought somebody on. Then you were like, "Surprise! We do one-on-ones," or was it like--?
Chris: No.
Dave: Was it like, "Okay, we're having some management troubles"? What was the, like, "Hey, you know what? We're going to start a one-on-one system"?
Chris: I wonder what happened with the one-on-ones. I think it was just a lark, maybe, at first.
Dave: Okay.
Chris: Then there was enough positivity from it that it works out good, and probably a worry that not everybody is talking together as much as they should. If anything happens to us that's reactionary it's because, "Oh, sh..." It's always, "We should talk more. We should talk more. We should talk more."
Dave: Mm-hmm.
Chris: If there's anything that's a problem, it always boils down to a lack of communication. It's always like, "I thought we were on the same page but we weren't."
Dave: Yeah, so this -- so it's -- I don't know. You're getting to know people, so that's it, but it's somewhat of an insurance policy that you don't have somebody -- like meltdown or breakdowns later, right?
Chris: Somebody is lost in the weeds.
Dave: Right. Yeah.
Chris: Yeah.
Dave: They've been working for two weeks on whatever, [laughter] the refactor of Linux. You know? To get it back working.
Chris: Right.
Dave: Yeah.
Chris: I just think front-end people need to have some understanding of what's happening with data and dev ops and stuff, even if they aren't immediately involved in it. It helps seed their mind for what the product is and what it can do and what its limitations are. Likewise, back-end people need to know what front-end people are thinking about. Those are not the only two divisions. That's just a classic one.
Dave: I wonder. I've thought this, too. I wonder if front-end -- front of the front-end or maybe even back of the front-end -- is a little more high-touch communication because, if you work on the back-end, you're kind of responsible for that service you're working on, right? This API spits out the JSON for this thing. But when you're on the front of the front-end, you're putting ten of those APIs into one view and they have to work together in a really responsible fashion. You know?
Chris: Right.
Dave: I sort of wonder if the front-end ends up being more kind of high-touch communication. You know, CSS, "Oh, what did we name this thing? Why did we name this thing that?"
Chris: Mm-hmm.
Dave: I know people try to - whatever - use frameworks and stuff to avoid naming things, but it happens, dude. You're naming components. You're naming CSS files. You're naming files. You're naming folders. You name things.
Chris: Right.
Dave: Or, "What's the best way to do this in the framework we're working on?" Asking stuff like that. Yeah, I've kind of sort of felt like I think front-end is a more high-touch discipline.
Chris: Glue. Mm-hmm.
Dave: Is that fair to say? Do you agree, disagree?
Chris: Yeah, especially because of the existence of back of the front. You know?
Dave: Mm-hmm.
Chris: Those people especially need to be hyper-aware of what's happening in API land and back-end land.
Dave: Yeah, because you can make a service that, in CodePen's situation, compiles a Sass file. That's cool but then I'm working on the front-end. Then I type @use blah-blah-blah and the Sass machine breaks. Then I have to go figure out, did I do it wrong? Use is fair syntax, so let's go figure out why. Anyway--
Chris: Yeah.
Dave: That's where the user stuff happens, right?
Chris: Right.
Dave: Oh, go ahead. You can go ahead. I have tons of questions about--
So, you went to kind of added more management structure to CodePen, or just in--
Chris: Yeah, and there's also been a response that people like feedback, that there should be accountability and feedback on how you're doing. Sometimes the one-on-ones help with that.
We also do this thing, Dave, that's similar to an all-hands, but lately, we've been calling them Thurs-doc. I think some companies do it daily. I've even seen Slack bots type of things that bug you and ask you, "Hey, what's your thing today? Please respond to this message," that has some bullet points of what you did.
Dave: Mm-hmm.
Chris: Which is your kind of accountability for the day and for management or whoever to check in to see what you're getting done - kind of thing. And to communicate, like, "This is done now, so maybe you could work on that," although that's not the best structure for that.
Every Thursday, you're required to turn in a document that's like pros, essentially, of what is going on with you.
Dave: Okay.
Chris: What you did, what your blockers are, that kind of thing. Everybody looks at everybody else's. You comment on them. You look at them. You see what's up. You have little communications there. Those are done in Notion, so there's a commenting structure kind of built in.
The point of that is some accountability, like, I need to be able to see your weekly and see that you're getting things done. If you have a bunch of weeklies with nothing on them, that's obviously a problem. It's accountability in that way, but it's also a chance to showcase what you did because not every single thing you do is appropriate to share in all-hands or talk about in Slack or something.
Dave: Mm-hmm.
Chris: But anything that you do is fair game for that weekly doc. If something took up some time of your week, tell me about it. You know?
Dave: Yeah. Hmm. Okay. No, that's good because we've started the Slack bot thing, mostly because it was like we had a bunch of people on a bunch of different projects. The client works a little bit different because we're contributing to different streams, if that makes sense.
It was like, "Oh, this one person needed a chart and graph," so we had to stop the work on project A to go work on project B. You know?
Chris: Yeah.
Dave: It was hard. We're kind of hitting the limit of, like, it's hard to figure out when something is going to arrive because inbound requests sort of wipe out any sort of plan we had.
Chris: Oh...
Dave: We kind of switched to -- the problem is probably too many clients, but then it's like if one client leaves, now you have too few clients. [Laughter] Anyway--
Chris: Yeah, there are versions of that in non-client work, too. I'd be like, "We got a plan. We got a Kanban. We got things to do." Then search results are twice as slow as they were last week. Well, guess what. That's like an email from a client that says, "You need this thing right away." It's a curveball.
Dave: Mm-hmm.
Chris: Now we're working on that because that's--
Dave: That was important.
Chris: --something else.
Dave: Now that's suddenly the most important thing.
Chris: Right.
Dave: Yeah. Yeah, no.
Chris: I feel bad for back-end people because it happens more to them than it does to front-end. It's very rare that you'll get some front-end tickets, like, "Your buttons are unaligned. It's on fire. It's going to take you all week to root out the cause of this and why and buy new hardware." Pfft. You know?
Dave: Yeah.
Chris: When a curveball gets thrown to back-end people it's just harder, more frustrating.
Dave: It's usually ... right.
Chris: Yeah.
Dave: It's usually something broke down, but what?
Chris: Yeah.
Dave: There's an investigation.
Chris: Has there ever been a company on Earth where the back-end is just waiting on the front-end? There's just beautiful APIs sitting there. Everything is fast. Everything is secure. Everything is just there, and they're like, "Gosh! I wish the front-end people would get around to building a UI for this."
Dave: Well, you haven't worked with me yet, Chris.
[Laughter]
Dave: Yeah. No, I think it's all-time, right? It's all -- but no, yeah, I think there's always sort of -- it's a give and take, and that's kind of back to, like, I think there's this thing where you maybe -- I don't know. Front-end is kind of high-touch, right? We have to kind of, like, "Hey, I stubbed out the view for this thing. It's waiting on data. And I see you pushed the data model for this thing, so I'm going to go switch over to this thing."
Chris: Right. Yeah.
Dave: Hopefully, we'll meet up in two weeks, and we'll have the same website. But it doesn't always work that way.
Chris: We did a cool Kanban the other week on a project where all the cards had different icons on them because there was some GO work to be done, so the GO icon has a little gopher guy.
Dave: Mm-hmm. Okay.
Chris: And there's a React icon.
Dave: Okay.
Chris: It's a little atom.
Dave: A little atom. Yeah.
Chris: That's UI work, essentially, that needed to be done because the design was pretty much done at this point, so there was no design icon. And a little GraphQL icon, like the glue between the back-end and the front-end, kind of like, "How do you get the data into the front-end?" thing, and that was the little GraphQL pink coinciding triangles icon thing.
Dave: Okay.
Chris: I think Rachel put this together. So, all the tickets had the icon on them, so you could just look real quick and be like, "This is a cross-functional Kanban, so everybody can look at it and know where this project is. It's not like we split it up into different teams or whatever. This is the Kanban for the project.
But you could also tell what type of tickets you could do or not because I can maybe help with some GraphQL stuff and some front-end stuff, but I ain't writing any GO code. You know? I'm just not qualified. I don't know that world.
Dave: Right.
Chris: I'd be like, that would wait. That would be like a blocker for me, but it just didn't have to be marked as a blocker because it was just obviously one depending on the icon it had.
Dave: Mm-hmm. Mm-hmm.
Chris: Then as soon as there's a React ticket, I'm like, "I'll grab it. Got it." You know?
Dave: Yeah, so you see the type of work and you know, "Hey, I can fit into that work."
Chris: Yeah. It's just like a tag or something or a column. There's a million ways you could do it, but it worked out nice.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Elastic. Elastic enables the world's leading organizations to put their data to work using the power of search. Whether it's connecting people in teams with content that matters, keeping applications and infrastructure online, or protecting entire digital ecosystems, Elastic's search platform is able to surface relevant results with speed and at scale.
Learn how you can get started with Elastic's search platform for free by going to -- get this -- elastic.co/shoptalk.
[Banjo music stops]
Dave: Are you -- have you seen the new GitHub issues?
Chris: Well, I just saw the homepage for it, and I was like, "Wow. You're doing fancy things with tables and stuff. Looks cool."
Then we even kind of like internally rejected it only because we were about to launch into some big planning stuff, and you'd think, "Oh, maybe that's perfect. Maybe we should explore it," but it kind of felt like that'll be a distraction right now.
Dave: Yeah.
Chris: It's very new. We don't even really have access yet. We already have these tools that we already know and use. If we're going to do a major planning session, maybe we just ought to keep it in comfortable territory for a minute.
Dave: Yeah. Yeah, because it's got Notion-y vibes because you can flip between a table or almost like air table vibes.
Chris: Yeah.
Dave: Because you can have these grouped tables that then flip into a board, right? But anyway, I was like, "Ooh, this is cool because you can kind of tag it," and you could tag it with something like GraphQL or GO. You could tag tickets with, like, "This is this kind of work," or even just front-end, back-end, or something like that.
Chris: Yeah. Yeah.
Dave: It might be the easiest way to put it. So, anyway, then you'd have an idea because I'm all about visualizing. Maybe that's a sighted person ableism sort of thing, but if you can visualize the work, you know what you need. You know who you need to hire, like, "Oh, we have 200 back-end tasks and 5 front-end tasks."
Chris: [Laughter] Exactly. That's always the case.
Dave: Like, "Oh, we need a back-end," you know?
Chris: Mm-hmm.
Dave: Or, in your situation, like, "This is a GO task. This is a Rails task."
Chris: Mm-hmm.
Dave: You probably even have different vibes of back-end.
Chris: Mm-hmm.
Dave: That different people could do, so yeah. I don't know. I'm just all about digesting that backlog.
Chris: Yeah.
Dave: I think I'm excited about these because I use GitHub issues pretty religiously. But now I can kind of really get some stuff done.
Chris: I bet you're excited.
Dave: Yeah.
Chris: Have you seen it? Have you actually used it yet?
Dave: Well, you know, they rolled out part of it. They rolled out this part where you make a checklist. Have you ever done that in GitHub issues, like dash?
Chris: Dash space.
Dave: Or hyphen space bracket.
Chris: Bracket, yeah.
Dave: Yeah.
Chris: And it either has an X in it or it doesn't.
Dave: Yeah.
Chris: Yeah.
Dave: And so, now -- then if you put a pound sign, like for an issue number, like number 1-2-3, it'll actually link to the issue and show the text and stuff like that.
Chris: Mm-hmm. Mm-hmm.
Dave: So, like, that's cool. But then if you just type whatever, "Go find database." [Laughter] That's terrible, but whatever. "Go find database," or "Setup database," and then you hit save or whatever and it's fine.
Well, now if it's turning into, oh, this is actually a pretty big task. This was not just to email somebody and it's done thing." This is a full-blown week issue.
Chris: Yeah.
Dave: You can now do "convert to issue" on that setup database, and so now that checkbox will be linked to an issue, and stuff like that.
Chris: Hmm. Fancy.
Dave: It's very micro but it's very awesome because it just -- I don't know, man. Now your to-dos or issues are linked to different things, and so -- yeah. Anyway, I'm stoked on many levels.
Chris: That's great.
Dave: Anyway, I got a free tool improvement over the holidays. Over my vacation, something got better. I'm looking for it. I just got into the beta, so I need to flip it on or whatever dumb trick I need to do there. Yeah.
Chris: I have a way to tie some things together here, maybe.
Dave: All right.
Chris: It's interesting. In order to make a board that also becomes a table, you've really got to know what you're doing data-wise, wouldn't you say?
Dave: Mm-hmm.
Chris: You can't -- it's not a front-end task, I'd say. That data model better support that, right?
We got a question here from David M. who writes in, "How do you guys go about designing and building out a database for a fresh new project? As you're building the project and new ideas come to mind, how do you implement the additions/changes, that may be required?"
Great question, David. I have a couple of thoughts here to start with before I pass it to Dave. One of them is that I was playing. I think in the last episode I mentioned Prisma. I was paired up with Chris Seth and did that thing.
Dave: Oh, you're going where I was going to go. Okay.
Chris: Nice. Okay.
Dave: [Laughter]
Chris: It was interesting. One of the ways that Prisma works is that you write like a schema kind of thing. As you save it and then run a little command-line utility thing that says, "Hey, generate my stuff," it will make a migration file. Yeah?
Dave: Yeah. You write a schema. It's almost like a GraphQL schema kind of thing.
Chris: Yeah. It's not, though. I mean it is, but--
Dave: Then you run this command line. What's that?
Chris: I want to know what it is. What is it?
Dave: Yeah, I think it's like a schema.
Chris: It's a weird format.
Dave: Yeah, and then GraphQL-like, we'll say.
Chris: Yeah.
Dave: But then you run this back-end tool. It creates a Rust app that is now a little two-meg Rust app that is super-fast and converts your JavaScript into good SQL, like optimized SQL to go fetch against your database.
Chris: Yeah. Crazy, right?
Dave: That's what's happening.
Chris: You can see the SQL that it generates. You know?
Dave: Yeah. Yeah.
Chris: So, you don't even have to write any SQL. That's the beauty of Prisma, right? But notably, it puts that SQL in a folder called migrations, because that's what it is.
Dave: Yeah.
Chris: That's how Rails did it, too. You know? You change some schema stuff; it makes a migration. Then when you deploy, you teach your server to run the migration before it does it. That way your app isn't asking for data that's not there - or whatever.
Migrations are key to this, so that's the deal. David, look into migrations. Check out how Prisma does it because it's pretty approachable, I think.
Although, I would note that we did that once. I don't have that much experience, but I did this during our screenshot or the screencast I did. There was a big ol' warning with the migration and deploying the migration. There was a thing that cropped up on the command prompt that said, "Hey, warning. When you run this, it's going to wipe your data. Literally, all data is going to be erased." I was like, blah.
Surely, you don't have to wipe your data during a migration. But what I didn't know is, how do you avoid it then? Why is it giving me that warning? Why does it feel incapable of running this migration without a data wipe? Was it a setting? What is whatever?
Surely, there's a way, right? I don't know what the way is, but of course, there's a way because it's data and it's just a database. There's a way.
But I don't know the way. That's the kind of moment where I feel like even if I edge maybe lately a little towards more back of the front stuff where I'm more comfortable with that, I'm not comfortable with that. To me, that's back-end work. Somebody's back-end has to be involved with this to make sure that that goes well.
Dave: Yeah. I'm using Prisma on this little app I'm building. Little -- it's big. It's a big app.
Chris: Yeah.
Dave: Why would I self-deprecate? [Laughter] Self -- whatever.
Yeah. It's good, because I've never seen migrations in JavaScript. This provides that, and that was really cool. I've maybe seen one or two tools that tried it but then just were like, "Oh, we don't do that anymore."
Chris: Hmm.
Dave: I think it's really awesome, and I think Tom Preston-Werner is an investor - and stuff like that. I think it's around for a while.
Chris: Oh, is it? Is that why Redwood--?
Dave: Redwood uses it, yeah.
Chris: Yeah.
Dave: That's where I learned about it, and I was like, "Oh, I've never seen this. This feels great," because if you've used Rails, migrations are kind of the bee's knees. They're really sweet for predictively adding data.
Chris: How is--? What is the business model of Prisma if it's not hosting your data and it's just like this little middleman between your front-end and your database?
Dave: If they were like, "Oh, use Prisma, but also we have databases," I'd sign up.
Chris: Yeah. Just use their hosted database. Why not?
Dave: I'm using so much DigitalOcean these days.
Chris: The website is so nice. They clearly have money, but what's the plan?
Dave: Yeah.
Chris: With Apollo, the plan is more clear.
Dave: Right. Well, and then there's also another tool called Supabase.
Chris: Yeah.
Dave: I don't know if you've seen that. That's more -- I think they're kind of building an ORM in JavaScript, which it looks cool. I think they are doing the more "we'll host your data if you want us to" sort of thing. Some tools around database, which are sorely needed.
Chris: It looks good. I think we have an article coming out on CSS-Tricks about it soon.
Dave: Yeah.
Chris: It looks pretty cool. They call it a Firebase alternative, which I don't doubt in any way. Also unclear on what the pricing prodigy is, but how many times have I said the word Astro, Skypack, Snowpack, and stuff? What's their plan? [Scoffs] You know?
Dave: What's their plan? Yeah.
Chris: But they said -- I mean I heard Fred--
Dave: How does it make money? [Laughter]
Chris: Yeah, well, I don't think that one needs to because it was work to put together but I think it's just hosting and the hosting is given by Cloudflare, probably. Then you just forget about it.
Dave: Okay. Okay.
Chris: But you know Astro and all that has very -- there's like a lot -- there's like full-time developers working on it. You know they probably have some funding or something, too. They have been a little clear and be like, "We're hoping to grow this into a platform. The platform hasn't arrived, but let's get this right first," kind of thing.
It's kind of coming. I wouldn't be surprised if that's the kind of vibe for Supabase and Prisma and stuff too is, like, "Let's make sure this kicks ass and has real developer love. Then we'll figure out the money."
I personally question that a little bit, but they've done it. Those tools are really good.
Dave: And I think the strategy there is good. It's like Gatsby's strategy. Get the tool right and then take people's data. Once you're hosting people's data, dude--
Chris: Yeah, for sure.
Dave: Sad trombone. That's all the risk. That's all the anger emails. That's all the customer support. Take people's data last, is sort of a great mantra.
[Laughter]
Chris: As long as you're ready. As long as you've thought of it. As long as you have been working towards that outcome since the beginning, that's okay.
Dave: Yeah.
Chris: As a slap-on is like, "Ah, developers love us. Now how should we make money? I don't know. Should we put ads in the CLI?" That's not going to work.
Dave: Yeah.
Chris: Okay. Well, that's cool. So, where I was going to take this, though, (I hope you don't mind) is that we're talking about Prisma. We're talking about migrations - all this data stuff. While we were putting together this little blog and, like, "Here's the data structure. Each post as an ID and a title and content and number of likes, which is an integer, which auto-increments by one (or whatever)," very satisfying work, I am not a data person, really. I can put together that schema, but what am I forgetting about here?
Should there be a relational model to a user's table such that each post can have an author but it's a relational relationship to an author? Then what if there should be multiple authors? Does that mean it should be a relational array? Is that even a thing that exists? I don't know. Let alone the data model for CodePen, which is (as I am a cofounder of but not a data person on) extremely complicated.
Dave: Yeah.
Chris: It's like I cannot -- I'm not -- that's not my thing. You know?
Dave: VARCHAR(255) is infinitely more performant than text. You know? [Laughter]
Chris: Infinite is right. I was making a Wufoo form the other day and I tried to make an 11th text area field. They're like, "No. There's no plan on Wufoo that allows you to have 11 text area fields on it."
Dave: [Laughter] This does not go up to 11.
Chris: It does not.
Dave: [Laughter] That's beautiful.
Chris: Because surely the data model was like, "We've made them text because they need to be big, and we can't roll back that choice. So, in order to limit this a little bit, we'll limit the literal number of them that you can have."
Dave: Yeah.
Chris: Crazy. Okay, so then where I was going to go with that is, you need a data modeling genius, essentially, at some point. Somebody with some real data smarts needs to do this because, as powerful as front-end is and our responsibility has grown and grown and grown and grown and grown to the point where, wow, front-end is super-powerful, we're even taking it to the point where we're crafting our back-ends and hosting products have gotten so good. I don't even really need a dev-ops team. Holy crap. Can I do it all?
I think one of those limits is that you're not a data modeling genius. That feels not front-end at all to me. That feels really screw-up territory.
The flip end of that is, what if you get the data modeling perfectly? What if you have such an awesome data model that it basically becomes your product because it's so awesome?
Chris: What I'm thinking about here is Notion. There is an article by Jake Teton-Landis about the data model behind Notion's flexibility. Notion, you can feel the data model as you use the product. It's so cool.
They wrote about this. Basically, every single thing on Notion is a block and it's represented, essentially, the same exact way down to a list item and a list. It's a block.
You know what else is a block? An entire page that has sub-pages. They're the same data model. It's very clever in how not clever it is - in a way.
Each block has a UUID, so it's totally unique. You can just arbitrarily make them and they'll be uniquely represented no matter what. You could fricken' create them offline and they'll be unique and you can trust that, even though they don't have any offline support - but theoretically, it should work.
Then if you modeled it in that way, then you can transition the block to other types of blocks by writing transformers between the properties that that block has. They all probably have a title - or do they? I don't know. What should become the title if it's not a title? Should the list items' content become the title of a page if you transition it?
I'm sure there's some complexity there, but the fact that that model is so smart and so incredibly flexible (and that blocks can arbitrarily contain other blocks) I think was a stroke of genius and not the kind of thing that my dumb little front-end developer brain is going to think of. I can think in CRUD models okay, but definitely not in, like, I'm going to innovate on this product in terms of data model.
Dave: Yeah, on my stealth project I'm working on, I was doing the CRUD way, right? I was doing, like, "Okay, this is model one and I have a create, a read, an edit, and a delete function. Then I have model two and a create, a read, an edit, and delete."
Chris: Yeah.
Dave: I'm making views for all this stuff. Then I had a feature like owner toggle, like the user, whoever, the person that owns the entry or whatever. I was just like, "Oh, man. I'm going to have to implement this like seven times." You know? Or I was going to set up a relation between two models, and I was like, "Oh, I'm going to have to do this like seven times," like if this model relates to these other three, or whatever.
I was just like, "This sucks!" And so, I was just like, "I think the best solution might be to go down to one (we called it) supermodel, but just one big - everything is this one thing, and they all relate to each other, and we'll figure out what we have to turn on and off later.
Chris: Amazing! Good idea.
Dave: We ended up refactoring - big refactor. I mean two months of, like, breaks. That was kind of a bummer. But, man, we saved a bunch of code. We saved a bunch of overhead, mental overhead. There's still a little bit, but you just basically have to just know everything is an entity now, we called it. It could be whatever.
Chris: There you go.
Dave: These entities may have blocks in the future because I'm looking at all these new block tools. I think you posted a tweet about that. I'm like, "Ooh, maybe that would actually be pretty helpful," like a chart and graph block or different kinds of blocks.
Yeah, I'm just like, "Oh, man. I got pretty, pretty far down this," and these entities have to present differently, but them all being the same is awesome because we had one feature, like file uploads or something. It all goes to every single entity and we're done. It's beautiful. Then we can just turn it off on entities that don't get file uploads - or whatever - so entity types.
That's a long story to say data modeling is tough. [Laughter]
Chris: Well, can you imagine? I did this little cheesy tweet thread that involved Notion because it was like, you can imagine in Notion (if you've ever used it) you type and it looks like a text editor, but really it's not. It's more like Gutenberg's block editor, you know, WordPress's block editor in that everything is a block. You can drag the blocks around. The blocks can be of different types and have different properties and stuff. Pretty neat.
It feels like the future of how documents are created. Not Word, although maybe Word will adopt a model like this at some point. It is pretty slick.
But then it wasn't just Notion. I was like, "My God. There's this Craft app I've been watching," because it has a very nice feel to it, I think, too, and more native feeling Mac app - perhaps, I might say. Maybe a little more better offline support. Although, I forget. You know, so I was watching that.
But then there's Coda, too, which not the old-school Panic Coda, but coda.io, I think it is, that is also similar. I have all these open, and I look for alternative ones. I didn't even include the WordPress editor, but it's clearly like that too.
I'd be like, "Look at these six apps are identical-ish in this approach to document editing." I don't know who was first. I don't really care who was first. It's just interesting. It's in the water, you know?
Dave: Google has a new one, right?
Chris: Do they?
Dave: Isn't it? The new Google Pages is kind of a block editor, I think.
Chris: Nice. Yeah, there's -- what did I see? TrueFlow? I can't remember.
First of all, there are open-source libraries that are block-based like this, too, if you want to build your own app but leverage that kind of concept. That's there. There are website builders that work in that way. Pretty cool.
[Laughter] Wow! Right? But do they all do it like Notion did it? I would think the temptation would have been if you're thinking about Notion for the first time. Well, we'll have a type of pages, and pages contain blocks, and pages have their own everything.
Dave: Mm-hmm.
Chris: They're just their own thing. But they didn't even do that. I think part of the genius was that even pages are blocks.
Dave: Whoa!
Chris: And that's weird. You know?
Dave: See. I think that's -- yeah, I mean that's the flex. They flexed.
Chris: Yeah.
Dave: They flexed on this, but yeah. No, that's cool.
Chris: Yeah.
Dave: I'm....
Chris: So, how would you do that? Didn't David -- can't you relate to David M.'s question here? What if you have a totally different data model idea? Crap. Then what? It's like, "Sorry, David. It's two months."
Dave: It's a big refactor.
Chris: Yeah.
Dave: Actually, this is where a tool like Prisma kind of help because we did have migrations. Thankfully, we're still in whatever built-out phase, so we don't have a bunch of client data we can't replicate. But you're going to have to have a way to migrate this data, like these ten tables become one table, the blocks table, or whatever. You're going to have to figure that out, and that's tough to do. You may need a database expert to do that.
As far as like designing a database, often pen and paper is the best, or whiteboard because you can start real big, like I have a user and a user has posts and then a post can have comments. But it doesn't have one comment. It has many posts. Oh, and a user can have many posts, and a user can have many comments.
You start getting into, like, that's maybe the Rails 101 tour, or whatever the Rails blog in five minutes thing. I think you figure out what the model is on pen and paper. That's the cheapest way to do it. Then maybe you try to build something in.
You can download a database thing. We all like TablePlus in the [techno voice] Discord.
Chris: Yes, we do.
Dave: That's in Setapp, right?
Chris: It is, but you can just get it separately if you want. Yeah.
Dave: I was using one called Beekeeper. It was kind of cool.
Chris: What?!
Dave: Free.
Chris: Really?
Dave: Anyway, it's not as good at TablePlus, I don't think, but it was nice. But it's basically just a way to see the tables in your database, MySQL, or whatever.
You can add columns and stuff like that. But if you change a column name, that's where it starts getting a little tricky. Especially ... data.
Chris: Yeah. I mean can you imagine if you took a production app and just changed a table name? Guess how well that's going to go. You know?
Dave: It's not going to go real well.
Chris: No.
Dave: So, data is unfortunately the thing you kind of want to get right. Otherwise, it's expensive to change later.
MongoDB is actually pretty good at changes.
Chris: That's surprising me, almost, because isn't Mongo just like, "Just throw some JSON at it," kind of thing?
Dave: Yeah. Well, and that's it. You're like, "Oh, we need a new terms of service checkbox. Cool. We'll just add it. We'll just send a terms bullion," terms, yes, or whatever to it. It's like, "Okay. Cool. Yeah, I'll take that." Otherwise, it's false, or something like that.
Chris: Hmm.
Dave: But in Rails land you're like, "Okay. Add this table. Now, set the default to false for 10,000 records." [Laughter] That's like pain town, right?
Chris: Yeah. Yeah.
Dave: Mongo is kind of a little more flexible in that regard.
Chris: That's cool.
Dave: I think some people like the flexibility of Mongo in that regard. But I personally use a whole bunch of Rails. Rails figured out data, man.
Chris: Hmm.
Dave: The way they did it was pretty efficient and a lot of startups run on that at scale, that model. I would maybe take Rails for a spin and look. Open up the TablePlus and figure out how it built the tables because I think there's some good learnings inside of there.
Chris: Yeah. I mean we use Rails too. Although, we're moving away from it. Not like on purpose. Not like, "We have launched the anti-Rails migration!" I think some of it is fine. It's just when we can do something better, we do.
We do use MySQL, still. Although, I think Alex is homing in on a Postgres finishing switch because there are some pretty damn--
Dave: Okay. Okay.
Chris: We looked into moving to Postgres long ago and it was not so compelling. I remember conversations. I'm like, "Guys, if we do this, what are we going to get out of it?" They're like, "Nothing, really. Just, you know--"
Dave: Yeah.
Chris: Then I was like, "Well, why the hell would we do it then?" and we didn't. Not that that was the only answer. I'm sure there were lots of considerations.
But now we're looking at it and there's lots of compelling stuff in it that's kind of better than MySQL, in my opinion - as I'm told. I'm not a data expert.
Dave: Yeah. There's one or maybe two killer features. One killer feature of Postgres is you can have a type=json.
Chris: Yep.
Dave: So, you can just chuck a JSON on there. It's not a....
Chris: And we do that in MySQL and it's awful.
Dave: Yeah.
Chris: We did it on purpose knowing that we couldn't query for it, but we were like, "Whatever. This is going to help us move fast," because then you don't have to run a migration, right?
Dave: Yeah.
Chris: You just throw it in the JSON and it's fine. But then you can't do shit with it. It's horrible. You know?
Dave: Yeah, but in Postgres land, it's cool.
Chris: It's cool. It's fine. Yeah.
Dave: I love it. I love this big old blob of text.
Chris: Yeah. Right.
Dave: ...blob of text. This is beautiful to me, and so that's pretty cool.
Chris: For us, it can be Elastic search-like too, that has search capabilities that are way killer beyond MySQL can do.
Dave: Mm-hmm.
Chris: You might be able to use the same database or a replica for search that you couldn't do in MySQL, which to us is like, "Really?!" You know?
As far as they talked about another one where it has built-in actions or something. I forget what they're called exactly, but it's kind of like you can teach the database. It's not just a data store. It has instructions. You can be like, "Take these ten records every day and roll them up into one," or something, and it'll kind of self-manage itself. Like, "Holy crap! Really?! That's amazing!" [Laughter]
Dave: Yeah. No, it's pretty cool.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Jetpack. You know the plugin that does all sorts of stuff for your self-hosted WordPress site.
I have not made it a mystery that I'm a fan - I don't think. I have it installed on all my WordPress sites. I love the features of it.
I love instant search. That's one of my favorites. It gives you this really good search experience on your site by doing - ah - nothing. It's basically a switch flip kind of thing and it's really nice. Then you've got full control over that search experience that's just way above and beyond what anything native WordPress could provide with control. Just amazing. Anyway, that's just one thing.
I do have an ask. Maybe you've seen it. I'm asking why people don't use it, if they don't. So, we put up a survey on CSS-Tricks.
It's just a Wufoo form kind of thing, but asks one question, so it should take very little of your time. It just makes you pick from things that are reasons why you don't use it, if you don't. All the way included to, like, "I don't even know what you're talking about, Chris."
But the point is to kind of home in on some of, like, if you hold any, do you have some baggage about Jetpack? What are your thoughts? Does it just not do anything you don't need or is it too expensive or do you think that it doesn't do things the way you want them to? There are a bunch of answers there. Pick the answers you want. Then if you want to, follow up with why. If you really want to expand on it, use the form, but you can even write to me if you want.
I'm just curious because they're a long-time sponsor. I like what they do. It's helpful for me as a sponsoree to know why somebody might not like the product.
I'm not just going to be like, "You're wrong!" You know? [Laughter] Because maybe you're right or maybe your opinion is valid or you have different things you're thinking of. But sometimes I think there are things that I could kind of nudge people and be like, "You know, actually, maybe you were right but you're not anymore," kind of thing, and that will just help me be a better sponsoree, and it's probably helpful for them to know what's up with their product, too.
So, thanks for the sponsorship and everybody who has already submitted that form, I appreciate it.
[Banjo music stops]
Dave: Back to Prisma, our best friend here on the show, they have a lot of -- they actually have a benefits of Postgres post here. Yeah, full-text search. Privilege management, that's kind of rad. I didn't know that that was there. Yeah, anyway, it has this concept of views, too. You can basically create a baby table, so that's kind of cool. The JSON stuff is kind of pretty radical.
Chris: Yeah.
Dave: It has money types, geometry types.
Chris: I don't know if it's easier to migrate, but I would imagine it is. I mean we lived through the days where we're like, "Oh, we're on a version of MySQL that has to lock tables during a migration," and then there was a new version of MySQL -- Was it 5.6 or something? -- where you didn't have to. What a big deal. That's the difference between telling your customers that you're going to have to go down and not.
Dave: Yeah.
Chris: That's huge.
Dave: Yeah. Anyway, yeah, I think it's cool. Anyway, hopefully, that helps, David. I don't know.
Chris: [Laughter]
Dave: There's also if you're designing and you want to do something in the browser, because I went on a bender. I was like, "How do you do databases in 2021?" I was just like, "There's got to be better than what I was doing?"
Chris: I don't know.
Dave: There's this cool tool called vuerd. I'll put a link in the GitHub or in the show notes on the show.
Chris: What are you talking about, vuerd?
Dave: ERD as in entity-relationship diagram. This would be if you're drawing it on pen and paper. You have a post entity and a user entity and you're drawing the relationship one-to-one, one-to-many, blah-blah-blah. This is a cool tool that you can put in your browser, actually, and it's all based--
Chris: What?!
Dave: It's written in Vue, but it'll actually give you SQL and stuff like that, or it can parse your SQL and build out the ERD file, I believe, like that. Anyway, it's a cool tool. I don't know if it -- I just came across it, and I think it's cool enough to talk about.
[Laughter]
Dave: Because it's just viewing. Again, I'm a visual person. I sometimes want to view how the data looks, but these entity-relationship diagrams are kind of an industry standard.
Chris: They are.
Dave: For building out or visualizing.
Chris: There are a lot of them in our back-end channel at CodePen. I'm like, "It looks good, team. Keep going."
Dave: [Laughter] This - that's a chart.
Chris: [Laughter] Yeah. Exactly. You should star this. You'd be the first person to star this.
Dave: I'll star it.
Chris: There are zero stars on GitHub. I'm going to star it too.
Dave: I'll star it. [Laughter] There's this really good, old Vine series. I'm going to post a link in the show notes here. It's called Gabe Gundacker or something. He was in Vine, and it's this, "Is this music?"
He walks in. He's like, "Oh, what is this? Music?" It's a guy who can't understand music, and--
Chris: [Laughter and snorting]
Dave: It's so funny. He's like -- he points at a plant. He's like, "Is the music coming from here?"
Chris: [Laughter]
Dave: "No? Okay. Just tell me where." He's pointing around the room. Anyway--
Chris: [Laughter]
Dave: Anyway. [Laughter] That's how I feel about databases. I'm like, "Is this data? Is that a database?"
"Yes."
"Okay. Cool. Yeah. Great."
Chris: Yeah. Yeah, because a database and, like, the schema for the data is a part of the story of a data model, which has different, deeper implications. Even that then isn't exactly like the decisions about what then is in the API and gets communicated that way is yet a different story. It's scarily over my head for something that shouldn't be.
That's why I'm so -- like, as much as I like to talk about, like, "Oh, my God. The front-end and our responsibilities are so incredible lately. There's so much going on that has gone to the front-end shoulders," I'm like, "Yeah, but there is also so much that is not," because I actually don't feel particularly powerful at work, believe it or not. I can do a lot of stuff, it feels like, but compared to what needs to get done around here, my skillset is narrow.
Dave: Yeah, right? But I feel like, too, those jobs are different. Right? Maybe I'm getting into duck-sized horse territory.
Chris: [Laughter]
Dave: But you're going to change the data model. Move to Postgres, right? That's a big block to move. Right? That's a big chunk you have to move to. Or you're setting up or rolling out a new database or whatever. That's a big chunk.
But then on the front-end it's like, "We're going to move to Postgres," or "We're going to add a checkbox to a form," and you're like, "Cool. I have to figure out where on the site that form shows up, so there are probably 600 different places I have to go check. I'll be right back." You know?
It's different, right? It's different. I feel like back-end work is usually big chunks or big tasks like month-long tasks, and front-end tasks is a lot of smaller, one-hour, two-day, three-day, five-day work. You know?
Chris: Totally.
Dave: That's just my vibe-vibe.
Chris: [Laughter] I like the word vibe. 2021 has a vibe-vibe.
Dave: Vibe-vibe. Well, Chris. Should we pack it up, pack it in? We're ready to go.
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 - for real. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.
If we didn't answer your question, send it in. Send in a question. [Laughter] That's why we didn't answer it. If you want to ask us more questions in real-time, you can join the Discord over at patreon.com/shoptalkshow.
Chris, do you have anything else you'd like to say?
Chris: [Whispering] ShopTalkShow.com.