Fullstack Security with Ryan Chenkie

Episode Description

Ryan Chenkie of Prisma discusses web security fundamentals, API authentication patterns, and how Prisma evolved into a TypeScript-first open source ORM.

Episode Summary

In this episode, Ryan Chenkie, developer advocate at Prisma, shares his programming journey from picking up HTML and CSS in 2012 to working at Auth0 and eventually joining Prisma. The conversation moves into a deep exploration of web security, starting with the distinction between authentication and authorization, and how developers should think about protecting both private and public endpoints. Ryan walks through practical scenarios like guest checkout in e-commerce to illustrate when an endpoint truly needs to be private versus when treating it as public is the right trade-off. The discussion extends into rate limiting, web application firewalls, API key generation, OAuth flows, and social logins, with Ryan drawing on his experience building a full-stack React security course. The episode then shifts to Prisma itself, where Ryan explains how the tool evolved from a hosted GraphQL service into a GraphQL-agnostic, TypeScript-first ORM that provides type-safe database access, migrations, and a visual studio for inspecting data. He addresses community concerns about Prisma's past directional shifts and previews upcoming features like MongoDB support and commercial product offerings, while the hosts discuss TypeScript adoption trends and database provider wishlists including CockroachDB and DynamoDB.

Chapters

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

The episode opens with Anthony Campolo welcoming Ryan Chenkie, developer advocate at Prisma, and recounting how a previous recommendation from Ryan led to a great episode with his colleague Jason. Ryan shares his programming origin story, explaining that he first touched code around 2012 before landing his first industry role at Auth0 in 2015, followed by a stint in freelance consulting.

Ryan reflects on why he returned to full-time work after consulting, noting that working solo caused his learning to plateau without a talented team to push him forward. He describes how his long-standing relationship with Prisma co-founder Johannes eventually led to him joining the company in mid-2020, drawn by the open source culture and the strength of the product and team.

00:06:17 - The Developer Advocate Role and Empathy in DevRel

The conversation turns to what it means to be a developer advocate, with Ryan emphasizing that while technical proficiency matters, empathy is the most critical skill. He explains that sensing developer frustrations—even without being told directly—and communicating with genuine care are what separate good developer advocates from the rest.

Ryan outlines the key pillars of the role: writing, public speaking, and video content creation. He notes that developer advocacy is not a cookie-cutter position and that each person brings unique strengths to it. Anthony highlights Ryan's thoughtful approach to a Redwood meetup demo, where he specifically chose to address a known pain point rather than giving a generic presentation, as an example of this philosophy in action.

00:09:01 - Security Fundamentals: Authentication vs. Authorization

Christopher Burns steers the conversation toward security, asking Ryan how developers should approach securing their endpoints from scratch. Ryan distinguishes between two broad categories—private endpoints requiring logged-in users and public endpoints open to anyone—and explains the critical difference between authentication, where a user proves their identity, and authorization, where an artifact like a token grants access to resources.

He walks through how sessions, cookies, and JSON web tokens fit into this model, and extends the concept to machine-to-machine communication scenarios. Ryan emphasizes that even after authentication is handled, developers need to think about protecting endpoints from abuse through techniques like rate limiting and upstream filtering with web application firewalls from services like Cloudflare or AWS.

00:16:17 - Public vs. Private Endpoints: The E-Commerce Example

Christopher poses a practical scenario about guest checkout in e-commerce, questioning how you authenticate a user who hasn't logged in but still needs to complete a purchase. Ryan works through the problem live, suggesting that a checkout endpoint for guest users is effectively a public endpoint, similar to a contact form submission, where the trade-off favors conversion over requiring account creation.

This leads to a broader discussion about what truly defines a private versus public endpoint. Ryan argues that private endpoints are those where you need to know the user's identity and restrict access to logged-in users, while public endpoints are appropriate when user identity isn't essential to the operation. He also touches on maintaining cart state via local storage and using bot-detection mechanisms to protect public endpoints from abuse.

00:22:03 - Full-Stack Security, API Keys, and OAuth

Ryan discusses his React security course, which covers the full stack and emphasizes that browser-based applications have no real concept of security on their own—meaningful authentication decisions must happen on the back end. The conversation then shifts to how developers generate and manage API keys, with Ryan describing two main approaches: simple long random strings acting as strong passwords, and full OAuth flows with access and refresh tokens.

He shares his frustration with overly complex implementations like the Instagram Graph API and contrasts that with Auth0's capabilities for setting up third-party developer access. Christopher asks whether API keys are typically scoped to users or teams, and Ryan explains that keys are usually tied to an application record rather than an individual, so team members share access to the same credentials.

00:30:11 - Social Logins, Passwordless Auth, and Security Trade-offs

The discussion rounds out the security segment with a look at whether developers typically roll their own API key systems or use third-party services, with Ryan noting that Auth0's value extends well beyond simple user login to enabling full OAuth infrastructure for third-party integrations. They then debate the pros and cons of social logins—higher conversion rates but reduced control and user trust issues, particularly with Facebook.

Christopher raises passwordless authentication as a hot topic, and Ryan expresses enthusiasm for web authentication using biometrics like fingerprint readers. Anthony adds a note of skepticism about user trust with biometric data, and the group acknowledges it's still an emerging technology largely behind browser flags before pivoting the conversation toward Prisma.

00:36:11 - What Prisma Is and How It Works

Ryan explains that Prisma has officially embraced the ORM label after previously trying to distinguish itself with different terminology—a shift Anthony claims to have predicted. He describes Prisma as an open source ORM supporting relational databases like Postgres, MySQL, and SQLite, with MongoDB support on the way, that replaces raw SQL with a clean, code-based API for database access.

