OwlTail

Cover image of Sam Selikoff

Sam Selikoff

13 Podcast Episodes

Latest 1 Oct 2022 | Updated Daily

Episode artwork

Positioning Open Source Projects with Sam Selikoff

The Business of Open Source

This conversation covers: Mirage’s role as an API mocking library, the value that it offers for developers, and who can benefit from using it. How Mirage empowers front end developers to create production-ready UIs as quickly as possible. How Mirage evolved into an API mocking library  How Mirage differs from JSON Server  Sam’s relationship to Mirage, and how it fits in with his business. Sam also talks about open source business models, and whether Mirage could work as a SaaS offering. One interesting use case for Mirage, which involves demoing software and driving sales. Links Mirage Sam’s teaching site Follow Sam on Twitter Subscribe to Sam’s YouTube Channel TranscriptEmily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.Emily: Welcome to the Business of Cloud Native. My name is Emily, I'm your host, and today I'm chatting with Sam Selikoff. Thank you so much for joining us, Sam.Sam: Thanks for having me.Emily: Yeah. So, today, we're going to do something a little bit different, and we're going to talk about positioning for open source projects. A lot of people talk about positioning for companies, which is also really important. And they don't always think about how positioning is important for open source. Open source maintainers often don't like to talk about marketing because you're not selling anything. But you are asking people to give you their time which, at least for some people, is actually more valuable than their money. And that means you have to make a compelling case for why it's worth it to contribute to your project, and also why they should use it, why they should care about it? So, anyway, we're going to talk with Sam, about Mirage. But first, I should let you introduce yourself. Sam, thank you so much for joining me, and can you introduce yourself a little bit?Sam: Sure. My name is Sam Selikoff. These days, I spend most of my time teaching people how to code in the form of videos on my YouTube channel, and my website, embermap.com. Most of it is front end web development focused. So, we focus on JavaScript. I have a business partner who also works with me. And then we also do custom app development, you know, some consulting throughout the year.Emily: Cool. And then tell me a little bit about Mirage.Sam: Yeah, so Mirage is the biggest open source project I've been a part of since falling into web development, I'd say about eight years ago, I got into open source pretty early on in programming, kind of what made me fall in love with web development and JavaScript. So, I was starting to help out and just get involved with existing projects and things that I was using. Eventually, I made my way to TED Talks, the conference company where I was a front end developer, and that's actually where I met my business partner, Ryan. And we were using Ember.js, which is a JavaScript framework, and we had lots of different apps at TED that were helping with various parts of publishing talks, and running conferences, and all that stuff. And we were seeing some common setup code that we were using across all these apps to help us test them, and that's where Mirage came from. There was another project called Pretender, which helped you mock out servers so that you could test your front end against different server states. And we first wrapped that with something called Pretenderify, and then it grew in complexity. So, I was working on it on my learning Wednesdays, renamed it to Mirage, and then I've been working on it basically ever since. And then, the other big step, I guess, in the history is that originally was an Ember only project, and then last year, we worked on generalizing it so that it can be used by React developers, React Native developers, Vue developers, so now it's just a general-purpose JavaScript API mocking library.Emily: So, we would say that the position is an API mocking library. And—does that sound right?Sam: Yeah. If I had to say what it is, I would say it's a mocking library that helps front end developers mock out backend API's so that they can develop and test the user interfaces without having to rely on back end services.Emily: Why does that matter?Sam: It matters because back end services can be very complicated, there can be multiple back end services that need to run in order to support a UI, and if you're a front end developer, and you just want to make a change and see what the shopping cart looks like when it's empty. What does the shopping cart look like when there's one item? What does it look like when there's 100 items, and we have to have multiple pages? All three of those states correspond to different data in some back end service, usually in a database. And so, for a front end developer, or anyone working on the user interface, really, it can be time-consuming and complex to put that actual server in that state that they need to help them develop the UI. That can involve anything from running, like, a Rails server on their computer to getting other API's that other teams manage into the state they need to develop the UI. So, Mirage lets them mock that out and basically have a fake server that they control and they can put into any state they need. So, it’s like a simplified version of back end services that the front end developer can control to help them develop and test the UI.Emily: And when you first started Mirage, did you think of it as an API mocking library?Sam: Not exactly. We used it mostly because of testing. So, in a test, it's usually a best practice to not have your test rely on an actual network. You want to be able to run your test suite of your user interface anywhere, let's say on an airplane or something like that. So, if your user interface relies on live back end services, that's usually where you would bring in a mocking library. And then you would say, okay, when the user visits amazon.com/cart, normally, it would go try to fetch the items in your cart from a real server, but in the test, we're going to say, “Oh, when my app does that, let's just respond with zero items. And then in this next test, when my app does that, let's respond with three items.” So, that's the motivation originally, is in a testing environment, giving the UI developer control over that. And then what happened was that it was so useful, we started using it in development as well, just to help during normal times, just because it was faster than working with the real back end services.Emily: Do you think there are any other projects that do something similar?Sam: Yeah, for sure. I think the most popular one is called JSON Server, which is a popular open source library that lets a front end developer put some data in a file, and then you point JSON Server to it, and then it just gives you an instant mock server you can use to help develop your app.Emily: So, what's the difference between Mirage and JSON Server?Sam: The difference is that JSON Server is made—it's really optimized for giving you a development—kind of a fake server as fast as possible, but it comes with a certain format that it gives you the data in. So, what ends up happening is that it can help you get feedback and build your UI faster, but eventually, you're going to need to point your app at a real API server, whatever you planning on using in production. And so the way JSON Server works might not correspond—in fact, often doesn't correspond with your actual API. So, Mirage fills that gap because Mirage is designed to be able to faithfully reproduce any production API; there's ways to customize how the data comes back so that it matches so that as you're developing your actual user interface against Mirage, you can have confidence that it'll work once you switch over to production.Emily: Is Mirage slower than other options?Sam: Not performance-wise because they're all JavaScript code that runs in the browser, but JSON Server is really optimized for just getting started as fast as possible because it comes with all of those pre-baked conventions about how the data is going to be moving back and forth. So, with Mirage—it can be faster, it depends—but with Mirage, you need to learn a little bit more in order to understand how to faithfully reproduce your production API. But I think it's faster because in the long run, if you're writing code against a mock server that doesn't match the interface of your production API, then you're just going to be having to change that application code that you're writing.Emily: How much do you talk to other people in the Mirage community, and talk about how they're actually using it?Sam: I felt more in touch with the users when it was an Ember project only because Ember is a more niche-type community. Whereas now, there's folks using it in React and Vue, like I was saying, and Angular. And so, we get issues almost every day on the project. It's not like a mega-popular project, but it does have enough people using it that people will ask questions, or open an issue almost every single day. And so I try to stay in touch with the users through that, basically. And then when I went to conferences—you know, before 2020—I would love to talk with people about it, or people would just bring it up. That's kind of how a lot of people know me on the internet. So, I would say that I do it in kind of a passive way. I haven't actively gone out to talk to them, partly because it's an open source project so it doesn't contribute to our revenue. We have some ideas for how that might happen one day, but as of right now, we can't justify doing proper product development on it in the sense of spending time doing customer interviews and stuff because it's a free project right now.Emily: That is my next question, which is, how does it fit in with your business in the larger sense? You know, how you put food on the table? And what are your goals for the project?Sam: A good question. I mean, it's really aligned with our overall mission of, of everything that we do because me and my business partner, Ryan, we really want to just help people get better at UI development, we want it to be easier, we want to help empower more people to do it because we think it's powerful tool in the world, and it's just too hard right now; there's so many things that are hard about it. So, that goes back to our consulting and our teaching; mainly our teaching. That's our main mission. And then Mirage is really—the purpose of Mirage is to enable front end developers to do more kind of with less, so they don't have to run a Docker container or get an SQL database up just to change some CSS for a given server state. So, it fits into that mission. I've been doing open source long enough to know the pattern, and it happens over and over again, where people work on something, it gets popular enough that they start opening issues, and it becomes a maintenance burden for the maintainers, and then they try to stay up late closing issues, they get burned out, and then the project kind of rots. So, that's something that happens a lot in open source. And so, over the last five years or so of working on Mirage, I've been more involved, or sometimes step back if I need to spend more time on other things, but I'm really interested in making it sustainable, and I know some people in the open source community who have made their projects sustainable financially, other with a pro plan, or support plan, or different related services. So, if we could snap our fingers, that would be what would happen, and that's what we're working on now.Emily: Which one of those open source business models do you think is most appropriate?Sam: At this point, we basically are trying to not guess that answer because we think the way to find out which one it is, is to get a critical mass of users and listen to what they're saying. So, on our podcast, we interviewed Mike Perham from Sidekick, who runs Sidekiq and Sidekiq Pro in the Rails community for about 10 years, and he makes really good money. Sidekiq Pro came about because the enterprise customers of Sidekiq were asking for more robust job servers and all this kind of stuff, so there was a natural path for him to making a pro version that he could sell to enterprise clients. And so that's worked out really well for him, and the rest of the community gets to use the base version for free. And I love that because I do love this zero-cost to entry to open source. And then my other friend, Adam Wathan who works on Tailwind, he's made money to help Tailwind be sustainable through education and courses, and then more recently, a project called Tailwind UI, which is pre-built UI components with Tailwind. And that, again, came about from people asking for that after he was working on Tailwind. So, I think the best way to do it is to get that critical mass of users to the point where you know what they're asking for, you hear over and over again, and then it makes sense to go forward with that.Emily: There's also a third option, which is a cloud service, and I'm just curious—like a complete SaaS offering—have you ever considered that?Sam: Absolutely. There's a really cool opportunity there for Mirage because your Mirage server usually lives alongside your front end code so that when every individual front end developer pulls the project down, starts working on it locally, they're running their own Mirage server. But some of the things that people have done organically with Mirage is, create a certain configuration of a server state—let's say for a demo—so let's say they create a shopping cart, or let's say they're working on a financial piece of software, and they need to show what it looks like with three clients and four contracts, and here are the products that we sold and how much money they are. People will make up a Mirage scenario with that specific set of data that their salespeople take and use on sales calls. And that way, again, the user interface looks fully realistic, it's a fully working UI that is talking to Mirage, but now you don't have to worry about the actual back end servers going down or anything like that. And so, we've had this thought of a hosted Mirage, basically like a Mirage cloud, where even non-technical people could tweak the data there, and then again, they don't have to get involved with ops people or anything like that. And that could be really powerful. So, there's a ton of ideas there. I think our hesitation with our company, Embermap, it's worked to some extent, but it's not grown to the point where it can sustain us, and so that's partly because of the market issue, Ember being a little smaller. So, we're nervous to jump into any particular solution before we feel there's a proven market need for it. And so that's why, even though we have a lot of these fun ideas that I think could really work out, we first want to wait until we get that critical mass, the audience size that we'd feel comfortable could sustain a business.Emily: How many people is that? What is the audience size?Sam: That's a tough question. Let's say Mirage cloud was the goal. I think instead of waiting to a certain point, and then trying to build Mirage cloud, we would do a few things in the interim that would be little experiments and lower risk. So, I think the first thing would be, let's say, a Mirage course. And if we can sell a course on Mirage—or even we make a free Mirage course—that gets enough attention, that would tell us that there is enough of a need there, that the positioning resonates, that people are seeing it's a valuable thing, and that would tell us, okay, let's try the next thing. So, we've been trying to do that. I make some YouTube videos over this last year, and I've been tweeting more about it and the work we've been doing, and so all of those are little experiments that I'm trying to pay attention to what resonates. Again, we have users who really love Mirage, and it's changed their workflow, but it's not at the point where I feel like it's a slam dunk and it makes sense to go on the next phase. So, I think there's been some frictions with Mirage, as we've brought it out to the wider JavaScript community. So, we have some things we want to tweak, and then ship a 1.0, and then I think maybe a 10 video course, would be a good next step, and just see the response to that, and basically take it from there.Emily: Yeah. It's always interesting to think like, how will that you have reached the critical mass?Sam: Yeah, I mean—Emily: Hard. Sam: It's really hard. And there's other strategies. I mean, a lot of businesses just have an idea and go try it out. There's this book I read, called Nail It and Scale It, and they talked about finding a problem. And we’ve have had some users of Mirage who use it at big, bigger companies, and it's really a big part of their workflow. And we've thought about, “Hey, what if we were to build something for them that we could generalize?” They actually have a need for something like a Mirage cloud because every time they develop a feature, they have to sit down with their product people, and their front end developer will basically run through all these different Mirage scenarios to show them how the feature works in every case, and they would love to be able to just send a link to a hosted version where they could do that. So, we've thought about building that kind of thing. But again, it's just a big risk. And then the market risk is there. So, what I've seen, I feel like, working in the past few years with a small circle of small business people and open source that I hang out with is this audience-first approach. So, it's like, if you're delivering a lot of value in the form of open source, and education, and talks, and you build an audience that believes what you have to say, and likes your opinion on things, likes your point of view, and again, resonates with the value of your work, then it becomes more and more obvious. You have a lot of people giving you feedback, you start seeing the same thing over and over. And that's just what we do with developing Mirage itself. We know a lot of what we work on next is driven by the same issues that come up, the same problems that come up in the issues, over and over again. So, I think it is hard to know, but it's one of those lukewarm things. And basically, right now, it feels too early. You know?Emily: And do you feel like, when you say to somebody, let's say, somebody who isn't involved with Mirage at the moment, maybe you're at a developer meetup or something, and you say, “I created Mirage. It's an API mocking library.” Do you have an aha moment? Are they like, “Oh, yeah. I know what that is. I know why you would use that.”Sam: Mm-hm. Sometimes yes, and sometimes no. There is a form of position I feel like, sometimes, really resonates well with people, which is like, “Don't get blocked by your back end developers.” So, if you're a front end developer, and the API is not ready, you can still build your app, including all the dynamic parts of it which would normally require a real server to be running. So, you're the front end developer, and you're trying to wire up the interface, and what happens when you click save on a cart, and it saves it in the back end, and then you show a success message. But your API is not ready, and you're working with another team that's working on the API, so you're kind of frustrated because you're stuck and you feel like you can't do anything, well, that's where Mirage can come in because you don't have to wait on them at all. You can just build it out yourself with Mirage. It's much simpler because it abstracts away all the complexity of a real server enough that you can actually build your UI against this kind of faithful reproduction of the back end. So, people really like that. And then people really like the testing use cases as well. They get confused about the best way to test user interfaces in this new distributed world we're living in where you're maybe working on a React app, and the back end is a separate API that's also serving up iPhone clients and things like that. So, there's really multiple apps involved with running a website like amazon.com. So, the question is, how do you test the front end? And Mirage is a great answer for that as well. And that's where it originally came from, so.Emily: Yeah. I can definitely see the positioning is sort of like a way for front end developers to decrease their dependence on their back end colleagues.Sam: Yeah, exactly. It's hard because there's a lot that it helps you with. And the people who use Mirage the most and have used it the most, it's really transformed their workflow because it lets the front end developer just move so much faster. So, it's really just, like, the fastest way to build a front end. That's really what the whole point of—every change we make to the library, every decision that went into it, it's how to empower a front end developer to build a production-ready user interface as fast as possible. And that includes accounting for all these different server states that are usually a pain in the butt to get.Emily: I'm just taking notes. I mean, that that actually sounded really powerful. Like, “Mirage lets front end developers work as fast as possible,” basically. It's fairly high level, but ultimately, that is a pretty compelling value statement.Sam: Yeah. And I believe it to be true, too. And I mean, that's how—I mean, I've been working on apps recently, and I still use Mirage because it's just faster than using a real server because it's right there in your code. It's right alongside your front end code, so you don't have to switch over to another process running, or open up a browser and see it; it's all right there. If you want to switch from being an admin to being a user, it's like you just uncomment a line alongside the code that you're already writing. So, I truly believe it is the best way to build a user interface. I think the positioning question is interesting because that is high-level. Sometimes developers in open source, they just want to know what it is, so there are some people who would see, “Just tell me what it is.” “It's an API mocking library.” “Okay, got it.” And that's what they want to know. “And what makes it different from other API mocking libraries?” Okay, we can talk about that. But then there's other people I think, who could stand to benefit from it, and if they saw, “Mirage is an API mocking library,” they're going to be like, “I don't really need that.” But then they go back to their job, and they have to work on their app, and they find themselves spinning up a Docker container, going to auth0 to sign in just so they can run their app in an authenticated state, and it's like, Mirage would actually be perfect for this. You could just mock all that stuff out in Mirage once, all your front end developers could use it. And now anytime you want to just work on your app in an auth state, it's just right there in Mirage, you don’t have to deal with any of the complexities of the production services.Emily: Yeah. I mean, I also like the idea of sort of the fastest way to build a front end app.Sam: Yeah.Emily: Or to build a UI. The fastest way to build a UI.Sam: Yeah. That is, that's nice. I mean, it's interesting. It's a pretty interesting thing to say, and it's pretty compelling, and it's like, if you can back it up, that's a pretty strong claim.Emily: Yeah. And I mean, one of the things that I also talk to clients about—so I work with all technical founders, usually, and we're often really focused on features, all the cool features, but—you don't have to ignore the features, but you sort of use them to prove that the thing that you're talking about, that the value you say you provide is not BS. But you still want to connect the dots. Like you were saying, sometimes even the most technical person is like, “Oh, a mocking library. But I don't need that.” They're not going to necessarily connect the dots that, like, “Oh, that's going to make my workflow way simpler.” Sam: Right.Emily: Does everybody know what a mocking library is? Like, everybody who needs one?Sam: Mm, depends. If you're a front end developer. I mean, these days, people are becoming more and more specialized, so there's some front end developers who don't even deal with the data fetching side of an app at all. They're working on a part of the app that already has the data, and they're just working on maybe styling, layout, things like that, but they're never writing code or refactoring code that actually interacts with the server. And then even if you are doing that, you might not be writing tests. So, a lot of people just do the lowest friction thing, which is, just point their local UI at whatever server they can. Maybe their company has a staging server or maybe they run one locally in development and they just build it like that. But again, that's the lowest friction, but it's slow because now you're running a Rails server. If you want to change the data, you have to know how to do it in Rails, and you have to run different commands. And then it comes to testing, it's really hard, too. So, I think most people would know, if you were to say, “Yeah, it mocks out the API.” Most people would know that. But people might have different conceptions of what that means. So, there are some approaches to mocking—or stubbing, or faking, there's some technical difference between those terms, but for the purpose of this conversation, it's just faking out that functionality—there's some people who would hear that and say, “Oh, okay, I get it. A function that my code calls when it normally goes to the server, I'm going to replace it with a different function that returns this fake data.” But Mirage works differently because it operates at the boundary of the app. So, when you mock your API with Mirage, you don't have to change anything about your application because it intercepts the network request before it goes to the server. So, that's another big benefit of Mirage, that Mirage has over other solutions for mocking out network functionality is that your application code stays exactly the same. And that's an important point because the whole goal with Mirage is to be the fastest way to build a production-ready user interface. And by production-ready, I mean an interface that can be plugged into your production API and you'll have confidence that it works. So, that boundary thing is another important point of Mirage. So, that would maybe be the one thing that people could mean different things when they say ‘mocking.’ But by and large, I would say most front end developers would understand if you said ‘API mocking,’ what they mean.Emily: And do you think they generally are also able to figure out what that's used for, why they should care?Sam: Yeah, that's the thing is that that's where I think the real opportunity is because I think, if you were to say ‘API mocking,’ people are going to immediately go to testing because that's the kind of environment where you would want to mock the API so you have control over it. But people who haven't used Mirage or something like Mirage, don't realize how powerful it can be, to mock it just during your normal development flow. So, again, once people use it and get it, they use Mirage for everything; it's just part of their workflow. I just start up my UI, I'm running Mirage in a specific scenario, and if I need to see the UI in a different state, I just changed my Mirage scenario, or put some new data in there, or empty out the database there. And so it totally affects your whole workflow because now you're just disconnected from the back end services. So, I think a lot of people aren't doing that. They are just stuck—you know, they're just used to the hassle of getting these three services up and running just so that they can run their UI, and it's a pain in the butt. I mean, I was just talking to someone on another podcast, and he was saying it's the same thing. And it's really hard when they onboard new people because they have to get them set up with all these auth keys just so they can run the front end, even though they don't really care about the auth setup, they just want to start working on this page. So, again, the companies that have used Mirage and adopted it don't have any of those problems because the Mirage server is right there with the user interface, and they don't have to worry about it. So, I think that is a big gap that we could probably do a lot better job of closing with information on the homepage, or examples, or something like that.Emily: So, Mirage also helps new hires get up to speed a lot faster, or get productive, I should say?Sam: So, yeah. If you were hired by Facebook, and you're a front end developer, and your first task is to update the way the colors look on the home feed, to get that running on your computer so you can make changes and see how it looks in the code, at many companies—probably most companies—it's going to involve a lot of moving pieces because you have this React app on the front end, but it has to fetch data from somewhere so you can see how it works. Maybe they have a server that is just used for development that the person can point to. But again, if you have this shared hosted server, you only get what's on there; maybe you don't have an easy way to change what data it gives you. So, usually, front end developers need to see a dynamic user interface in all these different states. But if you're using a shared server, you don't get all those different states. But it's easier to set up because it's already set up. So, the alternative is to say, “All right, Sam, you're new here. Let's get you set up so that you can run a copy of Facebook locally.” So, that usually involves a ton of steps. I mean, I've seen that take, like, a week just to get all the pieces that are required to run the back end up so that you can actually power your front end. So, yeah, companies definitely, definitely have a problem with this. They have a problem with shared staging servers, I’ve talked to tons of people over the years who hate their staging servers, the back end teams, the ops teams hate them because everyone's always trying to change it for the salespeople to go take demo calls or for people to test. And so basically a shared server like that is just a nightmare because it's basically another production server to maintain that your internal team is trying to use and people want it to do different things. So, that's why Mirage is nice because it's just local to the code, and every front end developer can just tweak it in exactly the way they need for what they're doing at that time. So, I think that's a big opportunity as well.Emily: One of the most interesting things, I think, about this conversation is that you've touched on this idea of salespeople doing demos, and I really like that because it's so different. It's such a different use case.Sam: Yeah. We had a thought about that, actually because we were talking to a handful of companies—did interviews with them, actually, a couple years ago—and we're like, this could be a cool product. And it's like, just the easiest way to show off your software. And again, we've even done consulting for companies that have had basically another server, just for the purposes of a demo. And again, it's just a pain in the butt because it's another production server to manage, you have to reset the database after each call you do, and with Mirage is not like that; it just restarts with the app. It's just heavier, it's a real server to manage, where again if you just need to show off the UI, you can do it with Mirage. So, we thought about doing that. It's an interesting use case, for sure.Emily: I think it's a really good illustration of how you can take the same technology, and reposition it, basically, to do something totally different, have a totally different set of value proposition. The people who would be actually benefiting from its use would be totally different. I mean, you have salespeople versus front end developers.Sam: Yep. We've thought about that. What would that look like to market to those people? And maybe one way you could do it would be, you know, the salespeople get frustrated because they want to just change the numbers in this part of the app on the spreadsheet summary because they know it's going to help them communicate the value to the people that they're talking to, but now they have to go and ask some back end developer or someone on the ops team, “Hey, can you change this database column so that my demo works better?” What if they had a Mirage-powered demo and they could tweak the Mirage data, maybe in some interface themselves, without having to involve anybody. And that's pretty compelling because Mirage, again, is designed to work with any API. So, no matter what your tech stack is on the back end, Mirage works for the front end team. And so now the back end team can do all their stuff, they can be switching from Rails to Elixir, they can be switching to Go or microservice architecture, and they have all this stuff going on, so they're the only ones who really know how to actually get this number from 100 to 200 in the system. Like, it's complicated. And so that’s, again, a benefit of just having Mirage because, on the sales calls, the people are just wanting to show what it looks like when the data is a certain way. So, yeah, that was definitely a use case that we didn't anticipate at all.Emily: Yeah. And even you could have five salespeople trying to do calls at the same time and—Sam: Exactly.Emily: Wanting to have different data reflected, and I'm sure that's just like—Sam: A nightmare. I mean, people have told us just, it's the worst. Basically, the shared staging server is a—yeah, it's a huge problem for a lot of teams.Emily: It’s so interesting. Well, anyway, taking us back from the rabbit hole, although it—I mean, it really is interesting, and just fascinating how you could change this to be something that's targeted at that totally different market.Sam: Right.Emily: To wrap up. I mean, I was thinking about how you're saying that the fastest way to build a production-ready UI, that possibly is the most powerful thing I think you've said.Sam: Yeah. We actually—I think that's how we had it when we first did the redesign of the site. And it was like, I don't know if that stuck in the sense of, what does production-ready mean? “Oh, I'm already writing production-ready code.” But then it's like, you have to—like you said, connect the dots and explain how you're not writing production-ready code unless the way you're mocking your API is matching your production API, so we kind of switched it to what it says now, which is, “Build complete front end features, even if your API doesn't exist.” Which basically came from the mouth of someone who was using it, and when they had their aha moment that was what they were saying. I've been thinking if we get to the 1.0 launch, I think I would want to go back to something like that because I do think it's compelling. So, “It's the fastest way to develop a UI, test it, and then share a working demo of it,” because that's is really the motivation for the library. So, yeah, it might be interesting to think about doubling down on that as the unique value proposition.Emily: Yeah. I'm curious what your immediate plans are.Sam: So, we've been working on this REPL playground area of the site where people can learn Mirage and see examples, and we can share them and stuff. So, that will hopefully—you'll see a lot of that kind of thing in the JavaScript community. If you go to Svelte, which is another front end framework, you can create little sandboxes and play around with Svelte and learn it. So, it's a really good way to learn things and just see how it works quickly right in the browser without having to install anything. So, we're about wrapping that up. And then I think it'll just be a matter of carving out the time to go through some of the issues and bugs that people have found, and getting it to a point where we feel good about slapping a 1.0 on it. At which point, we can take a look at all the feature requests and all the issues that people have run into and figure out okay, where do we want to focus our time? Again, considering, like, is there a story here where we can make it sustainable, and hopefully, dedicate more of our time to it? Because that's really, again, I think it's the biggest impact work I've done in my career so far, but it's just, sustainability in open source is tough. So, it's a matter of not jumping too early on any particular idea for how to sustain it and monetize it: if it's a pro version, if it's a support plan, people have asked for all these things, but not maybe in the strongest numbers that would make me feel comfortable diving in on that. But I do believe that it can work because I believe it's a really good idea and I know a lot of companies have gotten a lot of value from it. So, that's what our short term plan is.Emily: Well, fabulous. Thanks so much for talking about Mirage. This has been really interesting.Sam: Yeah, thanks a lot for having me, and I appreciate your input. It was fun to revisit the positioning stuff. It's been a while, so it's always good to be thinking about that.Emily: All right. I have one last question for you, which is what is an engineering tool you can't live without?Sam: These days, it's got to be Tailwind. It's a styling framework. And it's just really excellent. So, I would not want to work on a site without it because it would just be painful. So, [laugh] I love Tailwind. Yeah, it's a really good library.Emily: All right, cool. Well, thank you so much. And—oh, what—the very last thing it should be, how can listeners find you, follow you, keep up with you?Sam: Yeah, best place is Twitter, at @samselikoff. And I'm also making YouTube videos more and more these days: youtube.com/samselikoff. So, those would be the places to go.Emily: Right. Excellent.Emily: Thanks for listening. I hope you’ve learned just a little bit more about The Business of Cloud Native. If you’d like to connect with me or learn more about my positioning services, look me up on LinkedIn: I’m Emily Omier—that’s O-M-I-E-R—or visit my website which is emilyomier.com. Thank you, and until next time.Announcer: This has been a HumblePod production. Stay humble.

