Can Frontity be considered as part of the JAMStack?

🙋Get Help
1

A JAMStack is any stack that:

  • involves Javascript (for the client) and an API (for the server)
  • generates a static site that can be treated as any other static resource (it can be served from a CDN for example)

So… can Frontity be considered as a static site generator? Any thoughts regarding this?

1 Like
2

For what I understand by reading the docs this a feature in progress

Once this feature is done we could consider Frontitty as a static site generator and as part of the JAMStack, right?

3

Frontity is a bit on the edge of the JAMStack definition because it actually uses JavaScript, APIs and generates pre-rendered Markup which is then served from a CDN.

In my opinion the definition of JAMStack was created by Netlify to accommodate their specific technology and they usually talk only about static site generators, but it doesn’t make much sense to consider JAMStack to static generator only because nowadays the term is used to refer to the new way of creating sites using JavaScript and APIs to generate HTML (markup) which is the category that Frontity belongs to.

If you want to distinguish between static and dynamic pre-rendering, I would say that Frontity is “dynamic JAMStack” and the other ones (Jekyll, Hugo, Gatsby…) are “static JAMStack”.

1 Like
4

Can you elaborate this? For what I understand the content is served by a node server not by a CDN. is it possible to generate the Markup (with the content) and serve it from a CDN without the involvement of a node server? → Static site generation

If not… Is there a feature planned to allow this? Is there any visibility of the status of this?

Thanks!

5

In Frontity the HTML (markup) is pre-rendered dynamically by a node server or serverless and then it is served by a CDN. The only difference with static sites is that when the CDN considers the asset stale it will revisit the dynamic node/serverless service that would pre-render a new and updated HTML.

That is of course our recommended configuration. But it’s the same case for static site generators, they recommended to not serve the HTML directly from a static server (like AWS S3) but use a CDN on top.

Yes, static site generation is on our roadmap, but it’s not a top priority.

Actually, static site generation is not complex at all. All you need is a list of URLs, start the server locally in production mode, and save all the HTML files to disk. In the case of Frontity, we can extract the list of URLs from the REST API.

But even though generating static HTML files is nice for some use cases, it also introduces a lot of complexities like:

  • The need for hooks to retrigger the build each time the content of the CMS changes.
  • The need for incremental builds to reduce build times in medium/large sites.
  • Even the need for a dynamic node/serverless service for generating previews for content editors!

At the end of the day, the gain you obtain by generating HTML on build time is really low:

  • It’s not faster: The static HTML is cached by the CDN, the same way that the dynamic HTML generated by Frontity is cached by the CDN, so Frontity is as fast as any SSG.
  • It’s not cheaper:
    • For the sites that are small and do not change often the fact that a node/serverless server is not needed may seem great at first, but all those sites requirements fall into the “Free Tier” of the serverless hostings like AWS/Google-Functions/Azure/Now. Even Netlify has 125.000 free serverless requests per month. So both approaches are essentially free.
    • For sites that are big and receive a lot of traffic, the bill will go to the CDN provider for the bandwitdh, not to the node/serverless server.
      • @403page did a load test with Frontity and the result was that 99.89% of the requests were cached, so they were served by the CDN instead of the serverless function.
      • I did a calculation with a company who is currently migrating to Frontity and they pay several thousand euros per month for the hosting and have more than 100.000 pages indexed by Google and more than 15 millon pageviews per month. The cost of adding Frontity was only $50-100 per month (calculated using AWS Lambdas) which is ridiculous when compared to their other costs.
      • As soon as you have any dynamic part in your pages, like forms or comments, or your content editors need to access the dashboard to publish new content, you cannot shut down your CMS. Or alternatively, if you still want to shut down your CMS, you have to search for additional external services for forms/comments that will complicate your stack and will incur in additional costs.

Security is another interesting matter to mention because HTML files can’t be hacked. The only way to hack it would be to gain access to your static server and substitute those files, which is the very same risk of a serverless service, because even if someone gains access to that serverless execution, the file system of a serverless execution will be removed and the next time that funciton would be executed the “hack” won’t be there anymore. So in that regard, Frontity with serverless is as unhackable as HTML files.

The real benefit of static sites in terms of security is to be able to shut down your CMS. But as I already mentioned that is not possible/practical for a medium/large site that needs their content editors to access the dashboard and publish content every day. To mitigate that risk, people can do things like add a firewall to reject traffic from IPs not belonging to their editors, but they need to bypass the dynamic parts like forms or comments. For Frontity, a bypass of the REST API (or GraphQL in the future) is also needed. That’s the only difference in terms of security of Frontity vs a SSG: public access to the REST API.

I reckon that static site generation got a lot of marketing and hype lately in the JS/React developer ecosystem, but so far they are being used mostly for small sites. Using static site generation for a big publisher site is another story. And even once SSG frameworks like Gatsby solve the problems of previews and incremental build times I mentioned earlier, they still won’t have much benefits over a serverless dynamic approach like the one of Frontity or Next as I explained.

5 Likes
6

Ya, I’ve been a huge fan of Gatsby.js so it was hard to come to terms with… BUT…
I cannot see any benefit of SSG’s like Gatsby over Frontity.

Slapping a CDN in front of the JS server was a walk in the park, especially with Cloudflare.
I’m also fairly certain that the 99.89% observed in my tests is still theoretically low. It could be 100% (if no changes have taken place) - you can cache the REST responses inside Cloudflare too.

I’ll be doing a much larger test soon and logging my own 2 servers access logs/bandwidth usage at the same time as Cloudflare’s to see specifically what was uncached and sharing the results.

Frontity has all the benefits of a static site while remaining changeable on the fly. The possibilities for different types of clients has literally blown my mind.

4 Likes
7

Awesome! Let us know how it goes :slight_smile:

1 Like