He highlights the full ecosystem of tools: Prisma Migrate for database migrations and seeding, Prisma Studio for visual data browsing, and deeply integrated TypeScript support that generates types to make database access type-safe. Ryan emphasizes that this type safety means developers can catch invalid database operations at write time rather than at runtime, which significantly reduces errors and development time.

00:42:20 - Prisma's Roadmap, Commercial Plans, and Database Wishlists

The final segment looks ahead at Prisma's future, with Ryan expressing excitement about reaching general availability for all core components to rebuild community confidence after the significant pivot from Prisma 1's GraphQL-centric approach to Prisma 2's agnostic tooling. He briefly hints at commercial product offerings, including a hosted version of Studio, and emphasizes that upcoming features will focus on making database workflows easier for teams working with large datasets.

The hosts share their own database provider wishlists—Christopher is interested in CockroachDB for global distribution, while Anthony and Ryan discuss DynamoDB and the possibility of deploying Redwood entirely on AWS infrastructure. Ryan closes by sharing where listeners can find him on Twitter, his React security courses at reactsecurity.io, and his Entrepreneurial Coder podcast, before the episode wraps up.

Transcript

00:00:00 - Ryan Chenkie

I'm rolling.

00:00:11 - Anthony Campolo

Ryan is a developer advocate at Prisma. Welcome to the show, Ryan.

00:00:16 - Ryan Chenkie

Hey, thanks so much. Thanks for the invite.

00:00:18 - Anthony Campolo

Yeah, it's great to have you. We've had Jason, your colleague from Prisma, on as well.

And what's funny is I'd actually reached out to you because I saw you were doing some Nexus talks. I was like, we really want to know more about Nexus. And you were like, oh yeah, sure, but really, you should get Jason on.

And it was great. That was such a fantastic episode, so thank you for that recommendation. And now we're here to have you on to talk about the stuff you're working on.

But first, let's get a little bit of your background. How did you get into programming, and how did you find your way to Prisma?

00:00:46 - Ryan Chenkie

Sure, yeah. I've been programming now for what I guess is about nine years. I was actually thinking about this the other day. My very first touch with programming in its current form was back in 2012.

That's when I was a super-noob and I just got into HTML and CSS a little bit haphazardly. I started and stopped a couple of times, trying out some basic web development stuff. Over the next few years, I started to learn it more thoroughly, but I've been working in the industry since 2015.

My first job was in 2015 with Auth0, doing some kind of DevRel-type stuff with them. Since then, I've done a lot of stuff. I've worked as a consultant doing application builds for companies, and I've created a lot of content. I've got a lot of courses out, and yeah, I'm working at Prisma now. So I've touched a lot of different areas of programming, I suppose, and I've been at it career-wise, job-wise, for what I guess is like the sixth year, even though I've been touching it for at least eight or nine years now.

00:02:00 - Anthony Campolo

Oh, that's cool. That's actually not as long as I would have expected. That's pretty cool. You've made it pretty far in a pretty short amount of time, so congrats on that.

I'm in a similar boat, just getting started with my professional journey now, but I've been kind of learning to code for a couple of years. So it's always cool when I see someone who hasn't been at this since they were a kid who's still been able to get pretty successful.

And you had worked at Auth0 before Prisma, right?

00:02:25 - Ryan Chenkie

Yep, yeah. Auth0 from 2015 to 2017. Then I went out on my own, did some consulting, and basically spent a couple of years, I guess like two and a half years or whatever, building apps for companies and doing kind of freelance consulting stuff. I had a good number of clients.

Then I was interested in going back to work at a company because one thing that's really not great about going out on your own is that you're no longer surrounded by a team of really smart developers to help you get better and push yourself to learn more and stuff like that.

What I really noticed is that my learning started to plateau as I was out on my own. I was just kind of a single developer working on stuff and having a lot of fun, but my learning was really plateauing. I wasn't learning new stuff. I wasn't developing myself as a programmer as much anymore. So I wanted to get back into the realm of a super-talented team that would kind of push me to excel.

00:03:27 - Anthony Campolo

Awesome. Yeah, I definitely feel that. For me, I couldn't really learn anything on my own. It wasn't really until I started getting together with some of the Redwood people that I started really getting to accelerate, and so that's definitely a huge thing that you need.

You need these people around you who are constantly pushing you and just saying, hey, let's go work on this project. Like, well, I don't know how to do that project. Like, well, let's figure it out then. And then you get to work through it with people. And so it's always super fun.

And how did you first hear about Prisma? Did they reach out to you, or did you hear about them?

00:03:57 - Ryan Chenkie

You know, I've known Johannes for a long time, I guess since 2016. He was back in the GraphQL days when they were getting started. That's when I was at Auth0.

He had reached out more broadly, and it got filtered down to me. I think it was about doing some kind of collaboration on content and whatnot. Then I would see him at GraphQL events every year, basically. So he and I knew each other for a while, and he reached out to ask me if I would have any interest in coming to work at Prisma.

That was a little while before I made the decision to go back to a company after consulting for a while. So it took a little bit of convincing, but it was very much the case that if I was going to make a jump back to it, Prisma was the right spot to go. I really love what the company is doing. I love the open source nature of it. The product is great. The people are awesome. So it made a lot of sense.

He was able to strong-arm me into coming to work at Prisma, and that was last year. Yeah, now we're in 2021, so that was 2020. That was, I guess, the spring of 2020, and then I started there in July. That was my official start. It was the beginning of July last year.

00:05:20 - Anthony Campolo

Yeah, that makes sense because you had spoken for a Redwood meetup, actually, and this was toward the end of, it was like September or October, I think. And you had been working there for about three months or so, so yeah, that all tracks.

And what you did, I thought, was really cool. You did a demonstration of how to do relations with Prisma. And what I thought was cool about that is that you didn't just show up and do any old demo. You picked a specific demo that you knew was a pain point with Redwood developers, something we would be interested in seeing and learning. I thought it was really cool. I thought it was very thoughtful.

