Deploying Railway Applications with StepZen

Episode Description

Greg Schier joins the StepZen stream to demo Railway's database hosting and show how to connect a Postgres database to a GraphQL API with no application code.

Episode Summary

In this inaugural partner stream, Anthony Campolo welcomes Greg Schier, creator of the Insomnia API client and now engineer at Railway, to walk through building a GraphQL API backed by a Railway-hosted Postgres database. Greg shares his journey from building Insomnia through its acquisition by Kong to joining Railway after discovering shared goals with its founder. The conversation covers Railway's core value proposition — making database and application deployment as simple as front-end hosting — and demonstrates two workflows for provisioning a Postgres database: the GUI dashboard and the CLI. After seeding the database with test data, they use PostGraphile to automatically generate a full GraphQL API from the database schema without writing application code, then pipe that API through ngrok into a StepZen project to create a unified GraphQL endpoint. Along the way, Greg discusses Railway's environment management for development and production, upcoming usage-based pricing designed to support independent developers, plugin architecture for databases, and plans for multi-region support and microservices tooling. The demo highlights how combining modern infrastructure tools — Railway for hosting, PostGraphile for introspection, ngrok for tunneling, and StepZen for schema unification — enables developers to build full-stack applications with minimal custom code.

Chapters

00:00:00 - Introductions and Greg's Background

Anthony Campolo opens the stream by welcoming Greg Schier as the first external guest on the StepZen stream. Greg shares his professional history, starting with his creation of Insomnia, the popular desktop API client that was eventually acquired by Kong. He explains how he transitioned from there to Railway after discovering that its founder Jake was building the exact deployment platform Greg had envisioned independently.

Anthony reflects on his appreciation for Insomnia's clean interface compared to more feature-heavy alternatives, and the two discuss what it means to work in the space between front-end and back-end development. Greg describes his current work at Railway on Docker image scheduling and rollback features, and they touch on the concept of "the back of the front end" — the tooling layer that empowers front-end developers to ship full applications without deep infrastructure expertise.

00:04:32 - Greg's Infrastructure Experience and Full-Stack Identity

Greg talks about his earlier experience at a startup called Send With Us, where the team relied heavily on Heroku and had to scale application and database layers to handle sudden traffic spikes from large customers. This background gave him an appreciation for simple deployment systems and the challenges of scaling beyond what a platform handles automatically.

He describes himself as a true full-stack developer who enjoys both front-end work (which Insomnia was entirely) and complex back-end problem solving, but draws the line at pure DevOps tasks like setting up Kubernetes clusters. Anthony relates to this, sharing his own recent attempt to run Redwood on Kubernetes and how his roles in the open-source ecosystem push him across a broad spectrum of infrastructure topics, from Docker files to porting serverless functions across cloud providers.

00:08:34 - Railway Dashboard Walkthrough and GUI Demo

Anthony shifts to a live demo, navigating the Railway homepage and dashboard. Greg explains that Railway originally started as an easy way to spin up a database, and they walk through creating a new Postgres instance via the GUI. The dashboard's features are covered, including deployment history, logs, rollbacks, settings, and environment management.

Greg highlights his favorite Railway feature: the ability to create separate development and production environments so developers can use a cloud-hosted database during local development without running one on their own machine. This means switching computers preserves the same database state, and transitioning from development to production requires no code changes. They also explore project variables, discuss Railway's hosting on Google Cloud Platform in the US West region, and review the basic CPU and memory metrics that will support upcoming usage-based billing.

00:13:34 - Database Provisioning and SQL via GUI and CLI

Anthony demonstrates creating tables, inserting data, and querying the Postgres database directly through Railway's built-in data browser and a PSQL connection string. He emphasizes how significant this simplicity is for developers coming from bootcamps where database experience is often minimal, arguing that lowering the barrier to working with real databases is enormously valuable.

Greg agrees, noting that he rarely uses PSQL himself and appreciates being able to browse tables directly in the Railway GUI. Anthony then tears down the demo project and pivots to recreating the same setup using the Railway CLI, walking through login, project initialization, and the plugin system for adding databases. They discuss the CLI's value for reproducible workflows versus GUI-based "ClickOps," and Greg explains the concept of progressive disclosure — keeping things simple for beginners while offering power tools for advanced users when needed.

00:24:28 - CLI Development and Database Plugin System

Greg discusses recent CLI improvements, including the ability to run one-off commands against specific environments, such as migrating a production database while actively developing in a different environment. He notes that while most functionality is available through the CLI, he personally uses the GUI more for day-to-day work since GitHub integration handles automatic deployments.

They add a Postgres plugin via the CLI and discuss Railway's plugin architecture, which currently supports Postgres, MongoDB, Redis, and MySQL. Greg explains how plugin requests are tracked and mentions he's been working on a MinIO plugin for S3-compatible storage. Anthony raises the interesting tension between exposing more cloud functionality and maintaining the curated simplicity that makes Railway appealing in the first place, noting that unrestricted exposure would effectively recreate the complexity of the underlying cloud provider.

00:34:15 - Building a GraphQL API with PostGraphile

With the database provisioned and seeded, Anthony introduces PostGraphile, a tool that automatically generates a full GraphQL API by introspecting a Postgres database schema. Greg expresses genuine interest, having only ever built GraphQL APIs from scratch before. They launch the PostGraphile server and explore the auto-generated schema, queries, and the GraphiQL editor.

Anthony demonstrates querying the posts table through the GraphQL interface, then shows the same query working via a raw curl command and through Insomnia. He connects this to StepZen's roadmap for native database introspection and explains how PostGraphile's automatic schema generation previews the kind of zero-code database-to-API workflow that will become more broadly available. A viewer question about MongoDB support leads to a discussion of Railway's NoSQL options and the differences in introspection needs between relational and document databases.

00:40:04 - Connecting to StepZen via ngrok

Anthony sets up an ngrok tunnel to expose the local PostGraphile endpoint to the internet, explaining the tool's usefulness for webhook testing and sharing local development work. He then creates a StepZen project that uses a GraphQL directive to pull in the PostGraphile endpoint, effectively creating a unified GraphQL schema that queries through StepZen to the Railway-hosted Postgres database.

