00:00:00 Kent: Hello everybody, this is Sergio Zalambri. Say hi Sergio.

00:00:05 Sergio: Hi Sergio.

00:00:06 Kent: There you go, nice. Good. So Sergio, you've definitely, as you've been going through these workshops, Sergio is the author of a number of the packages and even patterns of different things that we've been doing in the workshops. So super thrilled to have Sergio in here. Sergio and I met

00:00:27 as part of Remix, so like I think Sergio and I are among the first dozen or so people who got licenses to Remix. Is that right, Sergio? Were you 1 of the first to get a license?

00:00:40 Sergio: I'm not sure if I was 1 of the first, but I was 1 of the ones who got a license.

00:00:45 Kent: Yeah, yeah. So we go back, it's a couple of years now. And yeah, it's just been such a pleasure to get to know you, Sergio. Can you introduce yourself to everybody for us?

00:00:57 Sergio: Yes, I'm Sergio. I am a web developer working at a startup fintech slash not-for-profit company called Daffy in the United States. I live in Peru. I am originally from Argentina. And yeah, I've been working on this for a long time, like almost 10 years.

00:01:18 I'm happy to be here.

00:01:19 Kent: Awesome, yeah, good stuff. So I wanna ask you, since you were so early in the Remix world, what drew you to Remix initially?

00:01:30 Sergio: Well, I was working on an internal application for my previous company, and we have been doing some patterns that in the newsletter of Remix, when they were just talking about the idea they have, I found that, hey, this is similar to what I'm doing, because we also

00:01:51 have moved it from using a React query on every component to move it to the root. I have some kind of loader, basically. And some of the ideas basically resonated with me, like this is a great way to do it, makes a lot of sense. So when they made

00:02:11 the option to purchase the license, I just went and got 1 to try to use it and see if we can use it at work. I never used it at that company, but I am using it now as my current 1.

00:02:25 Kent: And at the current company, though, you didn't start from scratch with Remix. You had to migrate, right? Can you describe your migration experience a little bit?

00:02:34 Sergio: Yeah, we originally started with a React Router application server from Rails URL. So we had this Rails monolith that served an API and also served in HTML that loaded the React Router application. We realized soon that we need SEO,

00:02:56 so we had to move to something that could serve and render that React Router application and we moved it to Next because 1 of my co-workers is 1 of the original authors of Next.js.

00:03:08 Kent: Oh, really? Oh, okay.

00:03:09 Sergio: From the G1. And I also had been using it for a lot of time. And we started doing that, but I also liked it a lot how Remix worked, so we followed with some of the patterns of Remix inside of our Next application. And after a while, we eventually decided to

00:03:29 migrate to Remix, so we had to do this gradual migration where we use Express to run both Next and Remix at the same time and move it root by root, well, URL by URL actually, to from Next to Remix until we eventually migrated everything

00:03:49 and we could remove the next part.

00:03:52 Kent: Yeah, so can you describe a little bit more technically how that was accomplished? Like how you, because I'm sure there are a number of people who are listening right now going through the workshops and they're like, this sounds really nice, it's too bad I'm using Next, or you know, they are interested. So what was the technical aspect of how you accomplished that?

00:04:13 Sergio: Well, the most important part was actually the HTTP server, the Next, the express 1, because at least on the next version we have, I'm not sure right now, but we could use next as a middleware in express, similar to how Remix works. So what

00:04:33 we did was set up this express server from express through express. So express receive the request and pass it to next. Every request went to next, except the static files. And then we started adding before the next request middleware, the remix 1.

00:04:53 So this line, that's where we configured it. We say a slash something goes to remix. Everything else goes to Next. And then we add another 1 and another 1. And as we migrated 1 by 1, we keep adding to this list of routes that were on the express server configured to go to REMIX. So

00:05:13 we had a long list of routes until we migrated the user profiles because user profiles were a catch-all route. So we were last whatever is a user profile. When we, once we migrated that to Remix, we did a switch and configured