And you didn't just go and say, I just want to show you some Prisma stuff. And I think that shows the kind of thoughtfulness that a good developer advocate has because we've talked about the role of a developer advocate, what exactly it means, whether it's more community, whether it's more content creation, whether it's more tooling, or whether it's a combination of all of them. So how do you think about that role and what your responsibilities are?

00:06:22 - Ryan Chenkie

Yeah, I appreciate the comments. Thank you.

It's an interesting role because you've got a lot of hats that you've got to wear as a developer advocate, right? There's, of course, the need to be proficient in programming to some extent. Maybe, arguably, you don't have to be the most super-talented engineer working on super obscure stuff to be successful as a developer advocate. At least I'm definitely not the most talented engineer there ever was.

But you've got to have some proficiency, of course, with being a developer. I think one of the biggest aspects of it, too, that goes way beyond that is being able to have a lot of empathy with people in general, but especially with developers out there, because much of the role is understanding the issues that people come across, maybe even being able to see issues that exist without even being told explicitly what those issues are.

So if people are frustrated with a product or frustrated with an open source library or something, what have you, it's great if you're able to sort of sense that without necessarily being told that there's an issue, right? I mean, you can go cruise through GitHub issues and see that there are problems with libraries, but being able to get a sense of that just through chatter online.

And not only that, but also being able to speak to that crowd in an empathetic way, being able to communicate with them in ways that show that you care about what they're going through. You care about the struggles that are happening, and you want to support them. I think that's a big part of it: this desire to support people to be successful in their endeavors with whatever they're working on. So that's kind of the, I suppose, maybe call it the emotional side of it, if you will, in terms of the skills that go into it.

I mean, it's a lot of stuff depending on what you're focusing on. But it's a lot like writing skills, doing talks, so being able to give a public talk, and also being able to do video stuff. Those three things, I see as some important key pillars of the job. And if you wrap all that up and you've got the kind of interest in it, then I think you've got a case for being a developer advocate.

That's at least one way that I look at it, but it's certainly multifaceted. There are different areas of specialization, too. Yeah, one thing about it is that I think it's kind of unique too. It's a job where whoever is in the position of being a developer advocate brings a lot of uniqueness to the table. It's not like a cookie-cutter role so much, right? It really relies on a lot of uniqueness that the individual brings to the table. At least that's what I've experienced myself, too.

00:09:01 - Christopher Burns

What I understand is you first worked with Angular and then moved to more React, and now you're with Prisma. That's more of a backend company, but one of the threads I've seen that kind of goes through all of them is security.

Security is something that we all can struggle with sometimes, to truly understand the scope of it and how important it is. And it can always be put on the back burner to make better another day. But it's one of those things. If I was going to take it in steps to go from a completely open backend or unauthenticated frontend, what would you say the first steps are to slowly make it more and more secure, almost like test coverage? What's the most important thing to do first to make something more secure?

00:09:52 - Ryan Chenkie

Sure, yeah, that's a great question.

You've got to look at the context of what you're building, for sure. So the question of how do you start making an endpoint more secure, let's just say an endpoint, depends on what it's doing. Maybe there are two broad cases.

There are endpoints that you would want to limit access to so that only, let's say, authenticated users can get access to them. And that's the case of an application that uses these endpoints where you have to be logged in to the thing to make use of it. There's that bucket.

And then I think there's another bucket, which is like you've got an open endpoint where it's a public API or something like that, or otherwise you are calling that endpoint through an application where the user doesn't need to be logged in to use it. And so there are two ways that you might approach it to begin with.

And so I think broadly, if you're taking the approach of the endpoint for a private application, you've got to be logged in to use the thing. The first thing you need is a way to authenticate requests to that endpoint. And what that looks like is you need to be able to tell something from the HTTP request that comes to that endpoint as to whether or not the user, or service, or whatever that's calling that endpoint should be allowed to get access to it.

One of the easiest ways to think about this, and it can get very broad, is to think about a user logging into an application, and then they want to do some things in it that would make a call to those endpoints to get data back. Let's say where you start generally is you want to authenticate a user. You want to get a user authenticated in the application before they can do anything. So this is where it's good to look at the difference between authentication and authorization.

Authentication is when the user comes to the application and they are able to prove that they are who they say they are. In a typical scenario, that would happen at some point in time, and then there would be some kind of setup in place. This could be many things. It could be cookies and sessions or JSON web tokens. There would be something in place such that requests to that endpoint would be authorized.

So this is the other auth step: first you do authentication, and then you have to do authorization. Authorization is different because it is not the user proving that they are who they say they are every time they ask for information. Rather, it's the user supplying some kind of artifact along with their request so that the endpoint can make a determination that the user is authorized to get access to that data. Let's say that's a typical setup with a user.

And you expand this out to various other scenarios where maybe it's services making calls to another service, like maybe you've got a backend that runs on a schedule and it needs to make requests for machine-to-machine communication. So it's not quite like a user calling a service, for example. But in any case, if you've got an endpoint that needs to be protected so that it only releases information to someone who's allowed to use it, you kind of need to start there.

If you're taking the other bucket, where it's a public endpoint and you just want to kind of secure it, make it robust in some fashion, you start in a different direction. But this direction also applies, I think, to the private endpoints.

Once you get past that initial setup phase of having authentication and authorization in this scenario, really what you want to do is a few things. You want to make sure that your endpoints aren't going to be abused. So what does that look like? You could have people writing scripts that would just be pinging your endpoints endlessly, and so they're trying to carry out some kind of denial-of-service attack on you. And there's lots of reasons why someone might do that.

