Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode we're going to be talking about using lighter objects to create better rest applications. Today's episode is brought to you once again by spec.fm if you are a designer or a developer looking to level up which you probably are. Then go and check out the other incredible content at spec.fm. There's tons of podcasts, hundreds and hundreds of hours of content to keep you busy and learning. So go and check it out, spec.fm. Today's episode is also brought to you by heap. If you are currently using something like Google Analytics or if you haven't even thought about analytics yet, go and check out heap. We will talk more about what heap does later on in today's episode. In the meantime you can go and check it out. Select.fm slash heap and you can learn more about the incredible features that heap provides. When creating a rest based application you are basing the application structure off of the concept of resources. You can create and update those resources and you can retrieve those resources. Rails developers are definitely familiar with this concept but I want to help you wrap your mind around how this plays out and give you a little bit of a new way of thinking about restful resources so that hopefully you can get out of the trap of thinking that restful resources are actually things, their actual physical objects or they are represented by something like a physical object. If I had to sum up the basics of today's episode I would simply say to think about your resources as much lighter than you currently think about them. Think about your resources as much lighter, much smaller objects, much more transitive nouns. Instead of thinking of your resources as these big important objects, start thinking of them as small and still important objects. Because it's far too easy to think about your application in terms of these large important objects and actions that you take on and with those objects and generally speaking you can create an application like this. The problem is this violates the purest form of the rest structure. You start adding more specific actions to your controllers that go beyond the base level rest actions. Now this isn't necessarily limited to web applications either. The same concepts can apply in pretty much any kind of software development. Really we aren't just talking about restful resource URLs. We're also talking about the concept of making your objects smaller so that you have more resources to work with. These resources aren't ultimately going to represent the different actions that you are actually taking. It's going to start looking more like history tracking. Let's look at a practical example. Let's say you have a store and you have products in your store and you want to archive a product. You want to archive a product. It's easy to think that you should just create a simple archive action in your controller and then add it to the routes. Now you have an endpoint to hit and you can archive that particular item. This won't necessarily be a problem. It creates complexity in your application that breaks from the concepts of rest. In other words, I have to go read that code to really know what's going on. While this in and of itself may not necessarily be a problem, when you choose to adhere to a design paradigm, you gain much more value out of that design paradigm if you adhere to it fully. In other words, if you don't break from that design paradigm for a number of exceptions. So for example, instead of having a specific archiving action in your controller, you may need to include that as one of the things you can do when you utilize the update rest action. We're going to take a quick sponsor break to talk about heap and then we're going to keep on talking about rest objects and better ways of thinking about lighter objects to make your rest apps more accessible, a little bit more maintainable. Today's episode is sponsored by heap speaking of maintainable. And for this read, I'm going to go off script and talk about what heap does that is so important for developers. Developers, you have been asked many times, most likely, to go and add a click event to track some kind of transaction in Google Analytics. And you do this over and over and every time that you get an email from some marketing team member to track a new event, you get a little bit frustrated because it seems like you're doing the same kind of work over and over and over and not adding any extra value. Well, heap replaces this concept of tracking clicks and instead heap tracks everything. So you have data that you otherwise would have never captured in the first place. And you can go back and ask the right questions after the fact, rather than having to come up with those right questions before the fact. This simple mindset shift could totally change the way you think about how you are doing analytics. And perhaps more importantly for developers, it's going to free you up to do the things that add the most value. Go and check out heap spec dot FM slash heap. Of course, that link can be found in the show notes at spec dot FM. So we've talked about the built in rest actions needing to be flexible enough to take on things like archiving. Another way to think about rest objects though is to think about the action itself as a noun. Let's talk about that a bit further. Let's say for example, that you want to make a connection from one object to another. You want to make a connection from the item to a particular store category, for example, how would you go about doing this? Well, perhaps you would use the update action on one or the other of the objects, but which one? For example, if you want to add a user as a member of a group, how would you do that? You could select the group and add the user to itself or you could add to the user's list of groups. But neither of these really captures the rest action entirely doesn't. Instead you could create a membership object. So now you have three objects in the mix. You have three resources to think about. You have the user, you have the membership, and you have the group itself. Of course, you may be thinking, well, that's just a fancy join table, isn't it? And in some ways, it sort of is. But it can function as far more than that. For example, in this case, you may have a membership, but that membership may also include the role of that member or the membership access level for that particular member. I'm actually building an application right now that uses this specific concept. And I found myself thinking myself time and time again for separating out the concept of a membership into its own resource. Another example of this is to create activity records, like for example, login action records. When a user logs in, you may simply create a login record that is attached to that user. And this object represents the user's login as well as that action in time. Now this goes back to the historical piece of this. What this allows you to do is actually look at all of the actions that have been taken in your application over time. And really what this also means is that you can go back to any history point in time if you implement this concept throughout your application. Of course, this can be a little bit heavy handed, which is why I don't think that it's necessarily appropriate in every single case. And that's why I decided to frame this more in terms of how to think about objects rather than just blindly choosing to create historical action objects. Instead, start thinking about objects as lighter and don't be afraid to create more resources. These resources are going to help simplify your application. And instead of having controllers that end up far too large or instead of having models that end up far too large, everything gets smaller. You end up with a lot more objects overall, but it's easier to think about more objects than it is to think about objects that have a lot of functionality packed into them. Thinking about your objects in terms of representation, whether that's an action or the actual object itself, the physical noun, that will help you realign your rest actions so that you aren't making these Frankenstein controllers and lots of these specific routes, long route files. Instead, you're creating a network of objects that can be created, updated, fetched, and deleted. And that's exactly what rest does. Thank you so much for listening to today's episode of Developer Tea. Thank you again to spec. If you are a listener of Developer Tea and you haven't checked out the other incredible shows on the spec network, go and check it out at spec.fm. We'll take a second to highlight does not compute in today's episode. In their latest episode, they talk about long running projects. Many of you are probably working on long running projects today. Sean and Paul both have a lot of insight on this kind of stuff. Go and check out their show. Does not compute. It's at spec.fm. Again, today's episode is sponsored by Heap. If you feel like you are fighting your analytics machines, where if you haven't even thought about adding analytics to your application, go and check out what Heap has to offer to you. Spec.fm slash Heap. They have a list, a laundry list, really, of features that you are going to be excited about. It works in mobile apps, native, and in web apps. So go and check it out. Spec.fm slash Heap. Thanks again to everyone who listens to Developer Tea. You are the reason this show exists. And until next time, enjoy your tea.