00:05:34 what routes, what URLs went to Next and send everything else to Remix. And then we started removing the lines 1 by 1.

00:05:46 Kent: So we

00:05:46 Sergio: had to change how authentication works. That was 1 of the first thing we had to do because we wanted to share the authentication between Next and Remix, and we were using NextOut at that moment. So We switched to RemixOut, I created RemixOut for that. And because the

00:06:07 session storage object from Remix is actually not tied at Remix at all. It's just an object to work with cookies and sessions. We just used that same object in Next. So we just imported it from Remix inside the Next application and used that to know if the user was authenticated.

00:06:27 And we did the same thing we were doing before, but with the Remix Session Storage. And in the Remix application, we just use a Remix app.

00:06:36 Kent: Yeah, yeah, yeah. That makes sense. How did you make it so that, cause actually to step back, during this transition, no pun intended, The transitions between 1 app to another had to be a full page refresh. Is that right? Because, yeah. So with that in mind, when you

00:06:57 migrated your first route to Remix, how did you communicate to Next.js that that page transition needed to be a full page refresh?

00:07:04 Sergio: We did the simplest thing that we could do. We just replaced the Next link component with an anchor tag. And every link from Remix to Next was also an anchor tag. It was actually a link tag, a link component, but with a reload document prop.

00:07:20 Kent: Oh, sure.

00:07:21 Sergio: So we just did that and everything was like a normal navigation.

00:07:26 Kent: So then as you migrated things from Next to Remix, you could change them from anchor tags to link tags?

00:07:33 Sergio: We actually just keep everything in Remix to reload the page because sometimes some routes redirected to a next URL, but it was initially a Remix route, and we send a post to a Remix route. So it was easy to just let everything

00:07:53 reload, work everything as an MPA. And when we migrated everything, we removed the reload document perhaps.

00:08:01 Kent: Yeah, that sounds pretty like the safe option there too, for sure.

00:08:05 Sergio: Yeah, we actually had some issues with that before. Before we started doing this, we had some cases where a remix is shown with a 404 page, then you reload it, it work out because it was not being routed to Next.js or the inverse too. Next tried to load the

00:08:25 page, the page didn't exist, it showed an error, you reloaded, it worked because now it was Remix.

00:08:32 Kent: Yeah, that makes plenty of sense. OK, so in the process of doing that, you mentioned that you built RemixAuth to make that easier to migrate. And then you also, I'm guessing, lots of the utilities that are in RemixUtils came as a result of all the work that you were

00:08:52 doing there, is that right?

00:08:53 Sergio: Yeah. Yeah. All my packages are from things I needed to do at 1 point. So RemixAu was, I needed to do authentication. We used Auth0 for that. And we tried a lot of things. I tried Passport, JS, FIRS, it worked, of course, because it was an express.

00:09:14 But I wanted to have that as part of Remix, not as part of Express. I also tried the Auth0, React, SDK. It worked too, but we had issues with server-side rendering because it's all intended to work client-side. And at the end, I just decided to

00:09:35 create Remix Auth. The original version was completely intended to use with OutZero. I eventually realized that I could just, everything OutZero do, it was actually just OAuth2 flow and that's standard so I could move it to a strategy and create this pattern. But it's

00:09:55 not, I didn't create it, it's the same thing as Passport does. I just started creating these strategies and created the OAuth2 strategy. So the Oauth2 strategy extends from there and then created other strategies mostly to show how this can be done. And a lot

00:10:15 of people created more strategies after that.

00:10:18 Kent: Yeah, that was a good call on doing the strategies following Passport's patterns there. I think that like, Passport is still very relevant for people doing Express apps and Node.js based apps and for a good reason, because it's just, it's good. It's good stuff.

00:10:38 And I've been enjoying using RemixAuth for especially the more complicated stuff. I found Originally, I just said, okay, I'm gonna use RemixAuth for everything. And I found that the web forms strategy wasn't giving me a whole lot on top of, just implementing that