It could be just because they don't like you or your application, which is definitely one reason. Or it could be trying to disrupt your business so that you're not going to succeed or whatever. There are plenty of reasons that people may want to do something like that.

00:13:56 - Anthony Campolo

It could be a foreign actor, right?

00:13:57 - Ryan Chenkie

Foreign actors, yeah. It could be political stuff. There are all sorts of reasons, and it's a very real thing. This happens to people every day. There's no shortage of these kinds of attempts being made.

And so in those cases, what you're looking to do is protect your endpoint in various ways. One thing you might want to start with is rate limiting. And so rate limiting kind of looks at the number of incoming requests from a specific IP address, let's say, in a given time span. And if it exceeds some threshold, you'll want to start to deny those requests.

So rate limiting helps in the sense that you won't be giving up information from your API if you've determined that the user is probably a bot or a bad actor or something. You can stop your API from releasing information to the user. One of the issues, though, is that depending on how your rate limiting is set up, let's say it's set up just at your application level, you're still going to incur the cost of receiving and processing those requests, even though you've put some kind of blockage in place.

So what you want to do is really move that upstream. And so what you would want to do is start to completely block, hopefully you've got a setup that can do this. If you're using something like AWS, this is fairly simple to do with firewalls.

Essentially what you want to do is put some kind of web application firewall in place, something that can look at the incoming requests outside of your application layer and determine whether or not it should pass that request through to your endpoint. So if you use Cloudflare or AWS, you can deal with that traffic outside of your app. And if you want to bounce that traffic, you can, and then your application layer doesn't need to process the request.

So those are pretty big things that apply both to public APIs, but also your private APIs, even if you've got authentication in place, because a bad actor could get a token which would allow them to authenticate with your API, and they could be trying to just get as much information as they can from that endpoint or something. And they could be sending plenty of requests. It would be unreasonable to expect that many requests from a regular user, so you want to put that kind of protection in place there too. Those are some of the broad things. Any more specific things you want to look at with those two, or what do you think?

00:16:17 - Christopher Burns

Say you've got a public service that you want authenticated, for example checkout. You want the guest who hasn't logged in to be the only one to call the private APIs to complete checkout, for example.

How would you do that in your sense of security? To me, it seems like the best way would be to first call an API to get a hash or a key, and then every time that user calls the more private APIs, they would then ask for that hash. But I don't know.

00:16:51 - Ryan Chenkie

Let's play this scenario out a bit. What's the scenario? So there's a private endpoint or a set of private endpoints. What would those be responsible for?

00:16:58 - Christopher Burns

Take an e-commerce example. So you have a guest who's not authenticated, as in logged in, but they need to hit, say, private endpoints like complete checkout, view order, this thing. How would you authenticate them on a private checkout if they've not done any authentication necessarily?

00:17:19 - Ryan Chenkie

I guess it depends on your application's needs and everything. But there are a couple of ways you could hit that.

And I've never implemented this whole flow myself, so I'm speculating here, and this is just me thinking off the cuff as to how I might do this. But in a guest checkout scenario, I think typically what you want for an e-commerce setting is you want to have the shopping cart state be retained even if a user is to leave and then come back.

So let's say they haven't authenticated because they don't have an account and they want to check out as a guest. They've got items in their cart. They close the browser tab, they come back, and we want to still show those.

So a couple of ways to do that, right? You can keep some state in local storage, in browser storage. This is information that is not really private stuff, right? Cart items aren't necessarily something that, for the most part, is going to matter if somebody has a cross-site scripting attack that's going to see what's in your local storage. That's a whole other subject. But in this case, probably not a bad idea to have cart items in local storage so you could maintain state that way.

And then when you go to do the checkout, I'm thinking of a typical flow at checkout. If you're a guest, you've got to provide your email address and your other stuff, and then when you go to pay... To me, just thinking initially about this, I don't know if buying or purchasing necessarily needs to be a private endpoint.

I think that's probably a public endpoint that takes in a payload with all your particulars from your form, email address, the items and price and all that stuff. You'd want to protect that endpoint such that it can't be easily abused. You might want to have some kind of, not necessarily a reCAPTCHA, but something that works to the same effect, something that can say this request came from a browser.

Looks like it's a legit user, not a bot trying to hit the endpoint with a fake credit card number or whatever. I mean, of course, you're going to do your credit card processing and verification and hopefully offload that to Stripe so that they can determine if the card is legit or not.

But yeah, to me, just thinking about it initially, I don't know if that's a private endpoint necessarily, the endpoint to purchase things.

00:19:36 - Christopher Burns

And I think that brings it to a really good security question: what is defined as public and private? Because in my head, I would think that almost every mutation would be a private endpoint that needs authenticating.

But what you're saying is actually some mutations are okay to be public mutations, like checkout.

00:19:55 - Ryan Chenkie

Yeah, and that's because in this scenario, we're accepting the fact that we're making this tradeoff that says we care more about people completing their purchases than we do about them having actual accounts with our service.

Therefore, let's treat this purchasing experience kind of like a contact form on your website. Let's say with your contact form, the endpoint that might be hit to submit that data isn't going to be a private endpoint. It's going to be public because there's no user session to speak of. So in that way, the guest checkout experience is kind of like just submitting data through a contact form.

We're just accepting the fact that we're going to get some user info, like their email address and their name. And in this case, instead of a message in the contact form, we're going to get their credit card number, let's say. I think that's largely a public endpoint. But back to your question, what separates them? What's public and what's private?

I think of private endpoints as ones where, to start with, it's any kind of endpoint that would be hit when you build an application that should only be accessible by logged-in users. So when we want the user to have to be logged in to use it, basically it's like you want to prevent usage by random people. You want to be able to know who's using your thing.

And something that gets kind of built in through that whole effect, that gets interwoven, is the fact that when you hit an endpoint as a logged-in user, a private endpoint, most often you're going to need to supply identity information about the user, like a user ID to say, when I make a mutation, save it with this user ID or whatever.