The demo showcases StepZen's ability to combine multiple GraphQL sources into a single endpoint, which Greg praises for turning confusing REST APIs into self-documenting, autocomplete-friendly GraphQL interfaces. Anthony explains the index GraphQL file structure, how StepZen handles authentication with API keys, and how the deployed endpoint can be consumed by front-end frameworks. He emphasizes that this entire integration — from database to unified API — was achieved with virtually no application code.

00:49:09 - Railway Roadmap and Closing Discussion

Greg and Anthony reflect on the demo, with Greg noting that the entire integration involved almost no custom code — exactly the future both Railway and StepZen are working toward, where developers only write business-specific logic. Greg outlines Railway's near-term priorities: usage-based pricing, a design overhaul led by a recently onboarded designer, and improved tooling for microservices deployment.

The microservices discussion touches on how applications are growing more complex, with companies running many interconnected services that need shared databases and inter-service communication. Greg connects this trend directly to StepZen's mission of integrating multiple data sources. Anthony closes by thanking Greg for his contributions to developer tooling across Insomnia and Railway, encourages viewers to check out the StepZen Discord and Twitter for future streams, and signs off for the week.

Transcript

00:00:00 - Anthony Campolo

Hello, everyone. Welcome to the StepZen stream. We are super happy to have Greg here. I forgot to ask you before the stream — is it "sheer" or "shire"?

00:00:14 - Greg Schier

It's Shire.

00:00:15 - Anthony Campolo

Shire, Greg. Shire. Thank you so much. Oh, yes, of course. Lord of the Rings energy here. I like it. We are really glad to have you as our inaugural guest. We've been doing some live streams at StepZen for a while now with just ourselves and building projects and sometimes building projects with each other. But I really wanted to get some other people on to learn a little bit about other things going on in the ecosystem that maybe can integrate with Stepzen or can do cool things with it. And you're someone who has a very illustrious career in dev tooling in the dev space. So I'd love to get a little bit of your background, who you are, what you do, and how you found yourself at this company.

00:00:57 - Greg Schier

Company, yeah. So I guess I can start with the last major thing I did, which was I made a tool called Insomnia, which is a desktop app for interacting with APIs. You can do like normal APIs, GraphQL, various things like that. Did that for about five years. Then that got acquired by a company called Kong, who builds API gateways and API tooling. And then I recently left there to just, like, go back to being independent. I originally, well, I was playing with a few ideas, but one of them that I wanted to do was build, like, an easier way to deploy applications, like web applications. And then the founder of Railway, Jake, reached out to me and he's like, hey, we're building this exact same thing. So I talked with him for a while. Turns out we had a lot of similar ideas. So I was like, hey, can I just join you guys? So that's what I'm doing now. I'm at Railway. We're working on, like, a platform to make it really, really easy to deploy databases and web applications. So I'm sure we'll get more into that as we go. But that's like the high level of what I've been doing recently.

00:02:11 - Anthony Campolo

Awesome. Yeah. And I am a big fan of Insomnia. I actually use it myself. And if you read some of my tutorials where I'll take screenshots of API calls that I do to test, it's usually in Insomnia, because most people, I think when they go through a bootcamp and they're kind of taught to work with APIs, the first thing most people are going to get is Postman, because it's really well known, it's ridiculously featureful. It's got very built out GUI and all that kind of stuff. But I really liked the simplicity of Insomnia and that it's a really clean interface and it's just doing your API calls. And then you also have a lot of great GraphQL tooling with autocomplete and schema generation and stuff like that. So it's great to work on some GraphQL stuff with you here. And we'll probably be using Insomnia at one or two points throughout this demo and it's a really great company Kong that has taken it over. And so they do a lot of API stuff, a lot like Stepzen, except not quite as GraphQL specific. And it's going to be cool to see where you've moved on beyond that because as you say, you're not really doing as much API stuff these days.

00:03:26 - Anthony Campolo

You're building more like infrastructure. And so I've been loving Railway and I tell everyone I can about Railway and I use it in like all sorts of tutorials and things like that because for me it's very much what a lot of people have been asking for, which is like we want a backend netlify. I think a lot of people want a backend system that has a really simple GUI and a really easy way to get spun up with anything you want to deploy, whether that's a relational database or a Mongo database or even a Redis instance. You've created this really cool platform for deploying all these back end pieces just as simply as you would deploy a front end web application. That's going to be some of the stuff that we're going to get into here. I would be curious like if you had done much DevOps infrastructure type stuff but before Railway or if this has been more of like a learning experience for you, getting deeper into like all this like AWS stuff and kind of what that's been like. Getting deeper into the DevOps infrastructure layer.

00:04:32 - Greg Schier

Yeah, it's been really interesting. I haven't been focused too much on the DevOps side — mostly in, like, the space between the front end and the DevOps, building out like our — I guess the part that's written in Go. So like scheduling like building Docker images and right now I'm working on rollbacks. So like snapshotting the Docker image, storing it in like a Google Cloud bucket and then like [unclear].

00:05:01 - Anthony Campolo

It's kind of silly that you wouldn't consider that DevOps to me that's like the most devopsy thing I could ever imagine is scheduling Docker containers.

00:05:07 - Greg Schier

I would consider DevOps more like to do with servers and setting up like networking and basically everything that's, that doesn't really involve the application code. I'm sort of like at the far end of the application code that's like right, the DevOps.

00:05:23 - Anthony Campolo

But there's a good term for this that is becoming more popular, which is the back of the front end. So like you're specializing in the back — it's the tooling layer that enables the front end devs to create these applications. And that's a space that I really enjoy, and it's why I think GraphQL is really cool because it sits in that perfect little mid ground between the front end and the back end. So you get that back of the front end front of the back end type feel. Yeah.

00:05:47 - Greg Schier

And before Insomnia, my first real job out of university was at a startup called Send With Us and we were building basically an API to send transactional emails and it would basically render an HTML template for you and send it to your email service provider like SendGrid or whatever. So at that job we were heavy users of Heroku, which is sort of where I have that appreciation for easy deployment systems. But we also had to scale a lot. Like we'd be doing like 100,000 requests per day and we'd get a big customer that comes on and like 10x's the traffic and all of a sudden our databases fall over, all this bad stuff happens. And even though we're on Heroku, we still had to scale our application code and our databases and all that stuff. So I have experience with infrastructure in that realm of like how do you scale an application and data layer? I'm really interested in that stuff as well.

00:06:49 - Greg Schier