00:10:58 myself, which I thought was kind of interesting. And I mentioned that to you and you said yeah that doesn't really do too much. So where I find RemixAuth being really useful, like extremely useful, is in the really complicated OAuth2 flows and OIDC and that sort of thing. It's

00:11:18 been extremely useful. In fact, today I will be recording those videos for Epic Web. So if you're watching this video as a part of those workshop exercises, both of those things happened today. Yeah. Yeah,

00:11:33 Sergio: I think it's interesting because the original form strategy was called a local strategy. That's how password also call it. And it's completely focused on you have 2 inputs, a username input that can be the email and a password input and that's it. And you just receive those values directly on the strategy

00:11:53 callback. And then I realized that what if you want 3 inputs? Like I use apps that needs 3 inputs. I use some, the app I use to pay my taxes needs 3 inputs, my ID, my username and my password. So I just created the form 1 and then when I build the form strategy,

00:12:14 it was like this doesn't do a lot of things. It just call requests from data for you and that's it. Yeah. It's useful if you already have everything. If you want to keep everything in RemixAuth, it's useful to have that. But if you don't, it's okay to just don't use it because it's not gonna do a lot of things.

00:12:34 Kent: Yes, yeah. And yeah, I found that with that approach then, I pretty much just use RemixAuth for handling the OAuth flow. And once I get the user from GitHub or from Google or from wherever, then I feed that into my regular auth flow with my own session storage

00:12:55 management and everything like that. And that's worked out really well. So RemixAuth really simplified the auth flow for the complicated stuff, but then allows me to have a lot of control over the lot simpler things, which I think is a really nice aspect of it. Yeah, so

00:13:16 I also am kind of curious what your thoughts are on more, shall we say modern approaches to authentication or like the up and coming approaches to authentication. Specifically, I'm talking about pass keys. Cause This is something that I think I had heard about a while ago, but it's really been picking up steam from the standards approach.

00:13:36 So can you tell us a little bit about Passkeys?

00:13:39 Sergio: Yeah. For those who don't know what Passkeys is, it's this new thing that Apple, Google, and other companies created that's basically similar to how two-factor authentication works. You have this hardware thing in the passkey scenario is your computer or your cell phone and you

00:13:59 start to authenticate with a website or application by using a private and public key. It's a private and public key authentication but using your device directly instead of a second device like a YubiKey. I like a lot the pattern. I hope every website

00:14:19 use passkey in the future because it's way simpler to just click a button and log in. And there are a lot of other things you can do, like automatically log in users. You don't need to wait for them to click a button. You can just check with JavaScript. Hey, does the user have the passkey for my website? If it

00:14:39 does and has only 1, you can automatically log in, log the user in and that's it. You don't need to think about that.

00:14:48 Kent: Yeah, I think it's a very cool thing. I appreciate that it's a standard. Alex Anderson put together a remix auth strategy for it. And while he was very responsive to my needs as I was experimenting with it. It's just still too early for me to include it in the workshop. So I may

00:15:08 add an exercise after the launch, but I need a little bit of time playing around with it before I can feel confident and say, do it this way. Because I don't, I'm not sure yet.

00:15:18 Sergio: Yeah. Makes sense.

00:15:20 Kent: Yeah, sorry, go ahead.

00:15:22 Sergio: Makes sense.

00:15:23 Kent: Yeah, yeah. So I definitely plan on the EpicStacks having pass keys in the future. Because I really look forward to a future where our users don't have to worry about storing passwords and things. And that their device just is the thing that identifies them, which I think

00:15:43 is cool. Of course, That does come with the drawback of like, if I want to use the library's computer, how do I log in? Which I think is probably why- You can,

00:15:54 Sergio: because ASCII's allow you to generate a QR code. The browser actually generates the QR code and you can use your phone, scan your code and authorize the computer. So you don't need to be on your computer. You just need to have your cell phone with you.