That's often going to need to be supplied along with your request. So you kind of have this interwoven fact of identity being part of the private experience. In cases where you don't care that the user is logged in, I think that's where you opt for the public thing, roughly speaking. I mean, that's a generalization, but that's kind of how I think about it.

00:21:52 - Christopher Burns

The reason we ask these security questions is because you've actually written your own course about security and React. Does it cover just the front end of security and React, or does it also cover the back end?

00:22:03 - Ryan Chenkie

Yeah, it goes into the full stack. It basically shows you how you would deal with security in the full-stack context and why, when we're thinking about security and auth within a React application, you really need to involve the full stack for it to make sense.

00:22:21 - Anthony Campolo

And what is the back end in that course? Like what database and what server are you using?

00:22:26 - Ryan Chenkie

Yeah, it's an Express API, so Node, and it is a Mongo database that we use. This was pre-Prisma, when I made that course. So nowadays, if I were to rerecord it, I'd probably just use Prisma on top of Postgres. That would be what I'd go for.

But yeah, it was Mongo. And the database, it's really just kind of a detail. The super important part that I draw out in the course is that when you think about your frontend, you've got to keep in mind that there's no real concept of security in a React application. There are ways to sort of give hints that your users might be authenticated in your application, but there's no way to know for sure.

And that's because React applications run in the browser. Or if you're doing React Native, they run in a mobile environment. But the point about browser-based application security is that you need to involve a backend for security to make any sense at all. Because it's on the backend where any kind of determination about an authentication state for the user can be made. That's the only place where it makes sense to do that.

Browsers are public clients, and they need to be treated as such. You need to just expect that nothing can be trusted. Essentially, that's what it comes down to in the browser.

00:23:49 - Christopher Burns

Part of it's a free course, and part of it's more of a paid course. It was done last year, so it's still quite relevant today.

And also, what I understand is it's not necessarily about the frameworks or the databases it's using. It's the patterns. That is what you mostly take away from it. One of my final security questions that I always think is interesting to know is: how does one go about making API keys to give to people? You have a user, but now you've added an API to your service. How do you authenticate an API?

00:24:25 - Ryan Chenkie

Yeah, that's a good question.

I think there are kind of two patterns you see with this. You'll find services. So let's say you're making an application. Part of it is an API, and you want third-party developers to be able to use your API to tie into your service somehow.

The typical way you could do it is you could have a spot in your backend, or within your user interface, where it says, give me an API key because I want to tie into the service. So typically when you get an API key like that, you've got some kind of app ID, let's say, which is supposed to be treated as public. And then you've got another thing which is like your API secret or whatever. Sometimes they're just in one single key; it doesn't have to be split out into two. And so with that, that's typically the, let's call it an API secret key or whatever.

It's a long random string of characters. You probably want to make sure it's URL-safe, so you don't want to have certain symbols in there. Typically people would just have letters and numbers. Give it a length of 64 characters, make it random, whatever. Hopefully use some kind of library that helps give you pseudo-random generation.

00:25:39 - Christopher Burns

Like Nano ID is one that I always see pop up.

00:25:42 - Ryan Chenkie

Nano ID, okay, I'm not familiar with that one, but something like that where it focuses on generating something that approximates true randomness. Because for those unfamiliar, it's actually very difficult, if not impossible, to actually produce random things with computers. So that's the idea.

You just give it, and so what it becomes is it's just a super-strong password, essentially, right? Your third-party services are calling into your API, and you're just relying on them producing a really strong, unguessable password and then just sending you that password every time to authenticate.

The other way to do it, which a lot of services use these days, is to have a whole OAuth setup. So a third-party service would need to authenticate through the OAuth protocol with your API before it can actually get access to it. And this requires a lot of steps, and often you have to initially get a code. Like if you're going through the code flow, you have to get a code. And then you send that code to another endpoint to produce a token, and then you have to store that token. The token is only valid for a certain amount of time, so you have to have a refresh token, which you're going to store somewhere and use to refresh the access token. And so there's a big, complicated flow.

And some services make it stupidly complicated to actually do what you want to do. One that I was frustrated with recently was the Instagram Graph API. I was looking to just get a list of recent posts on Instagram via the API, and figuring out actually how to do it through the Facebook Developers portal was just a nightmare. Anyway, there are a lot of services that will do this much more easily for you, but Facebook is not one of them.

So you've got two sort of approaches. I think generally OAuth, you can consider that more secure because you have a proper authentication flow in place, access tokens only have a certain lifetime, etc. Tons of security things to think about in that scenario, but maybe arguably more secure than just a super-strong password, which is the other variety.

00:27:45 - Christopher Burns

When you think about, say, a super-strong password, let's take Stripe as just the example. One of the ones it gives you is a secret key that you know is very secret. Don't give it to anyone because it allows you to use Stripe.

This is a question that I don't necessarily know: when you make a key, is that key to a team normally, or is that key to a user as a JWT token? Because a JWT token and a string of random letters are very different things that give you very different types of data back.

00:28:15 - Ryan Chenkie

Yeah, and a JSON web token extends beyond just thinking about a user as an actual person, like a human user. It also can be tied to a machine that is making calls. It can get very granular. It can be tied to, say, a specific channel within a Slack organization, something like that, right?

So when you generate a key, I forget how it looks in Stripe. I haven't been in there in the developer spot in a while, but I think generally for a lot of these services where you go in and you're like, hey, give me an API key, I need to make a call to your API, it'll be for an individual user of that application. Let's say you have some kind of team login.

I think it's going to be the case where all three of us, let's say we're on a developer team, we all use this service, we want it to give us an API key, we're probably all going to see that same API key if we log into that service. And then any one of us could copy it over to the spot it needs to go.