So I don't know, I consider myself like a true full stacker. Like I really like doing front end, which is basically what insomnia was 100%. And then I really also like just digging into hard problems on the back end. I think the one thing I don't like as much is just the pure DevOps. Like I wouldn't enjoy setting up a Kubernetes cluster, for example.

00:07:12 - Anthony Campolo

That's why I just tried to set up a Kubernetes Cluster for the first time this last week where someone posted how to self host Redwood on Kubernetes on the forums. And I was like, awesome, I want to run Redwood on Kubernetes. And it's like you probably learn Docker first before you learn Kubernetes. Actually.

00:07:28 - Greg Schier

Yeah, I guess your role covers like such a broad spectrum of stuff that you have to learn, I bet.

00:07:33 - Anthony Campolo

Well, it's. It's kind of a certain aspect of I get to decide where I want to focus my efforts because especially with something like Redwood, like with StepZen, there's a little more like boundaries of like what my role is, what I do. But with Redwood, because it's just an open source project that we're all volunteering our time for, there's not really kind of like expected things for me to do, especially because I'm not someone who really gets that deep into like the actual Redwood code base. So I always look at what are these other things happening in the ecosystem that we could synergize with. What does it actually mean to have a canonical Docker file for Redwood? And figuring that out just involves talking to lots of people who used Docker and lots of people who've used Redwood and collating all those different opinions into something that can be canonical. It also gets into things like how do we port this from Lambda to Azure Functions or even Cloudflare Worker. And no one knows how to do that because no one's really ever done that before. No one's ever tried to build a framework that could be portable between all these different things until Envelope.

00:08:34 - Anthony Campolo

But that's a big segue. We don't need to go down and we want to get into Railway here. So let's go ahead and get us looking at the Railway homepage and I'm going to also address the stream real quick. A lot of people in the stream, which is super cool. Happy to see so many good friends out there. We are streaming both to YouTube and to Twitch. I am here on StreamYard and blasting out to both of them. So if you're trying to see where the conversation is going, it looks like most people are chatting in the Twitch chat, but we also got some people in the YouTube chat as well. So feel free to hop around wherever you think the conversation will be. And I'm going to go ahead and share my screen and I also wanted to drop just this one just here. That's going to be what we'll be building out in a second, but don't worry about that too much yet. First let's take a look at Railway here. So Railway, what is the first thing someone should do when they kind of go to the Railway homepage?

00:09:43 - Greg Schier

I would say just deploy something. I guess you're not. You're already logged in right now.

00:09:48 - Anthony Campolo

But I am. There's my nice little cartoon face.

00:09:52 - Greg Schier

Yeah, if you're not logged in and you click the Go to Dashboard button, it'll usually prompt to deploy something.

00:10:00 - Anthony Campolo

So people can see that. Let's take a look in incognito. It would look like get started right there. Login. You can do an email, you can do a GitHub. I'm pretty sure I just synced my GitHub to it and never had trouble with auth. Always does a good job of recognizing who I am and what I'm doing. And if you go to the dashboard, you can see I've got a bunch kind of example projects already going. You will. It's worth mentioning you're only going to have three of these on the free plan. Right. But that may change. Is that true?

00:10:33 - Greg Schier

Yeah, we're working on a usage based pricing plan right now. The free plan will change. We haven't finalized the details yet, but you'll essentially get a certain amount of usage which will be good. Like we really want to target the independent developers. So we really want to have a free plan that is actually useful to people. Other products, like there's usually like a minimum cost. Like it's like $7 per month per project just to get something. So we want to make that a little bit more generous for people who maybe are deploying demos and starters and things like that that maybe won't get any traffic. They're just sort of going to be idle most of the time. So that's the.

00:11:13 - Anthony Campolo

That's me. Those are my projects.

00:11:15 - Greg Schier

Yeah, yeah. I have like maybe 15 or 20 projects that like, yeah, I've started this but no one's using it. It's just like in progress.

00:11:23 - Anthony Campolo

Yeah, I was usually spinning ones up and then tearing them down when I was done. But I've got a couple now that like live out in the wild. I want people to actually be able to see. So I upgrade and I've got a handful now, but it's been very much worth, worth the money. And it sounds like with the adjustments you're making, you're gonna make it even more economical for a wider range of people, which is really great. And one of the reasons I really stress these types of services like netlify or Vercel, because some people get really uncomfortable. Kind of like building on these VC funded type of, type of operations. And it's not so much about you want to build this whole company on this one specific provider so much as you want to provide the options to build at all to the rest of the world. Like everyone else who wants to learn how to use these tools wants to get a side project spun up, wants to maybe start building a company and be able to do that without having to break the bank and do this huge ridiculous infrastructure. So having this kind of like simple entryway on a free plan I think is so valuable and it's why I'm like very comfortable, like constantly promoting these types of companies, types of projects.

00:12:29 - Anthony Campolo

I do think it's like actually very, very valuable to a very wide range of people. Okay, so if we check out here, this is going to be how we start off a project. Looks like we've got a couple different things that we can do to start off. We could do it.

00:12:45 - Greg Schier

I just want to mention here one unique thing that Railway does. And this is actually what Railway started as, was just an easy way to get a database. So you can actually deploy just a database without any application code, which is a really popular thing and something we're going to take advantage of today.

00:13:03 - Anthony Campolo

What I want to do is I'm going to walk through this whole thing through the GUI and provisioning postgres and then after that we'll reset and do it through the cli so people can see the two different ways that we can do it. But I think most people are usually going to start with a gui. You can just choose postgres and it's going to have some old funny jokes under there as well if you pay attention. Here's our dashboard. What do we got going on here?

00:13:34 - Greg Schier

Yeah, so basically here's everything that you can do. You can see on the left there you have your setup pane, which is the one you're on. So it shows you how to like link the CLI to our project that we have here. Then you have the deployments, you can see all the deploys that your application submitted, I guess. And then from there you can view the logs for your app, you can cancel things, you can roll back, then you have your settings and then down below you have your environment specific stuff. So one thing that this is actually my favorite part about Railway is that you can do, basically you can connect it to your production environment, but also your development environment. So usually you have to, like when you're starting a new project, you have to run it locally. And then you have to set up a database on your computer. But with Railway, you can actually just create a development environment in Railway and your database will be there for development. So really you only have to run your application code locally and it can actually connect to a database on Railway, which is really cool because I'm someone who uses multiple computers for dev.

