Deploying Railway Applications with StepZen
Greg Schier from Railway discusses deploying databases and applications easily, demonstrating integration with StepZen to create a unified GraphQL API
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 and 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
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 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 was playing with a few ideas, but one of them that I wanted to do was build 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 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 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 a very built-out GUI and all that kind of stuff. But I really liked the simplicity of Insomnia, in 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 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 backend pieces just as simply as you would deploy a frontend web application. That's going to be some of the stuff that we're going to get into here. I would be curious if you had done much DevOps infrastructure-type stuff before Railway, or if this has been more of a learning experience for you, getting deeper into all this AWS stuff and 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 that space between the front end and the DevOps, building out the part that's written in Go. So, like, scheduling, building Docker images, and right now I'm working on rollbacks. So, like, snapshotting the Docker image, storing it in a Google Cloud bucket, and then...
00:05:01 - Anthony Campolo
That's kind of silly that you wouldn't consider that DevOps. To me, that's, like, the most DevOps-y thing I could ever imagine: scheduling Docker containers.
00:05:07 - Greg Schier
I would consider DevOps more to do with servers and setting up networking and basically everything that doesn't really involve the application code. I'm sort of at the far end of the application code that's right by 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 midground 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 got that appreciation for easy deployment systems. But we also had to scale a lot. Like, we'd be doing 100,000 requests per day, and we'd get a big customer that comes on and 10x 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 funny. I just tried to set up a Kubernetes cluster for the first time this last week because 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, hey, you should 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 kind of a certain aspect of it. 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 boundaries of what my role is and 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 expected things for me to do, especially because I'm not someone who really gets that deep into the actual Redwood code base. So I always look at what are these other things happening in the ecosystem that we could synergize with. So 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 kind of collating all those different opinions into something that can be canonical. And 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. We want to get into Railway here. So let's go ahead and get us looking at the Railway homepage. And I also wanted to 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 gist 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 already logged in right now, but...
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
Just so people can see that, let's take a look in incognito. It would look like: get started right there. Log in. You can do an email, you can do a GitHub. So I'm pretty sure I just synced my GitHub to it and never had trouble with auth. It 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 of example projects already going. 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 a minimum cost. Like, it's $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 sort of 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 live out in the wild. I want people to actually be able to see them. So I upgraded, and I've got a handful now, but it's been very much worth the money. And it sounds like with the adjustments you're making, you're going to 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, is because some people get really uncomfortable kind of building on these VC-funded type of operations. And it's not so much about wanting to build this whole company on this one specific provider so much as wanting to provide the option 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 build this huge, ridiculous infrastructure. So having this kind of simple entryway on a free plan, I think, is so valuable, and it's why I'm very comfortable constantly promoting these types of companies and these types of projects.
00:12:29 - Anthony Campolo
I do think it's 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, right? Looks like we've got a couple different things that we can do to start off. So we could do...
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 I think 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, and so you can just choose Postgres, and it's going to have some little funny jokes under there as well if you pay attention. And so 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 sort of shows you how to 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 basically connect it to your production environment, but also your development environment. So usually, 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 there will be a database available 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. And then we also have these project variables as well. This is going to be very useful for any time 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. So 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-5. So 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
Gotcha. So they also have the same kind of terminology of US West or US East, because it's the region that you're actually hosting in. So this tells me that my database is literally physically located in the United States somewhere on the West. So 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 now, because 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 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 meantime, you just want to figure out some way to stick a CDN in front of your application, which there are, of course, many, many, many ways of doing that.
00:17:14 - Greg Schier
Lots of 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 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 bill based on if you have a really intense CPU-based app, then you can see your CPU going up and down. If maybe 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 a very limited amount of memory. So yeah, that's the metrics now. Very basic, but also useful.
00:18:43 - Anthony Campolo
Awesome. And 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, and it is a kind of big part of my story, is that my boot camp, I say, is mostly a front-end boot camp that was kind of sold as a full-stack boot camp. I felt that it was almost entirely React, JavaScript kind of based, and then there was, like, one month of back end that had one week of databases in it. So I don't 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
So 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. So literally, I can just grab this whole guy, and we're going to tear down this database right afterwards. So even though we're showing my password right here, don't worry about that too much. And 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 we want to insert a couple more in, and then we want to select star from post, 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 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 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 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. So we're getting there. So first off, let's just go ahead, and 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 wanted 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, it 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 this 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. And 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 basically to delete all your migrations and start over. So 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, because I thought that that would be really valuable if you could avoid all this weird transition from a SQLite to a Postgres. And 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. And so 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. And then you've now shown me ways to do this even more nicely 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 automatically injecting your environment variables to connect to your database, automatically launching a PSQL process so that you can connect to your database without having to copy that big string or expose your password to the world. But yeah, we've been just making it more and more useful. So we have this concept of Railway environments, which before in the CLI you could only be on one environment at a time. So right now we're working on the ability to run a command, like a one-off command for a specific environment. Say you want to migrate your Prisma database on production, but you're currently active in your development environment. Well, you should be able to run something like railway run --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 giving the user a little bit more control, I guess, over 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 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'm usually just running 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 ClickOps. 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 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 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 hesitate whether to show someone to do something with the dashboard or the CLI, because which one's going to be better is going to kind of depend on...
00:27:20 - Anthony Campolo
...how much they know about working with a CLI, how easy it is going to be for them to get it installed and 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 one thing to touch on there, and this is something I focused on a lot with Insomnia as well, is something called progressive disclosure of enhancement. So basically, 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 very simple, like you said, for the novice user. You don't have to 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, maybe, like you said, you're working with a team, you want to write some setup scripts, some bootstrap scripts, some deployment scripts, well, then you can go fetch the CLI and get all that done as well. 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 to check our version number here, 0.2.40, which is the most recent version, I believe. And then you can run Railway login, and 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 if you're more security-minded, and 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 trouble with the login, so you need to run it through the browserless 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 an empty project. Actually, we're not going to do this, but let's just take a look at some of these because you have a ton of starters, right?
00:29:57 - Greg Schier
Yeah. And this is something that Faraz has been working on a lot, just getting different starters running on Railway, and they're all in a GitHub repo right now. And we've also been adding... like, we have one for Coder, we have one for 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, kind of like a Discord bot. 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 I didn't know about before. I was like, oh, cool. Umami is at the bottom, which is an analytics thing, and I was like, I'm going to try this out just because it's one click.
00:30:42 - Anthony Campolo
Yeah, I've been slacking. I've been meaning to create a Redwood one for these. It won't take me very long. I just got to sit down and do it. Okay, so let's go back now, and we're going to initialize an empty project, and let's call this GregStream. And 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 what plugins you're going to look at next.
00:31:34 - Greg Schier
Yeah. So I've only joined Railway about five months ago, so all these plugins existed before I came on board. But when you go to add a plugin in the UI, there's an option to request a plugin. So we have a giant list of all the plugins that have been requested, and you can see, yeah, LevelDB, the most popular one right there. But then you can just request things. And so we've got a giant list of to-do for plugins, basically. One of the ones that I've actually been working on, just a little bit passively, is one for MinIO, which is basically a tool that gives you Amazon S3 functionality but hosted yourself, like S3-compatible storage. So running that on Railway would be pretty cool, because then you don't need an Amazon account to store or host big images or videos or things like that.
00:32:29 - Anthony Campolo
Yeah, that's really interesting.
00:32:30 - Greg Schier
So those are the types of things that we're trying to add as plugins.
00:32:32 - Anthony Campolo
Yeah, I like that idea of slowly exposing more and more of the functionality of these underlying clouds because you're hosted on GCP, as you say, so you have 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? 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? What kind of guardrails do 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 a really interesting, really wide-open 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 get an entire Postgres database spun up and provisioned that quickly is so nuts. It used to take so long to do this kind of stuff.
00:33:31 - Greg Schier
Yeah, yeah. Waiting for anything is the worst.
00:33:36 - Anthony Campolo
Yeah. 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 it some seed data, and then read that seed data back. And then we can also do some PSQL commands to take a look at our database or describe our database. And the all-important command you must know is, of course, how to quit from PSQL.
00:34:13 - Greg Schier
Do you want to talk a little bit about what we're building as well?
00:34:15 - Anthony Campolo
Yeah. So now we're going to actually get into the real project here. And 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 I don't think you had used this before. I kind of suggested this, right?
00:34:40 - Greg Schier
Yeah. 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 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 sorts of databases. This is kind of an example of the real power you get from good GraphQL tooling, is that it gives you the ability to essentially point this tool just at a database and then 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
And so 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. And so there we can see what we have already written into our database. So 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. So 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 following in the background, watching them do for literally a year now, and it's really exciting. So if you want to do a Mongo database in addition to a relational database, that's something you can do with Railway. And it's really cool that 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. It seems like Postgres is kind of the database of choice, which is great if you're working with Postgres, but not everyone is working with Postgres. 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?" I don't think so.
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 probably what they mean.
00:37:56 - Greg Schier
So Railway doesn't allow you, or doesn't suggest relying on the file system, because a new deployment could be deployed on a totally different server and your file system wouldn't be there. This is very similar to how Heroku works. They call it an ephemeral file system. We are trying to figure out how we can do attached storage, essentially, to your Railway apps.
00:38:21 - Anthony Campolo
Yeah, because once you've got storage, you can just put whatever and do whatever with it. And that's where you can kind of do these weird hacky things that smart people ask about.
00:38:29 - Greg Schier
Yeah, things like even WordPress. If you want to host WordPress, it relies heavily on the file system. So if we want to be able to allow people to host WordPress or even Ghost, we allow 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
Nice. 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 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? So shameless advertising here, but that's what you signed up for. We are going to now take this endpoint and pipe it into a StepZen project. And so 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. And then one last thing that 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 can 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 localhost. Clear that, and then run 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 wanted 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 it's insanely useful. Yeah, yeah. So why don't you talk a little bit about your experience with it 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 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 maybe Stripe webhooks or whatever at your local environment to 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, and 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 into one single unified GraphQL endpoint. And so this whole workflow of 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, and I've found that's one of the things that makes GraphQL tooling really nice, because as long as everyone knows what your endpoint is and 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 an 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. And so if we add @graphql at the end, then we actually get the data back. So 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... oh, because I already... this is a 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 kind of 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. So 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 kind of 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 it, 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 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 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 a single tiny schema like this. You're going to have lots and lots of files with lots and lots of different schemas for users and for posts and 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 would 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 a 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. And this also shows 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 we've already tested this endpoint and we already know the endpoint works. And so 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've 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've 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. And 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'd want to make sure that you're masking that from the client with some sort of 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
Yeah. And it was all possible thanks to the magic of Railway. And getting that database set up really, really quickly, 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. So 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 frontend very easily with something like Vercel. And all of a sudden, you start having these full-stack applications with all these different kind of Jamstack tools. And some people may call it full-stack Jamstack, although who knows who would ever use such a term? Certainly not me. All right, cool. That is pretty much the whole project we wanted to show here. So is there anything you kind of want to talk about about Railway, other things that you think people should know about, or 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... 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. So yeah, continuously getting better and better.
00:50:37 - Anthony Campolo
Awesome. Yeah, and I've been watching this kind of progression as I've been using it over the last couple of months, and I've just noticed lots of little, small things you're constantly adding to the CLI and little tweaks you're making to the UI. So I'm seeing that kind of 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. And it's really great. I really enjoy finding these kinds of 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. And the more we can kind of align on ways to do that and workflows that work well, it's really awesome. And then we have a question about NoSQL DBs from Lucia, and that would be an example of Mongo being 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 anyway.
00:51:47 - Anthony Campolo
Yeah, yeah.
00:51:50 - Greg Schier
StepZen doesn't support Mongo, does it?
00:51:53 - Anthony Campolo
It 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 kinds of NoSQL options. Actually, I should correct myself. 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 too. 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 Railway. And then, oh, it 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 as I've been building out projects, any time I hit a snag, I'll post in the Discord. He responds very quickly and is very, very helpful. So having that kind of 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...
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 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 organization as well as visual polish, 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 Jake was talking to someone the other day who spun up 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 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 easier, because microservices are definitely... that's the way the world is going. Apps are getting more complicated. StepZen's purpose is to integrate multiple data sources, and maybe those data sources will even come from 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 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, and 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
Yeah. Not a single line of code, 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.