In that case, it's more like an API key is going to be associated with an application, I guess you could call it, or some kind of record that you create within that application where you say, hey, I've got a third-party service, it's called Foobar application. We're going to have our users do this with it. I need an API key for it. That's kind of the model I think that most people go for.

00:29:46 - Christopher Burns

Do you tend to see user authentication? A lot of people tend not to roll it themselves these days. They use Auth0, Netlify, even Magic.link is a new one that's popping up a lot.

But really, like API keys, do you tend to see that a lot of people would just run their own system, where it keeps the key in the database, or do they also use third-party services to generate those keys a lot?

00:30:11 - Ryan Chenkie

Would that be the case if you are creating an application and an API, and you want to enable third-party developers and you want to have some way to do that? Yeah, that's interesting. It's a good question.

I don't know of a service necessarily that would do that, so I guess we have to look at both sides of it, though. If you just want the super-strong-password variety, I don't know of any services that are built just for that because I think it's such a small scope, really. You need a library that's going to give you a good password, and you need to follow best practices, etc.

But if it's for the OAuth setup, that's actually what Auth0 specializes in. A lot of people think about it as, hey, I'm building an application, I need to give a way for my users to log in, so I'm going to drop in Auth0. That's definitely one way to use it. But a whole other way, which maybe people would get even more value from, is that Auth0 is a great way to say, hey, I've got an application and I want third-party developers to be able to make use of it. I need to provide the whole infrastructure and rules and all of that for people to be able to do the OAuth transactions that need to take place to allow them to hit my API.

In that way, you can set up your whole third-party experience within Auth0. That's going to solve that OAuth scenario for you. For the other scenario, what comes to mind initially for me is that I just need to find a library that's going to give me pseudo-random password generation.

00:31:43 - Christopher Burns

It's always interesting to know these things because you're a developer in a business and they go, okay, we're making this API. How do you even think about the security?

It's always such a hard question. Where do you even go to read about these things? Stack Overflow. Well, it's interesting you bring up Auth0 because Auth0 is a lot more than just user logins, because I think user logins are always the first thing everyone would do with Auth0.

The other interesting subject is social logins, and whether you necessarily think they're good things or bad things, because I always think they're a bit of both.

00:32:25 - Ryan Chenkie

You think they're good and bad.

00:32:27 - Christopher Burns

So why say good and bad? I think conversions tend to be higher because they just click login with Facebook or Google on public applications, but then you're also losing a lot of that control when it comes to the structure of your login process, passwords, usernames, and all the other things.

00:32:46 - Ryan Chenkie

I definitely see the side where it's bad there. The good points of social logins would come down to not having to build your own authentication stuff yourself. You can defer to Facebook or Google or whatever. And I think a lot of the benefits there are that you don't have to worry about your passwords getting breached. That's a big thing.

On the flip side, though, if you're going to do just username-and-password authentication, which I mean you probably, I guess, shouldn't in this day and age, there's not a great reason to solely support usernames and passwords. You should probably do something else. The process of doing that yourself, as long as you follow the best practices with it, can be decently secure. You need to make sure that you're hashing, salting your passwords, and doing all that sort of stuff. And there are libraries that, depending on what framework you're in and what language you're in, will do all that for you. So it's not a big deal, really. I don't think it's a big deal to do it on your own.

So arguably it's more secure with social because you offload all of that stuff to the provider. I think the benefits, as an application developer, of using social are that you get profile enrichment for your users. You need to ask them to consent to give you certain pieces of info, but as long as they do, you can build a bigger picture of your users and be able to, I don't know, sell them things more easily or something like that. So there's that.

And then I guess the downsides for me would be that people don't really like some social providers these days. Of course, Facebook comes to the top of my mind, but I don't know if trust is being lost in a lot of them. I don't know if you'd find anyone that is wary of logging in with Google because they're upset at Google for something or another, but maybe it is a thing. I'm not sure. I don't have a lot of the pulse on that.

I do know that because I'm not a big fan of Facebook, if given the option, I will generally never log in with Facebook.

00:35:02 - Anthony Campolo

I think you'll find people who feel the same way about Google, or feel the same way about Facebook, or feel the same way about both of them. So it kind of depends from person to person.

But while we've still got you here, I really want to get into some Prisma stuff. So let's kind of close this out. Is there anything else you want to hit on there? Burnzie, are you good?

00:35:18 - Christopher Burns

Just a hot take. It's a yes or no: passwordless logins.

00:35:22 - Ryan Chenkie

The future in some form? I think so. I'm really keen on web authentication, where you use a fingerprint reader and you're immediately logged into a website.

00:35:32 - Anthony Campolo

Yeah. If you think someone's afraid to give Facebook their password, imagine giving Facebook your fingerprint.

00:35:38 - Ryan Chenkie

Yeah. No, you wouldn't give it through Facebook.

00:35:40 - Anthony Campolo

The user doesn't know that though. They don't know the difference.

00:35:43 - Ryan Chenkie

Yeah. I'm curious to see.

00:35:46 - Christopher Burns

It's a super new thing.

00:35:47 - Ryan Chenkie

Yep. Super new.

00:35:48 - Christopher Burns

It's still behind a lot of Chrome flags as well. But in essence, what it is, you type in your email address and then click the fingerprint icon. Then put your finger on the fingerprint scanner, and now you're logged in. Obviously super-new technology that's still in development. So yeah, Prisma.

00:36:11 - Anthony Campolo

Let's talk a little bit about just what Prisma is. First of all, I think a lot of our listeners are already gonna know it's really a key pillar of FSJam, but I'd be curious to hear how you describe it today, because you guys have been a bit fluid in how you describe it.

00:36:24 - Ryan Chenkie

Yeah, for sure. We've kind of reverted back in our description of it because we used to call it an ORM.