00:14:41 - Greg Schier

So if I spin up my project here and I migrate my database locally and then create a couple of users, write some blog posts or whatever in my app, then I switch computers, that database is still going to be the same one that I'm using over there because it's on Railway. So that's one of my favorite things. And then it's also cool because when you're ready to go to production, since you're already using Railway in development, there's no like, oh, I have to change my code base to figure out how to deploy on this platform. It's like, oh, I'm already using it. I just basically hit a button to deploy to production instead of development.

00:15:17 - Anthony Campolo

Yeah, totally.

00:15:18 - Greg Schier

Very well integrated through the whole development process.

00:15:21 - Anthony Campolo

Very cool. Then we also have these project variables as well. This is going to be very useful for anytime you need to share your database around or you need to connect it to your application. You guys also do a really good job of hiding stuff that you don't want to see, especially for live demos like this. That's something I really appreciate. Let me show some of these that aren't going to be private. If you look at the user, we've got a postgres user like normal. If you look at our host, we are here containers US west five. When I see something like this, I think this is indicative of you being hosted on aws. Is that the case?

00:16:03 - Greg Schier

We're actually on Google Cloud platform, but it's very similar technologies there.

00:16:08 - Anthony Campolo

They also have the same terminology of US west or US Eastern, because it's the region that you're actually hosting tells me that my database is literally physically located in the United States, somewhere on the West. I think this means it's somewhere in California, I'm guessing.

00:16:25 - Greg Schier

Yeah, something like that.

00:16:27 - Anthony Campolo

Which is good because I am in California. So how do you manage that exactly? Is everything going to US West right now? Is there a way to kind of like sync that to the user's location or how does that work exactly?

00:16:40 - Greg Schier

Yeah, right. Right now because like, Railway's still super early. We're still working on all this stuff. So right now everything is in US West.

00:16:49 - Anthony Campolo

Nice for me.

00:16:49 - Greg Schier

We're trying to build our infrastructure to be multi region. We just haven't got there yet. But yeah, definitely right now everything's in west. And we're like, that's something. That's a big thing that's on the roadmap for the next little while.

00:17:04 - Anthony Campolo

Cool. Yeah. But in the, in the meantime, you just want to figure out some way stick a CDN in front of your application, which there's of course many, many, many ways of doing that.

00:17:14 - Greg Schier

And then Cloudflare, people are using it through Railway.

00:17:18 - Anthony Campolo

Oh, cool. Yeah, I'm a big fan of Cloudflare. I've been learning that over the last couple months for sure. And then we got our database, which is named Railway, and then we got our port number here as well. And what kind of metrics do you guys provide? This is one thing that I haven't gone too deep into, so I'd be curious to hear a little bit about this.

00:17:39 - Greg Schier

Yeah, so these are very basic metrics. Right now we basically just track CPU memory and network disk usage will also be coming soon. But we added the metrics mostly for the usage based billing stuff that we're working on. So that's sort of where it's coming from. We want to build out the metrics even more to provide like how many requests per second are coming to your app, more useful information like that. Maybe we'll overlay the deploys on the graphs over time so you can see like if a deploy affected your metrics. But yeah, right now this is mainly going to be used for the upcoming usage based billing. So we'll build based on like, if you're. If you have like a really intense CPU based app, then you can see your CPU going up and down. If you have like, maybe if you're running a Django app, it's going to use quite a bit of memory because that's just how Django works versus something like a Go app which will use very, very limited amount of memory. So yeah, that's just the metrics now. Very basic, but also useful.

00:18:43 - Anthony Campolo

Awesome. Then here is where the real meat of our project is right now. Because we have deployed a postgres database and you can create a table through the gui or you can actually, if you want to be really fancy, you have this command here that lets you automatically sync to psql. This is really cool because especially for people who don't know a lot about databases, just getting a database spun up and connected and being able to access it and read and write to it is just itself a pretty large barrier, especially for people coming from boot camps. And this is something that I've talked about on a million podcasts I've done is a kind of big part of my story is that my boot camp, I say, is mostly a front end bootcamp that was sold as a Full Stack boot camp. I felt that it was almost entirely React JavaScript based and then there was one month of backend that had one week of databases in it. I really feel like that is a good amount of material and curriculum to consider yourself a Full Stack developer if you spent a week learning about databases.

00:19:51 - Anthony Campolo

As I've gone into the working world now and I've worked on other projects, I've gotten involved with more of these full Stack frameworks. Learning the database aspects has been huge. And having these types of things provided for you to be able to work with a database really easily, you can't discount how important it is, how useful it is. Literally I can just grab this whole guy and we're going to tear down this database right afterwards. Even though we're showing my password right here. Don't worry about that too much. Right now. We can actually throw SQL straight into this if we wanted to. So if we wanted to create a table, we could do that. Create a table, we want to insert some values into it. We can do that as well. If I want to insert a couple more in and then we want to select star from post and then there we go, we got Post, so we're already hooked up. We got our database, it's deployed, it's on the Internet, we can access it, we can read to it, we can write to it. And then if we go check back in our GUI here, we can already see the data in our Railway table.

00:20:58 - Anthony Campolo

So just that right there is like a little hello world thing. Just blew my mind the first time I saw it.

00:21:05 - Greg Schier

Yeah, that's another one of the things I really like. Often development involves like so many different tools and a lot of them are from the command line like you just did PSQL and I never use PSQL because I just, I never remember how. So I always use a gui. But now I don't really have to use an external GUI application. I can just go into Railway and just browse the tables and create records and delete stuff. So I really like that aspect. And actually in the command line over there, you pasted that command right in there. But you can also run Railway Connect.

00:21:41 - Anthony Campolo

That's what we're going to show next, we're getting there. So first off, let's just go ahead and so now that we have exposed our environment variables to the world, we're going to want to tear this project down like so. And then now we're back to normal and I want to show how to do this with the Railway CLI. And this is just a little gist I've got here that I pasted in the chat a little while ago and let me actually go back to chat for a second and see if anyone asked any questions. Let's see. Nope, doesn't look like there's anything. So that little gist that I posted a second ago is where people can see these commands and follow the same flow if they want. I've also got a blog post that is fairly similar to what we'll be doing here. Let me drop that also and let's get back to sharing. You've actually helped me out with this whole CLI flow. This is something that I had originally done with Redwood, because with Redwood I had wanted to figure out a way to short circuit the SQLite part. And this is a very long and deep Redwood specific kind of story.