00:16:09 Kent: Yes, yeah. And that is actually super cool. So when I add that to the Epic stack, we'll definitely make sure that that is supported as well. And I don't think you have to do anything to support that. I think that just the standards, the user agent is the 1 that generates the QR code for you and everything. So it's pretty sick, actually. I love that. Let's

00:16:29 have the user agent do more for us please. But there is the drawback still of somebody loses their device and now they don't have access to any of their accounts, which I think is why Google and Apple and 1Password and all of these are going to hook into these so that you can save those to those password

00:16:49 managers. Cause yeah, otherwise you'll be in trouble.

00:16:54 Sergio: Yeah, I think Apple does that already with Keychain, with Apple Keychain, the password manager. And I remember I read that 1 password already supports that too.

00:17:09 Kent: Yeah, so it is gonna be an awesome world. I do think we will not get away from having some sort of password at some level. Like you're gonna need a password for your Apple account. You're gonna need a password for your 1Password account. Like at some place you're going to need to provide a password to get into

00:17:29 this wonderful world of passkeys, for it to work for those edge cases if I lost my device or whatever. But I definitely appreciate not having to enter a username and password everywhere. So Hopefully that is in our future. So I wanna ask you about

00:17:50 with RemixAuth, how do you decide what gets included in Remix, or sorry, not RemixAuth, RemixUtils. How do you decide what gets included into RemixUtils and how do you, where did lots of these ideas for these utilities come from?

00:18:06 Sergio: Well, most of them were things I built for myself or the work I do at Daffy. Most helpers you do for there, like get a client, a user, the client IP address function to get the IP of the user. We need

00:18:26 that to localize the user. So I build that. And others are things I saw people in the communities talking about on this call and I can get this is useful and more people should benefit from that and I can put it on. Let me get those. There's a

00:18:47 server-side event. You did this for examples were created originally by, by Ryan. And I just copied from the linear copy example that he built, grabbed those utils, put them on RemixUtils, improve them a little bit, and went back to the project

00:19:08 and send the PR tools, just use RemixUtils, so you don't need to copy that.

00:19:13 Kent: Yeah, I definitely appreciate that as a user of many Remix Utils utilities, especially the authenticity token for cross-site request forgery stuff and the Honeypot are both like, Honeypot is, I wouldn't say it's trivial.

00:19:34 It's like, there are a couple things you need to think about and certainly the authenticity token, not a trivial thing either. And so just having an easy way to do that is quite nice. And then of course, there's smaller things that I don't wanna have to copy around all over the place that I really appreciate. I just install Remix Utils

00:19:54 and I can use it all over the place.

00:19:57 Sergio: Yeah, that's a good idea.

00:19:58 Kent: Yeah, So Remix Utils is kind of about like filling in some, some things that might be considered gaps in Remix, or just like some things that we end up doing a lot that would be nice to not have to do over and over again. Are there like, but we can't fill in all of the gaps

00:20:19 that Remix has, like, there are some things that need to be done in Remix core to improve Remix itself. What are some of those things for you? Like, where is Remix lacking and what are you looking forward to in the future for Remix improving?

00:20:34 Sergio: I would love to have better internationalization support. Ooh, yeah. In Remix. Right now, you can do a lot of things with external packages like Remix I18next, But it's still, there are things that are

00:20:54 harder to do. But if you want to translate the path on the URL.

00:21:00 Kent: Yeah, yeah.

00:21:03 Sergio: I personally don't care about that as a user, but I know a lot of people do it. Like they translate slash about to whatever in that's translated in another language. They do it for SEO reasons. So that's something I would love to have more support directly

00:21:23 in Remix. Also maybe a way to load the translation files directly. Ideally everything in YMTnext is supported directly by Remix, but It's hard to do because how do you render text that includes a component inside, for example, that

00:21:43 needs more work to be done and it's the job that react in NextLoss.

00:21:49 Kent: I think that at least for translating the URL, from what I understand with what Remix is working on with version 3, that should be possible. So you can read what the user's locale is and then dynamically generate the routes based on that, which pretty wild. I