Then there was, I guess, reason to maybe not call it an ORM, just based on some technical details, I suppose, of Prisma. But what we came to realize is that it's an uphill battle to try to describe something to someone in terms that they're not familiar with.

00:36:50 - Anthony Campolo

When you were at the Redwood meetup, actually, I had asked you, when is Prisma going to admit that they built an ORM?

00:36:57 - Ryan Chenkie

There you go. Yeah, that's right, that's right.

00:36:59 - Anthony Campolo

At that point, you hadn't done it yet. You hadn't made the switch yet. But I was sensing it. I was sensing it. It was in the air.

00:37:05 - Ryan Chenkie

We've made the admission. Yeah.

So Prisma is an open source ORM that gives developers a really clean API, a really clean way to access databases. Right now, at the time of this recording, it's all relational databases. So there's Postgres, MySQL, SQLite. I think I might be missing one, but I'm not sure. But support for Mongo is on the way. It's on the roadmap and it's actively being worked on.

And so what does that look like? What does that translate to? It's like if you want to access a database from a backend, let's say in Node, currently we support Node and Go. But if you want to do it in Node, instead of writing raw SQL queries like select * from table, where, etc., instead of doing that, you'll go through Prisma, which is basically you write a bit of code to do that. And the way that looks is that you start with a model. You start with a Prisma model.

So Prisma not only gives you this API for accessing your data, it gives you all the tools you need for managing your databases in the first place. The Prisma model gives you a way to describe your tables in your database.

And then we have products like Prisma Migrate, which allows you to run migrations on your database, put your tables in place, seed them with data if you want. And then we've got other stuff like Prisma Studio, which allows you to view your database. It's like a TablePlus alternative, for example. It runs in the browser or in an Electron app.

We've got really intelligent things that surround all of that, like IntelliSense. It's all TypeScript. You get generated TypeScript types, which means that your database access is type-safe. And what that translates to is that it becomes very difficult to do something with your database that is invalid. That's a big reason I really like it. So at the time that you write your code, you can be pretty certain that what your code is trying to do with your database is something that is sound. Because the TypeScript types that get generated will prevent you from doing the wrong thing.

00:39:07 - Anthony Campolo

And then something else I find interesting about that is I've noticed that when you have Prisma, like you say, because of the TypeScript, and then you also have a GraphQL API because that is basically defining types, that's kind of what it's doing, you are able to write JavaScript and get a lot of the same benefits you would get from writing TypeScript without necessarily having to do it.

I find you still get a lot of the same autocomplete, and you still get a lot of the same errors, and I find that to be pretty interesting because, as you know, this whole tension between how deep we go into TypeScript or not. And so I like how we've set up, at least I've gotten to a place where I can have tooling that allows me to get a lot of the benefits from TypeScript without really having to write TypeScript.

00:39:46 - Ryan Chenkie

Yeah, absolutely. It's an interesting debate right now. TypeScript, of course, is really taking off. But there are developers that are sticking with JavaScript.

And one thing I've seen recently is that some library authors are actually reverting from TypeScript to JavaScript and just using JSDoc to get autocompletion.

00:40:06 - Anthony Campolo

Right? Rich Harris was talking about this. Yeah.

00:40:08 - Ryan Chenkie

Yeah, you saw that? Yeah, that's interesting. I guess there's some overhead with TypeScript that people don't want to deal with, which is, of course, fine. But I was curious. It was interesting to see that people are going from TypeScript back to JavaScript. I wouldn't have expected that necessarily.

00:40:23 - Anthony Campolo

Yeah, you're big into TypeScript. You did a really great TypeScript pocket guide that we'll link to in the show notes. I got a lot of value out of that, so thanks for writing that.

00:40:32 - Ryan Chenkie

You bet. Yeah, that was fun. Yeah, what's the story with TypeScript in Redwood these days? I remember talking to the guys a while ago, and it was on the way. But any movement there?

00:40:43 - Anthony Campolo

Yeah, I think we just got a lot of the router stuff in there, I think, is what we're working on. Chris will be closer to the ground on this. I know it's being worked on, but we're still not across the finish line yet.

00:40:53 - Christopher Burns

It's currently in a middle period where it was working for me on 23/24, then the router got rewritten and it broke it for me, so I can't upgrade to 24 right now, but there are fixes lined up for 25. After pre-rendering has been added, because obviously that does a lot with the routing and how that all works, really.

So it's gotten a lot better in the months since. If you're wondering, the easiest way to see how it's all going is the roadmap. I think it's the RedwoodJS roadmap, and it says where all the states are. TypeScript is one of them, where it says how far along it is. Nice.

00:41:34 - Ryan Chenkie

That's cool. Yeah, I think a lot of people are starting projects these days having it in mind that, at least if they've got experience with TypeScript, they probably wouldn't do a JavaScript project. I mean, that's the case for me anyway. If I'm starting a new project, it's going to be TypeScript all the way down, largely because I know the benefits I can get from it, but also the fact that because TypeScript is a superset of JavaScript, if I really don't want to deal with types, I don't necessarily have to. I can just kind of go on my way.

And I know there are some limitations to working with TypeScript. It's a little bit more overhead and whatever, but for me it's worked out well. I think my development has improved for sure. The time it takes to write something and get it working as it should be is much reduced, I think, because I get so many things ahead of time.

00:42:20 - Anthony Campolo

And what else do you think is going to be coming up this year for Prisma that you're looking forward to? You had mentioned Mongo support, and it sounds like migrate is getting to a good place as well. So you can speak to either of those or anything else that's going on.

00:42:33 - Ryan Chenkie

Yeah, I'm excited for basically the final sort of general availability of all the pieces. Getting everything to general availability is going to be awesome. I think it's going to give people even more confidence that, yep, all the core pieces are there. They're ready to go. I don't have to worry about regressions and whatnot.