38mins

25 Nov 2020

Episode artwork

110: Sam Selikoff on Finding a Full Stack React

React Podcast

News!We have a YouTube channel for React Podcast 🥳Watch the livestream of this chat with Sam and Subscribe for future chats!FeaturingSam Selikoff — Twitter, GitHub, Websitechantastic — Twitter, GitHub, WebsiteLinksFrontend First Podcast with Sam Selikoff and Ryan TorontoEmberMap — videos for professional Ember.js developersNextJSMirage — Build complete frontend features, even if your API doesn't existFirebaseHasuraJSON APISam's Recipe SiteNetlify AuthFirebase AuthSponsorsInfinite RedIn over your head with a React or React Native app?Infinite Red can help.They are React Native core contributors who've been designing, building and shipping apps for over 10 years.Learn more at reactpodcast.infinite.red.imgIXimgIX helps you deliver sharp, snappy images to customers with a powerful image processing and a simple API — delivered on a global CDN.Get a $300 account credit by visiting imgix.com/reactpodcast.Get involvedBlack Lives MatterPlease join us in donating to the Equal Justice Initiative

1hr 1min

17 Sep 2020

Similar People

Episode artwork

133: Sam Selikoff - Building Production-Ready SPAs Fast with Mirage.js

Full Stack Radio