00:22:09 don't know how they're gonna manage that, but yeah, pretty

00:22:12 Sergio: cool stuff. That would be amazing. Yeah. Right now you can do it. Everything you need to do, you can do it some way right now because Remix is really pluggable. But you need to go to the Remix config and add the roots functions and use define roots to define all the possible translation. And if you add a new 1, you need to

00:22:33 deploy again to build the app again.

00:22:35 Kent: Yeah. And you need

00:22:36 Sergio: to ensure the root IDs are not colliding. A lot of things that will be great if the framework do it directly for you.

00:22:46 Kent: Yeah, yeah, totally. Is there anything else that you're hoping for in the future of Remix?

00:22:51 Sergio: Well, I have some proposals I have to listen to. There is 1 that I think Red server components may solve for me. That's a sibling roots because I have a dashboard like UI that has many widgets

00:23:12 on the right side the right sidebar and they need to load their own data and sometimes they do mutations. And I need to support all of that in the root loader and the root action. But if we can say this root has all of these other sibling

00:23:32 roots and now rendered in this place. Like I just say, he rendered the sibling number 1, the sibling number 2, the sibling number 3, and have each sibling root had a loader and an action. So they can work in isolation. And I don't need to care about that on the main content root which is the primary root.

00:23:53 Kent: Yeah, yeah, yeah. So Remix v3 with server components, that 100% will solve that problem. Yeah, from at least from what I've seen, I'm not on the Remix team anymore, so I can't really say for sure, but from what I've seen, that is definitely a use case that will be completely satisfied by

00:24:13 V3. So in that world, things actually get simpler than more complicated because it changes from being root specific to being components. And then you can kind of opt into a component having URL by configuring it as part

00:24:33 of the router. And so, yeah, every single component can have a loader and an action and all of that. It basically takes the full stack component concept and turns it into like a legit thing where every component can be its own quote unquote route with

00:24:54 a letter and an action. So it's going to be a pretty sweet world in the future. I'm looking forward to it myself.

00:25:01 Sergio: Yeah, same. Another thing I'm looking for is to have some root constraints. That's how they're called in Rails world. The idea that you can say this root only match if the UR is a param in the URoot has this constraint, like it starts

00:25:21 with a specific character, or it starts with a number, or it has at least 1 dash, and things like that. So you can have 2 routes at the same level of the URL and the same segment, but they can match different values. Like you can say,

00:25:43 if it starts with the U character, U dash something, it's a user name, it's a user profile, and if it's not, it's something else, it's a landing page, and you can have these 2 routes as separate files with the separate

00:26:03 loaders and everything, and You don't need to start doing conditions based on the URL that I had to do right now.

00:26:10 Kent: Yeah.

00:26:14 Sergio: Another constraint Rails has that will be great to have is to say this param is actually a subdomain. So you can have things like kent.something.application.com and that's gonna be the version of the application

00:26:34 that only match for your company. So you can do multi tenant applications that use the URL directly and it's encoded in the router itself.

00:26:46 Kent: Yes, yeah, that would be pretty sweet. Yeah, Another thing that I'm looking forward to, and I think you've actually got a workaround for this, so it's probably not a pain for you, but being able to have a set of routes that are, that require authentication and like

00:27:06 get the user in the 1 place. And so then all the routes don't need to worry about getting the user or like an admin route. So it not only does it require the user, but also requires certain permissions or roles. Right now, you've got to work around for that. I'll let you describe if I understand correctly.

00:27:24 Sergio: The middlewares. Yeah, what I do is basically move that to the HTTP server. I embrace the HTTP server there and just say, move that there. I also had to do it because on my blog, I use Cloudflare and a lot of things need invariables that are not global in Cloudflare.

00:27:45 So things like session storage needs to be created on the HTTP server and pass it to Remix. And because of that I also need to create the authenticator and pass to Remix. And once I was there I said, why I don't do authentication right there? And I authenticate only once. So it's way simpler to just go

