Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.
Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.
Hey, everybody. Welcome back to a new episode of DejaVue.
Michael Thiessen:It's your favorite Vue podcast. You just don't know it yet. And today, we've got not just one guest, but we've got 2 guests.
Alexander Lichter:Exactly. It's a world premiere, and we're here with Zoey and Dan from SideStream. Welcome you 2. How are you doing?
Zoey Kaiser:Hi, Alex, High Michael. I'm doing great. Thanks for having me on today.
Dan Kremerov:Yeah. Thanks for having us. I'm excited to, talk to you and see what the next hour brings.
Alexander Lichter:Yeah. Likewise. And before we get started, as you already mentioned, like, we're here, the 4 of us. I'm here with Michael Thiessen, who is an educator and content creator all around the Vue ecosystem, amazing blog posts, amazing courses, and the Nuxt tips collection where it's the little discount code in the description. The code DEJAVUE will net you a little discount if you haven't bought the tips collection yet.
Michael Thiessen:And my co host, Alex, who is a Nuxt core team member as well as producing lots of content and amazing other things all around the Internet and in person, if you manage to see him at a conference and, you know, get to say hi.
Michael Thiessen:We have got, as we've said, these 2 guests here, Zoey, who is a developer at SideStream and core maintainer of SideBase. So we'll get into, what the difference is there between SideStream and SideBase. And, you know, you might have seen around on GitHub with NuxtAuth. I know I use NuxtAuth and have been, you know, seeing seeing some things there.
Michael Thiessen:And we've also got Dan, who is one of the cofounders of SideStream.
Alexander Lichter:Yeah. And maybe that brings us straight away to the point. Maybe some people heard SideBase probably a bit more in the developer, ecosystem than SideStream, but, the names are pretty close to each other, so maybe it's a good start to to understand what SiteStream is and then what's the difference to Sitebase and how that's related.
Dan Kremerov:Yeah. I take this one. Yeah. So in 2018, we started SiteStream. So it's me and my cofounder, Nils.
Dan Kremerov:You might know him from GitHub as BracketJohn. And, yeah, so we just put, like, a software development agency with, like, focus on high quality software development. And, yeah, we kinda grew as a company to 25 people and was the goal to really have a working culture where we wanna show up every day and just do good work. And, yeah, then in 2022, we created this nonprofit spin off site base where we basically took a lot of good things that we built in over, like, 100 projects for our software development agency customers and created a starter that we open sourced and also created a lot of modules that we kinda, you needed ourselves but didn't find in the Nuxt and Vue ecosystem.
Zoey Kaiser:Yeah. And that was around the time when Nuxt was migrating from version 2 to version 3. And, coincidentally, it was also actually the time where I was doing my internship at Sidestream. So I began working at Sidestream in 2021, and, I kind of started honestly because I was feeling really lonely and also really bored due to COVID. So I had recently just started studying in the Netherlands in Maastricht, And, yeah, I moved in 2020.
Zoey Kaiser:I basically stayed the entire time inside of my apartment due to different lockdown restrictions and began working on some fun side projects, but even those after a while start to become stale. So that kind of motivated me to look around and see if I can find some software development jobs that would interest me and kind of fit my portfolio, and I spontaneously stumbled over SiteStream. And after continuing my studies, it was time to do an internship, and this kind of perfectly had, like, a magical alignment with the stars and ended up in me starting Sitebase together with Nils. And I've been loving to work on it ever since.
Alexander Lichter:Amazing. Yeah. That's, like, that's sometimes how how the world is going. Like, such a such a great fit eventually.
Alexander Lichter:And it's also interesting to see that, like, as a, like, say, software agency with, like, more than 25 people right now, that you all bet on on modern technology such as such as Nuxt.js So maybe let's let's talk about how that came because I I guess when you started the software agencies was not like, oh, yeah. Let's, just, like, randomly spin the wheel and see which of the gazillion JavaScript frameworks you pick, if it's a JavaScript framework at all. So so how did how did that, happen eventually?
Dan Kremerov:Yeah. So I mean, as always with startups, not the first idea worked. So in September 2018, Nils and I basically left our jobs to start something. And for the 1st year, we were just building 24/7 all kinds of products. I think the first one was a disposable email service.
Dan Kremerov:We had a fintech that shall help you, like, yeah, save money for your retirement. We also created a Hotpepper product with web apps that, was supposed to help beekeepers to better take care of the bees. And all these things, they had one thing in common or at least one thing in common, and we always used Vue and Nuxt to build, front ends. And I think when we actually left our jobs, we we weren't really, front end developers, so we both came more from the Python side of things. And so we just picked the frameworks that had apparently, like, a good learning curve to quickly get into.
Dan Kremerov:I think on the 1st weekend, we were already on the 1st weekend working with Nuxt, we already shipped those disposable email servers. Wow. So it was just a very good, experience. And, yeah, since then, we just kept it forever. And, of course, we went through some improvements.
Dan Kremerov:We can also talk about this later, how we changed our tech stack over time. But I think so one constant since the first day was actually a few of Vue and Nuxt.
Alexander Lichter:Amazing. So, like, you said you you were not front end developers by by trade. So it all came from the back end Python side and eventually picked Vue because it seemed to be the easiest to learn and then also Nuxt.js.
Dan Kremerov:Yeah. Exactly. I mean, I think we we both had experience with, like, a bit of Angular, a bit of React, but not, like, on a professional level. And, I mean, I wouldn't do this again that I learn a new technology while, while building a business. That's, that was not a good idea in my opinion.
Dan Kremerov:But yeah. So it's a pick from VioNex was a good decision.
Alexander Lichter:Glad to hear that, of course. And I understand it's like it's it's just double the work and effort and exhaustion if you, like, build something, and then you have to, like, discover things and, like, think think ahead of what what to do with the business side. And then also from the development side, you can't build as fast because you have to learn. But, yeah. Luckily, I mean, with with you and Nuxt, you can still ship fast as you just said with, like, oh, yeah.
Alexander Lichter:I know first weekend, just like casually throw out the disposable email, like, website. That's, that's pretty strong. Like, yeah, pretty amazing work.
Zoey Kaiser:Yeah. So from my side, I actually came from a mixture of React and PHP, and I was introduced to Vue and Nuxt through Sidestream. I think for the most part, sort of Vue 2 and its entire option syntax had always kind of thrown me off, which is why I would say, like, I didn't initially began I began working in Vue myself. But, yeah, after getting into Vue 2, and becoming more familiar with it and actually enjoying it, the migration to Vue 3 just completely sucked me in, and, I don't really see any way that I would go back to React or Angular anytime soon with the developments that, Vue and the Nuxt ecosystem is making at the moment.
Alexander Lichter:Perfect. That's that's always good to hear because it's it's interesting. Let's let's just, bring a little side story in there. Like, I I've I've heard from quite some people. So I'm like, oh, yeah.
Alexander Lichter:Because the React ecosystem is bigger, the whole, like, job market topic, but there was also, like, thematized and countless Reddit threads and even with with Evan when he was in the episode. And I think there are some points where, like, okay. If you have lots of libraries available, because there are, of course, there are more people in in the React world. There might be more libraries. I think still, like, in the Vue universe, we have a lot of things that just work and still also a lot of innovation that's, well, other, framework systems might long for.
Alexander Lichter:So even though we don't have that many people compared to others, I think we're still pretty strong in in terms of innovation and, also time to market. So we just make things easy.
Michael Thiessen:Using Nuxt and Vue in a freelance, like or not a freelance, but an agency like like you have, how have you found that? Like, do do clients care what tech stack you're using, first of all? And, like, do they how's their experience with it, and how is your experience with it? Do you find that it's that is it easy to hire people to to do the to use Nuxt? Or do you just find people and then, you know, train them up on on Nuxt and Vue?
Michael Thiessen:Or how does how does that work for you with with this agency?
Dan Kremerov:Yeah. Very good question. I think when we started, we were very afraid. So I mean, to close the story. So we had all these different products, and they all like the email service and the Fintech and so on.
Dan Kremerov:And, yeah, at some point, we ran out of money. So it's a usual startup story. So we started to freelance. And, yeah, of course, we were building everything in Vue and Nuxt, and so we thought, yeah, we would just offer this, but we're very afraid of what you just asked that they were all, wanna have React developers. But we quickly learned that the tech stack, like, to certain customers doesn't really matter that much as long as it's modern.
Dan Kremerov:So because if they're in need for software development, they usually yeah. They don't have a, like, very strong opinion on technologies, but they, of course, wanna be future proven or future oriented. So, it was not a very like, it's till this day also not a very big topic, like, which, front end front end stack we use. Where we made a slightly different experience was with our back end. So, yeah, in the past, it was in Python, and they are actually it was so we went away.
Dan Kremerov:That's maybe we talk about this later from Python, but this was always a big topic for our customers. So because this was much much more established language in their organizations, and they wanted to keep it. But for front end technologies, it it was quite smooth. So we probably lost a few projects because they weren't React, but not many and mostly they just care about the results.
Dan Kremerov:For the second part of your question, so, about hiring talent.
Dan Kremerov:So we, yeah, we educate, people a lot. So we we actually hire a lot of people from university, that don't have a main tech stack yet, and then we can basically, with our proven processes, bring them on a very good level in a very short amount of time. But for more senior people, of course, we are looking actively in the viewer ecosystem and hire people who already have experience so that they can help our organization to, yeah, improve their tech capabilities and, of course, educate the new joiners.
Alexander Lichter:And how would you say because it's also, like, a a very frequent topic, like the job market. Once again, like, do you feel if you're looking for, like, more senior people in the Vue space that it's hard to find? Would you say, like, okay, especially if you're involved in the community, it's a bit easier. And also given what you offer with with site base, which we'll talk about also more in detail in a bit, would you say that it kind of helps finding people or even say the right people for a job?
Dan Kremerov:Yeah. I think so. It's a mix of of all of those things that you mentioned helps. So we we never have acute problems of finding the right people that we need. So, it's just a good yeah.
Dan Kremerov:If you have a good engineering culture and you use modern technologies, and, of course, it helps to have these, like, size side bets, like, site based, things that makes us quite unique. And, of course, we are just 25 people, so we need to hire. We don't need to hire, like, tons of people, but just very selectively. So, yeah, that was always, like, I think it's something that works well for us.
Zoey Kaiser:I think another very important factor that I, at least, found when I was going through the recruitment process at Sidestream was kind of the methods used to, get to know each other in a sense. And I think this is something that very much convinced me of the company when I was first applying. And it's that there's no real, I would say, like, corporate interview and also no corporate test to, like, prove your skills. So ever since I, I applied at SideStream up until now, whenever people do apply to the company, they have a quick welcome chat, and then they complete something that we call a work teaser. And this is like a full kind of, like, application created in our tech stack, with a couple of demo issues as you would probably get them in your day to day work.
Zoey Kaiser:And, you would get these issues, and you could then work through these issues by yourself and kind of also share your thoughts and what you were doing and how you approached a certain issue. And based off that, we will then give you a bunch of feedback and basically do, like, a pull request review on it. And, this work teaser gives us a good chance to kind of already get to know the programming style and how this person would approach an issue. And at the same time, it gives applicants a really nice overview and insight into how they can kind of, like, expect their working life to be at Sidestream.
Michael Thiessen:Yeah. That sounds like a good process to have to as opposed to doing these, like, arbitrary random questions, like, you know, implement a binary search tree or something like, okay. How often are you actually doing this in your real job? Or, like, how many windows are there in, you know, this city and, like, okay. Like, are these actually like, what are you actually testing here?
Michael Thiessen:You know?
Alexander Lichter:Yeah. Well, they're irrelevant questions. Like, nobody cares if you can reverse a a linked list if you do applying for, like, a full stack position. So I I also like it a lot that it's more like a, let's say, real life near real life test to see, okay, how first of all, how comfortable is is the person with that task? And, you also have a, I think, a good variety of, like, okay.
Alexander Lichter:It's a bit of JavaScript, of course, also in a tech steck. So Vue and Nuxt, but you can also see, okay, is that that does the person have, like, the the basic skills for that position without any arbitrary questions?
Alexander Lichter:So, yeah, that's definitely a big plus point compared to other interview processes. And so we we mentioned site based a lot by now, and we already got, like, a brief overview of of how, like, how it eventually originated and roughly what it is. So maybe that's a good point to to continue from there.
Alexander Lichter:What well, you were using Vue and Nuxt and then started open source. Because before, if if I'm if I'm not mistaken here, please correct me if I'm wrong, You as a company, as, like, SiteStream, you never did, like, much in in open source in terms of, like, hey. We open source our, a package or we open source something we built. So how how did that happen of, like, okay. Let's just, do that.
Alexander Lichter:Let's just open source it. Maybe what was the intention behind it, and what are the benefits?
Dan Kremerov:So I think it was, it was not really planned like it it just happened. I mean, Zoey mentioned that it was like this time when Nuxt 3 was very early, and we kinda so and the other thing is we have as an advantage that we just start a lot of projects. Right? So we we don't have, like, one fixed project, but we maybe start, like, a project every 1 or 2 months. So I think it was September 2022.
Dan Kremerov:By the time, Next Free was very early, but we already used it in probably 10 or more projects, like, with some of our customers. And we needed the starter kind of ourselves, right, to just basically offer to the customers, like, a head start into a project. So not like the first 10 days of work, nothing happens. But, yeah, we have the starter, and we just copy it. And then you already have a lot of things in place before we even started, billing for time.
Dan Kremerov:So we used this for the whole IKEA of 2022. But then to pause a trigger, I think that was a bit of a a rogue action by Nils, Brekajan. So on this one weekend, he just did, like, all the work that was required to, like, make make the starter open source ready and then just tweeted about it, and the tweet went viral. And then when we all came back to office on Monday, everyone was super hyped about sideways. And, yeah, then we started developing a proper road map and, yeah, allocate the time and so on.
Dan Kremerov:But this initial launch, it was just, yeah, a road action, Van Neece.
Zoey Kaiser:Yeah. And I think the funny part about that is he even did that while he was going on vacation. So he pushed he pushed this tweet out on a Sunday evening when he was sitting at the airport, flying on flying to his vacation. And, yeah, I remember, coming back to work on Monday, and in the morning, receiving a text message from Dan. Yeah.
Zoey Kaiser:We need a website for Sybase. I'm like, okay. What am I working with here? What's kind of the time frame? Oh, yeah.
Zoey Kaiser:I would like to have it by this afternoon. And I think this was kind of like the first moment where I was like, okay. Let's get started. Let's work on Sybase a bit more. So, yeah, that Monday after the tweet was pushed out, I was then just quickly trying to spin up a website.
Zoey Kaiser:Obviously, like, not having a lot of time to perfect it, but just getting something out there. And I remember a few days later, we then produced, like, a YouTube video. Also super funny looking back at it. I'm sure that you will be able to find it if you just search for sidebase on YouTube.
Alexander Lichter:Probably put in the show notes for sure.
Zoey Kaiser:Yeah. Of course. And it's just screen recordings of, like, starting up the project and, kind of like these very early looks into Nuxt, which I think is always like a blast from the past.
Alexander Lichter:Amazing. But it's I I like I I really love that story, especially the best part is like, oh, yeah. Let's just push it. Like, it's open source ready. There we go.
Alexander Lichter:And okay. Nils is going on vacation. Goodbye. You know? Now you come to office on Monday.
Alexander Lichter:I'm like, oh, what happened? And you have to deal, like, deal with it, quote unquote. It's, that's that's fun. But, yeah, it it it went so well. Like, it was lots of positive feedback, on the whole thing.
Alexander Lichter:And, it's it's still, like, I think, one of the the most common, like, free starter starter options, for Nuxt.js the at at the time of recording, I would say.
Zoey Kaiser:Yeah. I would agree with that.
Zoey Kaiser:So we do keep looking into sidebase and primarily at this point, it's been renamed to create-sidebase. So, originally, like Dan had mentioned, we created a GitHub, template repository that we would just copy over and then use for all of our agency projects. The issue with that, though, was the more complex the template became, the harder it was to customize it for every project in the way that we needed it.
Zoey Kaiser:So at some point, we then developed a CLI based on this original site based starter, which actually pulls in the newest Nuxt starter base template and then starts building upon it. And I think our notion from the very beginning with create site based has been it's not gonna replace the nuxi add command. So we never wanted to add anything that you could install with one command or just installing a package and adding it to the Nuxt modules. That was never really the goal or focus of Sybase. It was always to kind of start a project with a few more complex settings and set up things that weren't easy to do on your own.
Zoey Kaiser:So everything that needed more steps of documentation than just installing and adding to the Nuxt modules as something that we were potentially ready to add to site base. And I think we still try to keep the selection of what you can add to site base very limited. I personally also think that the more we add, the more complex it gets, which which then takes away from the beauty of it. And, I remember at the very beginning, we had quite a long discussion. How many component libraries do we wanna add?
Zoey Kaiser:And we were thinking, okay. At the moment, we are loving Naive UI, especially for our agency projects where we need a few very complex components, which this library does have. And then people started asking for PrimeView and amp design. And then later on, Nuxt UI also came out. And we were debating, oh, do we wanna add selections for all these different component libraries?
Zoey Kaiser:But in the end, we kind of decided, let's keep it simple. This is oriented around our preferred tech stack at the moment, and it's gonna change and adapt with the things that we use at the same time. And, I think that was a really good decision, because I do know a lot of CLIs and starter tools that just overwhelm you with options and choices. And especially if you're just trying to get into Nuxt, which is also kind of like the goal of Sybase. Getting people into the Nuxt ecosystem, helping them just set up this first test Nuxt app, you're not gonna really know what the difference is between all these different packages or options that you would have.
Zoey Kaiser:And I think that's why we decided to keep the CLI pretty simple.
Alexander Lichter:Yeah. On that note, it's, like, really reminds me, in terms of complexity, like, the the Nuxt 2 wizard when you, like, had create Nuxt step back then. Like, of course, if you know exactly, oh, yeah. I want this, this, that, that that's lovely. It will save you some time.
Alexander Lichter:But I remember the the sheer amount of component libraries in there. Like, what are all these? Which should I pick? What makes sense? And I think that's also one of the the reasons why we don't have, like, a wizard in Nuxt 3 right now.
Alexander Lichter:It's there is an issue for that also linked in in the show notes because I know some people ask about it very often. But, yeah, having the right balance between what should you ask for and what's just, like, one step too much, especially for people also just wanna start a bit more minimal, just like right right now. It's like Nuxt 3 if you start with, like, nuxi like nuxi in it. It's pretty minimal, and that's great. But then people like, oh, yeah.
Alexander Lichter:What can I do? I could read the dogs and spend hours on that or minutes, but I I don't do it. So I just wanna have all the things to take a look at. And, yeah, it's it's hard to balance, and I think the same applies to to starter and the and the CLI.
Michael Thiessen:So right now, what are the things that the starter comes with? If you're gonna start a new project, what can you expect? What are the options that that you can can get with this starter?
Zoey Kaiser:Yeah. So, Sidebase has always been focused around being a full stack NUXT 3 starter. In theory, you could bootstrap it without the back end parts, but I do feel that those are the most powerful components that you can add to the starter because they normally require the most setup. So I would say, like, the 2 base components that really make site based useful, in my opinion, are Prisma and tRPC. And both of these, modules and packages in general are a bit tricky to get set up in Nuxt properly.
Zoey Kaiser:Also looking into both of them, there are modules available for it. There are packages available from the libraries themselves, and each one of them does things slightly different. And I think they all do a really great job in what they're trying to achieve. But through the long time we've spent in Nuxt 3, especially with this Prisma and tRPC stack, I feel like we've gotten quite confident in what setup works best for us. And that is what we added to Sitebase.
Zoey Kaiser:And for both tRPC and Prisma, we use every package from the organizations themselves. So we refrain from using more Nuxt modules or trying to, like, install other packages that may wrap them because we figured out that especially with these back end routes, it's really best to just get the things from the source. And we fell into that same trap at the beginning because, initially, we actually developed a Nuxt Prisma module and a Nuxt RPC module, just to see how that would work. And at the beginning, Sybase was using these, but we did notice that, these are 2 packages that are just kind of better imported directly instead of having another wrapper on top of it. So, yeah, those 2 kind of make up the base core of it.
Zoey Kaiser:Then we obviously also add our own modules to the selection. So in this case, Nuxt off being another very big one, which also requires more configuration than just installing it and adding it to the docs module section, especially if you're using OAuth providers or trying to create a more complex login flow. So in create site base, you get a GitHub provider and a credentials provider configured out of the box as well as page protection on certain page routes, which does give you quite a nice starting point to then continue configuring the providers as you would need yourselves. We also added a lot of in code comments to what we generate, that it's not just, oh, here's your code. Have fun.
Zoey Kaiser:But you also get small indications on what does this actually do now exactly, or linking it to further docs where you can actually read more about it. So it really focuses on kind of giving you this helping hand in continuing to work with it. Yeah. And then lastly, we have a few styling options, and I would say these are more the optional parts that you can install if you'd like, which is Naive UI, the component library I mentioned before, Tailwind CSS, and, we recently also integrated the internalization module from Nuxt, Nuxt I one eight n, after we started enforcing it in a lot of our agency projects as well. Yeah.
Zoey Kaiser:And this pretty much makes up the base selection of what you can add to site base. So like I mentioned, quite limited and quite small in scope. But I feel like that by focusing on these core elements, we can do that really well.
Alexander Lichter:Yeah. I mean, it sounds reasonable to be more opinionated and saying, okay. This is what works well for us, so we provide it to the other people as well. And if you have a similar use case, maybe you want to throw a not Naive UI, but, yeah, maybe maybe Nuxt UI or or PrimeView or Vuetify or whatsoever, then you're free to do it. Right?
Alexander Lichter:You don't have to choose the API to to work with Sidebase. You can just select let's not use it and use all the rest of it.
Michael Thiessen:So you had mentioned that you had wrapped the Prisma and the tRPC packages, and then you found that it wasn't actually worth worth wrapping at all. What were the issues that you ran into where you found it was it was getting in your way?
Zoey Kaiser:So I think if I focus on Prisma specifically, the entire, like, small little configuration areas and ways to hook into Prisma. Writing a wrapper around Prisma and then still allowing for the level of configuration that you could get from the base module is very difficult. And, this include things like defining your own Prisma middleware, augmenting the types, extending it further, adding other database providers, and, this became very challenging to maintain. And I would say also generally just the fact that every time Prisma didn't update, we would have to update all the modules accordingly, just generally resulted in the system where we didn't add much to the module itself that the module couldn't do itself and just added more layers of abstraction on top of it that, at least in my opinion, retrospectively, were not necessarily needed.
Alexander Lichter:Yeah. I I also can second that experience, because may maybe some of the listeners know, the whole topic around the Sentry SDK or module, a long standing issue. But luckily, also, they are plugging that already. There's an alpha version of the Nuxt SDK available right now. Link also in the show notes.
Alexander Lichter:Definitely give it a spin. Give it a try. I'm very happy to see, that Sentry is building a known SDK for Nuxt by now, also with the help of, the the Nuxt team for some questions and back and forth. But I I wrote a blog post. So, like, okay.
Alexander Lichter:Look. I tried building a module for that, but the big issue is, like, yeah, making it work for every developer. And I remember that's, one of the 100 people was even, like, retweeting the the tweet back then. It's like, yeah. Oh, I also shared with our engineers, and we that resonates very well with the problems we have of, like, okay.
Alexander Lichter:Here's our, I don't know, error monitoring and performance monitoring suite. Let's make it work for all languages, all frameworks, everything for every like, even the weirdest requirements, and that's super difficult. And then even if you say, okay. It's not even the software that you built. It's a wrapper around that for a standard kit.
Alexander Lichter:So you have such a high level of abstract abstraction. It's it's super difficult to build an interface that works for everyone, without, like, giving an option to, like, okay. Let's eject from there. And that's also I I'm a big fan of, like, using a recipe in favor of a module if it makes sense. They're like, hey.
Alexander Lichter:Here, this is how you can initialize it in terms of starter. That's the code. Here you go. You can do whatever you want with it, but you own your implementation.
Zoey Kaiser:I think that's actually a great way of putting it. And that's exactly what we use create site base for, to primarily give those recipes directly to you into your code editor or into your project, and adding the things where we say, okay. A Nuxt module may not be the best option to actually add this to your project.
Alexander Lichter:Totally makes sense.
Alexander Lichter:And maybe from here, pivoting once again back to to SIDESTREAM, like, okay, Sidebase became more popular, knocked off. This will also be a blog we'll talk about dedicatedly about the knocked off a module of of the site based organization. But how, like, how would you say open source benefited? Like, how how did SiteStream benefit from making site based being open source and being in that space?
Dan Kremerov:Yeah. I think when we open sourced it, there was this natural reaction of a lot of people that, okay, it's a spin out now, and we need to find a way to make it sustainable, also maybe monetize it. That was, like, a very natural reaction by a lot of employees and by myself as well. So we had a few brainstorming sessions. Okay.
Dan Kremerov:What's a good maybe business model for site based? Came up with also usual suspects. But then if you really, like, do the math, we have a, like, very well working business at SiteStream. And, yeah, we we need all the manpower actually to to run it. So, it's actually much better to label sidebase just as a, like, nonprofit.
Dan Kremerov:That gives a lot of other benefits to us. And, yeah, that brings me to the question. So, I think one one emotional thing that it brings to a lot to many of us is that we have finally, like, our own product. So something where we can take care of daily because, I mean, the we we have very long lasting products in the agency also for years, and we take care of them very very well. But the thing is still that, it's not ours.
Dan Kremerov:So, any day, the customer can come and take it away from us. And so we kinda always had this, like, emotional emotional thing that, yeah, we need some, like, baby. We need something to take care of. Also, like, there's much more motivation of people to, like, take care of site base on the weekends or fix issues on the weekends than, of course, for some agency customer. That's one big thing.
Dan Kremerov:But then there are also a lot of other smaller things as we talked about, so, like, attracting talent, being close to the next core team, and, yeah, also, like, kinda understanding how they take how to, like, raise concerns that we might have in our day to day, developments. And, yeah, also, just it's just fun to be in the community and contribute. So I think these are all the drivers of, yeah, putting daily work into set base.
Alexander Lichter:100%. Like, I I also think, as you mentioned, like, open source for lots of people, open source is like a hobby or like, a little side project. But also being able to to do it both as, like, a hobby but also during your work hours is is a real benefit. Because also, I think if you build things like an agency, of course, you have, like, projects. They're out.
Alexander Lichter:It's like, hey. I don't know. This ecommerce solution or this dashboard, that's maybe dashboard is even worse because just a handful of people might see it. If ecommerce, they'll just shop. Like, hey.
Alexander Lichter:You can show, hey. This is what I built. Look. But with open source, also more like, hey. I I contribute to what, like, potentially 1,000, even more maybe people use.
Alexander Lichter:And this also has like a long lasting impact. So I think that's, in a way also, like, a really good intrinsic motivation of people going, yeah. Yeah. Nice. I wanna work on that.
Alexander Lichter:It's it's fun.
Zoey Kaiser:Yeah. For me, the community is a big factor and why I really enjoy working on and kind of maintaining side base. So I interact with so many different people from all around the world, and we kind of have this one combining factor, which is Nuxt. And, I always love hopping into calls or also just chatting with people, primarily through Sidebase. And I've seen so many really cool projects and other initiatives that are using Sidebase to then kind of build up their product.
Zoey Kaiser:And through Sitebase, I've just been able to get this really nice insight into what other people are working on. And, obviously, it has also opened up so many contact avenues for me, and has kind of also motivated us to be a bit more active inside the community if it's, attending conferences, joining calls with other people, or generally also just opening up issues or pull requests inside of the Nuxt repos itself. So I think I think the community is one of the biggest driving factors for me and, kind of continuing the work on Sidebase and ensuring that it stays up to date and works.
Michael Thiessen:That sounds like a lot of fun. You're you're tempting me to start my own side project, in the open source. I don't know if I have time
Alexander Lichter:Do it!
Michael Thiessen:for that, but, I've got so many ideas for side projects. I feel like every episode we, you know, someone comes on here and talks about something really cool and I'm like, oh, yeah. I should do that too. And so
Dan Kremerov:It's a lot it's a lot of work.
Alexander Lichter:Yeah. That's that's true. But it's like I I think I think with people getting inspired by these stories, so by people going like, hey, this is super cool library, like, try it out. Or hey. We have this cool open source project.
Alexander Lichter:Might not contribute. Like, I think that's that's a really good way also to see what's out there and people, like, work on it with passion. Why people even doing it. Right? Like, what's the motivation behind it?
Alexander Lichter:And for example, the community aspect is a big one. And and also, like, it's it brings you further in a way of, like I never for example, I never had, like, a formal, like, supervisor in terms of code. I had no one ever review my code at work. And open source was more or less my my mentor. Like, people in open source were, like, reviewing, criticizing, and and that's helped a lot, and that helps a lot of people out there.
Alexander Lichter:So it's also, like, a a really good way to improve your skills and learn from the the best of the best out there because lots of maintainers and library authors there. They're pretty smart people. So yeah. Also, once again, people get into open source and do it.
Zoey Kaiser:I yeah. Definitely. And I also think what you just mentioned, even on-site based, when we were quite small and still starting up, we were already getting pull requests by Daniel Roe or also by yourself. And I think this kind of shows that the Nuxt, yeah, maintainers are active inside of their community. And even if you just start a small project, the chance that you're gonna get a review or you're gonna get help and you're gonna learn more things from other people is very high, and you don't necessarily need to go searching for it.
Zoey Kaiser:I think, eventually, just by the Nuxt community, people are gonna become aware of your project, and you're gonna learn more about it, which I think is awesome. It's really lowering the bar to being able to publish something in open source. And it also takes me kind of, like, to my next point on developing Nuxt modules, especially for Nuxt 3. Because when I first started working on Sybase, I had honestly no idea what I was doing. And I, like, had published, like, 1 or 2 npm packages before maximum.
Zoey Kaiser:But just generally, the process of bootstrapping and setting up a package that I could then distribute on npm was such a foreign and hard concept to me, especially when you then wanna integrate TypeScript. That when I began developing my first Nuxt Nuxt modules, I was really surprised by how easy it was. And I I feel like that is also one of, like, the main benefits that I see for Nuxt and also where yeah. The the barrier to entry is the lowest of all the different major frameworks out there. Developing a package for React or Angular is, at least in my opinion, a lot harder than it is for Nuxt.
Zoey Kaiser:And, Alex, you had mentioned before that some people may say, oh, the Nuxt ecosystem isn't as big as the React or the Angular ecosystem. Where I would kind of counter that to that and say, it's become so easy to expand on this ecosystem and just create your own module. Take a port of something else and make it available for Nuxt 3 yourself, that, that isn't really a factor for me anymore. If I'm missing a certain feature or a certain packet and it exists as a regular TypeScript or JavaScript package, I can easily just add that to Vue and, create a great developer experience, a great integration for it, and less that in less time that I would probably need to create the same package for for React or for Angular.
Alexander Lichter:Yeah. But that's that's that's definitely true. Like, the Nuxt module integration also compared to most of the major frameworks out there, at least what I tried, is like, none none of the the big ones has has a similar way of, like, okay. Let's just add things, extend things, and you need it. Like, even if you write your own module for in your company.
Alexander Lichter:Right? Just like, okay. Here are our our ways of dealing with things, with our data integration, with our, I don't know, with our CMS that has a a weird requirement. That's that's a great way of doing it and then sharing it around either open source it or, like, in your in your company. I've seen it also multiple times, and it makes things really easy when it comes to code reuse.
Michael Thiessen:So I have a question about how you started with Sidebase. So you mentioned that you you had, you know, a 100 different client projects that you had done in the past with Nuxt. So how do you go from all of these projects where you've written lots of code for maybe the same things over and over again to then creating this starter? Like, did you go back to previous projects and pull out code from there, or did you start from scratch just with what you had learned? Or, like, how what was that process like for you?
Dan Kremerov:I think it was mainly so we were building the starter internally over over the years. So we also had one for Max too back then. It was just a natural thing because if you start, like, a new project every every month, then you just wanna and then you always hear from the team on the previous project, yeah, this went well and this didn't went well. Let's do it a bit different next time. And so every every project is like a bit of greenfield and an opportunity to just have a cleaner start.
Dan Kremerov:And, yeah, if you do this, like, 50 or a 100 times, then, in the end, you have a pretty good result. And I think it tells us day we like, every every project we start, like, as an opportunity to test out, like, 1 or 2 new things. And if they are good, they might make it to site based one day. So that's how how we think about it. And then the open sourcing of the starter was, yeah, was quite natural once we once we had, like, a starter we were confident with.
Zoey Kaiser:Yeah. I think for the most part, it really gets born from necessity. So, we develop what isn't really available yet, or if we have a very specific use case, then we may also need something specific for that. I think, honestly, the fact that the migration from Nuxt 2 to Nuxt 3 was this big is probably one of the main reasons that Sybase did become available to this extent. And it was really just the fact that we were using Nuxt, 3 release candidate 2, and we're trying to get this running in production for our client projects.
Zoey Kaiser:And, obviously, when working with clients and especially internal applications, something like authentication is an absolute requirement. And at that point, in RC 2, nothing existed yet. So we had initially then, for our first project, just started developing, authentication system inside of the project itself, which then later kind of became the authentication module, but also not quite. So, yeah, I I think it's really just necessity. What do we need at the moment inside of our projects?
Zoey Kaiser:We develop that, and then afterwards, we see, is this something really specific for our project, for our use case, or is this something that everyone could benefit from?
Alexander Lichter:Totally makes sense.
Alexander Lichter:I was I was wondering, now when when you talk about how you created Sidebase base and then also you mentioned that you used Python in in back in time, and you switched the tech stack now. I wonder if if it came to your mind, it's like, let's create something similar, like like site based, but for, let's say, the back end, the Python world. Or what made you eventually move away from Python to what you have right now, and what is it?
Dan Kremerov:So, yeah, we are full full stack TypeScript now. That's that's the end result. But, yeah, it was a long journey, here. So, I mean, we started Python. I I mentioned this in the beginning.
Dan Kremerov:I've seen the two main reasons why, okay, we already knew it quite well, and this was, like, the only language besides some, like, legacy languages where, like, potential customers were kinda attracted to. So I think we actually we landed our first very big customer because of Python. So, and then we worked, like, maybe 2 years with them, and we still work, with them. But, like, after 2 years, we maybe had 3 or 4 applications running just for them, always the Python back end, plus a few other customers. And then there was kinda so we always had to submit, okay.
Dan Kremerov:If we switch away, we have still have to maintain all these things. So we were quite scared for a long time. But at at some point, we basically just started, saying, okay. Also, new projects will be forced like Type Script, no Python in new projects anymore. Similar like we also did for Nuxt 3 at, at some point.
Dan Kremerov:So we still have to maintain some Nuxt 2 projects, for instance, and we still have to maintain a few Python projects. But over time, this, becomes small a small amount. And, I mean, why we did it was basically two two reasons. One is efficiency. So we put a lot of, like, emphasis on quality.
Dan Kremerov:So that's what we are known for, high quality software development. But customers still care about cost and efficiency, so we sometimes got the feedbacks that we are just too slow. And then we kinda thought, okay, what can we do? And, yeah, unifying the language basically helps with, yeah, documenting everything better, having more, more clear processes, reviews, but also with staffing people. So, we used to have the separation of front end, Vue people and back end Python people.
Dan Kremerov:Now everyone is just a full stack developer, so that makes things in staffing also easier. It makes also things in hiring easier. And, yeah, I think everything just got much easier by removing this complexity, and we also got more efficient. So I would, I would do the choice again.
Zoey Kaiser:Yeah. I remember back in the days where I would so I was in the front end team, and I would finish my Vue 2, parts of the application or the feature, and then I would wait, like, an entire week for the back end to also be finished up and merged. And in the meantime, I was working with, like, some mock data and trying to, like, get everything previewed. And at that point, my implementation and my designs are all approved, but I'm really just waiting on the back end to also complete the feature while they might still be working on something else that I would then have to get to. And I think this unification of nowadays, I get one feature and I complete it end to end in 1 or 2 PRs is really amazing for the developer experience.
Michael Thiessen:I've worked, in both both sides of of that where in one job I was the the front end developer, and then I had the same experience, like waiting. We we did the full agile thing. So, you know, halfway through the sprint, my work was done, but the back end was still being finished. So then I had like a full week where I was like doing other stuff or, you know, reading articles about front end development online or something. And then then the the next place I worked at, it was the opposite where we were all full stack developers.
Michael Thiessen:So if I was working on a feature, then I'd add the UI for it. I'd maybe update some database schema or maybe, you know, try and figure out how to tweak some AWS settings if I needed to. And then, like, I yeah. From from the CSS all the way down, that was all owned by a single person. And it was scary at first because I didn't know how to do all this other stuff.
Michael Thiessen:But, you know, you have people to help you, and so that that that's great. But it's yeah. It's it's better to own the whole thing, I think, because you're never blocked and waiting for someone else. You just get to keep going and and yeah.
Alexander Lichter:I think also that's why, like, a lot of people move towards full stack developers. Even though, like, full stack like, of course, you still might be having more front end oriented focus or maybe a 4 like, back end focus because that's what your strengths and your interests are. But you still can do both, and, of course, you have then then people reviewing your code as well, so it will always be a certain quality. I hope you folks out there also have code reviews. Otherwise, maybe check the process.
Alexander Lichter:That would be really good if you have, save for tests, but that's also a definite topic. Anyway, like, I I understand it's also really good in terms of responsibility because I'm like, okay. That's a feature. That person gets it. There are some reviewers or, like, you can always ask for help, of course, but then you're up to implementing it.
Alexander Lichter:What I was wondering is, did you switch to use, like, full stack in terms of you have that 1 Nuxt 3 application? You do everything in there, so, like, in the server folder with Nitro, or do you have, like, external services in TypeScript? So what's what's the strategy there?
Zoey Kaiser:Yeah. So up until now, it's always been one single application that we were working in. We have our first project right now, where we're actually starting to use, Nuxt layers, ever since, I think, in 3.12. They introduced the auto import from the layers folder. So, that was kind of a really good motivation and a good, test for us to, try and modulize different parts of this really big application that we had.
Zoey Kaiser:And so far, we're really enjoying it. It works really well with kind of, like, allowing this domain driven splitting of the code by still kind of having one single source of truth and one single repository. But, yeah, aside from that, all of the Nuxt 3 projects at least have been running on a full stack Nuxt 3 server, that would then be deployed or scaled horizontally, however needed.
Alexander Lichter:Okay. Sweet. And do you still use, for example, tRPC in your stack then even though you don't have, like, an external API anymore, or, like, are the Nitro end to end type safety set enough for you?
Zoey Kaiser:So we actually still use tRPC instead of all of our projects. I think one of the main reasons for it is that it has a really great integration with zod, And just in general, it makes data validation, sending back and forth, also auto generating types super easy. So, yeah, when it comes to our normal development stack at the moment, we would really define the schemas as Zod schemas, use them for the input and the, and the outputs of the different tRPC routes, and then just access that directly in the front end of our application and have validated inputs into our API and validated outputs, which has been making working with data and also kind of connecting the 2 separate parts together super easy.
Alexander Lichter:Yeah. I I also think, like, that's, like, that's the strength of tRPC compared to what we have right now in our 3 because I think we will get there when especially you have, like, types type body or, like, type query parameters and and routes in general. Like, the routes you already have with Nitro. Right? But you can also validate your inputs.
Alexander Lichter:The only thing that's missing is like, okay. You can define for your for your endpoints. Like, okay. These are the query params that I wanna see. This is the body schema, and then you're good to go.
Alexander Lichter:As soon as that's coming and I it's it's pending for a while, but it will come, I think then maybe it's time to switch at some point. Who knows?
Zoey Kaiser:Yeah. I I mean, I also really love the, built in API routes by Nuxt. I've just also figured out it's amazing when you have a small project, but, we recently did a head count of all of our tRPC routes for our biggest project. And we're almost at 211 different API routes to make everything completely functional. So 211 mutations or queries that are possible contained in, like, I think, like, 43 routers themselves.
Zoey Kaiser:And, I I I just couldn't really imagine the amount of files that you would kind of have and the amount of code spinning that you would need to make this work in API routes. So I think for me, like, the main kind of, like, reason for using tRPC is is kind of, like, not necessarily needing to define single routes for single actions, but just having a lot of different actions, domain split inside of different files.
Alexander Lichter:Interesting. Yeah. I mean, I I think that's a fair point. Even probably you could do a similar thing as you don't have to rely on file based routing as you already know, of course. But I I I see the point of, okay, we just have the functions.
Alexander Lichter:We can just call them. We're we're fine, and not having, like, okay, let's name these. Let's have have it like restful, get post, puts, delete, even though it also gives a sense of structure, but I I I get the point for sure. Alright. Maybe that's also a really good point to jump over from tRPC versus Nitro API routes over to, another thing we mentioned before, which is authentication and and Nuxt off.
Alexander Lichter:Because I think besides, like, the create-sidebase CLI and starter, Nuxt the Nuxt auth module at site based Nuxt auth module is probably, like, one of your if not the most popular thing in in the Nuxt ecosystem that you've, that you've published and still maintaining, today. So, also, there, you you briefly teased how it got started, like, how how it happened that you were interested in building that module. But maybe, like, bring bring the whole journey of, like, how you got to building, the next off module, and maybe some other modules that you've built and and how, yeah, how it happened and what the current state is.
Zoey Kaiser:Yeah. So, like we mentioned before with Nuxt Auth, it was primarily born out of necessity. And also back then, we kinda wanted to find a way that we can quickly support as many authentication methods as possible without having to, in a sense, do all of the hard work ourselves. And, we noticed that there are a lot of different OAuth providers out there. And as we've spoken about before, once you release a module, people are gonna wanna be able to use it in all of their projects.
Zoey Kaiser:And everyone requires different authentication methods. And kind of just being able to support and maintain this seemed like quite a big challenge, so we approached a bit differently. Instead of writing our full custom authentication module, we very early on found a way to kind of hack NextAuth into working with Nuxt. And this, I would say, was primarily a challenge because we had to find a way to convert everything Nitro and h three based into requests that NextAuth could actually handle. And, obviously, we also had to do, like, a further layer between that to then not just migrate h three and Nitro events into, like, standard web events, but also get them back transformed into React and NextJS events that could be properly read out by NextAuth in the background. And, I think this was the most challenging part of it. But as soon as we kind of had the first proof of concepts working, and then did our first initial release, we launched with, I think, over 40 OAuth providers out of the box, which is something that would have not been possible if we kinda started at the very beginning. So I think we did do the correct choice there. But over the long run, there were also some clear limitations with using NextAuth.
Zoey Kaiser:I think one of the biggest ones being that it required a server side deployed application where the client and the server were running separately. Any kind of, like, on the edge, production deployment was not possible, and static deployments also caused a a bunch of issues because you obviously need, you know, some kind of server in the background to handle the requests. So based off that, we then added the initial provider's, system on top of it, and introduced a local and a refresh provider and really tried to make those match the old local and refresh provider that was available in the Nuxt auth, module for, Nuxt 2. And, these kind of became our answer for statically deployed applications that people could then continue building on more. And these 2 providers were completely our code, so no having an external package or anything else run under the hood, which was really nice because there were so many issues that were opened on NextAuth where we just said, this is due to NextAuth.
Zoey Kaiser:We can't really do anything here. Our hands are tied to a certain degree. If they don't have this feature, we can't really modify their package to be able to support this. Yeah. And now we have arrived at present day.
Zoey Kaiser:I would say that the usage of the Auth.js provider is still slightly higher than the local and refresh provider, but, we do see a lot of people using the local and refresh provider. So there seems to be quite a demand for static or just generally credentials authenticated apps as well. And, yeah, our next big step is fully moving away from NextAuth and running the new Auth.js core under the hood, which is basically NextAuth without any React logic. And the team, behind NextAuth, they created auth.js. They basically took all of their code from the next module and, split it all into actual JavaScript chunks that could then be framework agnostic and, gave this out to everyone in the community to begin building integrations for all frameworks that might be out there.
Alexander Lichter:Sweet. So that means in the future, we'll also see, like, Auth.Js, the the successor of NextAuth, so to say, fully working with with, sidebase NuxtAuth. I've seen some some PRs now for us about it already as well.
Zoey Kaiser:Yeah. Yeah. We hope that, that this migration will, be quite soon. I think definitely this year, but we don't wanna rush into it. So we have kind of been doing, like, a slow migration instead of doing, like, one single hard cut with 1 huge PR that changes everything.
Zoey Kaiser:So, for example, we recently migrated to the, off JS core functions that were already used inside of the NextAuth package itself, but haven't switched over the primary package yet. But that's gonna be one of the next steps. And through this small incremental migration, we hope to generally create quite a smooth migration, where in the end, most people wouldn't even notice something had changed, aside from them maybe installing a new package. And ultimately, that's our goal with this, to make it as easy as possible, and also avoid any unforeseen issues before they could even occur.
Michael Thiessen:Seems like a smart way to get this started by wrapping and building on top of another thing that already exists so you can get that initial level of functionality, but then slowly adding on extra bits that you need, slowly moving away from that internal piece if you need to, and, like, doing that incrementally so you don't break the existing functionality, but you yeah. You get that you get that head start. I think that's, yeah, that's a smart smart approach. Obviously, not with that, it's, drawbacks though.
Alexander Lichter:Yeah. There's always pros and cons. Right? Like, if you rely on dependencies, you also have to deal with them. But they they are back to, like, recipe and owning the implementation versus, yeah, actually having a and making it accessible, to all the people.
Alexander Lichter:What what I was wondering because, like, sidebase like, nuxt auth came out pretty early as well. Like, people were always longer for an off module because I admitted, like, building off, can be depending on the system quite some pain. You all know that here. And I wonder, like, over the time also, like, in the core of h3, for example, and also in the Nuxt ecosystem, there were a few improvements, I would say. For example, the the session in h three, the session support or also what is what Sebastian aka Atinux is building, Nuxt auth utils came out.
Alexander Lichter:How would you say that that these two things and maybe also others that can come to your mind, like impact, Nuxt Auth, and and when maybe we would use 1 or the other?
Zoey Kaiser:It's actually super funny that you mentioned the h3 sessions, because prior to Nuxt Off, we actually developed Nuxt Session. And this was basically identical to what h three has now, but before h three had it. And I think kind of moving away from Nuxt Session and then also deprecating it after the release of h three sessions is kind of the way that I would see it. In the end, we want to kind of, like, use the best feature or best system that's currently out there. And, the h3 sessions were done super well, and we didn't really see a reason to keep Nuxt Session around if a much better built and alternative for it exists.
Zoey Kaiser:And we are super happy with the h3 sessions. So it's not in any kind of way something negative, I would say. It's always something very positive, I would say, for the entire community. And I think, I have the same view on any kind of other authentication library for Nuxt 3 that comes out. I'm super excited whenever I see someone release something for Nuxt and authentication related, because I do know that our module doesn't do everything.
Zoey Kaiser:And our module also shouldn't do everything. And I find myself actually quite often also recommending other modules or also very often the nuxt-auth-utils by, Sebastian instead of our module, just because they may be a better fit for what someone is building. I still kind of think that by using auth.js or NexAtuh, we provide, like, a very out of the box preconfigured solution for people, which I think is really awesome, especially if you just wanna get authentication up and running super quickly. But I also do know the drawbacks of it, which, yeah, can make setting up things like refresh tokens for especially different providers out there super difficult and challenging. Or accessing very specific points of the authentication life cycle.
Zoey Kaiser:And I think in those cases, if you really need a strong level of control over your authentication flow, then a package like Nuxt Off Utils, provides a much better provides, yeah, a much better experience for it, and in the end, provides, like it has in its name, utilities for it. So I think, any kind of authentication related module, I'm always super excited about. I love seeing what other people come up with. And I I think it's really just a matter of choosing the tool that's correct for your current needs and your current project.
Dan Kremerov:Yeah. Just just second this. Maybe that's also benefit of us doing this, like, yeah, non for profit, basically. So there were
Dan Kremerov:a few issues, especially, with pause when other other solutions came out and we were we were a bit unsure how to treat them, because, of course, you have some, yeah, competitive mindset also. But in the end, I mean, this is really like, our mission is just to give back to the community, and, yeah, we can we can admit if, like, another solution is better or also, like yeah. We always recommend, like, the best solution for the person and not necessarily ours because we don't have any, like, hidden motivation to find our users into a certain solution that we own. Yeah. So it was a bit hard to get used to this mindset, admittedly, but now I really enjoyed.
Zoey Kaiser:Definitely agree. Like, the mindset that I was just explaining, like, I didn't have this at the beginning. When the first other projects were coming up with Nuts authentication, I was, like, head deep comparing it being like, oh, what are we missing? What should I have right now? What do I need to quickly push out without properly testing and building it?
Zoey Kaiser:But I feel like the longer I've kind of been working in open source, the more I've noticed that there's never gonna be too many packages of something. And people, in the end, are always gonna gravitate to the solution that most fits them. And if site based wouldn't be the solution for them, then that's completely fine. Then that's just the way it's gonna be. And I I think, like, another major shifting point for me there was kind of reaching this point where people wanted features that I just wouldn't necessarily see as being part of the scope of our module.
Zoey Kaiser:And getting to a point where we began noticing, okay, we already offered so much and we're maintaining so many different parts of code here. We can't add much more. We can't add more edge cases. We can't add more special features for every single person that could require them. And I think in those cases, it makes so much sense to then continue developing on top of that, creating a new module, switching to something else that then does provide those features.
Zoey Kaiser:And in hindsight, that's that's a net positive for the developers. It's a net positive for us as maintainers because I also wouldn't wanna maintain a module that's been 2 or 3 years in development and has expanded in scope so much that I I just can't get behind it anymore.
Alexander Lichter:Yeah. I think it's it's a it's a really good take and, also attitude, especially when it comes to open source. Because, yeah, I think if you would have a product that you would sell and be like, hey. This is what pays our bills, then it's almost like and, of course, if you have competition, you wanna be better, you wanna be the the best out there. But even there, you can say, like, okay.
Alexander Lichter:Look. We can learn. What do they do? What could we do better? Also, what we don't wanna do.
Alexander Lichter:And if people want x and we don't offer x, then they can go to to a competitor. So I I think it's in the end, it's very good to see open source. Like, hey. We all want to collaborate in a way, and it doesn't matter if you choose, like, our module or if the other one is better fit, then please take the other one instead of choosing ours and complaining why it doesn't work for your use case. So I I like that toolbox metaphor a lot.
Alexander Lichter:Like, okay, you have so many tools, AKA tools in your toolbox, like choose the right one for your job. And like also having, like, having maintainers thinking the same will really help to, like, have this collaborative mindset. Because as you said before, okay, people from the Nuxt team make PRs and the other way around as well. So it's like a give and take on all directions to make, like, everything better for for all the users.
Alexander Lichter:And coming maybe coming from Nuxt Auth to other modules we've pulled, you mentioned the the Prisma module before, which doesn't exist anywhere in your tRPC module.
Alexander Lichter:Are there are there any other modules that were, like, on the list that's that's don't exist anymore that might come up that's, are still there but might not be? I'm curious.
Zoey Kaiser:Yeah. There's one module that got away from me. And this is kind of really, like I would say it's my sad story when it comes to development and Nuxt because it's something that I really just wasn't able to do. And, I think for the most part, it's primarily just because I had a vision that was unrealistic. I tried to implement it, but I just noticed it wasn't going to be as good as I wanted.
Zoey Kaiser:And that is probably the reason why I stopped developing it. And, that was gonna be the nuts PDF module. And I was kind of really hoping to find a way to build a solution where you wouldn't really have HTML to PDF, but you would have a kind of more native solution. So in a sense, something that goes in direction of Vue email or React email, where you have pre built components, which you could then use instead of Vue components to create a PDF. But I did notice after a while that emails are based on HTML, PDF is definitely not.
Zoey Kaiser:And no matter how much optimization I was trying to do, it just wasn't turning out in the way that I had hoped for. And ideally, I would have wanted it to be just like Nuxt Mail or, or React email, where you build your component and it just renders a PDF magically out of the box for you. But, yeah. It just never really turned out the way that I was hoping for. And I think at some point, I noticed, okay, this isn't that much better than just taking HTML to PDF and using that internally.
Zoey Kaiser:So, I kind of paused development on that. Who knows? Maybe in 2 or 3 years, there's gonna be another solution that I think of, or maybe someone else figure something out. I think that would be absolutely amazing. But creating PDFs, kinda still one of those pain points for me in development.
Zoey Kaiser:But, yeah, I wasn't able to find a solution for it, I would say.
Alexander Lichter:Yeah. PDFs are are difficult format. I I think there's no place like, hey, PDF. I love the format. It's so amazing because it works on every device.
Alexander Lichter:It's so easy no matter with with PDF reader use. I had the weirdest issues with that. Even, like, just bureaucracy in in Germany as well. Like, there's so many PDFs you should, like, print out. If you send them online, then you can't see the field inputs and, oh, it works on Mac OS, but it doesn't work on Windows and no.
Alexander Lichter:This is it's it's really messed up.
Zoey Kaiser:It really is. Yeah.
Michael Thiessen:And even tools like, so I've used prints XML, which is really great and it has like a support for the whole CSS paged media thing, but then like you're, you're learning a whole set of CSS features, which aren't implemented in browsers because browsers don't need them. And then maybe some, like, special CSS attributes and things that that Prince has just to, like, get the the PDFs to, like, you know, break out the pay break the page at the certain spot. And it it seems at first that you're like, oh, great. HTML and CSS. I know how to I know how to do that.
Michael Thiessen:But then you're actually, like, learning this whole, like, niche language in a way, and so it's it can be difficult. And, you know, once once you've learned it, it's easier, like, with everything, once you know how to do it. But getting to that point is, a little frustrating.
Alexander Lichter:But I also get why, like, at some point, you just said, like, okay. Look. I don't wanna dig down all the way to rabbit hole to maybe just find out there is still no solution. So I I also, like I I think it's a good point to, like, even though you spent a lot of time and it's just like, look. This probably won't lead anywhere.
Alexander Lichter:Maybe it will, but I have no idea how. So let's let's, like, spend time maybe on more on all for other modules and say, okay. That's that's a better, let's say, a better use of time. And it's an important point for developing because everybody runs in into a point where, like, maybe an own application, even even business. I'm like, okay.
Alexander Lichter:Look. Yeah. We we tried. It doesn't work. Let's, cut the losses and, yeah, go ahead.
Zoey Kaiser:Yeah. I definitely agree. And I think that was also a really big learning moment for me. Because I, yeah, I was I was doing as much much research as I could, reading up on things, looking how other people were doing it. But after a while, I noticed, like, even if I managed to get something working, that does, in theory, function as it should, I personally wouldn't use it.
Zoey Kaiser:And I think that moment was kind of like the point where I was like, okay. Then I won't give this back to the community if it's something I wouldn't even wanna use myself.
Alexander Lichter:Yeah. Like, you have your own quality standards and be like, okay. If that doesn't even match mine, how can I bring it to the people?
Zoey Kaiser:Yeah. Yeah. Exactly. So a lot of amazing development out there. Even though every now and then everybody is, once again, you're, like, hit a dead end, well, turn around, try another way, and here we go. So so amazing models to see. So
Alexander Lichter:I wonder, what is what is planned for, let's say, the future of of Sidebase and of SIDESTREAM?
Dan Kremerov:So for SIDESTREAM, we are now in our 5th year of business. I think we established ourselves. We know we have a stable company with very good employees and great customers. So, this year,
Dan Kremerov:we basically started specializing. And this year, we basically started specializing in what we offer. Before that, we were may maybe having the same tech stack, but basically developing all kinds of things. We have 2 two main focus areas at SiteStream, in terms of what we do now. And the one is custom VIP systems.
Dan Kremerov:So basically, this emerged from a few customers that we had. So they they were like midsize companies and they didn't wanna take one of these standard enterprise resource planning tools like SAP because they kind of thought it doesn't make sense that, I have this well running business and now I have to adjust all my good processes just to, yeah, basically introduce like a digital system. And then they came to us and basically told us to develop, like custom made, ERP system for them that really digitized all their processes. And, yeah, we did this now a few times. Sometimes they call it ERP.
Dan Kremerov:Sometimes it's just one department that wants to digitize their processes. For instance, we also did, like, a big, project now for the city of Cologne, where, like, one of their, basically, departments wanted to digitize something, and they didn't call it ERP. But in the end, it was basically an internal tool that takes some of their well functioning processes and makes them digital. So we found this niche now for us and really wanna double down, find more similar projects because, we realized, okay, these projects really add value to their customers in the long run. And they also really play into our strengths of, yeah, build basically building software that, has certain longevity, that you don't throw away after 2 years, but that you, maintain and develop further.
Dan Kremerov:So we yeah. That's our plan to double down on this niche in the next year. And the other niche, we also we didn't talk about this yet, but that's also a big part of SiteStream actually. So we're also in the crypto web 3, sphere. So 3 years ago, actually, we started working with MakerDAO, which is one of the leading, protocols in crypto.
Dan Kremerov:It's like a decentralized bank of crypto, so to say. For us, it was just a normal customer in the beginning, and we also just build a few, yeah, applications for them. In crypto, they call everything that is not smart contracts, just front ends, but, it was a proper application. And yeah. So we have been doing this for 3 years now.
Dan Kremerov:Also, I actually expanded our tech stack, yeah, with smart contract development because you just really need it to, yeah, be encrypted for the long term. And for us, I wanna double down here because it's a lot a lot of fun. We have some people, who really believe in the space, including myself. And here, we
Dan Kremerov:have this one very nice customer. They actually just today, 2 hours before this recording, they rebranded from Maker to Sky, which is, I think, the biggest rebranding and decentralized finance of all time. So we feel quite privileged to be be at the center of this, this techno technological shift. And, yeah, also happy to build Vue and Max front ends, over at the crypto land, despite these guys being very React focused. So
Michael Thiessen:Like, a big part of the world. Yeah. I'm I'm I'm so happy to hear, like, that there are, like, so many different areas. I mean, first of all, it's cool that a part of German bureaucracy gets digitalized with Unangstrom. That's, that's always like a big yay for everybody living in city cologne at least.
Alexander Lichter:Maybe then things will go faster or just better. So it's, yeah. It's it's nice to see where where the technology can be used, and and the amazing benefits for for all the people out there.
Michael Thiessen:Yeah. It seems like such very different different worlds, like a city government and web 3 stuff. Yeah. It's
Alexander Lichter:also true.
Michael Thiessen:That's that's amazing. Yeah.
Dan Kremerov:Yeah. Definitely. But both of it has its bureaucracies. So it's it's actually more similar than you might think.
Alexander Lichter:Interesting. Yeah. Wouldn't think that straight away, but, yeah. It it kinda makes sense the the longer you think about it. You're right.
Alexander Lichter:Okay. So that's that's for SiteStream. And how about Sidebase? The open source side of it, so to say.
Dan Kremerov:So I think for Sidebase, it's just about consistency. So because I think a lot of people, including ourselves, were a bit afraid, like, if we really can maintain it in the long term just next to our, like, core business. But now I think we have a bit of Lindy effect. We are doing it for, like, 2 years now. So it's almost 2 years after since, New Street.
Dan Kremerov:Right? So, I think we have, like, proven to ourselves that, yeah, we're here for the long term, and we'll just keep developing, yeah, on the call call, call modules, come up with new ideas, test them, maybe throw them away like Zoe just got for the PDFs. So but, yeah, I think we'll just go with the flow and see see also what we need ourselves on projects, what the community wants. But we so to my knowledge, we don't have, like, very concrete plans besides what we were we talked in there for the ROS module.
Zoey Kaiser:Yeah. Agreed. I think we're gonna primarily really stick with this core of maintaining the authentication module. Like Dan said, like, we're gonna, every once in a while, throw something against the wall, see if it sticks. I currently I'm also working on a couple of new modules under the hood, just seeing what would work and what wouldn't work.
Zoey Kaiser:Nothing at the point where I would say, like, oh, I'm definitely gonna release it. Some things I might really at least privately, some under site based. So I think the future is very open in that regards, which I think is one of the main draw ins for me at least on open source that you can kind of just trial and error, see what happens, see if it works well. I know for myself, there are a couple of directions that I do think would be super interesting to look further into, especially for the next community. One of them may be also potentially being combining the web 3 aspects of our company and site based themselves.
Zoey Kaiser:So seeing if we can release some kind of utilities module for interacting or building web 3 projects with Vue and Nuxt, which I think is an area that could be super interesting to work more inside of. So I think, yeah, there's definitely a lot of possibilities. So I'm very excited to see what the future holds.
Alexander Lichter:Amazing. Yeah. I I think this, the future sounds bright and vivid. Like, some some on one hand, very, very decisive and concrete plans. On the other hand, for open source side, like, ok.
Alexander Lichter:You have the core that works well. So what works well? Double down on that. Continue, and then see whatever works out. And I think as mentioned before, like shipping things and also archiving things, and deep deprecating things, that's part of the process.
Alexander Lichter:Like, we all had countless projects, I would say, that are not alive anymore for good reason, but you all learned for them and, and it all influences what code we write now, how we analyze problems and also what, what like business decisions we make in the end. So, that, that sounds pretty good. Then
Alexander Lichter:I would say last but not least, because we're we're on for for all of an hour by now, we we have to ask you the one one more question. Dan and Zoe, where can people follow you, like, you as people, but also you as, like, okay, site stream, site based. Of course, all the links, everything that will come now is also mentioned in the show notes, but still, we wanna hear everything so we can type it down afterwards.
Alexander Lichter:There we go.
Zoey Kaiser:Yeah. So you can find me on GitHub, with my username, zoey-kaiser. And, now a bit confusing on Twitter, it's zoey_kaiser. And then, obviously, you can find, SideBase just under the name Sidebase or at sidebase.io. We also have an amazing Discord community for Sidebase, which you will also find the link below, where you're obviously invited to join us there.
Zoey Kaiser:I also do regular meetups there, or I'm always ready to hop into a call with people if they ever request it. So I'd love to see you there, chat, maybe get to know you a bit. Yeah.
Dan Kremerov:Yeah. The best place to find me is on x @dankremerov. And sidestream.tech for the website of SIDESTREAM.
Alexander Lichter:Perfect. Then thank you too so much for joining, the the podcast, the very first For People episode. Yeah. World premiere once again. And I hope that, everybody out there learned a lot about SiteStream, as a business, about Sidebase as an open source endeavor, all the amazing modules, the Vue job market, and all the things we talked about in the episode.
Alexander Lichter:As usual, check out all the earlier episodes. We got lots of amazing ones, so don't miss them out. Also, the next ones depending when you're listening. If there's no next one and you listen to all of them, then definitely write it in the comment below because we're curious if that's the case. Then thank you so much, for for listening.
Alexander Lichter:Check the show notes or the YouTube description no matter where you are. And thanks everybody, and hope to hear you in the next episode, folks.
Dan Kremerov:Thanks for having us. See you.
Zoey Kaiser:Bye. Thank you so much.