Topics What is Mirage and how does it work? What makes Mirage better than a dummy JSON server you run on another port? What makes Mirage better than running your actual API locally? Using Mirage for actual development, and not just for your test suite How Mirage's internal ORM works, and how it can help you mirror your API's behavior more quickly Managing the risks of maintaining a complex stub of your real API with Mirage and keeping them in sync What's next for Mirage Links Mirage.js Mirage.js on GitHub Supporting the showI decided to stop taking sponsors for the show because I think advertisements are annoying and no one wants to listen to them.If you do want to support the show, the best way to do it is to pick up one of my books or courses: Refactoring UI, a book and video series I put together with Steve Schoger on designing beautiful user interfaces, without relying on a designer. Advanced Vue Component Design, a course on designing simpler, more flexible Vue components that are both more powerful and easier to maintain. Test-Driven Laravel, a massive video course on designing robust Laravel applications with TDD. Learn how to build a real-world application from scratch without writing a single line of untested code. Refactoring to Collections, a book and video course that teaches you how to apply functional programming principles to break down ugly, complex code into simple transformations — free of loops, complex conditionals, and temporary variables.

1hr 3mins

29 Jan 2020

Episode artwork

MJS 121: Sam Selikoff

Devchat.tv Episode Roundup

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Ruby Rogues React Native Radio CacheFly Host: Charles Max Wood Joined by Special Guest: Sam Selikoff Episode Summary Sam Selikoff, Co-Founder at EmberMap shares his journey of how he became a developer. Sam was an Economics major in college and he really loved the theory of economics. When he graduated, he started working as a consultant and while working with data for statistical analysis he found that he enjoyed working with SQL and that how he started his developing career. Sam explains why he prefers Ember.js framework to other frameworks. He also talks about the projects he is working on currently. Apart from coding Sam enjoys reading economics books and playing music with his family. He shares some of his favorite books to read on the Theory Of Economics. Links JSJ 364: Ember Octane with Sam Selikoff EmberMap Podcast Sam's Twitter Picks Charles Max Wood Podcast Movement Sam Selikoff UPLIFT Desk Midsommar Movie