00:23:08 - Anthony Campolo

But basically the way our tutorial is set up, you start with SQLite and then end up with Postgres. And because of Prisma Migrate having a migration lock file, you end up with all this weird complex stuff that requires you to basically delete all your migrations and start over. I wanted to have a tutorial where as soon as you create your Redwood application, the first thing you do, you spin up a Postgres database. You connect to that Postgres database and you start developing that way. I thought that that would be really valuable. You'd avoid all this weird transition from SQLite to Postgres. I realized that the Railway CLI was really, really powerful in how it could do this for you because you could actually insert yourself directly into either environment, either your database environment or your application environment. You could pull an environment variable directly from your database, insert it directly into your project, and do that all in a single command, which is what you showed me how to do. Then you've now shown me ways to do this even nicer because you've been continuing to build out the CLI and the functionality and ways of doing that connection, making it even more seamless.

00:24:19 - Anthony Campolo

Can you talk a little bit about what kind of work you've done on the CLI and where you've seen it progress and where you think it's going in the future?

00:24:28 - Greg Schier

Yeah. So I guess lately in the CLI we've mostly been working on exposing more functionality. I think the CLI has been pretty powerful for a while in regards to like automatically injecting your environment variables to connect to your database automatically, like launching a PSQL process so that you can connect to your database without having to like copy that big string or expose your, your password to the world. But yeah, we've been just like making it more and more trying to make it more useful. So we have this concept of Railway environments which before in the CLI you could only be on one environment at the time. So right now we're working on the ability to run a command, like a one off command for a specific environment. Like say you want to migrate your Prisma database on production, but you're like currently active in your development environment. Well, you should be able to run like railway, run, dash, dash, production, prisma, migrate and then just run that one off command on your production database. So that's sort of where we're going now is making it a little, giving the user a little bit more control I guess over like where they're running things, not just having it useful during development.

00:25:42 - Greg Schier

So yeah, you can do most things that you can do on Railway you can do with the CLI, especially in a read fashion. You can get your variables, you can list your plugins, you can add a plugin, you can deploy stuff. Yeah, there's lots of stuff in there. I actually use, to be honest, the GUI more than the CLI just because it's usually all that I need. I can connect my GitHub repo so it automatically does deploys. And then with the CLI I usually just run my app.

00:26:17 - Anthony Campolo

The real value I see from clis especially, and why I tend to push it, is that if you have a CLI that works well and works consistently, it allows you to make the steps of your workflow far more reproducible than you would with a gui. And this is why there's a term that I really like called Click Ops. You want to avoid clickops as much as possible because it's just not reproducible. It's very hard to document, it's very hard to share with others, and it's very hard to like make that a shared kind of workflow unless you're really, really, really good about having a hyper focused GUI with only a couple things you can do. And so that's where like Railway and netlify and these companies have done a great job of narrowing the scope of what you can do with a gui. So you don't end up with this crazy AWS dashboard sprawl kind of problem. You are able to make a simpler kind of workflow. And so I kind of, I'll hesitate like whether to show someone to do something with the Dashboard or the cli because it's which one's going to be better.

00:27:20 - Anthony Campolo

It's going to kind of depend on how much they know about working with a cli. How easy is it going to be for them to get installed and like on their machine and working correctly. But I think once you can get past those initial barriers of actually getting the CLI on someone's machine in the first place and working correctly, then you can be like, all right, run this command, this command, this command, boom, boom, boom. And then you're set up and it's going to work every time. So that's partly the real value I see there and why I'm going to be kind of walking through more of a CLI based workflow for this example.

00:27:53 - Greg Schier

And I think the one thing to touch on that, and this is something I focused on a lot with Insomnia as well, which is something called progressive disclosure of enhancement. So basically like starting off as simple as possible, you don't have to have a CLI to deploy something, but as soon as you need that you can go download it and set it up. So it's like, it's very simple like you said, for the, like the novice user, you don't have to like use a CLI ever. You can look at your database on the website, you can do all this stuff, but as soon as you need it, like maybe like you said, you're working with a team, you want to write some like setup scripts and bootstrap scripts, some deployment scripts. Well then you can go fetch the CLI and get all that done as well. So like, but it's not forced on you from day one, which is something I really appreciate.

00:28:37 - Anthony Campolo

Yeah, totally. So so far I ran Railway version. Just check our version number here, 0.2.40, which is the most recent version I believe. And then you can run Railway login and then that just kicked open this browser window over here to authenticate. You also have the ability though, if you want to, to log in in a browserless way, which is not something I've ever done. But if you want to do an SSH session or something like that, you can do that as well. So for more security minded, you don't want to be going through the browser. That can be really useful as well.

00:29:13 - Greg Schier

Yeah, that's if the CLI doesn't have the ability to contact a web browser, like if you're running on a different computer or something. Also, Safari has troubles with the login, so you need to run it through the browser, this mode, which just gives you a link that you copy into Safari.

00:29:31 - Anthony Campolo

Gotcha. Interesting. All right, so Railway init. This is going to be how we spin up our project. This would have been similar to going on the dashboard and just clicking new project, correct?

00:29:43 - Greg Schier

Yeah.

00:29:45 - Anthony Campolo

And then it'll ask us if we want to do a starter template or empty project. Actually, we're not going to do this. Let's just take a look at some of these because you have like a ton of starters, right?

00:29:57 - Greg Schier

Yeah. And this is something that for us has been working on a lot, just like getting different starters running on Railway and like they're all in a GitHub repo right now. And we've also been adding like. Like we have one for coder, we have one for like Ghost blog engine, like a bunch of things that you wouldn't really consider code. It's more like a product that you're

00:30:21 - Anthony Campolo

hosting on Railway, like kind of like a Discord bot. That's. That's pretty cool. That's not something I would usually see as a starter.

00:30:29 - Greg Schier

Yeah, there's a lot of cool stuff in there and there's actually stuff in there that like, I didn't know about before, but I was like, oh, cool. Like Umami's at the bottom, which is an analytics thing. I was like, I'm going to try this out. Just because it's like one click.

00:30:42 - Anthony Campolo

Yeah, I've been slacking. I've been mean to create a redwood one for these. It won't take me very long. I just got to sit down and do it. Let's go back now and we're going to initialize an empty project and let's call this GregStream right now. It will then do the same thing where it just kicks us up to this basic project here. But I want to keep us here in the cli. And now Railway Add. This will be the step of actually adding in the plugin, correct?

