Cookbook: Hybrid-bot - a hybrid serverless/serverful discord bot

Contributing
#1

At the meetup on Thursday, I was inspired by the excellent presentation about a tool for streamers by @KrisCoulson, and joined the call during the open time and talked about a related idea I have. The idea is to make it convenient to run a server (or a long-running process), like is needed for a discord bot, using the serverless platform to handle most of the app’s functionality including the user interface, the api, database migrations, configuration, and more.

I’ve started work on it in a repository (on GitHub and GitLab). I have made it run the discord bot inside the redwood API, using redwood only to build it, so the serverful component doesn’t need to have access to the database. Depending on the requirements of the app, that may be wanted, but for most, the data can be accessed through the API.

Currently it’s just a bot that says “Cheetos” whenever it is mentioned. It’s running in my startup’s Discord. There’s a link to it in the hybrid-bot README.

I am making functionality that uses the database now, to show integration between the serverless and the serverful components. I have added a model for drawing entrants, with a scaffold, and am adding an API key to the configuration, and making it so the serverful component only uses the API_KEY which is shared between the serverless and serverful component, to start up, and having the serverless component send the Discord bot token to the serverful process. After that I will work on making the deployment and updating of the serverful component smooth. It could run on a $5 VPS or a serverful PaaS like fly.io.

I’d like to make an official cookbook entry once I get things working smoothly.

I hope this will be useful and be the start of a lot of collaboration in the Redwood.js community. I may stream some of the work on twitch. I’m happy to get feedback or help building it! Thanks.

5 Likes
#2

Yessssssss :rocket:

I’m excited to see this in action and stoked you’re already running with the idea! Here’s some background about what I said at the Meetup.

We started this community here on Discourse (aka the Redwood Forums) because we specifically wanted to create a searchable knowledge-base that would grow in value over time. Starting forums from scratch is notoriously hard, but there was already a handful of us and we were committed to making it work. And it did!

Then some members of the community needed more real-time conversation to coordinate on specific tasks and projects. The offered to start a Discord server that would “just be for a small group” — and now it’s the Redwood Discord server :laughing: Chat is awesome and also serves as a easier entry point for new people which has it’s pros/cons. So around that time I experimented with a local Discord Bot, using Discord.js, and got it working. The goal would be to use a bot to “connect” the Forums and Chat. I stalled out when it came to deploying, 'cause I just didn’t want to spend time setting up all the dev-ops, lifecycle management stuffz (“Ok, I’ll put it in a container, then setup up deploy trigger, and hot swapping, and then monitoring, and then… gah!”). I just wanted to live the Jamstack + Serverless Dream!

My laziness aside, the need to further integrate and connect the Forums and Chat is still a priority. Some ideas:

  • copy text or a message to quickly start a new topic on the Forums (effectively move a conversation to the Forums)
  • search the Forums and view a list of the top 5 results in Discord
  • have a way to “index” code snippets from Discord for Forums search
  • have the bot invite Chat users to Meetups and events and/or give updates for things like new Releases (effectively announcements in the Forums)
  • 'nudge users who create long posts, or strings of messages, that they should consider moving their long-form content to the Forums for deeper discussion and long-term building the knowledgebase
  • …

All for the hopper and fwiw. But hopefully more to come! :crossed_fingers:

1 Like
#3

Fly.io looks :star_struck:

For simple things, I’ve stuck to DigitalOcean. Cheap but requires more manual setup.

Hearing lots of goodness about https://render.com/

2 Likes
#4

Those are great ideas, for connecting the forums and chats, and making sure the knowledge base is being maintained. I would like to help build that.

I am making some progress on the serverless/serverful example. I am having the serverless GraphQL API store the Discord API token, and the serverful discord bot ask for it using an API key. This is in a PR. For realtime stuff, it would be useful for the serverful component to run a graphql server, and for the Discord bot to subscribe to it, or for the Discord bot to access data directly. I think a good default is to give the Discord bot access to the API and the credentials it needs (in a simple case just the Discord bot token).

2 Likes
#5

I’ve heard of render.com. Thanks for reminding me of that. I think it’s a lot like fly.io.

Alex Ellis of OpenFaaS is working on automating DigitalOcean deploys, through cloud-init. I just saw this released: https://github.com/inlets/cloud-provision It is very simple. Unlike chef and puppet which can manage instances through lots of upgrades, these seem to be designed for instances that are rebuilt from scratch when things outside of the application change.

1 Like
#6

Hey @bat, wondering if this is still something you’re blocked on or if you said screw it and moved on?

I’ve been doing a lot of work recently around using a GraphQL gateway to manage API keys for serverless apps without needing to spin up a server on something like Digital Ocean or Render, so I’ve got a lot of ideas.

#7

@ajcwebdev we should chat sometime soon! This hybrid bot idea would be pretty awesome. And my team internally has been talking about building out both a discord bot and a twitch bot

1 Like
#8

Would love to, the question though is do I send you a follow up message about it on the Redwood forum, Twitter, Discord, email, or carrier pigeon?

#9

Shoot for discord! I am always connected there.

1 Like
#10

Inserting relevant RFC 2549 for further discussion :laughing:

1 Like