27mins

3 Sep 2019

Most Popular

Episode artwork

MJS 121: Sam Selikoff

My JavaScript Story

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Ruby Rogues React Native Radio CacheFly Host: Charles Max WoodJoined by Special Guest: Sam SelikoffEpisode SummarySam Selikoff, Co-Founder at EmberMap shares his journey of how he became a developer. Sam was an Economics major in college and he really loved the theory of economics.When he graduated, he started working as a consultant and while working with data for statistical analysis he found that he enjoyed working with SQL and that how he started his developing career.Sam explains why he prefers Ember.js framework to other frameworks. He also talks about the projects he is working on currently.Apart from coding Sam enjoys reading economics books and playing music with his family. He shares some of his favorite books to read on the Theory Of Economics.Links JSJ 364: Ember Octane with Sam Selikoff EmberMap Podcast Sam's Twitter PicksCharles Max Wood Podcast Movement Sam Selikoff UPLIFT Desk Midsommar Movie

27mins

3 Sep 2019

Episode artwork

MJS 121: Sam Selikoff

All JavaScript Podcasts by Devchat.tv

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Ruby Rogues React Native Radio CacheFly Host: Charles Max Wood Joined by Special Guest: Sam Selikoff Episode Summary Sam Selikoff, Co-Founder at EmberMap shares his journey of how he became a developer. Sam was an Economics major in college and he really loved the theory of economics. When he graduated, he started working as a consultant and while working with data for statistical analysis he found that he enjoyed working with SQL and that how he started his developing career. Sam explains why he prefers Ember.js framework to other frameworks. He also talks about the projects he is working on currently. Apart from coding Sam enjoys reading economics books and playing music with his family. He shares some of his favorite books to read on the Theory Of Economics. Links JSJ 364: Ember Octane with Sam Selikoff EmberMap Podcast Sam's Twitter Picks Charles Max Wood Podcast Movement Sam Selikoff UPLIFT Desk Midsommar Movie