One of the challenges is that Prisma 1, for those unfamiliar, was like this hosted kind of GraphQL... it was self-hosted. So anyway, let's take it all the way back. [Graphcool?] was the initial incarnation of what is now Prisma. That was a hosted GraphQL service. Your database would be hosted, and then a GraphQL API would be produced for you to easily get into your database, etc. Prisma 1 evolved to be something that you host yourself, but you get a GraphQL API, and now Prisma 2 is totally GraphQL-agnostic. It's not concerned with what your API implementation is. It's just tools. Like I was mentioning earlier, this ORM that sits on top of your database, which makes working with databases way easier, and that's where the key value comes in.

So all that to say, there's this issue that developed over the course of time where people have been a little bit burned by Prisma making such drastic changes to the product and changing directions a bit. I think now the people on Prisma 2 who really like it, once these general-availability pieces stick in place, it's going to be like, okay, yeah, I feel really good about this. Nothing's going to change so substantially that it'll wipe out my project. I think people will be super excited about that.

So I'm stoked on that. And I think seeing what comes out of the developments around the commercial product offerings that are kind of taking place right now. Right now, everything is kind of open source, but the actual strategy and commercial product side of things is in the works right now.

00:44:18 - Anthony Campolo

Do you have any speculation in that area of what direction you guys are at least thinking about? I know Jason has said that this is something that is still very new and exploratory right now, but I'm curious at least what you're thinking.

00:44:29 - Christopher Burns

There is one that's on the public roadmap, and that's a hosted version of Studio.

00:44:34 - Ryan Chenkie

Yeah, and that's I think what I can speak to mostly, is the hosted experience. So Studio on the roadmap is something that people will benefit from. I think there's not a whole lot else I can say right now, but we can basically say building on the things that make Prisma awesome right now will be things that make working with databases in teams and in settings where there's a lot of data really good. It'll make for ease of use for developers working on large datasets and stuff like that.

00:45:04 - Anthony Campolo

Yeah, that's what Jason had said as well. He was talking about the workflows around databases, which we've had guests on the show, like Chris Ball, talk about issues he's had with this.

And so, yeah, there's definitely a huge space. And this is kind of similar to what Peter Pistorius is working on as well. So making it easier to work with databases is definitely something that a lot of people are looking for. So that'll be exciting to see.

00:45:28 - Christopher Burns

The provider I'm more interested in for Prisma is actually CockroachDB more than Mongo, because at one point in the future my application will need to be hosted worldwide, and thinking about having to manage multiple versions of Postgres, Cockroach just seems to have that down from their marketing page.

00:45:47 - Ryan Chenkie

Yep, the one I'm keen on myself personally is DynamoDB. I've just gotten into that and it's really cool. Same benefits, right? You just create it within AWS and you've got global support. You don't have to scale anything. It's awesome.

00:46:01 - Anthony Campolo

Yeah. If I could start supporting DynamoDB, that could be huge.

00:46:05 - Ryan Chenkie

Do you like Dynamo?

00:46:06 - Anthony Campolo

Yeah, I like Dynamo. And I'm trying to get Redwood into a state where it could be entirely hosted just on AWS, like with the database, because the thing that we don't really have right now is the database piece. We can do all this stuff with Netlify, Vercel, which is all building on AWS, but that's still really more so the frontend.

Then we have the backend, which we usually would pull in like a Postgres database on Heroku or something like that. So I'm looking at things like Begin and SAM and that sort of stuff, and trying to figure out how to get Redwood in some sort of infrastructure-as-code setup that can be deployed just to AWS.

And so getting the Dynamo piece is really important, unless we want to use something like Aurora or RDS or the more relational offerings.

00:46:46 - Christopher Burns

So what you want is, if I remember rightly, a mega CloudFormation file that basically sets up AWS for you. Is it CloudFormation?

00:46:55 - Anthony Campolo

Begin and SAM are both syntactic sugar on top of CloudFormation. So yeah, that's the idea.

00:47:02 - Christopher Burns

All right. No, I guess that's it. Thank you for your time. How can our listeners find you?

00:47:09 - Ryan Chenkie

Sure, yeah, you can find me on Twitter. That's where I'm most active, and I'm sure you'll probably put that as a link.

And yeah, if you're interested in the security stuff that we're talking about, reactsecurity.io is where you'll find details on that. And there's a free course there and some pro courses too.

00:47:25 - Christopher Burns

And you also have your own podcast.

00:47:27 - Ryan Chenkie

Yeah, I do. So if you're interested in business stuff, especially indie hacking and stuff like that, the Entrepreneurial Coder podcast is the one I host.

I chat with developers who are building side businesses or releasing books and courses and stuff like that, and getting to know what methods they go through to release products and do cool stuff.

00:47:49 - Christopher Burns

Your latest one was Justin Jackson, who built Transistor.fm.

00:47:54 - Ryan Chenkie

So he was, man, he was one of the early guests. So maybe you saw a recent tweet. I got some Twitter activity going where I just retweet older episodes. He was like last year or even the year before, maybe.

So anyway, that was a great episode, though. Yeah, he builds Transistor, which is the platform that I use for hosting.

00:48:10 - Christopher Burns

We do too.

00:48:11 - Ryan Chenkie

Oh, nice.

00:48:12 - Christopher Burns

Everybody does. Well, only the cool podcasts do.

00:48:16 - Ryan Chenkie

That's right.

00:48:17 - Christopher Burns

But yeah, that's it. Thank you for your time.

00:48:19 - Ryan Chenkie

Yeah. Thank you guys. Really good to talk to you.

00:48:21 - Anthony Campolo

Have a good one.

00:48:52 - Ryan Chenkie

Awesome.