How "expensive" are API calls?

I was thinking about an SPA that has a like button. In "Liking Post" tutorial you wrote a method that checks if the current user liked the post, but in an SPA that means I will have to make a call to the API to check that. Does this mean your app will be slower in general? Isn't it faster to it hit the database from a monolithic app instead of calling API's from a client app?

In general, API calls are pretty lightweight. They are significantly cheaper requests than regular page views because they don't require you to generate a full page, you only have to render some JSON which is easily generated from Rails. You'll notice most of these requests should complete in a smaller portion of the time that a full page request would take in your Rails logs. An example might be like 50ms to produce the JSON instead of 100ms to produce the full HTML page depending on how complicate your pages are. Of course, this all depends on the work you're doing server-side to make it happen. Some things can be slower like if you have to hit an external API.

There are many ways to optimize as well. For example, in an SPA, if you request a resource (like an Episode) you can pre-load the Likes inside of the JSON so the SPA can handle that all at once. Then when you click "Like" it can do the AJAX request just like I showed in the episode. If you take this approach, it's almost no different than what we did in that episode, except for the fact that the frontend is managed and rendered by the JS. That will make for a significantly slower first page load as it has to download a lot of Javascript the first time, but from there it mostly just needs to request JSON from the server after that.

One big issue with SPAs is that you have to still make these indexible by search engines, therefore requiring you to figure out a way of server-side rendering HTML still to have SEO for your site.

Now having explained all that, these approaches are significantly different. You've changed from producing HTML to JSON and moved a giant amount of logic from the server side to the frontend JS. This might be what you want, but Turbolinks is designed to be a middleground for these two approaches. You get the speed benefits of an SPA while keeping the same HTML the backend produces and writing minimal JS. The other giant benefit of this approach is that with the mobile adapters, you can operate with a smaller team all using the same Rails app HTML responses. The mobile devs get to focus on what they need to make a great experience native on mobile without having to rebuild the entire UI for mobile which is awesome.

Of course, SPAs make a lot of sense when you need to expose an external API for random people to consume. You can use the same API internally as what they would consume externally which is a strong reason for why you might want to go that approach over Turbolinks. Either way you can kill two birds with one stone, just depends on what your end goals are (and how much money you have to invest in a team to build it).

Clearly I should make a video on this asap. :-)

Wow, thanks for the thorough response. I actually got better in it since last time we talk. I'm able to register and login users from my React app now. The reason I'm doing it is for React Native. It's much better than all the other options that just render a web view. In general I would never build an SPA since like you said, turbolinks does it for you already.
I also ditched Devise in favor of Michael Hartl auth system since it gives me more flexibility.