27mins

3 Sep 2019

Episode artwork

JSJ 364: Ember Octane with Sam Selikoff

All JavaScript Podcasts by Devchat.tv

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit Linode CacheFly Panel AJ O’Neal Joined by special guest: Sam Selikoff Episode Summary In this episode of JavaScript Jabber, Sam Selikoff, Co-Founder at EmberMap, Inc. starts with giving a brief background about himself and his work followed by a discussion with AJ O’Neal about the Ember community. Sam mentions some of the biggest advantages in using Ember, and what it should and should not be used for. He explains the architecture of Ember apps, addresses some of the performance concerns and then dives into Octane in detail. He talks about a bunch of Ember components, compiler compatibility, relative weight of Ember apps compared to other frameworks, the underlying build system, and security considerations. Sam then helps listeners understand the usage of ES6 classes and decorators in Ember at length. At the end, they discuss component rendering and element modifiers and move onto picks. Links Sam’s website Sam on Twitter Sam on GitHub Follow JavaScript Jabber on Devchat.tv, Facebook and Twitter. Picks AJ O’Neal: Good Mythical Morning - YouTube Sam Selikoff: The Man In the High Castle Tailwind CSS

52mins

14 May 2019

Episode artwork

JSJ 364: Ember Octane with Sam Selikoff