00:31:18 - Greg Schier

Yeah.

00:31:19 - Anthony Campolo

Yeah. So the different plugins you have, you have Postgres, MongoDB, Redis and MySQL. I'm very curious what decision making goes into what plugins you started with and like what plugins you're going to look at next.

00:31:34 - Greg Schier

Yeah. So I actually. So I've only joined Railway about five months ago. So all these plugins existed before I came on board. But I. We do have, when you go to add a plugin in the ui, there's like an option to request a plugin. So we have like a giant list of all the plugins that have been requested and you can see level db, the most popular one right there. But then you can just request things. And so we've got a giant list of like to do for plugins. Basically one of the ones that I've actually been working on, one just a little bit passively, one for minio, which is basically a tool that gives you like Amazon S3 functionality but hosted yourself like S3 compatible storage. So like running on that, on Railway would be pretty cool because then you don't need like an Amazon account to store or host big images or videos or things like that.

00:32:29 - Anthony Campolo

Yeah, so those are types of things

00:32:30 - Greg Schier

that we're trying to add as plugins.

00:32:32 - Anthony Campolo

Yeah, I like that idea of like slowly exposing more and more of the functionality of these underlying clouds because you're, you're hosted on gcp, as you say, so you have, you know, storage buckets and you have all this kind of stuff there, but if you just expose all that, then you're just gcp, you know, it's like so having some sort of curated path is the whole point and why someone's using it in the first place. But there's always going to be that tension of like, how much can you expose to the user? Like what, what do you need? What kind of guardrails you need to put in place if you want to expose it and give a similar sort of DX to the current plugin. So it's really interesting, like really wide open kind of, kind of problem space that I always find really interesting to think about. All right, so now we're going to be adding our postgres plugin. And to me, just the fact that you can like get an entire postgres database like spun up and provisioned that quickly is so nuts. Like it used to takes so long time to do this kind of stuff.

00:33:31 - Greg Schier

Yeah, yeah. Waiting for anything is the worst.

00:33:36 - Anthony Campolo

And then now we're going to connect and as we did before, we're now in and we're ready to go. We're in PSQL so we can do the same thing we did before where we're going to kick open just a table, give us some seed data and then read that seed data back. Then we can also do some PSQL commands to take a look at our database or describe our database. The all important command you must know is of course, how to quit from psql do you want to talk a

00:34:13 - Greg Schier

little bit about what we're building as well?

00:34:15 - Anthony Campolo

Yeah. Now we're going to actually get into the real project here. What we're going to do is we're going to create a GraphQL API with this Postgres database that we just set up. And so we have this tool, PostGraphile, that we're going to use. And you hadn't used this before — I kind of suggested this, right?

00:34:40 - Greg Schier

Yeah, usually. I've only ever implemented a GraphQL API from scratch, so I'm actually really interested in this because it seems like it would save you a lot of time.

00:34:51 - Anthony Campolo

Totally, yeah. And so it's. This is an example of the whole problem of database introspection. What we're showing right now is going to be the type of functionality we're going to have in StepZen very, very soon for MySQL and Postgres and all databases. This is an example of the real power you get from good GraphQL tooling — it gives you the ability to essentially point this tool just at a database and get back a full GraphQL API that you can do whatever you want with. So if we look at this right now, we have a GraphQL API running on localhost 5000 /graphql and then we also have our handy dandy GraphiQL editor and it will even tell us our Postgres that we're connected to. It is kind enough to hide our secret for us. And when we kick this open over here, this is a very similar GUI to what we'll see with stepzen in a second. When we connect this project to stepzen, this is basically all you could do with this database. It creates the schema for you, it creates the queries for you, and then all you have to do is go look at the schema, look at the queries, and figure out the query you want to run.

00:36:09 - Anthony Campolo

We're going to want to get all of our posts, we're going to want to see how many posts we have, and then we're going to want to get the body and title of each post. There we can see what we have already written into our database just with a single command. We're already hooked up, connected to our database with a GraphQL interface, able to query it and get the data back.

00:36:34 - Greg Schier

That's awesome. No code at all.

00:36:37 - Anthony Campolo

I know it's nuts. Cool. We had a question about Mongo. So we do have Mongo support. That's actually something I'm playing around with right now because MongoDB is now compatible with Prisma. Prisma just added preview support for MongoDB, which is really, really exciting. And it's been a project I've been kind of like following in the background, watching them do for literally a year now. And it's really exciting. So if you want to do Mongo database in addition to relational database, that's something you can do with Railway. And it's really cool. You have all these different database options. So you're not just kind of locked in. Because a lot of these providers, I find, have gone really heavy into Postgres. Like, it seems like Postgres is kind of like the database of choice, which is, which is great if you're working with Postgres, but not everyone is working with Postgres, you know, so you guys give the option to pick these different databases and have these different options depending on kind of whatever DB you're coming from. And then we had another question saying, can I request a random text file on a file system as my db?

00:37:47 - Greg Schier

I assume that maybe they're referring to SQLite.

00:37:52 - Anthony Campolo

I would guess so, yeah. When you just have a DB file, that's. That probably is right now.

00:37:56 - Greg Schier

So Railway doesn't allow you or doesn't suggest relying on the file system because, like, a new deployment could be deployed on a totally different server and your file system wouldn't be there. This is very similar to like, how Heroku works. They call it an ephemeral file system. We do, we are trying to figure out how we can do like attached storage essentially to your Railways.

00:38:21 - Anthony Campolo

But yeah, because once you got storage, you can just put whatever and do whatever with. And that's where you can kind of do these weird hacky things that smart,

00:38:29 - Greg Schier

smart people want to ask even WordPress, like, if you want to host WordPress, it relies heavily on the files system. So, like, if we want to be able to allow people to host WordPress or even Ghost, we allowed Ghost. But you have to do some things to sort of get around that limitation right now. So I think that would be really awesome.

00:38:47 - Anthony Campolo

