Paul: Hi there and welcome to PodRocket. I'm your host, Paul. Today, we have Steffen Trog with us. Welcome Steffen. Steffen Trog: Hi, thanks for having me. Paul: So we're going to be talking about Telegram and bots and opensource, more opensource flavors today because we actually had a viewer write in about Steffen and his project that he's the founder of, which is the grammY bot. Steffen, this is a Telegram bot, right? Steffen Trog: I mean, it's a framework for creating bots. So it's basically the library that underpins a lot of other bots that people can create. Paul: So just to start Steffen, could you explain to people who aren't immediately familiar what is Telegram, because that's the space we're talking about today? Steffen Trog: Yes. So Telegram, first of all, Telegram is a messenger, like an instant messaging service, like basically all others. But it has some interesting features to it that many other messengers don't have. One of these features is that you can write bots for it. So you can basically have automated user accounts. So users that are on the platform, but that don't really correspond to a human, but that have a server running in the background that does everything. Paul: I've used Telegram a few times, but I feel like it's usually been for weirder internet channels or crypto related things. It has a sense of security about it, right? It's the secure platform for chat. Steffen Trog: Yes. That's definitely how they advertise themselves. It is debatable if that is actually the case, because it's still a cloud messenger, right? So all your messages are stored on the servers of Telegram. They do have their own encryption, which seems to be pretty good, but since it's their own, no one trust it really. But I didn't really start using Telegram because of the security. I just started using it because it's very, very fast and it's very easy to use and very expressive and it has bots and it has lots of other cool things. So while they do a lot of marketing with the security stuff, it's not really why I'm there. Paul: I mean, one thing I love Telegram is you get all the features that you would expect from like a Discord environment, but it's simple. Really, Telegram does not overwhelm me which is a feeling I can easily get on other messaging platforms. It's very well laid out, I would say. Steffen Trog: Yeah. Yeah. I agree. Yeah. It's very nice. It's very approachable. They do have advanced features that unlock as you start using the app. So for example, you can categorize your chats into folders, but you will never see that there's a way to organize chats that way unless you start having a lot of chats where this starts to make sense. So it doesn't clutter the interface unless you really need the feature. Paul: Wow. That's brilliant. It makes sense. We had somebody write in about this and they were hailing how great this framework was and what a great opensource community was built around it. We like to focus on opensource projects and creators here. So I would love to get into a little bit about your story, how you started and all these things that made your opensource community really click. But before we get there, let's talk a little about the technology, the framework that you built. What caused you to want to build the framework? Steffen Trog: Yeah. I mean, it's a bit of a stereotypical story because at the time, I was studying and I was just sitting alone in my room and was like, "There's no good framework that does this sufficiently well." So I just sat down and coded my own thing and- Paul: This was bots? Steffen Trog: Yeah. Okay. Maybe we can start even earlier. I started writing bots before I started writing the framework, right? So my first Telegram bot that I created was because I was in a chat with a group of friends and someone always sent video files in AVI format and my phone can't play it. So I always had to download the file and convert it to MP4 and then post it back to the chat so everyone else could watch it too. That was really annoying over the time. That person was not really up for sending them in MP4 directly. So what I did was just code a little Telegram bot that I could add to the chat and that would do this automatically for me. So it would just convert these video files. So that was super useful. I mean, the bot was working, but it wasn't the nicest code. So I tried to make it a little bit prettier, just cleaner. Then I found out, well, if I want to have a cleaner bot, it basically means I have to use a better library and that library didn't exist. So I started contributing to the library that I was using at the time, it's called Telegraph. But it was written in JavaScript and I wanted to write TypeScript. So I tried to port it over to TypeScript, but that revealed some really funky internals that didn't really work that well. Ah, I don't know. I mean, it was okay, but it was never really good. I was never really happy. So in the end I felt like, "Yeah, just screw this. I can write a better bot framework than this in two weeks of time." That's what I thought and turns out I was wrong. It took three weeks. But in the end, I had a bot framework and I thought, "Well, now this is nice. Now I'm done." Once again, that was wrong because the real work only starts once you have a project that people start using. Because then all the people started reporting small bugs and had feature requests and wanted to write plugins and do all these things. Then they wanted to have a website with documentation. So it really started taking off from there really. That's like one and a half years ago I started publishing stuff and we are at 500 stars on GitHub now. Paul: Yeah. So you've been creating this framework. When did you decide to go opensource with it? Was it from the very beginning you were like, "I'm going to create this. I'm just going to make it open and we'll see what happens"? Or did you kind of work on it in your room and then finally do a big release? Steffen Trog: No, that was basically from the very start. It was because I had used other libraries in the bot I wanted to build that all were opensource. So I first started improving them, and only then when I figured I need to write my own thing, that was just the natural way of continuing, publish something that's better and have this whole community that likes that one framework transition basically, or at least try to convince them that there's better solutions out there. Paul: So what do you think was one of the big drivers of success when you were starting from the get-go because gaining steam is difficult? Steffen Trog: Yes. I don't think there was like this one single event that made the huge change. But I think there was a number of smaller factors that all needed to be right in order for this project to have the success it has. So I think I started realizing very early on that you cannot have a successful opensource project alone, right? It's not possible to have one person working in it like full-time and then it's something that actually takes off. So from the beginning basically, I started setting up the GitHub organization, for example, in a way that more people could join and could develop their own parts and that it's like this collaborative project. Right now, we are like 15 people in the organization and we have, I don't know, 30 different plugins or something. So just the fact that I'm able to delegate basically everything is, in my eyes, that's like one of the reasons why we are able to develop so much and have such a wide variety of integrations with web frameworks and databases and all these things. That's just too much for one person to wrap their head around. Just the fact that it's collaborative and people are working together and are nice to each other, that is a huge thing. Yeah, so then the other part I think is approachability, right? Because it's actually quite funny when you look at who wants to develop a bot, right, then it's often people who have experience in JavaScript. So people who maybe have done a little bit of front-end work and maybe who want to get into the backend. Then it's very hard to actually write a backend without having a front-end, right? Because it's not that much fun to send HTTP requests and then be happy that your software is technically working correctly because you want to provide some value to the world. It should matter what you do, right? So Telegram bots are quite convenient because you can write your backend. But since everything works through the chat interface to Telegram, you don't have to care about the front-end at all. That's just all done for you. So as a result, there's a lot of people who don't really have a lot of experience in doing backend stuff joining this, yeah, this community. So that's why we have to be very careful to explain things with very basic terms, right? Because 90% of the people just have this small project that they do in their free time. So it has to be very, very simple and very easy to understand. Then similar to Telegram, the more you know, the more features you are interested in maybe, and the better you get at coding, the more advanced concepts the documentation introduces to you. So this way that the library basically scales up with your knowledge, that's another thing where I feel it makes it very attractive to people. Paul: Enjoying the podcast? Consider hitting that follow button for more great episodes. Paul: Do you implement that by, I'm just shooting in the dark here, but having really sensible default, really good, easy ways to instant things? So that's one thing that Google does I know that makes their amazingly giantly complicated cloud infrastructure approachable is you can copy and paste one line of code and interact with Firestore database. Steffen Trog: Yes. That is actually something we do. So for example, one of the things that made things a lot more approachable is that usually if you develop something in the backend, you do need a database after all, right? So Telegram sends the messages for you, but it doesn't give you a data storage for everything. So that's a bit of a hassle because if you do need to store data, but you just started coding, then it's a bit difficult to set up a database and configure everything and then you probably have to rent some server somewhere and all these things. So what we actually do is we provide free data storage to everyone. So people can just get some free database storage space with two lines of code and everything's completely set up and ready. Then there are some limits to this, right? It's not the fastest data storage. We don't actually give away infinite amounts of storage space. But it's very easy to get up and running. When you need a better database, you can swap out these things and then you can start configuring things. So that's the one side that we do provide these defaults, just like you said. The other thing is that actually we have some fairly sophisticated concepts that are implemented in the core library. They're very hard to understand if you just want to write a little bot and they also not necessarily to understand. So what we actually do is we divide it up into different levels of abstraction and we start explaining it in a very high level way and give code examples so you can basically just copy paste it and it works and you know roughly what it's doing. Then in the end of the section, it says, "Yeah. By the way, if you want to dig deeper, click here," and then you get the next chapter a bit later in the advanced section and then it explains to you, "Yeah. Well, we explained this to you earlier and it's not wrong, but it's just a simplification." Then we start digging deeper and unveil what's actually below. We do this in several durations, and at least for the difficult concepts everywhere. So I think that also contributes to bridging this gap between people who just want to know a little bit and people who really want to know everything. Paul: Yeah. Really bringing in, enriching the community with the way that you're being careful about it. I mean, it sounds like the big takeaway here is really be well thought about how you are abstracting the different layers of business logic within your application. Because if you're really precise about that and you do it in an optimal way, you're going to have an optimal path that people can build mental models around your project and consume it easier. Steffen Trog: Yes. That's what we're trying at least. It does help. I mean, we're doing a library, right? The framework that powers a lot of other projects, so if you just do your one application, then you might not care too much about the right abstractions here and there, because it's just one application. It might make sense, but I feel like it's easier to be a little careless there while our library is used so much by thousands of projects that we kind of have to be very careful that everything's perfectly right before we release it. Paul: It's really tempting as developers sometime to say, "This is so annoying. Let's just make auto magicking defaulty, this and that," and then you run yourself into a hole, a really complicated maze, so. Steffen Trog: Yes. I think we've all been there. Paul: Yeah. Emily: It's Emily again, producer for PodRocket and I want to talk to you. Yeah, you, the person who's listening but won't stop talking about your new favorite front-end framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it because you're really important to us as a listener. So what do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing, weird little component libraries, how to become a productive developer when your WiFi's out? I don't know and that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on, or tell us we're doing great, whatever. If you do, we'll give you a $25 gift card. That's pretty sweet, right? So reach out to us. Links are in the description. $25 gift card. Paul: Is there any things you've learned while doing this project that you take away as pillars of truth that help you think about abstractions for your next project? Steffen Trog: Yeah, I think so. So what is interesting is no matter how convinced you are that you have the right abstraction, you have to test it. You have to actually go and write some code for it and work with it for a while and maybe have other people read it and other people try to understand it. It's time that can tell whether your abstraction is any good and not how amazed you are by it. I've had it several times that I thought like, "Oh, this is genius. Man, I have such a good idea here," and then it turns out no, that's not the case. So just doing iterative work, it shows very often in software that doing things iteratively helps a lot. I think that's even more true for abstractions. Paul: People are always saying test driven development, test driven development. Well, if you're developing an abstraction, what you're testing is the human interaction. So go test on human, go test on- Steffen Trog: That's a very good observation. That's right. Yeah. Paul: Building the opensource community, one observation I had while you were talking is that it sounds like one thing that was very conducive to this community being built and being strong. Well, it's two things. One of them we already talked about, which is making the stack approachable to mental model, conceivably consumable for the average person. But the second thing seems to be the way that you set up this framework was an integrations plugin based paradigm, where you have a highly trained core set of people, being yourself, maybe whoever else is doing it on the framework. Then anybody else can come in and with a limited set of knowledge, develop a plugin with the API you guys provide, and it instantly grows the breadth of this framework. Do you think that was the design decision that really helped propel the growth of the project? Steffen Trog: I think so, yeah, actually. Yeah. It's interesting because the framework I used before had a similar setup. So it wasn't quite working as well as this one is, as grammY is, but they had a similar setup and still they weren't able to grow a community. I think that is because we have this thing we call official plugins, so when people come to the group chat and be like, "Yeah, by the way, wouldn't it be cool to have a plugin that does so and so?" Then we actually encourage them to not just publish it, but also transfer it to our GitHub organization and publish it on our organization on NPM. Then they get their dedicated page on the website and they become the maintainer. It feels like the community is giving you something back for the ideas you have and for the contributions you make. So in a way, I mean, for example, people have asked if they can donate things to the organization or just help us financially. Well, we don't really have much costs. So I'm not sure what the point would be. But I think the main thing that people get out of contributing to grammY is that they make a difference, they are relevant. It's just nice because you do your thing and it's not like you help someone else with the project. It's actually like you get your own piece of it. You get to own your plugin and you get to work on it and you get to make the decisions. Of course, we have certain standards, things should be well documented and should be high code quality and no bugs and try to be responsive in these things, right? But in the end, it's really like whoever joins us as a maintainer is going to have their own plugin. I think that is the kind of motivation and drives a sort of engagement that other projects sometimes lack. So it's this combination of having this open platform where people can plugin in combination with supporting them in doing so and, yeah, encouraging them. Paul: It reminds me of this post. I saw a cheesy LinkedIn post the other day. It was like, "If you want employees to stay, pay is good and this is good. But the one thing that made me stay when I was young was ownership of the work I was doing." I mean, that's one thing with opensource is like I've pushed up a bug before and it's kind of like it just gets lost in the abyss. Then I'll get a random email four months later because somebody else commented on my thread and I'm like, "Oh yeah, I remember doing that." That doesn't matter at all in my life. So having this sort of community driven thing, I can totally see that having a huge profound effect on the base of people that want to contribute. What's one of the most whimsical plugins that somebody's made? Maybe not the most useful, but one of the most fun or silly? Steffen Trog: There's one which I like particularly well. It's a framework for writing bots, right? In messengers, you use a lot of emoji, but in code, it's really not that nice to type emoji all the time, because you often have to copy and paste them from websites. Then some editors don't render them in the right width. I mean, it's possible and it's allowed, JavaScript can do it. I never felt like it was nice. So there was this plugin where you can basically reference all the thousands of emoji by these short names, these alpha names. So what you can do is instead of typing a message the bot should send and then pasting an emoji into your source code, you can just call that function and pass the strings saying, "Thinking face," and then it's going to insert this emoji for you. Then there's like all sorts of other things to this plugin that makes it very convenient to use. But just the fact of making it easier to have emoji in your code, I don't know, I was pretty amused when that was published. Paul: Yeah. That definitely fits the whimsical box. Are there any integrations or other services out there that you hope to see integrated soon or things that are in your mind low hanging fruit and you're like, "Why don't people see this? It's such a good opportunity"? Steffen Trog: I mean, we already have a really, really high number of integration. I mean, really, really high. There's, I don't know, how many different databases. We have like 10 to 15 or something. Paul: Oh, wow. Wow. You're really good. Steffen Trog: Yeah. Yeah. There is one guy doing all of this. I mean, some were contributed by other ones. Actually, we have like, yeah, just like an hour ago we had the last edition of a new... We are supporting Prisma now, which is some- Paul: Wow. Oh, that's awesome. Steffen Trog: Yeah. We have an integration with NestJS and all sorts of things. So I don't really feel like there are these amazing things out there and we just can't integrate. It's more like we have so many things and I don't even know all of them. So that's, of course, very nice. Then also, because often people write code that is both a bot and a regular web server. So you sometimes want to integrate with things like Express and COA and these things and those exist too. I don't remember how many integrations with the web frameworks we have, but all the main ones are there. All the different hosting platforms like Amazon, like the AWS Lambda. I don't know, it's all there. So yeah, I'm excited to see what other frameworks emerge that we can integrate with. Paul: Yeah. [inaudible 00:25:29] in the same position that I'm in. I'm like I want to give ideas to help people brainstorm, but you're like, "Come to me. I don't know." Steffen Trog: Been there, done that. Yeah. The fun thing was that we actually started working with Deno. It poses itself as this successor of Node.js and it has some interesting concepts. So we always publish all libraries and plugins. I mean, the core library and all plugins for both run times. So that opens up a new dimension of frameworks and databases and so on to integrate with. So yeah, when it comes to compatibility, I think we're fairly on a good track here. Paul: So what's next on your roadmap? Steffen Trog: I mean, so far what we've done is we take the API that Telegram offers us and make it nice, basically, right? In essence, it's about how does it get more convenient to write a bot. But still everything was tied to this model of the API that you get a message from user and then you reply to that message and then you maybe get a next message and reply to that one. Or I don't know, people press buttons or do searches and all the other features that Telegram has. But in the end, it's really just this, there comes a request and there goes a response. If you think about chat, like how humans text with each other, that's not really how it works, because any question and any piece of information you'd get needs to be seen in the context of the chat history, right? If I asked what time, it doesn't really make much sense just that message. You always have to remember what was the history before, like which messages did we exchange before, right? So there's this fundamental mismatch between how do servers work today and how do humans chat, right? So if you look at the code that you write to make a bot, you can clearly see this because you write code in this event based way, but really, you can't read through the code and understand, oh right, yeah, whoever uses this bot will have the conversation that looks like this. Because it's just, I don't know, it doesn't add up. So we've done months and months of brainstorming. I've had a couple of ideas that I thought were genius and turns out, nope, they weren't. But in the end we settled with something which we call grammY conversations and it's this new kind of abstraction that I hope to get published soon-ish. We'll see how well it goes. I hope we're talking just a few weeks. But it's this way of basically being able to write your code exactly the way the chat would work. So basically, send a message and then wait for a response and then do this and then do that. Then we have some very, very fancy things going on under the hood that basically translate this one concept into the other, so that things work out in the end. But it involves things like executing code partially, and then just stopping execution of user provided code at random points in the middle and storing the state of execution into some database. Then when the next message comes, we have to rewind the code up to that place and continue executing bits of it. It's pretty fancy, but it works very well. We have an unstable version of it published and even though there aren't really any docs for it yet, and there are a lot of bugs that just need to be fixed and missing features and so on, and still people are really excited about it. It's one of the most demanded plugins. So it seems to be going in a really good direction right now. So I'm excited to get this done and see if it actually turns out as well as I hope it will. Paul: So is that one of the things that you would store in the grammY database for processing? Steffen Trog: That is one thing that you could store there, yes. It does integrate with each other. So all plugins we have basically, we make sure that everything integrates extremely well with each other, so. Paul: So yeah, I guess the conversations that's really you're building a state machine that's stored in a database that's like- Steffen Trog: Right, exactly. Just that. I mean, and people have tried other abstractions and the state machine is one of the abstractions that people have tried, but it turns out that writing a state machine in code is often not that nice because, I mean, you can do it in their libraries to make it okay. You still don't get as close to a chat as you do with grammY conversations now. So in a way you can see it as a very weird abstraction over a state machine. Paul: Yeah. I'd never heard of something like this existing for Discord, not that I've looked but- Steffen Trog: I have tried to find it actually. I searched through all frameworks that I know for Telegram and all for Discord. Because apparently Google and Microsoft and so on, they also have their own chat things. I don't quite know what they do, but just the parts of it that were opensource, I read through the code and they all just had the similar abstractions that everyone else does, but I couldn't find what we came up with now anywhere. So it seems to be novel. Paul: It must feel really good to, I mean, that might be new novel chat room technology that you're coming out with. Steffen Trog: Yeah. I mean, it does make it much easier to design these bots and it does make it much easier for anyone to get started. So I hope, I mean, usually it's that way, if you have a higher abstraction and you can start to reason about your code differently, that it will enable you to build different products and build better products. So I'm fairly excited about it. So I hope people agree with me when it's ready. Paul: So if listeners want to go look at the project, they can go to github.com grammY repo. If they want to find you Steffen, where can people find you? Steffen Trog: I'm also mostly on GitHub. I'm on Telegram, of course. I'm always in the group chat, which is linked in the repo and on the website. I think if you find any trace of the project, it will be very easy to find me. Paul: I guess if people want to look into this and for examples, I can go to the grammY website and just go to the documentation, right? Steffen Trog: Yes. So if you already have Node.js installed, it shouldn't take more than five minutes to get your first bot running. It's really, really simple. Yeah. We have detailed guides and tutorials for everything. So it's really not a steep learning curve. Paul: I guess if you want to get involved with opensource, this might be a great repo and project to take a look at, not only because the great things we talked about on this episode about how Steffen's managing this opensource community and the way this is built, the paradigm and abstractions that's built on, but also let's quickly remember that this episode was brought by somebody who's contributing to the repo. They had just amazing things to say about the community that's being built over here and the level of interactivity that everybody's having. So definitely go check it out if you want to see what opensource is like, me having gotten into it as well. Well, thank you for your time, Steffen. We appreciate it. Appreciate the things you have to share with the world about running the successful community you guys are building over at grammY. Steffen Trog: Thank you so much. Emily: Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. Because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great dev like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcast.