Dax Raad & Paul Swail: Some Friends Talk About Serverless and Where Everything is Headed
Dax and Paul join Adam to discuss lots of things, mostly centered around serverless. Is serverless good for startups? Do we know where serverless developer experience is headed? Are Dax and Paul actually Adam's friends or was the friendship forced upon them?
Dax is an engineer and entrepreneur that has spent the last decade building technology and teams at early stage startups. A majority of that time was spent as a consultant working for dozens of companies using different technologies across infrastructure, frontend and backend.
Most recently he's been bitten by the serverless bug and is working on Serverless Stack to improve the last mile experience of deploying full-stack serverless applications on AWS.
Paul has been delivering software solutions to customers across several industries using a wide range of technologies for almost 20 years. He is a full-stack web developer by trade and is passionate about the cloud and web technology, but even more passionate about using software to solve real business problems.
In addition to consulting work, Paul ran an AWS-based SaaS product for seven years between 2014–2021.
Paul lives in Belfast, N. Ireland with his wife and 3 daughters. When he’s not busy working, changing nappies or referring to himself in the third person, he enjoys playing and watching football, particularly the mighty Manchester United.
Adam Elmore: Hey, everyone. Welcome to AWS-FM, a podcast with guests from around the AWS community.
Adam Elmore: I'm your host, Adam Elmore, and today is different. I'm with a couple of my dear friends, Paul Swail, Dax Raad. This is not a normal AWS-FM episode because normally, I have people on and I'm really trying to highlight that person, their background, kind of where they came from, and where they are and, where they're headed. I'm not trying to do that today because you guys have heard from both of these folks on my show and other places, so you should be well acquainted. And these are just people that I really want to get on a call together and talk about things, serverless mostly, probably. It's sort of stemming from some Twitter conversations and realizing that I see these two a lot interacting. I always want to interact with them and I thought it'd be great to interact with them together on a phone call, so here we are. And I just learned before the call that they've not actually talked face-to-face as much as I see them interact digitally, this is a first. So welcome to both of you.
Paul Swail: Thanks, Adam.
Dax Raad: Thanks. Thanks for the intro.
Adam Elmore: Yeah, so I've got some bullet points. This is the least I've sort of written out stuff and prepared for a show, because I really just have lots of things I want to talk to you guys about that I've talked with you about on Twitter, just doing it more live. I think there's more that could kind of be discussed, uncovered. The first thing I guess, Dax, when I scheduled this, when we scheduled this, I didn't realize tomorrow is SST Conf.
Dax Raad: Yeah. I actually didn't realize it either. I was like, My schedule is free and I was like, "Oh wait, I actually have something this week for once." But yeah, the conferences is tomorrow, obviously really excited. I have to finish my talk after this call, which is what I'll spend the rest of the day doing. Procrastinated to the last minute. But I think initially it actually started out as a joke. Frank, the CTO, was like, "Oh, what if we could get HBO to come talk about how they use it?" And we were obsessed with that idea and then we decided to reach out. HBO didn't agree, but a bunch of other really great companies did. And then it just all came together, so it's going to be our first conference I'm doing that tomorrow. It's going to be the shortest two hours but, yeah.
Adam Elmore: I will not release this podcast until well after SST Conf has come and gone. You're doing a talk on your new super secret GraphQL stuff, which I'm very excited about. I think you've told me a little in the past. Can you talk about that now since no one will hear this, but me and Paul?
Dax Raad: Yeah. So basically I got into serverless, I don't remember the exact time now, it's been over a year now. And over the course of that year, I've been researching how do I personally want to do stuff with this setup. I was avoiding GraphQL for a few years and I finally decided I'd jump into it and it ended up clicking for me and then I was like, "Okay, how do I want to do GraphQL on Lambda with SST?" So this stack is just a culmination of my research. I think it's at a good place where it's something that other people can use and it's going to be a 1.0 of it, or I don't know, a beta of it. But there's so much more we're going to do. There's probably at least a year of work I can see. But we're hoping it's going to be a great starting point for a great full-stack end-to-end GraphQL stack.
Dax Raad: So, type safety from backend to frontend using... We're using some tools that aren't super popular but we think will become a lot more popular over the next year. It's been a lot of cool TypeScript focused tooling that has come out with GraphQL. So yeah, the idea is, with GraphQL you can define a very strong, complex scheme on the backend now that you have that, like how far can you go with using that typing in other places. And I think a lot of people using GraphQL, they necessarily haven't had the time to really dig into the full capabilities of it. So, and it's kind of something that we can do.
Adam Elmore: So is it available tomorrow as part of the conference that is launching or is it seen?
Dax Raad: No, we're probably actually going to do a full week of releases for it a month from now. The conference has been our focus, GraphQL stack... Or sorry, 1.0 SST has been our focus. GraphQL stack has been a side project and now that 1.0 is out, I'm going to wrap it up over the next month and probably come out at the end of... Or somewhere around June.
Adam Elmore: Yeah. I think you mentioned some tools that people maybe aren't very familiar with. I think I've got those pinned, like tweets that you've written about tools that kind of blow your mind. Like I don't have to write query files on the frontend anymore and generate from those.
Dax Raad: Yeah, exactly. There's a whole class of GraphQL clients for the frontend, actually not just for the front, just anywhere, but I use them in my test as well. Where you can just write the queries using TypeScript and the typing is generated from your schema. So you get auto complete for all your queries, all your invocations, all the arguments, the response types based off of what fields you query, like the response type will match with that. There's a few clients in that category. We picked one of them that we think works well. Yeah. It's been really cool. It's really fluid. You make a change in the backend immediately in the frontend you can have access to that.
Adam Elmore: Paul, I'm realizing I don't know your stance on like, are you a GraphQL guy?
Paul Swail: Well, yeah. I initially started with REST, I guess it's existed a lot longer. But yeah I have used spelled several AppSync projects for clients and yeah some non AppSync, like an Apollo GraphQL on one client so yeah, no, I really see the benefits of GRaphQL. Just especially what you're saying with the frontend typing, just being able to define that in a schema file and just the whole [inaudible 00:06:11] side type checking, you can say exactly what you can just discover from your IDE the IntelliSense, just what queries you can make. And yeah, there's obviously the whole DynamoDB backend thing. There's just making sure that performance wise, everything's still good, but there's ways of doing that so yeah. But yeah, big GraphQL fan especially if you're doing full-stack web app. If you're doing both the frontend and backend, that's I think is there's a big win for those developers. Actually, the teams that I've built with, it's actually been a separation. So they've still seen there's been a separate web frontend team on a separate backend team and they still get the benefit as well. But so yeah, big. I think I really like... I don't know if [inaudible 00:07:04] example is AppSync. I'm guessing it's not, I didn't hear you mention AppSync. [inaudible 00:07:07]
Adam Elmore: No, so this first version is not in AppSync. Yeah.
Paul Swail: Yeah. I do not like VTL, Adam and I have had to come to terms around that. So that's, I guess, my one in the AppSync version of GraphQL that I don't like, but yeah, generally I love the concept.
Adam Elmore: And I feel like there's so many different things here that my brain is jumping off on. I feel like AppSync is sort of, there's a shift away from AppSync in the circles I'm in where maybe it's VTL, maybe it's something else. But I'm seeing aside from what you're doing Dax at SST, there's other companies and other tools that are sort of building their own GraphQL services. Can I think of the SST one Dax as like a managed service? Or is it more of like what SST is today where it's like a library that you're using?
Dax Raad: Yeah. So one of the new things we're getting into now is so far we've only shipped infrastructure contract. So stuff you use to define your infrastructure, but with this, we're starting to ship application libraries. So one of them is a GraphQL server that's optimized to run an Lambda. I think a lot of people are just using the Apollo. There's an Apollo Lambda thing. There's a few issues with that. The Apollo, just from our experimenting with it, that's where we started. Apollo doesn't bundle for ESM, so a lot of the nice tree shaking stuff goes away. It's a pretty big bundle. Also the default Apollo Lambda thing puts an express server in between. So that's like another bundle of stuff. So we just kept stripping stuff and eventually we ended up with... We found a great library called helix, which is a very well implemented low level GraphQL server. We wrapped it a little bit and now that's the thing that you point your Lambda at. So it's not a managed service. It's just like a pre-built... It's like an easy way to get a Lambda going that has GraphQL functionality.
Adam Elmore: So I want to dive into the idea of the future of serverless development. I don't know if there's been more activity lately or if I'm just more plugged in than I normally have been, but I feel like there's this convergence and or maybe it's the divergence of approaches. There's serverless ink. There's what you guys are doing at SST. There's other companies kind of getting into this space that I've been newly made aware of. And then there's the idea of rails and what does rails for serverless look like. And I don't think any of those things are rails for serverless, right? Even what you guys are building is focused around GraphQL, but then you've got obviously SST as a framework. No one's sort of made it up high enough on the stack to be building email is easier in this framework and those sort of application level concerns. Is there anything that am I just not seeing? Is there something that exists today somebody that's working on that framework or what would it look like if it doesn't exist today? I guess that was two very big questions. Let's start with the first one.
Dax Raad: Yeah. I mean, I'm not aware of it. And that's why the reason we've been thinking about it is we're like, "Oh, no one is doing this. It could be us." And this is a first step in that direction like providing more application level stuff. I think for us, the thinking was I'm... So Jay and Frank, the founders of SST, they've been in the serverless space a lot longer than I have. So they've had the feeling of, oh, serverless adoption is just around the corner for years and years and years now. So we talk about a lot of like, why does it always feel like it's about to happen but it never really does? And if we're really honest with ourselves, if there's a new startup founder, maybe a first time founder, maybe not a ton of experience, they're mostly worried about can I even build my product? And they can pick up rails or like Phoenix, similar thing to open the lecture space.
Dax Raad: And that will save them for a very long time. It'll make sure that they can pretty much do everything they need and they can get up to speed with it real quick. To get to a set up that was as good or at least comparable, I probably have to spend a year really dedicating my time to learning AWS, learning serverless. Even such basic things like where do I put my config. I kind of did discover best practices and learn all on my own. I remember when I was first getting into it, I was bought into the idea of serverless but I kept Googling real life example app serverless, because there's just basic questions that I had that there were examples of. So yeah. I'm really not aware of it. And I needed it when I was learning it and I couldn't find it.
Adam Elmore: And Paul, what would it take? You work with a lot of startups, what would it take for a startup to adopt serverless? What would that framework need to look like? I guess.
Paul Swail: Yeah. I'm trying to think. I think one of the things, there's no standard folder structure. Everybody has a separate folder structure. That's just simple. That's something which reals just decided for you. And lots of other, I guess, tools for common concerns just the likes of... Say it's a REST API you're building and you just want to write handlers in the same way that express JS did for you. Just something which is literally, you don't really need to care that it's separate Lambda functions. Like low level sort of single responsibility lambda functions is a generally recommended best practice. But if the framework just bake that in, so you couldn't really go wrong, you didn't really need to make that decision. Things like that. And I guess the other pins are like, I am permissions [inaudible 00:12:59] best recommended to have a minimal least privilege somehow building that into the framework so that the developer doesn't need to learn that upfront and also apply it every time they're building a feature which requires new permission. Something making those sort of pins.
Paul Swail: And there's a lot of general AWS overhead. Like for example, for new clients if it's a new startup and they're built on AWS, there's a lot of just the provisional AWS accounts which is in separate accounts and setting up SSO. And I have a service that I do for people but it's a lot of steps to do and people just don't know to do that. And if you don't do that, it's very hard to retro retroactively do it. Just things like that which involves some manual effort [inaudible 00:13:46] which should just be baked in as default and default features of a product. It probably needs to be a lot of some aspect of host. I don't know if it can be completely client side like IAC constructs in the sort of a CDK and I guess SST does a lot, but I don't think there still would need to be some sort of service, cloud service side things done to make it the ideal experience.
Adam Elmore: Yeah. So what about serverless cloud? So that also comes with like a whole different approach where you're building more like an application, the infrastructure's inferred, but they're doing the hosting side, they're creating the accounts for you. How do you guys feel about that offering as a long term startup strategy? I'm sure it has its use cases with like a solo stuff in particular. But with the startup, do you guys think that approach is too heavy handed? What is it on the path? Where is that?
Dax Raad: Yeah, I mean, I'm going to be a little biased because they're like a direct competitor in other ways. So I am familiar with the product just from researching it as a competitor. I think it's compelling. I think it's interesting. I think for a lot of people new to serverless it's going to feel like a great out the box experience. I don't know. It's always a spectrum. It's you do nothing for people so they have full control or you do a lot, but at what point do they have to eject out of it?
Dax Raad: I personally don't feel like where they landed on that spectrum is where... For a product that I would want for myself, it's not exactly there. I can see myself ejecting out of that fairly quickly. The inferring your infrastructure from your application, I think that's interesting. I'm glad someone's exploring that. I think there's a few efforts out, even outside of them that are going that direction. I want to see how far that can go. My gut tells me I'm probably going to prefer being explicit about at least some of my infrastructure. I know some of the stuff, Adam, you had where you define your VTL files and those automatically get picked up based off of little header things like that, that stuff I think is great. It's like semi inferred. Fully inferred, I'm not too sure about. I just want to see how they progress and maybe it's viable. I'm just not too sure now.
Adam Elmore: Yeah. Paul, do you have any thoughts on that in terms of serverless?
Paul Swail: Yeah, I really like serverless cloud. I did back in the early days, so it's probably moved on a lot. So I want to be worried about the features that I'm commenting on in case they've changed it. The initial version, it was completely like they abstracted like DynamoDB, I think they used it behind the scenes but it was abstracted into their data service. I don't know how you can... Anything which you have to eject from, I'm wary about which you may need to eject from. But I don't know if they can allow you to deploy into your own AWS account rather than into their one. I don't know if that's possible.
Adam Elmore: I'm not sure. I thought they just sort-
Paul Swail: [inaudible 00:16:50] be a big consideration, I guess. I know lockin is something which is generally FUD in terms of big cloud providers. But I think when you're a startup vendor, there's a little and you may not be there. I can trust AWS more than... Or I'll know they'll be there much as the guys are great at the team but to build your app, I guess, for sale and [inaudible 00:17:12] are similar boats. Although there's less infrastructure, you could probably a bit more portable than nature of the apps that you could deploy to those services.
Adam Elmore: And that's what I've been, I guess, thinking about is the Vercel comp. I am totally happy to deploy to Vercel and not think about the infrastructure that they're provisioning for that particular problem. My frontend is hosted, my ISR and all those next features I take advantage of, Vercel just handles it. If there were an equivalent, if there were a service that I felt like took over the backend like my GraphQL API in a similar way, I'd be pretty excited about that, I guess.
Paul Swail: Yeah. They're not doing anything massively proprietary. I don't think the services that they're offering they may be the best in class for next JS apps, but I would imagine if they went bankrupt or whatever something happened, your app you could put it to someone else with minimal [inaudible 00:18:09]
Adam Elmore: I mean, even serverless, there's plugins for deploying next steps into your account and SST, you guys have a next adapter, right?
Dax Raad: Yeah. It's funny. Because I think the pain I feel is there's all these great services like Vercel and these one off specific services that do one thing really, really well. I love them and I want to use them, but I can never bring myself to move something outside AWS because it's like, okay, I need to pass a variable from something in my AWS world into Vercel that now turns manual overs before the CDK. Everything is just in line. So to me it always feels like, okay, I'm going to always not use the best service, but at least all together in one place. And that's a painful trade off to always make on at AWS.
Adam Elmore: Yeah, no, I did the same for a long time. It was very hard for me to think about. And I think Vercel's the first that I've opened that door to. I did sort of want everything in my own account and just know that all the services are there, I've got it all in my CDK app or whatever. So I haven't had any manual steps, I guess I use the Vercel CLI to sort of automate the passing back and forth of things, but it's still nasty and I don't like... Like if you want to interact with your API from your Vercel, you have a API handler or something. A next JS API handler and you want to interact with your other stuff, like your real API, it just gets nasty. So I basically don't use any of that stuff in next JS and-
Dax Raad: Yeah, exactly.
Adam Elmore: Yeah. Have you guys heard of a graph base? It's a very small, I think they're very early just raised the seed round.
Dax Raad: No, I don't think I've heard of them. I think I'm mixing that up with that data... They're on a database company, right?
Adam Elmore: No. Oh yeah, I know what you're talking. Is that-
Dax Raad: EdgeQL or something. I forgot.
Adam Elmore: I think I know what you're speaking of and I can't think of the name. Graph base is kind of I think trying to be the Vercel of GraphQL APIs as a service. I spoke with the founder, Frederick, on kind of like whim where he just DM'd me and I didn't know who he was. He doesn't have a big following. Graph base doesn't have a big following, but getting on the phone with the guy, this is turning into a graph based commercial. I'm sorry. Very exciting and I think you look at the graph base landing pages got his investor base and lots of founders of these companies, Vercel and Netlify and whatever, have gotten behind this. It's like he's doing some of the things that I've thought this particular offering should do which is auto optimize your DynamoDB single table. So basically he's using Dynamo behind the curtain, but it's all edge based rust stuff for the GraphQL and then sort of auto optimizing your models into single table. I don't know. It sounds like he knows what he's doing. And it was very... I did not know what to expect on the call. I was very impressed. Yeah. I don't know. I just didn't know if you guys have heard of it. [inaudible 00:21:13]
Dax Raad: Because I think I like AppSync as a concept and I think AppSync actually came native us through an acquisition if I remember correctly.
Adam Elmore: Yeah. He mentioned that to me actually.
Dax Raad: Okay. Yeah. It's a good concept. A managed GraphQL service and I think there just needs to be more of them so that there's no more competition. And I want to see how far people can push things. Yeah, I was actually thinking about, well, SST one day built something like that but it sounds like graph base is in that space.
Adam Elmore: Well, I mean, I think SST is in a perfect position to do anything on the serverless front. And I love the idea of you guys moving into more like [inaudible 00:21:48] I saw in a tweet where you said application stacks and I wanted to ask you what that meant, but I think you've already explained. Yeah. Getting into the more managey like we're going to do stuff for you, not just give you tools. Yeah. So, I think the tweet that started this, like why I wanted to get on with the both of you, Paul, you had tweeted about startups. Not necessarily adopting serverless. That had been my feeling as well. I sort of consulted for startups mostly and I guess, Paul, you wrote a little blurb summarizing your findings but I was looking through the responses is good. Would you want to summarize some of those responses that you got?
Paul Swail: Yeah, there was a lot. And I guess the question I asked is I think I'd heard from that there was a recent accelerator cohort. I don't know what figure I allowed to say publicly, but I'll just say that there was a large, a very well known accelerator cohort and there was this very small percentage of people were actively meaningfully using serverless and just asking for reasons why is adoption. And I was specifically asking about funded startups, that's because I was just potentially and selfishly looking to potentially target them for my consulting services. But I wanted to know if it was worth the effort or why are some fee funded startups coming my way. But actually just talking... And sort of related, before you get into the answers to that. I was talking on actually in real life and Friday to a lot of math culture and other sort of people who've worked in big enterprise serverless apps and just the difference in their concerns and to me in the AWS community, it seems very... Maybe I'm just by enterprise heavy or like big people who've already adopted [inaudible 00:23:36].
Paul Swail: It's easier for them. They have sort of dedicated platform teams or whatever to help them that they have sort of different concerns about using serverless than me coming from a startup point of view. And yeah, just the lack of the answers to my Twitter question were I think the main one, there was just general lack of awareness. The startup has to through main goal is to get version one chip to test some hypothesis and or to show investors and CTOs will just use whatever they already know. And I think that's fair and that any new technology has to be in its time to just get to that level of awareness. So, but some other more fun things specifically to surplus and to startups, just the steep learning curve I think was the main thing. That there's a lot of aspects to that, that can be broken down into, okay.
Paul Swail: Like event distributed systems in general are more difficult to understand, observability and lots of people who want to build startups probably just want to build a [inaudible 00:24:38] app possibly to... And initially they might even be aware of the concepts of a lot of distributed [inaudible 00:24:46] messaging and all that thing. But so, yeah. And the other sort of predominant aspect was the developer experience in tooling really doesn't match what other sort of server based applications have. I guess you'd mentioned rails before or similar [inaudible 00:25:07] I don't know it. But those sort of, I guess, opinionated application stacks which just sort of show developers can just start. Service doesn't really have that right now.
Adam Elmore: Well, I guess am I just trying to make serverless good for what I do, which is like work by myself? Is it actually not as good? Is it mostly for big teams and I just try to make it good.
Paul Swail: I guess it's hard when... I'm trying not to be bad, I've been in the serverless space for quite a few years. A you know what you know and you know how quickly you could build with what you know. So, but I think there was a good point like some of the real benefits of serverless are that the deployment and scalability or the scalability aspects, which is great. But you don't really care about that as a startup in the early stages. Scaling to zero was great, because you're not paying for it while you're... But scaling high, it's probably a funded startup would just throw engineers at it once it's making enough money to get that the care. So that is maybe not so such a big sale, but I don't know.
Paul Swail: I still think somebody, I disagreed with this, but someone said that you can build a monolith app and deploy it to a monolith server based app on a server based production architecture and deploy that with less effort. I think that's developers who have application developers. They're just thinking about the application code part of it. I still think the whole deployment and the provision in the infrastructure and building the CICD pipeline, which I would want to do for any sort of startup to deploy stuff fast. There's still a lot of work there, even for an early stage startup. So I still don't know. You could still have a very simple synchronous best API using Lambda functions and API gateway and DynamoDB and nothing else. And you could build a pretty reasonable V1 with that. So, but yeah, there was lots of nice... The application having a nice application framework which just shows you have the folder structure and how to do everything would really make it a lot easier.
Adam Elmore: Yeah. So which one are you is building that and how soon, because-
Dax Raad: [inaudible 00:27:25]
Adam Elmore: Is SST going to build that? Because it would be really great. I do hate structuring projects and I don't realize how much I've just given up from a past life and woke up one day and suddenly this is life, but-
Dax Raad: Yeah. It's where we started. We're kind of headed in that direction. Going back to the thing with, is it actually good for startups? Most of our users are startups. Our conference tomorrow we're highlighting a lot of big companies, but we're also highlighting a bunch of startups and they're the majority of our current user base or who we're targeting. And I do believe it is very good for startups. I think all three of us have a lot of consulting experience. I love that experience that I've had, it lets you see all different companies, all different variations between them. What is true, globally what is true specific to a company. You really get a sense of how the gaps between different companies. You know when you work at one company you imagine, okay, there's some companies better than us. They're probably 20% better. And a lot of companies that are worse than us, probably 20% worse. When you're consultant, you realize there's some companies that are a hundred times better, literally a hundred times better [inaudible 00:29:49] an exaggeration.
Dax Raad: And I think if you want to be one of those, there's always going to many people better than you, but there's always been people worse than you as well. If you want to push along that bar, I do believe serverless is one way to do that. Today it requires a lot of upfront learning, but that's kind of the cost that exists. I think if you've been through the startup cycle a few times, you're not as worried about can I even get a product up. You're more worried about how do I prevent my company from being a terrible place to work out in year two, year three. And I think those are the people today that are interested in serverless because this is a path to helping that. But it's just one that's like a hierarchy of concerns. You're not really worried about the quality of your company in year three the first time you're doing a startup up. So I think that's why we're not seeing as many people care about this, but if we can just make that a thing everyone gets for free, then I think we'll see more people use it.
Paul Swail: No, I think just that point about first time finders and not first time finders, there's a distinction there. I guess they haven't went through the pain of knowing what's involved first time finders of infrastructure and they also... I had my own SAS and when I fell for this, I treated it as like playing with the infrastructure and that was actually in a strange way. It was totally not helpful for the users, but it was interesting and you could see it as a playground and I think some people do. Serverless is just abstracting away too much for them and they just want that control. So yeah, there is that stream from a pure, it has a really good business case serverless but there is a developer. Developer always wants to build something that desire to just tinker and just make sure it's tinkered at the right level off abstraction.
Adam Elmore: I don't know why. I feel like I'm sort of trying to go to bat for Dynamo or for serverless when I feel like they're under appreciated. I don't know what that comes out of. I definitely have a very specific view and it's so nice to see people like you guys talk on Twitter to kind of open my eyes to other views. I don't think about a company that has teams. I just don't think about that use case because I just don't care. I care about small teams, like one group of people building a thing. And that's where I think serverless, I guess, is so great that a small group of people can do a whole lot when those people are skilled with serverless. And I guess that's the key.
Paul Swail: Yeah. I think what you said there is pretty much, I think, coming around to my whole... Even my whole outlook on helping people with serverless and not really serverless is a vehicle through which to help small teams. I hear lots of people using serverless in the enterprise and that's great, but I'm never going to help them. I'm helping small teams. Especially the whole DevOps aspect where up would've been a separate person deploying and provisioning stuff. That's just the developer can do that. The developer building the features has a part to do all that and it's just very liberating I think as a developer working like that where you can just provision the whole environment quickly just by running just one command and or so. Yeah, that just those small team environments just from a pure joy point of view if nothing else. It's what I want to work in and want to help other people work in those sort of teams.
Adam Elmore: Yeah, same. Sometimes I wonder if I'm just drinking cool aid if I'm just whatever. Like I'm part of this very specific culture that believes this one thing but you guys generally we all agree that this is sort of where things are headed. It's just taking a long path to get there.
Dax Raad: Yeah. I think the small team angle is a good thing to bring up. I also love small teams. I think the more responsibility each person on the team has, the better the product is the better the environment is. As soon as your company gets to a certain size, it just flips into being this different thing where you have middle managers and everyone's over overly specialized. And I think there's a perception that it has to be that way. If you're building a certain product at a certain scale, you eventually have to do that. The thing is there's pretty much counterexamples in every single industry of a company that didn't have to do that. Where they kept the team pretty small and did things that other companies have 10 X that team size for. So I don't really think there's a debate around, does it have to be that way? I don't think it has to be that way. And I think it is something we should try for because maybe not a lot of people have experience with it, but it is truly a great environment at work when your team is small.
Adam Elmore: I mean that excites me a lot to think that things don't have to get so big. I mean obviously like there are going to be huge companies forever, but maybe for building basic web applications they don't have to be huge companies. That's exciting to me. I just don't want to work in huge companies and I like working on web applications. So the more the world looks like that, I guess the better for me.
Paul Swail: Yeah. And especially with this, I guess, like the swing in the markets now there's this sudden focus on efficiency that it's coming out like it's a brand new idea. And the way I've been thinking about it is if this market turn is making you change your strategy, it kind of meant that you weren't really thinking about too hard to with. There's plenty of companies that were focused on efficiency from the beginning. How small can I keep my team? They're not really thinking about changing their strategy and reaction to the market. So I'm hoping the plus side is, okay, there is more focus on this. Is this a thing that investors will demand out of companies? It's not this thing of, oh, we can just throw more engineers at it. It's how do you design things from day one to make it so that's not a thing you're even considering, right?
Adam Elmore: Yeah. Both of you have great minds and I love reading your writings, Twitter, elsewhere. Are there things that are on your mind right now like just topics that you'd like to just share more about that you can't get out in a tweet or whatever?
Paul Swail: I'm not sure. I think the only thing that I'd say, I was chatting with Dax about... Most of my work I do on serverless framework. So, but I know there's the CDK and SST, which is on top of CDK. That whole movement towards sort of TypeScript as your infrastructure's code tool of choice. It seems to be gathering momentum. And I am going to spend time over the next month diving into SST in particular I think, so.
Adam Elmore: Same.
Paul Swail: So this scenario, I want to have your CDK for non-service projects, like at a big DPC, EC2 thing to do last couple of years ago. And CDK worked well. There's dynamic aspect to it, but yeah. I just not for any of the dynamics like parts of the infrastructure, it's just more for the TypeScript, the quality checks that you can build in at an early stage. That's what I want to explore further. So yeah, hopefully do a bit more writing in that area once I take some experimenting. But I think it goes to the whole... The single tier, like the type of developer who's going to be, I guess you're full-stack application developer there sort of felt comfortable. Whereas YAML is a sort of a hangover from sort of ups and tools being brought forward to the developer, to the application developers whereas... I know there are arguments about why declarative is better too and I can see those two, but yeah. I just think in order to... I think it will ease adoption tools if you using TypeScript what developers are already going to be familiar with.
Adam Elmore: But like adoption, you've kind of hit on something that I realized last I spoke with you Dax. I was very adamant on getting into SST and it's a thing that's been next up on my roadmap forever. It is so hard to adopt new things. And I guess that's a barrier to anybody building these frameworks. It's like your thing and you're doing your things so I guess I can't really complain too much about the people that don't want to jump into serverless because I mean, the SST is so similar to the CDK and it's months now that I've been trying to get to it
Dax Raad: A as a company that is working on a tool for developers, the way I think it really works in a lot of situations is someone's already had an existing company with existing product, in their spare time maybe they try out SST. We actually have to wait for them to leave that company and start a new project for that to actually fully materialize. So it is a very long term thing. You have to be committed to thinking in terms of years as opposed to getting a bunch of people building their company on it in the short term.
Adam Elmore: Yeah. Now that makes sense. Is DynamoDB the future, is that like... I mean, not the future. It's obviously doing lots of really big things today, but is it the future for such startups and serverless? Being all in on Dynamo, is that a good call in 2022?
Dax Raad: Yeah, I think, and we talked about this a little bit before, but I love DynamoDB. I think it, again, it's never problems that show up in the first year of your company. It's problems that show up later. I think a lot of people are used to building new features and then knowing that they're going to have to revisit six months down the road to tweak it once it gets at scale. There's a bunch of surprises that always happen. I think DynamoDB more or less eliminates that when you ship a feature assuming you followed the way DynamoDB should be modeled. It's going to run forever at any scale. And it doesn't matter. I'm not really talking about large, like huge scale, which of course it scales to. I'm just talking about normal growth where you have a feature barely being used or a feature being used by a thousand people. Oftentimes in other databases that requires some refactoring and being able to rely on the consistency whether you're on day one, day 100, day 1000. I think it's amazing. It's really hard to communicate that value, especially because Dynamo is very weird compared to what other people have used. Even for our GraphQL stack. This first version of it, we're actually using RDS because there's already a lot to learn. Learning single table design is pretty advanced. We did find a new library recently called ElectroDB that we're all in on.
Adam Elmore: Yeah. Tyler, forget his last name.
Dax Raad: Yeah. I think it's one of those new class of libraries that are highs script first. The API was really focused on inference and making a great TypeScript experience, but it also encapsulates last single table design. So I can see you using that without having to read the whole book first.
Adam Elmore: I love SST for the way you guys suck up all the really great tools. You make them much more visible. I can just follow the things you guys use because they're great. And they don't necessarily, they're not on the-
Dax Raad: Yeah. Some great authors out there that people are missing out for whatever reason.
Adam Elmore: Have you guys played... Well, I guess Paul, you're just trying to get into TypeScript as an infrastructure as code thing. Have you played with functionless? Have you guys seen Sam Goodwin?
Dax Raad: Oh, yeah. I haven't played with it yet mainly because I haven't had the-
Adam Elmore: Adoption. Sorry.
Dax Raad: Is it tied to CDK specifically?
Adam Elmore: Yeah.
Paul Swail: So yeah, I have looked in it looks great. And the problem that it solves is a really good problem. I just haven't got a chance to, but for folks who don't know it's a TypeScript library which allows you to not... I think it supports step functions, ASL state machines and AppSync VTLs. So rather than writing both those two domain specific languages you can use TypeScript, which I think is great. I think [inaudible 00:41:49] blog post does it go about all the drawbacks of using functionless like direct integrations [inaudible 00:41:56] between AWS services. Yeah. But it's a really good powerful concept, but there is a lot of developer tooling specific things like you have to use this weird language or you can't compose, you can't reuse common code that you would want to use. Yeah. Hopefully I would really like to see that do well, that functionless Sam component.
Adam Elmore: Yeah. That stuff's just kind of way over my head how it's possible, but it sort of amazes me the examples I've seen. I still haven't played with it either, but.
Paul Swail: Yeah. I think he also has a DynamoDB single table design TypeScript library, which it just show you can go really TypeScript is actually using it. You want the high this, you can define a type really specific to a string [inaudible 00:42:45] and so the PK has to begin with this exact string, one of these exact strings and it's like you can get really... But those are the sort of pins that writing a DynamoDB library. If you're writing code to talk to a single table DynamoDB. I've hit those issues. Like you use uppercase instead of lowercase something as part of the fixed string in or use a dash instead of a hash key character in your prefix, things like that which the pins that I've actually hit and would be very difficult to retrospectively fix if the data gets updated. That if you can catch that at compile time, that is a big win.
Adam Elmore: Yeah. I don't know. I feel like I'm just spewing all the random things in my head. There's just so many... I feel like so many things going on from so many different talented people pushing the bar forward. I just wish I knew where it was all headed where I could see. I'm just betting on serverless but I don't know what serverless is going to look like in five years. I wish I did.
Dax Raad: Sometimes I just want to like fast forward, like skip all this and I just want to see where we get to.
Adam Elmore: Yeah. I feel like we're at a weird point where there's just a lot of ideas and a lot of different ways it could go and everyone agrees that the developer experience isn't great. The potential is great. Where does it land?
Paul Swail: I think I seen, was it Sean Swang? I think it was Sean had a Twitter poll recently around which of these, I guess, ways will win. Was it frontend, backend, or backend its frontend. And I can't remember what the other options were. Front end eating backend, I think was the winning.
Adam Elmore: Or staying separate sort of... The frontend and backend, staying separate I think that was the other option.
Paul Swail: Yeah. That's it. Yes. So, I think the frontend eating backend was all access Vercel adding functions and gradually I guess adding eventing capabilities, I guess, or.
Adam Elmore: Yeah, I don't know. It feels like Vercel for all of its might and all of the amazing things it does on the web dev side, sort of like glosses over. I think in my opinion, the rest of the complexities of an application, maybe that is the plan that API handler like these API functions are enough to build out any application. I don't think that's their plan but maybe they... I don't know. Maybe they plan to acquire companies that are doing other things like [inaudible 00:45:08].
Dax Raad: I do feel like the backend gets glossed over. It's almost like, oh, that's just a generic detail that doesn't really matter. I think a lot of the frontend frameworks are just like, oh yeah, just a database, whatever. So yeah, I agree. It doesn't get as much attention. I also think specifically Twitter to me feels extremely frontend heavy. I feel like all the conversations are always around frontend. I'm just like, where are all the backend people at? I think that maybe speaks to some of the results of that poll.
Adam Elmore: Yeah. Even like seeing some of the responses, Rich Harris, I think responded sort of overwhelmingly like it's option number one, that frontend is going to move and take over full-stack. And that does seem like the representation on Twitter. That is the response you would expect. And I think he made good points that I think frontend is harder to just get rid of as a concept. I do feel like backend, we've talked about some of the ways that maybe things get abstracted away and get easier to build out GraphQL APIs or whatever else. It's hard to imagine abstracting away frontend, all the ways that the user interacts with your thing. So I don't know. It's all very interesting to me.
Paul Swail: Forgetting about the actual current tools and technical implementations frontend in the, I guess, the value chain is closer to the actual users. So the frontend developers are working directly either with users or with product managers or whatever. They're the guy they're... Again, going back to the small teams, if it's one person can do it, you're always going to need someone building the frontend. If the backend constructs can be abstracted sufficiently like APIs events, usual or whatever to make that easy for that one person to do. I think all the better. I think that's the natural way of doing it. So I think that's there is a natural sort of way for it to be frontend driven, pushing backwards.
Dax Raad: Yeah. I mean, the reason we're all using TypeScript is because we can't avoid it on the frontend and now it's just become the common thing we're using everywhere. Which it's great because I like TypeScript, but it really wasn't a choice, I don't think.
Adam Elmore: Yeah. So that's just a sign of the frontend eating the full sec, I guess that's a good point. Well, I really like these conversations. They helped me kind of figure out what it is I care about because I generally don't think about those sort of high level things. Like what are the things that I'm really interested in watching play out? And then I hang out all on Twitter a lot so I get a lot of frontend stuff that I end up thinking about web desk stuff I really don't care about. I do care about serverless and I care about following you two on Twitter. Where else? I guess, I don't know. We've probably done this before, but is Twitter the best place to find you guys? Paul, you've got serverlessfirst.com.
Paul Swail: Yes. Serverlessfirst.com, @PaulSwail on Twitter.
Dax Raad: Yeah. I'm really just on Twitter, @THDXR
Adam Elmore: THDXR. I remember you talking about that on the last one. Well, it's been so good. Yeah. I think since having both of your episodes, I've wanted to get both of you back on a phone call and I think we've maybe had some phone calls, but it's really great to get you together and to get to sit here and watch you guys talk. That's a real treat. So yeah. I don't really even have an after anymore. I'm not going to say things about innovative. I don't really care. Did you guys have anything else before we close it out?
Dax Raad: No, this was great. Great conversation. Yeah. Thanks for having us.
Paul Swail: No, I think that's it, Adam. Yeah. Thanks a lot.
Adam Elmore: Cool.