Devchat.tv Episode Roundup

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit Linode CacheFly Panel AJ O’Neal Joined by special guest: Sam Selikoff Episode Summary In this episode of JavaScript Jabber, Sam Selikoff, Co-Founder at EmberMap, Inc. starts with giving a brief background about himself and his work followed by a discussion with AJ O’Neal about the Ember community. Sam mentions some of the biggest advantages in using Ember, and what it should and should not be used for. He explains the architecture of Ember apps, addresses some of the performance concerns and then dives into Octane in detail. He talks about a bunch of Ember components, compiler compatibility, relative weight of Ember apps compared to other frameworks, the underlying build system, and security considerations. Sam then helps listeners understand the usage of ES6 classes and decorators in Ember at length. At the end, they discuss component rendering and element modifiers and move onto picks. Links Sam’s website Sam on Twitter Sam on GitHub Follow JavaScript Jabber on Devchat.tv, Facebook and Twitter. Picks AJ O’Neal: Good Mythical Morning - YouTube Sam Selikoff: The Man In the High Castle Tailwind CSS

52mins

14 May 2019

Episode artwork

JSJ 364: Ember Octane with Sam Selikoff

JavaScript Jabber

Sponsors Triplebyte offers a $1000 signing bonus Sentry use the code “devchat” for $100 credit Linode CacheFly PanelAJ O’NealJoined by special guest: Sam SelikoffEpisode SummaryIn this episode of JavaScript Jabber, Sam Selikoff, Co-Founder at EmberMap, Inc. starts with giving a brief background about himself and his work followed by a discussion with AJ O’Neal about the Ember community. Sam mentions some of the biggest advantages in using Ember, and what it should and should not be used for. He explains the architecture of Ember apps, addresses some of the performance concerns and then dives into Octane in detail. He talks about a bunch of Ember components, compiler compatibility, relative weight of Ember apps compared to other frameworks, the underlying build system, and security considerations. Sam then helps listeners understand the usage of ES6 classes and decorators in Ember at length. At the end, they discuss component rendering and element modifiers and move onto picks.Links Sam’s website Sam on Twitter Sam on GitHubFollow JavaScript Jabber on Devchat.tv, Facebook and Twitter.PicksAJ O’Neal:Good Mythical Morning - YouTubeSam Selikoff: The Man In the High Castle Tailwind CSSSpecial Guest: Sam Selikoff.

52mins

14 May 2019

Episode artwork

107: Sam Selikoff - Pushing Complexity to the Client-Side

Full Stack Radio

Topics include: Building an API without writing any controller code Thinking of your API like a database as much as possible Modeling everything on the server as a resource, including things like S3 upload signatures Using tools like Firebase to avoid writing an API entirely Sponsors: Rollbar, sign up at https://rollbar.com/fullstackradio and install Rollbar in your app to receive a $100 gift card for Open Collective Cloudinary, sign up and get 300,000 images/videos, 10GB of storage and 20GB of monthly bandwidth for free Links: EmberMap, Sam's Ember.js training site JSON:API, the API spec Sam uses to build his SPA backends JSONAPI::Resources, the Rails gem for declaratively building a JSON:API compliant API Firebase Vuex Apollo GraphQL

50mins

30 Jan 2019

Loading