The simplicity of the JAMstack shines from its decoupled architecture. In contrast to monolithic setups of the past, JAMstack sites are far more flexible and customizable. The decoupled, API driven model of the JAMstack means developers have the freedom to choose the services and implementation details that their sites use. This freedom of choice while desirable, conversely puts the onus on the developer to keep sites lean and performant. Though JAMstack sites help with making sites more performant, speed is not guaranteed on the JAMstack. If picked poorly and in abundance, APIs can quickly add bloat to a site. This is especially the case if an API is expected to execute at run time. Features like comments, and likes often require third party services and come with their own set of specific implementation details not to mention how much of a performance bottleneck they are—Harry Roberts has an incredible talk on this that’s excellently titled “It's My (Third) Party and I'll Cry If I Want To” if third party performance interests you.
Build time can also suffer when too many APIs are added to a site. Adding even one API that dynamically fetches user generated content at build, can add complexity and increase the execution time of your build process. When it comes to the question of how many is too many APIs, there is unfortunately no one true answer. However, a consideration worthy of note is to exercise restraint as much as possible, or as Harry mentioned in his third party talk mentioned earlier “use as little as possible for as long as possible”. With the JAMstack approach, it can be easy to reach for an API when the need arises. Stopping to consider the use case and sometimes even crafting a custom solution to an easily solvable problem (like comments) can mean a more lean, performant JAMstack site.
To get started on "rolling your own" features (like comments) on a JAMstack site, check out this excellent demo by the wonderful Phil Hawksworth:
Shout out to Marie-Luce for the article suggestion!