Ep. #97, Self-Hosted Solutions with Brandon Leckemby of Appwrite

Brian Douglas: Welcome to another installment of JAMstack Radio.

Today we've got a special guest, and I will ask you to introduce yourself. Tell us why you're here.

Brandon Leckemby: Glad to. My name is Brandon Leckemby. I am a Full Stack Engineer at Appwrite.

Appwrite is trying to make app development easier because the simple fact is that app development is hard, and it continually gets harder.

Every stage from engineering and design to data structures and deployment, and proxying and balancing, there is so much that goes into running a modern application that it is worth our time to try to make it easier.

Appwrite is trying to do that, to accelerate app development by providing a backend as a service, with our focus on developer experience.

We started this project to be multi tenant, to be hosted in the cloud, to be run anywhere, and that focus and that control has allowed us to deliver excellent developer experiences.

It allows us to focus really on what our community is telling us that they need from the product and we have tons of happy users that hop into our community every day.

Brian: That's awesome. Speaking about community, you had mentioned before I hit record that you were the first hired engineer working on the open source project.

Can you talk about that experience? But also even just the open source angle of this?

Brandon: Yeah. I got this job entirely because of open source, because I did not come into the Appwrite community looking to find a job.

I found Appwrite because I couldn't be bothered to write another authorization service.

I was working on apps and I couldn't be bothered.

I joined the community, I started digging through the documentation and digging through the source code, as I was excited to do and realized how easy some of this was to hop in and implement and not have to worry about it.

Importantly, I started engaging with the community in Discord and on GitHub, responding to feature requests and issues, commenting in anything that I could find where Appwrite was looking for feedback for the community to participate in.

The process of adding new features via RFCs. My contribution was just thinking, was just stepping into the project and doing more than the code.

The code comes and those contributions are always a gift.

But I was able to enter the community to help. I had a story where I was still quite new to the Flutter and Dart space but thankfully it's a quite agreeable language, and there was an issue that a community member was facing.

I was able to hop into DMs with this person, I helped them with their issue and read through source code that I had never read before, because the product was so simple to understand.

Enough of that happens, I got in my first pull requests which wasn't anything complicated.

I think I was obfuscating some secure keys in the console, so nothing too difficult but that's what really kick started all the conversation.

It just so happened that this open source project that I was contributing too was about to grow into something much bigger, and I had found it at a great time.

But all because I was contributing to an open source community, not looking for work.

Brian: Yeah. That's wild too, as well.

And people who listen, they know I have a project that encourages people to do open source and get involved in community, and for the most part it's folks getting involved in my community... I have a couple of side projects I'll mention later.

But I love that you were able to find employment, your next job, through a contribution and it might've been...

Maybe it was an underwhelming contribution on your behalf, that it was like, "I'm just trying to obfuscate these keys."

But perhaps that was something that was impactful enough for somebody else down the road. It's like by default this happens now.

I mean there's a good signal that it was enough value that now you have a role at the company as well, which I wanted to get into this company angle too as well.

Because I knew of Appwrite, I keep seeing it, random places, be it somebody just tweeting about it.

I think it solves a niche that I need, actually, because I tend to do a lot of JAMstack apps, I do a lot of focus on the front end and prototype ideas.

But I don't usually think about-- Okay, I spent a couple days on a log in a couple weeks ago and I ended up using a service because I was like, "I've done what you've done, I've built authentication as well."

At least once, I didn't do it much more after that because I always opt in for either a service or a library or a plugin or a tool that can manage the passing of tokens, maybe using cookies and whatnot.

It's like the same patterns over and over again, but I don't want to build that again.

It's a great interview question, but it's not a great thing to maintain when something happens.

Brandon: Yeah. I think the same thing for images as well.

Images are something that can get very complicated to deal with, that it would be very convenient if you had an API to deal with that.

There are services for that, cloud in areas is the first one that comes to mind, that dedicated themselves specifically to images.

They all exist but they're all over the places.

You have different focuses, and one thing developers like is to have one dependency, have one piece of technology that they add into their stack. They don't want to add, five, ten for all of their needs. While that works, that allows developers to run fast, it doesn't necessarily allow them to lean into their preexisting knowledge.

When you're stepping into a new API, you have to learn the idiosyncrasies, you have to learn the patterns, you have to learn the structure, how they have structured their code so that you can consume it on your side.

