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)
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:
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 :)
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?
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?
What I already have are
SSR is slow
It's not like you can't prerender SSR if you really need to.
In reality, many popular websites already failed lighthouse score.
Like Next JS?
Just plain puppeteer or playwright is enough.
There is also thing called precaching.