107: Sam Selikoff - Pushing Complexity to the Client-Side

In this episode of Fullstack Radio, I continue my conversation with Sam Selakoff about building client side applications. This time focusing on how to keep your API code simple and how to push more of the complexity into the client. This is Fullstack Radio episode one zero seven. Hey, everyone. Before we get into the discussion with Sam today, make sure that you go back and listen to episode one zero six before this one, if you haven't already. As this is kind of like a part two of that conversation, we recorded it all together and I just kind of split it up into two episodes because it was a really long conversation where the first half was sort of focused on one topic and the second half was focused on another. So there are some times in this conversation where we reference things in the previous episode as if it was a continuation of that conversation. So if you haven't listened to that episode, definitely check that one out first. And if you have listened to it, enjoy this conversation with Sam. So the next piece that I wanted to get into is what your server stuff looks like and how much of that stuff, like, you aren't doing anymore that maybe I am still worrying about in, like, my server rendered applications, how much code, like, you have to write there, how complex it is, what sort of stuff it's doing. Because I know, typically, based on the conversations I've had with you in the past, your Ember apps are most of the time you're backing them with, like, a rails API that you guys are building yourself and managing yourself. And I know the Ember map site has a rails API backing it. Right? Yep. So what does your rails API look like when you're making this like concerted effort to push as much logic and responsibility as possible into the client? So we use, something called JSON API which is just a format for how to structure those JSON responses, and requests. And this was, created by some of the folks who work with Ember, but basically it's just some conventions around it, around your API. There's also some tools and there's some gems in the rails ecosystem that help if you are building, JSON API API. So I know JSON API is like the worst name ever because it, you know, it's a it's a spec. There's so many other JSON APIs that don't implement the JSON APIs back. Exactly. But you can imagine, you know, GraphQL is a is a similar idea where, it's really a spec that's designed to serve fat clients. It's it's designed to serve, clients with rich interactions and capabilities to enable them to build new UI features with spending the littlest amount of effort possible on your back end. That's kind of the that's kind of where it came from. So, with JSON API, we use this gem …