00:28:05 there and go to Express or Hono, I like Hono a lot for this because you use web APIs instead of some things like Express. Just put your middle words there like you would do in an express application and say, if you are on a Labs admin, you need to authenticate and also need to

00:28:25 ensure the user is an admin. And you just pass the user object to the Remix app. And you know, in the loader run, you are already authenticated and you already have permissions.

00:28:39 Kent: Yeah, that, I actually thought a lot about doing that as part of the workshops and as part of the Epic stack. And I think that 1 of the biggest reasons that I decided not to is because I don't find it actually saves a lot of boilerplate because

00:28:59 of the extra work you have to do to make sure your loader context is typed. Right, so correct me if I'm wrong, but you are using get load context to get the user data and everything in there. But the types for that are, for

00:29:19 the load context are, like you have to define it, it's set to any. So I'm guessing you have like a custom type for loaders in action, is that right?

00:29:28 Sergio: Yeah, you can use a TypeScript declaration version to extend the upload context interface that Remix has, which is a record. And because it's a record, you can just say, this key has this value and extend it that way. So I usually have an app, app.dts,

00:29:50 a file where I put this and extend it and make my tsconfig load that file. That way my app load context is always typed correctly as in 1. It's not really typed in the

00:30:06 Kent: same way.

00:30:07 Sergio: I type safe because you are saying this has this type and you trust the HTTP server gives you the correct type. But also get load context will afford you to try to send it. So while you can fake it, it's less likely that you fake

00:30:27 it because your TypeScript will juggle you on the HTTP server side.

00:30:32 Kent: Yeah, that makes sense. So 1 concern that I would have then is, like on the admin route, it would definitely say, yep, here's your user, but let's say I'm on the homepage. Now it's saying that I have a user, but I don't necessarily. So do you type those as being optional?

00:30:54 Sergio: I usually just type everything as required.

00:30:59 Kent: Oh, okay.

00:31:00 Sergio: I am using indicators all the time.

00:31:02 Kent: Yeah, okay, interesting. Yeah, so there's something there. I think that that's another thing that I'm looking forward to with Remix v3 is having a built-in support for that type of middleware And the stuff that I've seen with TanStack and the router

00:31:22 that he's working on and as type safe as it is and all of that. I know that the Remix team is watching that very carefully for as far as the type safety is concerned and seeing how we can get type safety for that type of thing. Cause I think your solution is a good 1, especially when you've got many, many routes

00:31:42 and you don't want to have to repeat, you know, require user ID and all that. But I do think that there's more room that Remix can do for us, and I'm looking forward to the future where

00:31:53 Sergio: Remix does that. Yeah, I think this is like a solution for now until Remix has actual middleware support. So we can do that in Remix, really. And then I can just move there.

00:32:07 Kent: Yeah, it'll be a nice feature. Yeah. Yeah, that's actually, when Ryan first approached me to join Remix, I said, this was after a year of the developer preview being out, almost a year just before they went open source. I was like, oh man, I

00:32:27 really would have liked to be a part of it earlier, like much earlier, because now all the interesting and fun stuff is done. Like you already made all the decisions and turns out like there's still so much in the future of Remix that, yeah, they'll be working on stuff for a long time, I think.

00:32:45 Sergio: Yeah, so there is this thing that Remix intends to be full stack and right now it's really good at the center of the stack. And yeah, for the front end part you have React, so you have everything that React has. But for the back-end

00:33:05 part, there is a lot of things missing that frameworks more focused on back-end like Ruby on Rails has. And EpicStack solves a lot of that things. But I still feel like it would be great if the framework gives you the things because they will be more integrated. Yeah. Like it's not the same having

00:33:25 Prisma and some mail server and Qt jobs integrated by using different libraries and put all of that together, that have a single way to do all of that. Because the pattern is always the same and the API is always

00:33:46 the same because they are built by the same people.