You're not actually spending time applying the knowledge that you know, you're learning, you're reading documentation and you are putting pieces together.

That's not really conducive to the creative process or the development process if you're stopping to figure out how you're not animating, you're not developing.

So the core problem is if you can isolate those coordinates, those core APIs down to the most fundamental and, most importantly, most repeated.

If you can isolate those down to a nice, little list, that's what I believe developers are looking for and that's what Appwrite is definitely trying to deliver.

All the little pieces that you need, in one place.

Brian: So does Appwrite have a specific answer to authentication that you're using?

Are we using opting into other third party tools or libraries, and then it's creating a Borg?

Brandon: No. This is all run on our own thing with the data structures in the Appwrite database, everything stays put, that you're looking for.

Brian: Got it. So then Appwrite, also as a backend as a service, we're also opting in on Appwrite's solution for backend databases. I'm curious what technology is underlying there?

Brandon: It's funny that you bring that up because that's where I've been spending most of my engineering time in the last couple months.

Appwrite is built on top of ReadDB at the moment, really just any relational database.

The database API that we offer though is a little bit different.

We offer a document based API because they're intuitive to use.

Love or hate Mongo, however you feel about it, it's really easy to use to just put data in when you need to save it.

That model is becoming more and more popular and so Appwrite presents a document based API for the database service.

But it doesn't have to be a document database under the hood.

At the moment we run on ReadDB and MySQL but we've just finished a new version to add support for multiple databases.

We're still figuring that out on the product side but on the database layer we can support both relational and non relational databases, with a goal that with this plug and play architecture you get to pick just the pieces that you need, just the pieces that you're comfortable with.

And from a systems perspective, just the pieces that you're familiar troubleshooting is sometimes worth its weight in gold.

You might have an engineering team that knows how to troubleshoot Postgres, but drop them into a MongoDB world and they have no idea what they're doing.

It's about finding the right fit for your specific problem.

Brian: Yeah. I am the inverse, I definitely can do the whole document model and debug myself that way.

I have tons of experience in Postgres, but it's just the experience is like five years old.

Which, fun part about Postgres, it's still relevant.

So I just started a new Postgres database for my new side project and getting in there and debugging migrations and trying to do patch updates within my migrations.

It was all like getting on a bicycle, but it did take some for me to remember how to ride myself into a Postgres situation.

But I like that there's a bit of a plug and play architecture and decisions that can be made with that.

So backend as a service, folks like Glitch.js which now is about to launch a whole nother project on top of that, gasping to have a certain deployed solution.

These are all front end architectures and focuses. The backend as a service model I know existed and I know there's tons of people who do it.

It's not a place I spend a lot of time in because I do reach for the Mongos or the Auth0 to solve the problem I need at that time.

But I never even thought of can someone give me a full solution out of the box.

I'm curious, what are we looking at as far as adoption?

Are you seeing folks engaging and then leveraging this for their new projects?

Brandon: Massively. We have seen tons of community members and developers dive into Appwrite and realize the joy of building apps when you don't have to worry about stuff, really.

Worrying about sharing resources across teams, worrying about how to store files in a file system and handling permissions.

What if you want those files to be downloaded? At every point, even if we pick any individual service, it gets really complicated.

If we talk just about databases, since I have been working with them recently, the whole concept of database indexing, right?

The whole concept of databases in general is we're fighting physics.

There is a single point that we can't move faster than, and that's how fast discs operate.

How can we pull data in and out of discs, that's the fundamental problem that we're trying to solve here.

Everything that we do, all the tools that databases offer, views, indexes, stored procedure, all that sort of thing, they're all really making trade offs.

Trade offs that you don't see, but trade offs nonetheless.

Indexes fundamentally trade write performance for read performance, but even indexes get very complicated.

How indexes are shared, how some databases allow you to hint at which index you'd like the database engine to actually execute on.

Every piece gets complicated the further you go down in, so I think there's just a huge need in taking all of those pieces and simplifying them, simplifying them to the point where you can understand how to work with it in every language, in every architecture, with anything that you want.

If we can distill the hard problems that developers have building real apps, simplify them as far as we can and build a suite of services around that, that's really the sweet spot because that's what people actually use.

Brian: Yeah. And talking about simplifying, I'm curious of what is... If I were to purchase you today for a project, what is my interaction with Appwrite?

Am I signing up on appwrite.com or .io? Actually I don't even remember what the website is, .io. Am I getting a URL I can point to a front end?