Thanks. All right, let's get back into our screen sharing here. So this is, as I said, our first partner stream we have with you. And kind of the idea of with all these streams is I'm going to be thinking, all right, how do we get your thing connected to StepZen in the shortest amount of possible steps. Shameless advertising here, but that's what you signed up for. We are going to now take this endpoint and we're going to pipe it into a StepZen project. For anyone who doesn't know anything about StepZen, it's a way to create a unified GraphQL schema that then takes in all these different data sources and does whatever you want with them. One last thing I also want to show is if you just want to run a straight up curl command against this endpoint, if you don't want to use a graphical editor or insomnia or anything like that, you just straight up curl it and then send the URL, send a header with the content type, and then send this data containing the actual query that we sent over here, and then you get the data back like so. So very, very nice developer tooling setup we've got here.

00:40:04 - Anthony Campolo

And then if we open up our handy dandy insomnia right here, then we can also do the same thing and run a query against it. So here we're just going against our local host, clear that and then running that query and then we get the data back just like so. Now the one thing you need to do though, if you want to pipe this into StepZen, is that you need to create an ngrok endpoint. And so this is just because we're kind of using PostGraphile right now on localhost. If we want to deploy this endpoint, then we wouldn't need to do this. But this is a nice little developer tool that I've been learning how to use recently. And our CEO Anant is a huge fan of ngrok. He uses it all the time. So this is again, useful. Yeah, yeah. So why don't you talk about a little bit like kind of your experience with and what you found it useful for.

00:41:04 - Greg Schier

Yeah. So when I was at Send With Us, we used it a lot to test webhooks. So like in order to point a webhook at your local environment, you have to have it exposed to the Internet. Right. And there's no way to do that if you can't like forward a port from your router. The only other way to do that is with something like ngrok, which essentially creates a proxy that exposes your local network to the world or whatever's running on that port that you specify. So then you can actually point your like maybe stripe webhooks or whatever at your local environment to like, more easily iterate on development with that. And the other thing I love it for is if I'm working on something and I want to share it with you. I can use ngrok, get a public URL and then send that to you so you can actually look at what's running on my computer.

00:41:48 - Anthony Campolo

Yeah, that's exactly what I really like about it and why I found it very useful, especially working with StepZen, because part of the whole point of StepZen is that we have all these endpoints that we're trying to get inside one single unified GraphQL endpoint. This whole workflow being able to spin up endpoints really quickly, share them around, have other people test them with their API testing tool of choice, it's really great. It's a really nice workflow. Found that's one of the things that makes like GraphQL tooling really nice, because as long as everyone knows what your endpoint is and like some sort of agreement on a schema, people can just start throwing queries and getting data and playing with the applications very, very quickly. I'm a big fan of that. So this is going to open up a Ngrok endpoint for us right here. And then if we pipe this in here and do the exact same query, we're going to get cannot post. And the reason for that is because it's a GraphQL endpoint. If we add GraphQL at the end, then we actually get the data back. Now we have this endpoint set up and we can pipe this into StepZen.

00:43:01 - Anthony Campolo

Now, the reason we can do this is because we have a StepZen @graphql directive that gives you the ability to basically plug any GraphQL endpoint in and query it as if it were your own. And this is going to be where all the StepZen-isms come into play. The only real things you need to know is you have your index GraphQL file, which is this is project I already created. Let's do this.

00:43:42 - Greg Schier

So can you integrate other data sources besides GraphQL into StepZen?

00:43:46 - Anthony Campolo

So actually, the fact that you can integrate GraphQL at all is a fairly new thing. In the past, it was more for things like databases and REST endpoints. So if you see here in our docs, you can connect any Rest API you want and then turn that into a GraphQL schema. And then you can also connect databases as well, like a MySQL or a Postgres. And so we could connect directly to the Postgres database if we wanted to. But I want to show off this new @graphql directive we have now because it shows how we are in a space now where GraphQL itself can be the lingua franca. You can have as many GraphQL endpoints as you want and combine them all into this one and they're all still going to speak the same language, you're going to understand the same queries. And it's just like piping them all together in a way that makes them really, really easy to work with. As of now, the @graphql directive isn't actually even really documented that well. This is something that we're working on right now, and you guys are getting a sneak peek of. But it's a great way to feed any GraphQL source into your whole unified one graph, as some people call it.

00:45:07 - Greg Schier

Yeah, that's awesome. I really love, because GraphQL is such a good user experience because of the schema introspection. Like all the tooling can do all the autocomplete for you make it really easy to use. So you take a rest API that's really confusing and you have to look at the documentation. Putting it in a GraphQL is like, oh, I can just use it. The tool tells me how now.

00:45:28 - Anthony Campolo

Yeah, well, fat fingering some stuff over here. Code. Boom, there we go. Okay, so the main StepZen-ism you got to know about is your index GraphQL, which is what's going to combine all your other schemas into your one unified schema. Whenever I make this file, I'm usually doing like kind of these basic example proof of concepts. So you're just using one file. But the idea being that you're probably never going to have an actual real GraphQL project with just like a single tiny schema like this. You're going to have lots and lots of files with lots, lots of different schemas for users and for posts and for all the for customers or products and orders and all sorts of stuff like that. So this is just a kind of basic example to show you how this works. But in the real world you have lots and lots of different files that all get connected together. And then this is right here going to be our connection to this endpoint we've spun up. And there's type, which is your post connections. And this is because PostGraphile kind of spits out the schema in a certain opinionated way.

00:46:43 - Anthony Campolo

This is the type of thing that once we have our own native DB introspection, you won't have to worry so much about this. This stuff is eventually going to be pretty much generated for you out of the box and then you are just going to have to feed it your endpoint, which we had over here. This also shows how the workflow of going from your endpoint, just testing it with a tool like Insomnia to then plugging it into StepZen. We can feel fairly confident that we know this is going to work because you've already tested this endpoint and we already know the endpoint works. As long as we did our schema correctly and rewrote our query correctly, that's all we really have to worry about here. And then now we're going to do stepzen start and this is going to deploy our endpoint. It knows where to deploy it just because we have this StepZen config JSON. If I didn't write that in, it would have asked us on the CLI to name our endpoint. And then here, this should look fairly similar to what we were just looking at before on PostGraphile.

00:47:51 - Anthony Campolo

And then now we've got this. We got the Postgres database connected to the PostGraphile endpoint, which is connected to ngrok, which is now being fed into the StepZen schema. And the StepZen schema is doing the query all the way to the back end and all the way back to the front. There we go.

00:48:09 - Greg Schier

So StepZen here is also running locally.

00:48:13 - Anthony Campolo