00:33:49 Kent: Yeah, yeah, that is tough. I have mixed feelings about that. For 1 side of, so first of all, I've never used those other frameworks. And so I can't really, I hear people talking about them and I can tell that it must be wonderful to be able to have that experience. On the other

00:34:09 hand, it's nice to be able to, or It's difficult for a single team to build the 1 thing that will work for everybody, right? And so I like that the Prisma team is just like

00:34:29 super hyper-focused on ORM and making that the best thing that it can possibly be. And I like these different focuses and being able to swap things out. I think there's just something about the JavaScript ecosystem that We just really like being able to have options and being able to swap

00:34:50 things out, which doesn't appear to be the case in like Rails or PHP as much.

00:34:56 Sergio: Yeah, I think this is something we decided years ago when Node.js become a thing, like everything needs to be a package and they need to be single purpose like the Unix philosophy. And then we basically condemned ourselves to not have something like Rails. Yes, that's true. When we did that.

00:35:17 But I liked that. And I still like that for some things, but when I started using Rails, I saw that you can do a command. You can run 1 command on your terminal, call it Rails g scaffold. And you can say you want to scaffold a user with some

00:35:37 fields like a name that's a string, an age that is a date and things like that. And it automatically generates the immigration file, the model, the controller, the views. You have a crude, completely do for you. And it's like something you can do

00:35:58 in JS that easy because what do you use for your model? What do you use for your controller? In REM, if you have loaders and action for the controller and you have react for the view, but what's the ORM? You can use Prism or you can use Drizzle, you can use Sizzle, you can use a lot of other ORMs. And what do you want to send

00:36:18 mails? You have a lot of options. I think EpicStack had the opportunity to do that. Like just create these generators so you don't need to do a lot of code and avoid a lot of boilerplate. But the framework itself doesn't have that option because it doesn't provide all of the options.

00:36:37 Kent: Yeah. And honestly, I don't think that that is something the Remix team is interested in. I think they wanna stay focused on the thing that they're doing. I know that like they do talk about being center stack and kind of eating out from the middle outwards. But yeah, I just don't really see

00:36:57 a future where they're like, okay, we're gonna build our own ORM when something like Prisma exists already, right?

00:37:03 Sergio: Yeah, I don't expect them to do that. I just think it would be nice if there would be a way to do that, like maybe a framework on top of Remix that can provide all of that things. Right now, for example, the way I use Remix is not as a full stack backend, a full stack framework. I

00:37:23 just have a Rails application. That's my API that has all of these things. And then I have Remix as a backend from the framework that can use fetch to consume that API inside the loaders and actions. So sometimes it feels like you are duplicating calls, like a

00:37:43 phone sends the data to Remix, which sends the data to Rails. And like, you could just remove Remix from there and go directly to Rails. But you can also do a lot of other things like validate early and send a response earlier.

00:38:06 Kent: Yeah, it's an interesting feature. There's a lot of room. So for people listening, there's plenty of room for making things better. So thank you Sergio for taking the time to chat with me about this stuff. Is there anything else that you wanted to bring up that we didn't talk about?

00:38:25 Sergio: No, I think we talked about a lot of things.

00:38:27 Kent: Yeah, we covered a lot of ground. Okay, so what's the best way for people to get in touch with you and keep up with what you're working on?

00:38:36 Sergio: You can go to my website, my blog, SergioDXA.com and on Twitter, slash X, I add SergioDXA and on Discord, also I am SergioDXA. I'm SergioDXA everyone.

00:38:54 Kent: That makes me think. And everyone

00:38:54 Sergio: else has that handle somewhere else.

00:38:58 Kent: Awesome. Well, Thank you so much, Sergio. And yeah, have a wonderful evening, afternoon, or whatever. I guess it's afternoon for you, right?

00:39:06 Sergio: It's morning.

00:39:07 Kent: Oh, it's morning? Oh man, I gotta look at a globe. Yeah, have a really nice day, and we'll chat with you later.

00:39:15 Sergio: Yep, thanks.

00:39:16 Kent: Bye everyone