What is step zero for folks in getting started with this?

Brandon: Well, step zero since its inception has been self hosting.

That's one of the most important parts that we have offered through the entirety of Appwrite's history.

Every part of Appwrite can be self hosted and deployed.

It's distributed as a set of Docker containers, that's the underlying tech assumption that we make to allow it to be portable everywhere.

So we deploy it as a set of Docker containers and you stand that up wherever you need it.

You can deploy it on your own VPS, manage your own resources, but we do very importantly have our own cloud solution on the way.

Very similar to how you'd interact with a firebase, you would sign up at appwrite.io, you would create your project there and everything would just be ready for you.

We have the full transparency in offering the source code, if you want it, if you need it, if data location and all of that stuff is critical to your application you can.

We're never going to stop you. But if you would like to get started faster, you don't want to deploy it on your own machine or you just want to pay somebody to handle it for you, that's where we step in.

Brian: I'm a big fan of paying other people to handle all that complicated stuff for me, because I don't fancy myself as a backend programmer anymore.

I'm a full stack dev, but I'm so far removed from all that orchestration, even Docker stuff, that now I know enough to be dangerous or go sit as an IC on a team, but I'm probably not going to be the person to call to set up something from zero.

I have people I'm going to call and people I can beg for help to be like, "Hey, I don't know how to ship this stuff. Get me unstuck and I'll get you a pizza or a beer or something."

Brandon: That's why it's critical to make sure that that deployment process is easy, right?

The Appwrite deployment script as it stands is a one liner Docker run that you copy from the main website.

You run it on your VPS and pick your ports, and you're done really.

We've tried to make that part as smooth as possible because you're right, not many people are going to go through the process of setting up themselves.

I'm a weird one, I'm the guy who has multiple Raspberry Pis in a server cluster at home and I run Appwrite myself, and I run all of my own local services.

That's me, but that's not everybody so it's important to have both.

Brian: Yeah. I'm a big fan of that, especially if I can copy and paste a command, and if I decide to self host it somewhere else I can just drop that in the other place and hope for the best.

Because my day job doesn't really require me to do a lot of day to day maintenance, I tend to spin up a lot of side projects.

Some quick ideas, they're proof of concepts, and then I go and try to sell it to another team, to say, "Hey, take this off my hands if you want to run with it. If not, let's just let it hit the ground."

My role in DevRel, that's where I advocate for. So I appreciate folks like Appwrite, open source projects like Appwrite too, which is another thing that I wanted to touch on.

Is there a community around Appwrite? And in the open source ecosystem, do you have a Discord? How do other folks get involved?

Brandon: Absolutely. We have a great, growing Discord community as well as in other places.

We publish on Dev.to quite frequently for all of our content, and our GitHub community is growing as well. I think we just crossed 16,000 GitHub stars.

Brian: Yeah. I mean that's a lot of folks who are engaged and looking to see what's next with Appwrite.

You mentioned in passing the Flutter and Dart aspect, was this Flutter and Dart specific at first or is this language agnostic?

Brandon: Appwrite is inherently language agnostic, but it just so happens to pair really well with Flutter as we found.

A lot of our community growth has been in the Flutter community, and just how fast you can build things.

That's the whole mantra, in Flutter the speed in which you can put things together, quality services, quality applications together.

Brian: I have built one Flutter app, thus far. It was actually one of those hybrid mobile apps as well.

I'm a fan, I wish I had more time to dig into it. I definitely will check it out now that I know Appwrite works well with it.

With that, I did want to transition us to picks. I appreciate you shared about Appwrite.

I hope folks, everybody go start a repo, go sign up when they have login.

If you're listening to this and they have the cloud version, sign up today, but also try out the self hosting.

I imagine there's probably some guides or docs for folks to get started and make some HelloWorlds as well.

Brandon: Absolutely. We have a landing page, appwrite.io/cloud.

If you are interested in getting the latest news on our cloud offering, that's the place to be to sign up for any updates. Or just find us on Discord.

Brian: Cool. All right, so I had mentioned a couple of times picks, so these are Jam Picks, things that we are jamming on.

This could be music, food, coding related, there's no limit. Usually one or two is good.

If you don't mind, I'm going to mention because I alluded to this a few times, which is my pick, which is hotopensauce.pizza.

So I actually haven't talked about this. Well, I have mentioned this in passing in previous episodes, but I finally shipped something where I prototype as an API.