It is. And it also deploys an endpoint for you here, which we could hit. I would just need to then grab my API keys as well to do that, because the public endpoint is protected by default. So when you go to stepzen.com and you create an account, it gives you API keys that you can then use. Like if I want to now take this endpoint and put it into a Next JS app or a Redwood app or a Nuxt app. You could do that and then you'd be able to query it with your keys. And you want to make sure that you're masking that from the client with some serverless function, which is where Redwood comes in really handy. But the point is that you have the endpoint. It's already there. It's already secured for you. All that is handled and you can bypass that through this nice little local experience. But it's ready to go deployed as well at the same time.

00:49:09 - Greg Schier

Yeah, that's awesome.

00:49:11 - Anthony Campolo

It was all possible thanks to the magic of Railway. And getting that database set up really, really quickly is like. You can't discount that because we don't host databases for you. That's not a thing Stepzen does. We are the gateway we are the API that stitches together all those backends, but you still need the backend. This is why I find that if you have these really nice infrastructure hosting providers now, you can combine that with these really nice API gateways and then you also can deploy your front end very easily with something like Vercel. And all of a sudden you start having these full Stack applications with all these different jamstack tools. And some people may call it Full Stack jamstack, although who knows who would ever use such terms. Certainly not me. Cool. That is pretty much the whole project we wanted to show here. Is there anything you want to talk about about Railway? Other things that you think people should know about or. Or like cool stuff that you have coming down the pipe?

00:50:12 - Greg Schier

Not too much now. Right now we're sort of in the next big thing is the usage based pricing and then we're just doing a lot of stuff behind the scenes right now to sort of handle the growth of Railway. We added 2FA recently. Lots of cool stuff like that. Yeah. Continuously getting better and better.

00:50:37 - Anthony Campolo

Awesome. I've been watching this progression as I've been using it over the last couple of months and I've just noticed lots of small things. You're constantly adding a CLI and little tweaks you're making to the ui. So I'm seeing that continuous process and it's really cool and it inspires me to want to keep building with you guys and keep writing tutorials of how to use it. It's really great. I really enjoy finding these synergies between different projects in the ecosystem that fit very well together because we're all trying to do the same thing. We're trying to enable developers to build better, faster, more secure applications. The more we can align on ways to do that and workflows that work well. It's really awesome. Then we have a question about NoSQL DBS from Lucia and that would be an example of Mongo would be a NoSQL database. So if we wanted to hook up to Mongo, we could do that as well. And then you wouldn't be able to use a tool like PostGraphile, but you wouldn't really need to introspect a Mongo database, I don't think, because you're basically just kind of throwing JSON objects into it.

00:51:47 - Anthony Campolo

Yeah, yeah. So I'm not.

00:51:50 - Greg Schier

StepZen doesn't support Mongo, does it?

00:51:53 - Anthony Campolo

Doesn't. I would imagine we will. We've experimented with Mongo, we've experimented with Firebase. There's definitely a real strong need and want for these kind of no SQL options. Actually, I should correct myself actually. Anant did a stream where he showed how to do this and so this is one of the things that we're still kind of documenting and getting out there, but this is something that is possible today. If you want to check out his stream, I'll go ahead and drop that in the chat as well. And yeah, we've got a lot of streams coming up in the future and we're really excited to bring on some other people to talk about cool projects they're working on and we're trying to get Jake on as well, so hopefully he'll be interested to come chat with us as well. And yeah, thank you so much Greg for being here. As I said at the beginning, I've benefited greatly from the tools you've already worked on and helped build and continue to with things like Railway. So we're really happy to have you here and get to learn about. And then, oh, looks like Jake's about to pop in here with some stuff that we're working on there.

00:53:12 - Anthony Campolo

So give him a chance to say his piece. Jake's also been really, really helpful with just debugging and like as I've been building out projects, anytime I hit a snag, I'll post in the discord. He responds very quickly and is very, very helpful. So having that kind of like support for a platform like this is really important as well. You can't discount that. And it sounds like they're working on a design overhaul and we brought on a.

00:53:41 - Greg Schier

Just to touch on these a little bit. Yeah, we've been working on — we onboarded a designer a few weeks ago, Jitachi, and we're working on just like polishing up the entire design. I think a lot of people like the visual style of it, but we're sort of working on the, the organization as well as visual polish, but just making it even easier to use and making all the parts of railway more consistent and having them fit together more. So yeah, that's design overhaul monolith to microservices. I think we just had Jake was talking to someone the other day who spun up like a product with like 12 microservices on railway or something. So like providing tooling to make those more easily deployable because a lot of microservices need to like be able to know how to talk to each other, they need to share databases, they need to do all these things. So providing more tooling around that to make that more easy, because microservices are definitely, like, that's the way the world is going. Apps are getting more complicated. Like, StepZen's purpose is to, like, integrate multiple data sources, and maybe those data sources will even come from, like, products within your own company that are just written in different languages or deployed in different places.

00:55:01 - Greg Schier

So, yeah, those are the sort of the things that we want to make easier for people, because right now, they're way too complicated.

00:55:08 - Anthony Campolo

Cool. Yeah, no, I love that. I've been going a little bit down the microservices rabbit hole myself recently, and it's definitely not, like, the easiest thing to kind of get your foot into. So it's great to hear that it's a problem that you're tackling.

00:55:24 - Greg Schier

Yeah, yeah. Keeping all this stuff easy. I think the interesting thing from our demo today was, like, we integrated a lot of things and we didn't write any code.

00:55:35 - Anthony Campolo

And I think, yeah, I was seeing a lot of code. Yeah. Except that little bit of StepZen code. Just a tiny bit.

00:55:40 - Greg Schier

And it's cool because, like, when you're deploying an app, like, you don't want to. Like, if you're starting a company, you don't want to have to write any code that's not specific to your business. You don't want to have to, like, write code to deploy servers or to manage servers or to, like, spin up databases or do, like, GraphQL bootstrapping. Ideally, everything that is not specific to you is just provided out of the box from a tool. That's what we're working on. That seems like what StepZen's working on. That seems to be the way of the future, and we're just trying to get there.

00:56:15 - Anthony Campolo

Awesome. This is going to conclude our stream for the week. Join us next week, same time, noon. We'll be doing these every week, and so stay tuned on the StepZen Twitter or Discord to hear about what that will be. And, yeah, we'll catch you guys next time.