Ben:
Hello, and welcome to PodRocket. Today, I'm here with Fernando Rojo, who's the co-founder and CTO of BeatGig and the creator of Solito. How are you doing Fernando?
Fernando Rojo:
Great. Thanks for having me.
Ben:
Excited to have you on the show and hear about some of the projects you've worked on. I think in addition to the two I mentioned, we may even talk about some of the other things you've worked on before because you've done a lot in the React Native space. But I guess, what you prefer to talk about BeatGig first or Solito or how do you want to tell your story and talk about some of the things you've worked on?
Fernando Rojo:
Maybe I can introduce how I got into React Native and BeatGig and how I ended up at Solito. So I first went through YC a few years ago and I was building my first React Native app then. We were building a social network. So that was just for an actual iOS app. And that was my first venture into React Native I'd only used JavaScript before then. That company ended up not working out. And so then my co-founder and I, with a few other people started working on BeatGig and the challenge there was we needed to build a website and an app and React Native was in this early days of having web support too. And so as we started building that company, I decided, "I'm going to make a big investment in trying to have a cross platform stack, keep our engineering team very nimble."
Fernando Rojo:
And what I learned over the last year and a half building that product is that the hardest part of sharing code with an app at a website is navigation code, because the patterns are very, very different. Code aside, just the mental model of using the same code on an app at a website has just a lot of inconsistencies. And so that began my journey of working on what became Solito and it's something I've been thinking about for the past year and a half on accident. I didn't expect it to take so long. And so recently I released that as its own library.
Ben:
Awesome. And just for folks who are not as familiar with mobile dev and mostly a lot of our audiences web dev, what is navigation on mobile, obviously going between different screens, different parts of the app, but what are some of the difficulties there? How does it differ from the way you think about doing navigation in a web app?
Fernando Rojo:
An easy way to think about it is on web, you have this really nice API, which is the address bar at the top of your browser. And that acts as the majority of your state for what would be your navigation. In this case, navigation is just where are you in a page and then you have events that trigger you to change from one into another. So web is very flat. You're typically on one page at a time, you go somewhere else. So let's say you're on the home screen and you go to search, the home screen completely unmounts and then you open the search screen. And they're two distinct components in React terms that are never alive at the same time. Now consider the alternative in a native app. Imagine you're on Spotify's iPhone app and at the bottom they have these tabs and you're on the home screen.
Fernando Rojo:
And maybe on the home screen, you open an album. So then inside of the home screen, you get this stack animation that comes in on top, and then you switch tabs to the search to the right. So now you have two tabs that are both alive and if you go back to home, it actually is presuming its entire state. So already there, we see that web has a very flat simple navigation pattern that is almost entirely described by the URL, whereas on native apps, iOS and Android, you have these complex, basically completely undefined states that have nested states, you preserve the state of the previous screen you were at. There are many other considerations to have in mind.
Ben:
Got it. And some of that, I do think, especially in today's age of SPAs on the web, you do have some of those concerns and you can have state of navigation in the app that's not necessarily reflected in the URL. And oftentimes developers sometimes can get flack if they do too much that's not leveraging the native paradigms of the web. But on native definitely a lot of additional complications. So tell me a bit about how Solito solves the problem or helps make it easier for developers.
Fernando Rojo:
So plainly Solito is a library that lets you use the same code in a React website, specifically a Next.js website and in a React Native app. So the way works is under the hood, it's using Next.js's Next router and on iPhone and Android, it's using React Native code, which is from the library React navigation. So plainly, it looks like you're writing Next.js code. So if you've ever used React Router or Next router, they all have link components. It's very common on web. You have this link component and what we did is... I took that same API that you get on web and really just brought it to native and made it work on both. Basically, I copied everything that Next.js allows you to do with routing now, but provided a way to use that on native.
Fernando Rojo:
And now that we can use the same API on both, we can actually just use the same library. So the way it works is you have a link component, you pass at the screen you want to go to and under the hood, Solito says, "Okay, I'm going to find which platform you're on. So if you're on web, I'm just going to use Next code. If you're on iOS, I'm going to use this React Native code. Based on the URL you give me, I'll figure out which screen you want to go to and I'll get you there." And that's everything that happens into the hood.
Ben:
Got it. For folks who haven't used React Native, what are the other ways you could do navigation or routing if you weren't using something like Solito?
Fernando Rojo:
There are a number of popular libraries for navigation on React Native and they typically seem to follow a bit more of the actual iOS and Android paradigm. So like I said before on web, you have this really convenient thing, that's the URL, which doesn't encapsulate your whole state, but it lets you get where you want to be. On native there's no such concept. So typically on a native app, you have a function called navigate. And what you do is you can pass it a screen name and then some parameters. So instead of using query parameters, you're actually passing just an object, for example, I might want to go to the artist screen and I could pass it an artist ID parameter. The thing is, it's a lot more complicated than that as you scale an app because you'll have tabs at the bottom, you'll have stacks inside of it, you'll have modals that pop up on top. All these nested paradigms.
Fernando Rojo:
And so sometimes you'll say, "All right, I want to go to the artist tab and I want to open an artist profile in there, but then I want to open the edit screen of that profile." So you need to traverse this nested set. So what you would do is you do call the navigate function. The first argument would be the artist tab and then you would write inside and then take me to the nested screen that is based on the screen name, edit artist. So a lot of that is just a fully different API and I find it very difficult to scale. What's nice about URLs in general is they have this strict contract that's fixed in time. Over time if you enter this URL you go to /project /Solito, you'll always get a project.
Fernando Rojo:
And it forces teams and companies in general to really respect this URL, because users will always rely on it. Whereas in a native app, you just have these screen names that might change, might start as dashboard and change to home. And it's just hard to know what to name things, but I find that URLs provide a very linear path. And so what I did is just bring the URL concept to native. So if you want to use Solito, what you're doing is there's no more screen name navigation. It's all now using URLs. And I find that's just a much simpler mental model.
Ben:
How does it work? Is the idea that if I have an app that both lives on web with React and mobile with React Native, I can then share the same URLs and they'll work in both and deep link into the mobile version of the app or what's the ideal use case?
Fernando Rojo:
Yeah, it's weird actually. It's a lot simpler than that. The way it works is, let's say you create a screen. The way I view the description of how you should code this is your screens are your primitives. So you might have a home screen, a dashboard screen, a search screen. Those are your primitives. And then your platform is your skeleton. So in this case, if you're using Next.js, the pages folder is your skeleton. Whenever you create a screen, you just export it from your pages folder. If you're using React Router, you create... You use router and you use these components to render. That's your skeleton. So on React Native, you have a component based skeleton basically that looks a lot like React Router, if you've ever used that before.
Fernando Rojo:
So the way you use Solito is you create the screen component and under the hood you're coding with React Native components, which render on the web just like a
. So you could write a view and import that from React Native. And if you render that on the website, it just uses a
under the hood. So you can actually use React Native on web. And so the 2nd piece is how do you go from page to page? Does the mobile app speak to the website? How does that work? The way it actually works is, you don't actually have any communication between the app and website. They don't know each other exists. You're not inserting a website in an app or anything like that. There's no web views. What you're actually doing is you're taking this shared screen component and on Next.js or whatever web platform you're using, you just export that.
Fernando Rojo:
And then on React Native, you also export it. And so the missing piece is just telling each platform, how do you go from a URL to a certain screen? So on Next.js, the URL to a certain screen is solved with the pages folder. And on React Native, you do this thing called a linking config. It's a React navigation API, where instead of having a pages folder, you create this variable and you just say, "If someone gives me this URL, go to this screen. If someone gives me this other URL, go to this other screen." And so each platform has to basically know, given a URL, which screen do I go to? And then that screen itself is shared across both apps because you have a monorepo. So in the future, I actually want to add a pages folder to React Native, to give it perfect feature parody with Next.js and above all, to give us one source of truth for what our URLs should resolve to. But for now, you basically take the same component and export it a different way in each platform.
Ben:
What's the future of Solito. You've built this functionality. First of all, I guess, is it launched? Is it out there? Are people using it or is so work to do? And then curious, what you see as the next steps?
Fernando Rojo:
It is launched. I launched it on Twitter a few weeks ago. It actually reached number three on the front page of Hacker News, which I was pretty surprised by.
Ben:
Oh, congrats. Yeah.
Fernando Rojo:
Thanks. Yeah, it got, I think it was something like 12,000 uniques within a few hours after that. That was pretty crazy. It has been getting a good amount of usage. The way this all came about for me was in November, I spoke at Next.js Conf about how we built the BeatGig App using React Native and Next.js and from there, a good amount of people had interest in the stack and were like, "Oh, I would like to build this too. What do I have to do?" And so I made an example monorepo with a few other people.
Fernando Rojo:
And then the biggest question, there's this giant poll request with hundreds of comments almost on this monorepo I made after the talk of, how do I handle navigation? Okay, I got this cool expo and Next.js App working, but the navigation is so different, how do I do this? So I launched this a few weeks ago. I've been thinking about it for like a year, at least. And the real work came from November after this talk, when a ton of people were coming being like, "How do I actually use this stack in production?" And yeah, I just had an itch to solve that. And I tried a few different solutions, it'd be a bit technical to describe them all, but I ultimately decided on this. And so it's now live, we're actually using it at BeatGig.
Fernando Rojo:
I've tested it out on a bunch of mini apps. There are some other companies that are fully adopting it. I've even heard of some companies rewriting their entire navigation stack to use this. It's pretty exciting. And I was definitely a bit surprised by the reception I got. I thought it was going to be a bit more like of a... It feels very niche to me, but it seems like there's definitely a desire to be able to be a web dev and code a great app, or be a React Native developer and be able to code a website without too much extra effort.
Ben:
Yeah, for sure. And would this work? I imagine the answer is yes, but if you're using React Native web, you could use the same paradigm and you could use Solito, right?
Fernando Rojo:
That's exactly right, yeah. So React Native web, for those who don't know is basically, a library that under the hood, lets you import components from React Native and use them on the web. So it's actually a pretty good library, even if you're just building a website. In fact, when I build websites, I just use React Native now because React Native web is a very accessible set of components that do a lot of the boilerplate that CSS and web apps do get incorrectly. So it has a much simpler, predictable styling system than CSS, but it all compiles down to... Or under the hood, it all uses React and normal React code. So in general, I think it's a pretty good thing to use even if you're just making website. And yeah Solito is leveraging the React Native web paradigm whenever you're be building for a website.
Ben:
Got it. Now that we've talked about Solito a bit, how did you get into BeatGig or what is BeatGig? How did you decide to start building that and tell us a little bit about what you're working on?
Fernando Rojo:
So BeatGig is a marketplace for booking artists. You can think of it like Airbnb for live music. We have a few thousand artists on the platform, anything from DJ Khaled or Kesha to some local bar bands. And so you open the app, you sign up, once you get approved for an account. You can actually browse the prices to book any artist for a live event. It's the only place where you can actually see how much it costs to book all these artists. So it might be for a wedding or any private event. But recently our largest growing customer has actually been restaurants, nightclubs, and bars. So we've been getting more into the B2B space. We now power basically the careers of many artists who want to find better ways to get booked, want to manage their bookings and their taxes and getting, receiving payments.
Fernando Rojo:
And for the bars, it's the same thing where we're helping them discover new acts, we're managing their entire calendar, we're helping them get all their taxes, settle with the artists and things like that. Fundamentally, that's the flow for users and I think it's been a few years now of working on this one and it's been growing quite a bit recently.
Ben:
That's super cool. I'm curious, before BeatGig existed, if I want to hire Kesha to perform at my wedding, how would that have worked? Would I just have to find her agent and figure that out? What was the process before BeatGig?
Fernando Rojo:
Yeah. It's a disaster honestly. You have to try to find the agency, email them, hope you get pointed to the right rep and then... Who knows what you're supposed to do now? Like what is the contract supposed to look like? Are they going to take me seriously? The biggest problem people will have trying to book an artist, is that no one wants to have their time wasted. People might not respond to you or if they do, who knows if they're giving you a fair price? This is the benefit of these websites and marketplaces that are giving a lot of price transparency and also just adding level of legitimacy. It would be pretty complicated, just the contractual side, like who should you talk to?
Fernando Rojo:
Is it the manager or the agent? How do you compare if this price is good? What if this artist isn't available after a few weeks of work? How do you get to someone else? That's another common case that we have. So yeah it took a few years to abstract that all into an app obviously. But it's an industry that has a reputation of being shady and very not transparent, so I think it's pretty fun to build for.
Ben:
And do you take on some of the risk of like Airbnb, if something goes wrong, I think they make either party whole, if the host... If the experience isn't as described, you get your money back as a guest. If the guest destroys the place, there's some compensation for the host I think. Do you take on some of that risk in terms of making sure both parties get a fair deal and if something goes wrong helping out?
Fernando Rojo:
We do have pretty good insurance. I can't say that necess- Yeah, I mean, we don't necessarily take on all of the risk for the event itself, but what we do is provide basically the entire service you need to make sure the contract is just very favorable to both parties, very fair. Something really good that we add in general to what we call a buyer, someone who wants to book out an event is, first of all, we'll handle the contracting for you. We'll help you walk you through all of it. And above all, we're going to add a level of legitimacy. We don't go to agents without an offer that they know is legit. So whenever BeatGig comes to you as an agency, we have deals with all them. They know this is a solid offer.
Fernando Rojo:
And the other thing we bring to the buyers on the risk side is, we have seen which artists you should and shouldn't book. And so we also provide this level of... We have reviews and things like that. But we also have a nudging of, these acts are going to maybe do as they say, these ones won't and you can learn from that. And it's really all solved by this market place problem in general. But we also have pretty good contracts for handling all the risky scenarios that could come out.
Ben:
Tell me a bit about the tech side of things. I think as a website, is there an app as well? Tell me about some of the architectural technical decisions you made.
Fernando Rojo:
Yeah. So we're a website. We also have an app on the app store. I'm actually shipping an update in the next probably few hours for it. That was the initial idea. We still to this day, actually we're a team of 10 currently and we're going to be hiring a lot more people with the coming months. But only two of us are actual engineers. Only two of us build product, my co-founder and I. He does all the backend and I do all the frontend and we've been able to scale our website and app using just the two of us. We've been building together since YC and the technical decisions were always trying to say nimble. I think that something we learned a lot in YC is, being very self sufficient, being able to build fast, just the two of us.
Fernando Rojo:
And so all the time we're thinking, "What is the right abstraction for this? How will we be able to build this again in the future? Is this the right way? Can we build this just the two of us without ever trying to reach to hire a bunch of people quite yet, to build product?" And so we can also keep runway to hire other operations people. And so, our app of course, is built with React Native and the website is too, and almost all of our code is shared.
Fernando Rojo:
And that was a big piece for us as being able to do that seamlessly. And we've gone through a lot of iterations with how the frontend and the backend communicate. We started out using REST, our backends with Python. And so what we did is we have an open API Swagger integration on the backend, which for someone who doesn't know, it's like a GraphQL for REST situation. It takes your backend endpoints and generates schema and it also lets you share types from Python and types of script or across any languages really. So that was pretty nice, we had shared types across platforms. I'd never had to write fetch/users/whatever. We had a codegen library for every single endpoint, super convenient. We recently switched to GraphQL. So I've been shifting things that way and for our search we use Algolia.
Ben:
What have your thoughts been on GraphQL? Are you happy you made the switch from REST?
Fernando Rojo:
Yeah, I think it's unlocked a lot for me doing the frontend because I used to have this... We were using Dgraph and now we're trying out EdgeDB just two like kind of new databases. Dgraph was a graph database and I think EdgeDB is on top of Postgres. I don't know exactly how the database side works, but I have really liked switching to GraphQL. I'm using URQL on the frontend, which is an Apollo competitor, basically. And so we have a library that takes in all my queries and generates a set of hooks. So I have a use user hook and use dashboard query hook, things like that. What I like about GraphQL is I can really express what I want to do from the frontend and just get the fields I want.
Fernando Rojo:
And our database is fast enough to allow very nested fields on many objects at once, things like that. Whereas with REST in the past, I would have to do first, get the user and then once I have the user ID, all right now I can do things with that user. Like if the user is a buyer, I can fetch their venues. If the user is a seller, I can fetch their artists. But now I can just express that all in one query and for different screens, I can just write which fields I want. So I found it just makes me less reliant on the backend. Like in the past, when we were using REST, I had to tell my co-founder, "Hey, can you make this endpoint for me?" And he's like, "Oh, this one's not going to be that fast. Let me make this smaller one." It's like, "Oh, images are actually bloating because it's..." I don't know all these considerations, but I'm offloading some of that time of having to go back and forth. So I've definitely liked the improved GraphQL extraction.
Ben:
And do you use Solito with BeatGig?
Fernando Rojo:
Yeah. Previously, I actually used another library I had made called expo-next-react-navigation. So it's the same idea, it's the same navigation, between Expo which is React Native, between Expo and Next.js. That's mostly what our app actually uses, but I've been transitioning it all over to Solito. The tricky part is BeatGig as an app. We have like hundreds of screens now. This is a massive product and I have basically used it as a playground to test so many different navigation possibilities. I built like a whole modal manager for Next.js, like tons of things and so we are using Solito now. But I have a ton of almost legacy code from all these other things I've tried, which led me to build Solito ultimately. But most of the existing navigation code is using expo-next-react-navigation, which is my first version of this whole stack.
Ben:
Not as catchy a name as Solito.
Fernando Rojo:
Yeah. It's a lot more boring.
Ben:
It's descriptive, but maybe doesn't slip off the tongue as easily.
Fernando Rojo:
Yeah, not quite.
Ben:
I'd be curious to learn about some of your other projects aside from BeatGig and Solito, you know, obviously, Expo, Next, React Native, any others that you want to talk about today?
Fernando Rojo:
Yeah, definitely. I built a number of libraries over the last few years, all with a similar thesis. It should be easy to build cross platform apps. They should render and feel the way users expect on the given platform. So in the Solito case that we've been talking about, navigation should feel like an iOS app, if you're building it for that. It should feel like a website on the website and you should be able to use the same code every time. So the first library I built for this stack after I built expo-next-react-navigation was called Dripsy. So Dripsy is a set of UI primitives on style UI primitives. It's basically theme UI for React Native. Theme UI is like a Tailwind alternative or like style system. It's a bit less like known as Tailwind, but I'd use that on plain React websites before.
Fernando Rojo:
So in plain terms, Dripsy is a library that lets you build a theme based UI that works on web and native and it also allows responsive design. So what's cool about this is you define all your responsive styles based on screen size rather than what people might do like platform. So in the past, people would do like, "If I'm on a website, show this UI. If I'm on the iPhone app, show this UI." Whenever they're building with React Native because React Native doesn't have media queries. So there's no at media API that people are used to with CSS. So I had to figure out a way to bring that feature into native apps. So it works on iPhones and iPads. And then as a result, it also works on websites. So that's what we use for all of our responsive design.
Fernando Rojo:
It's the first question I always would get a year ago, like, "Oh, you're building for React Native and websites, how do you do responsive design?" Now there are a lot of... I was very public about how annoyed I was that this didn't exist at the time. There are a lot of cool libraries that exist for this now. Like Shopify has one called Restyle. There are many Tailwind for React Native and web libraries that are pretty cool. But that is Drispsy, so that's the first one.
Ben:
Cool. Any others you want to cover?
Fernando Rojo:
Yeah. The other one would be Moti. Moti is inspired by Framer Motion. It's basically an animation library that works on iOS, Android and web. Again, all with the same API. It borrows a lot of the Framer features like you just create a component, you can pass it your initial state, you can pass an animate prop whenever that changes based on React state or anything else, it'll automatically animate for you. And what's nice is under the hood on React Native, it uses this library called React Native Reanimated, which is a little bit more of mouthful. And that's a really cool library. It basically allows you to write your animations in JavaScript but perform them all on the native thread. So you can animate any property you want and it's all at 60 frames. And this is a pretty revolutionary thing for React Native. In the past, you could only do opacity and scale. Basically, opacity transforms that would be fast. And even then they had their bottlenecks, but what Moti lets you do in React Native is just drop in one component and you can fade it in. You can do presence animations. So you can animate when component unmounts, like Framer Motion, things like that.
Ben:
Cool. I'm curious, seems like you've had a bunch of these cases where you encounter a problem and then you decide to build the tool to solve it. If you had unlimited time, any other ideas kicking around for tools or libraries that you'd like to build if-
Fernando Rojo:
Yeah. All the time. I guess it's a bit hard to say it off the top of my head, but really all the time. I think one big missing thing in general, is an actual unified API across platforms. So I'm thinking like an open source project, not really like a dev tools company. Even Solito, it solves this good problem and it lets you... I think for right now, it's really interesting, I guess consider revolutionary. But if I could do everything I really wanted to without sacrificing my time, I think it would seem very trivial, what it achieved. I would like to have one framework that works on every single platform and is native Teach One. I think Expo has some ambitions to build this where it's also great for web and native, but everyone has their own separation concerns.
Fernando Rojo:
Some companies are really focused on the web. Some are really focused on iOS and Android. I think there are a few things that are just very separate, like Layout Animations, which are great on Framer and are great with reanimated but they just don't work super well with the same API across platforms. If I want to make an element transition things like that, shared element transitions, are very difficult. It's also just difficult like with React Native, there's no real performant way currently to do shared element transitions as you open different screens. So just as I'm thinking narrow about BeatGig and what my desires are to make the user experience better, those are the kinds of things I want to have. I'm always surprised by how underappreciated the fact is that you can use the same code on both platforms.
Fernando Rojo:
I think people are really starting to come around to it now because a lot of these problems like animation and responsive design and navigation are getting solved. But to me, it always just seems so obvious. It's just, it wasn't quite there yet. So I think we still need a few things like this to really unify the API and let you leverage the best of both worlds. You shouldn't really need a monorepo. You should be able to just have one folder that you just single API and it does the right thing on each platform. So that's kind of the thing I'd love to have.
Ben:
So one of the concerns I often hear when people talk about the promise of, write code, have it run at any platform, is that each platform has its own design language or patterns or paradigms. iOS does things a certain way, Android does things a certain way and web is kind of... Web, I feel like it's less opinionated, but there are kind of established patterns. And so would you imagine a way to solve that or be respectful of each platforms design patterns?
Fernando Rojo:
I think this is probably the most important piece and it's what every attempt at this in the past has gotten wrong. And I think it's why Solito, the way it's structured now, can work. So I have a whole piece on this in the Solito docs describing what we do and what we don't do. And like you were saying, each platform has its own styles. Like on an iOS app, you have this form sheet modal and on web, you have usually no page transitions, things like that. I think it actually is not that hard to let each platform have its own designs and things like that. As long as you just abstract at the right layer. In our case, when we create a navigation stack, it renders as a native Android stack and native iOS stack and then a web there's no stack at all.
Fernando Rojo:
It just renders a page. And so I just think what's important is to get the right layer of abstraction at each step. And the other thing is, React Native is an interest technology because it's basically just using React. And I think what's nice about React is, it is expressive and enough to build any UI really. I actually think React Native is the right UI layer for any platform, a TV, a computer or whatever. The challenge is just getting it up to par with native performance and letting you easily do the same thing across platforms. So in general, what I think about this is people are going to expect different things on different platforms and it's like, you really need to make sure that you don't try to make an Android app look like an iOS app or a website or anything like that.
Fernando Rojo:
And so anytime I find myself writing, if platform is web, do this. If platform is iOS, do that. Anytime I do that, I'm like, "Okay, this is a good opportunity to write an open source library." And that's where it's happened every time. And so I think it's actually pretty possible to still achieve this native feel for each platform you're on, as long as there's a library in between you and the UI layer that does that side for you.
Ben:
Well, Fernando, thanks so much for joining us today. It's been awesome to learn about Solito and BeatGig and all of your other projects. I'm very excited to see what else you build in the future. For folks out there who want to learn more about anything we've talked about today, we can put links in the episode description to any or all of these projects, but anything else you'd recommend if people want to learn more about your work?
Fernando Rojo:
The easiest way to keep up with my work is probably to follow me on Twitter. It's @FernandoTheRojo. I post a lot on Twitter about this stuff usually as I'm working on it. And it's just a fun place to share progress. And the other place honestly, might be on GitHub. If you follow me on GitHub and there's some people out there who subscribe to all these repos, because I post a lot on issues and poll requests. Just like random ideas I've had. The idea for Moti came up from just a long issue I wrote on Dripsy, so if you want to chime in and be part of the stack, just follow me, I guess on Twitter and on GitHub. Oh and I'll be speaking at App.js Conf about Solito in two months.
Ben:
Great. Well, thanks again.
Speaker 3:
Thanks for listening to PodRocket. You can find us @PodRocketpod on Twitter and don't forget to subscribe, rate and review on Apple Podcast. Thanks.