Server side rendering (SSR) and Static Site Generation (SSG) are two ways to create websites using a modern front-end stack (getting content from a...
For further actions, you may consider blocking this person and/or reporting abuse
With AWS tou can actually use CloudFront caching for dynamic serving content, it has TTL mechanisms to cope with it. So there are ways around the issue.
Look here for some use cases,
aws.amazon.com/cloudfront/dynamic-...
In my experience, the major reasons for looking towards SSG rather than any form of active server (SSR, Wordpress, Wiki's, etc.) are: security, static content has nothing to attack outside the base web server, which is typically a very well tested off-the-shelf option; cost saving, typically one can host static files in S3 or Azure storage for 10% of the cost of a hosting a VM.
Personally I'm moving from Wordpress and MoinMoin to static sites with Hugo for these reasons.
I totally agree with you.
After a period converting Wordpress sites to Gatsby with Wordpress REST and Admin, we decided to build our "React Bricks" CMS (based on React Components) to avoid Wordpress altogether.
We'll release it in beta soon; we have already used it for 3 sites and we love the new way of working with Gatsby/Next SSG and our CMS.
Thank you, I was able to understand difference between SSR and SSG clearly after this.
i have a confusing about SSG
do we can make api calls on run time or not because you said "Since you call the APIs only at build time"
and them at the end in "How to cope with cons:" section you said
"and frequently changing data (stock quantity) you may do an API call on component load to fetch an updated version of just the frequently changing data."
and even authentication on SSG websites it needs api calls to server to sign up or sign in or fetching user data
so please clear it to me.
What about the Netlify CMS? Aren't you guys trying to do the same?
No, it's different: in NetlifyCMS you edit the content in a form and you have the preview on the side. With React Bricks you edit directly the content through the React components created by you (using React Bricks WYSIWYG components Text, RichText, Image) and the editing page is really the same as what you'll get in the frontend, because the frontend is created by React Bricks's Viewer component.
We have prepared starters for both Gatsby and Next.js.
What's more, you don't have to use components like Gatsby Image, because React Bricks has its own cross-platform Image component (with lazyload, srcSet, etc.).
Migrating from Gatsby to Next or viceversa is just a matter of cloning another starter, copying ApiKey and AppId and the block schema.
BTW, we are launching tomorrow in beta!! :)