When YOU make Static Site (with SSG), what additional APIs do YOU eventually have to use and how? (third-party or self-made)

#discuss #webdev #ssg #ssr

So, static site generators are lies. I always at least crave for comment-engine and search-engine.

My comment-engine is third party.
My search-engine is a serverless function.
It would be nice to have an Email and Subscribe function. Maybe I have to go to third-party, again???

So, I reach a conclusion - SSR might still a better way; but I am not ready for a full-blown HEADFUL CMS, yet.

I have a question

If the API is self-made, and not on the same platform as the main thing. How do you manage the connection, and the security?

Top comments (8)

Jordan Kicklighter • Dec 16 '20

So, static site generators are lies.

This is a bit misleading, or possibly the result of someone else writing something misleading. Static site generators are incredible at the thing the set out to accomplish, which is quickly responding to client browser requests with static files. On-the-fly rendering cannot compete with the speed of static content delivery, which is why CMS's like WordPress lean heavily into caching plugins for scalability.

Now to the actual problems:

Comment solutions for static sites exist, and they generally just load up a JS library after the page has loaded. Disqus is one fairly popular option, Commento comes up in a quick search, and there are several others.
Search engine solutions also exist, but the correct one depends on your needs. If your site is small enough, you could build the search function in JS and build the search cache when you rebuild your site. A serverless function is a common way to handle this, like what you're doing.
Email and subscribe functions are also often handled with serverless functions. Netlify has Netlify Forms which would make the setup fairly trivial, although isn't free once you hit a certain number of responses.

As for security, it's a bit of a complex question. What type of security requirements do you have for a search engine? It seems that this would be public-facing, just like your site. And the same question exists for the email/subscription functionality. Perhaps include some sort of robot detection if you are concerned about spam, but what other security issues are a concern if it is a public-facing form? The connections for both of these are simply public API endpoints.

Static sites are fantastic at serving infrequently changing data to browsers. The problems that you called out do not fall into that category, and they all work with a back-end to accomplish their tasks. The only reason that a CMS is "easier" in this regard is because you already have a back-end running to serve your content. The thing is, it is trivially easy to serve a static site. The server requirements are much less than that of a CMS. The speed and ease-of-hosting come with trade-offs, as you have found, but a CMS has a different set of trade-offs such as speed, cost, and infrastructure complexity.

Hopefully this helped, I admittedly haven't finished my cup of coffee yet :)

Pacharapol Withayasakpunt • Dec 16 '20 • Edited

It's also a matter of static site hosting trying to sell their serverless solutions and lock-in to their platforms. Also deploying readymade JavaScript libraries isn't hard; but in reality, there is a database actively CRUD'ing somewhere, and JS library is just to simplify the connection (like Algolia).

Now, to the real question and very direct. What is the best way to connect my self-made server (for API only, on perhaps DigitalOcean), to a static hosting platform (say Netlify)? I know proxying isn't that hard; but how do I practically "hide" and "secure" the connection from unauthorized access?

Jordan Kicklighter • Dec 16 '20

I think the exact scenario is important here. What type of backend API are you hosting? What about the API is important to hide and secure?

Pacharapol Withayasakpunt • Dec 16 '20 • Edited

What I already have are

Remark42 comment on Google Compute Engine, where I have free credits. (If I host on DO now, I will have to pay monthly).
- This is the only practical API I have currently that does not comply with 12-factor. I cannot host a database server outside.
Several of stateless API on Heroku, or Google Cloud Run (i.e. Docker runner). Many of them are connected to MongoDB Atlas.
- For these, I think it is a matter of ensuring privacy and availability. Also, contain the cost for GCR.
Static web pages on Netlify and Vercel, where there may be SQLite and JSON files being reading via serverless.