I just wanted to find a way to find open source projects that are up and coming that I could try to contribute to in the future, or just build something with.

So I created this API where, based on the folks who sign up to open source, we check to see what stuff people are submitting there.

Then based on that knowledge base, we then recommend, "These open source users are having fun with these projects. Here's a project for you to check out." So that's how the API works.

It's built on top of this project that we've actually had on the podcast previously called Supabase.

I basically just added all this data to Supabase, it's a Postgres database which is now my new... I'm back in the Postgres again, I'm back, everybody. It was a lot of fun.

I prototyped a quick UI in next.js, which is all the buzziest words you could probably do, this is the app.

And then Astro, I also leverage Astro a bit for this as well. Yeah, shipped it from the week before Christmas, it was like the Friday before Christmas.

The day before I was doing a stream, built out the UI and then tweeted, "If anybody wanted to work on this, I could use help getting the UI components up and running."

By the time I landed I had a PR, or shortly before I even took off, I had a PR of the UI they merged.

Then I had a bunch of other folks who came and contributed some small touchups, and then we really just focused on usability and from the Friday before Christmas to the Wednesday before New Yea's Eve I had a fully functional, working UI built on top of the API that you can find new open source projects and upvote them.

That's the gimmick, is you can also upvote. We will have user submissions for repos, probably by the time this podcast comes out.

So just thinking of product time for open source projects, that's where I'm working towards.

I was talking to you earlier before I actually hit record, that I haven't built a project from zero to usable in a very long time because I have been so much focused on the day job.

I actually impressed myself on how quickly I could do it, and I imagined things like Appwrite, which it's actually pretty serendipitous to have this conversation because now I have confidence that I could just, "You know what? I'm going to try Flutter for this project here, it's ensuring I can only ship these features. Can I do it in like a weekend?"

And if I did a hack, I'm not a big fan of hackathons because there's so much anxiety and pressure, but honestly I'd probably do it in Appwrite.

I'd use Appwrite or something else to get a leg up to actually get it to work.

Brandon: That's awesome. I want to highlight one Appwrite thing on there, is that you're talking about doing coding in different languages.

Appwrite supports a variety of different SDKs that we build from the same API spec, that we build from the same code base so we guarantee that our APIs are consistent and familiar.

Even when you cross programming languages, you'll have a similar Appwrite dev experience as if you need a serverless function in Python, for instance, or you're building your front end in Flutter or you switch to Web.

If so, Appwrite is very much there for you, especially if you're doing projects in other places.

Brian: Honestly, I think I might check it out. If y'all do a hackathon, definitely tweet that out.

Brandon: Will do.

Brian: Let us all know when it happens.

Brandon: I guess I should talk about my pick, Huh?

Brian: Yeah, go for it.

Brandon: So before I came to find technology and love technology, I worked in a bunch of different careers.

One of those careers is I was a touring jazz musician. I got fed up with a previous career and decided to sink all of my money in playing music.

I played and I had an amazing life changing time, touring and playing some jazz.

But then I obviously ran out of money. One of the things that I have been doing recently is I've been retouching with some of the old jazz that I used to play when I was playing in restaurants and bars, and I'm trying to find the good jazz that isn't the, "I'm confused" jazz.

That's what I'm the hunt for right now, that's what I've been jamming to. Jazz that makes you feel things that isn't confusion, as weird as that sounds.

Brian: I'm a musician myself, I don't play jazz mainly because of the amount of effort and technique that goes into it.

But yeah, I respect and love listening to jazz. Do you have any players or folks you'd recommend?

Brandon: I'm a trumpet player, so I very much like Miles Davis and Chet Baker and the like.

But I think that it's really enjoyable to go back to jazz as roots, or at least jazz as what we know it, going back to blues, going back to Dixieland.

Different styles of where this came from. Jazz music has an incredibly rich history that's worth exploring.

Yeah, I'd encourage anybody to look at some old jazz, see how we got here, and hopefully you like what you find.

Brian: Cool. Honestly, I might actually be listening to some jazz later today because you've inspired me to switch up the playlist while working.

Brandon: Wonderful. I'm glad.

Brian: Cool. Well, folks, if you've been inspired either from talking about music or just getting started with Appwrite, definitely check it out.

I appreciate Brandon coming on and sharing with us.

Brandon: Thank you so very much for having me.

Brian: Keep spreading the jam.