In practice it’s adding between 10-50ms per load if that. The connection is super low latency as both boxes exist in the same datacenter. In fact, the method I’m using to pull in data to components loads pages marginally faster than Discourse rendering it’s own static pages (difference of about 100ms) and that is including a DB operation that uses Discord ID’s to add User data into the API responses before they’re forwarded to the client. (Ruby requests data from External Application → Parse JSON → DB query.each loop to append data to response-> Generate JSON and return to frontend client). It’s understandable considering how large the codebase is but there is definitely an overhead internally that makes room for these requests that are traditionally seen as “expensive” to go completely unnoticed. With that said, we’re talking about the speed of light and sound here which to the end user is still incredibly fast as Discourse is an amazing platform.
A cache would be a great addition and will be something I look into, very new to Ruby so I’ll update as I learn more about the available functions. I’m going to update this as I go forward because I think some sort of method for this, albeit hacky at the moment, could be potentially very beneficial to the plugin development side. For people with existing applications, being able to use the API they know to slide the data they need where they need it efficiently without having to build out systems to sync data between their database and Discourse or mess around with additional models or db migrations drastically cuts down on development time and keeps plugin authors in some of the better documented areas of the application (i.e. the Plugin API).
I greatly appreciate the insight, definitely excited to continue to learn more about this platform and hopefully contribute in the future.