DEV Community: chen4119

Netlify vs Cloudflare pages vs AWS Amplify

chen4119 — Tue, 16 Nov 2021 16:28:00 +0000

I've been using Netlify for a few years now to host my static website and really love how easy it was to get going. Before Netlify, I hosted my static site on AWS S3 and that experience was painful. You need to configure S3 for public and CORS access, add cloudfront, then set up a custom domain. It's a lot of work just to deploy a static website so I'm very happy when I found Netlify. I know Cloudflare pages and AWS Amplify also provide an easy way to host static websites and I finally had the chance to try them out. Here are some thoughts.

Ease of use

Both Netlify and Cloudflare made it really easy to get started and deploy a static website directly from your Github repo. I'll say overall Netlify has a better user experience compare to Cloudflare because it's site is more intuitive and visually appealing whereas Cloudflare pages feel more barebone. One major downside for Cloudflare is that there is no federated login. You need to use an email and password to create a Cloudflare account whereas for Netlify, you can just use your Github credential. In this day and age where we all have hundreds of online accounts, I'll prefer not to have another password for Cloudflare.

AWS Amplify also kept it really easy to deploy a static website but it's hard to say AWS Amplify is just as easy as Netlify and Cloudflare pages simply because AWS Amplify is a small feature within the AWS beast. For those who are already familiar with AWS, Amplify will feel pretty simple but new users will be overwhelmed by so much options. In terms of user experience, it definitely still lags Netlify and Cloudflare. Instead of filling out a simple form, Amplify makes you edit the config blob below. Not a big deal but it definitely feel more like a roadblock than a welcome sign.

Custom domain

Both Netlify and AWS Amplify allow you to easily set up custom domains with free ssl certificate. It works with any third party DNS provider, you just need to set up an ALIAS record for it to work.

Cloudflare pages on the other hand will force you to use their DNS service in order to set up custom domain. It won't work with third party DNS providers. This might be a deal breaker for some people but at least Clouflare offers a free plan for their DNS service and it's really fast.

Build time

I generated my website with Sambal static site generator. Below is a timing of how fast each platform took from the moment I commit to github to a deployed website. AWS Amplify was the fastest while Cloudflare took the longest. For some reason Cloudflare took close to 2 minutes just to initialize the build environment. By that time, AWS Amplify had already deployed my website.

	Build time
AWS Amplify	1m 58s
Netlify	2m 33s
Cloudflare pages	2m 53s

TTFB test

To test how my static website perform across all regions around the world, I deployed the same website to all 3 platforms then use SpeedVitals TTFB test to test the time to first byte across 25 different locations without using custom domain. I hit each platform with their native URL. Here is the average latency for the 3 platforms across different regions.

	Americas	Europe	Asia
Cloudflare pages	146ms	107ms	148ms
AWS Amplify	142ms	155ms	294ms
Netlify	186ms	67ms	271ms

Overall Cloudflare seem to have consistently good latency across different regions. I ran the test multiple times for each platform. The first test is always the worst because the CDN hasn't cached anything yet. Subsequent tests always show better latency. The average latencies reported above are measured after 3 - 4 tries to get a more accurate picture. I noticed with Cloudflare, it took just 2 tries to get consistently good results and it felt like once your page is cached, the traffic is always fast. AWS Amplify is somewhere in the middle, while Netlify results can vary quite a lot on different tries. Sometimes it's fast and sometimes it felt like there's a cache miss somewhere so it went back to your origin server.

To get a better picture, let's also look at the worst latency measured for the 3 platforms across different regions.

	Americas	Europe	Asia
Cloudflare pages	232ms	181ms	363ms
AWS Amplify	187ms	184ms	407ms
Netlify	744ms	140ms	1100ms

From this table, it's more obvious that Netlify latency can be pretty bad at some locations although it seems to be consistently great in Europe. Every platform has the worst latency in Asia.

Summary

Netlify is a great platform for users who don't want to deal too much with technical stuff. They just want to get their static website up and running. It's easy to use and it offers pretty much anything you'll need to run a professional website. Serverless backend, A/B testing, user authentication, forms, etc. All these features with minimal coding.

Cloudflare is a great platform for developers who don't mind jumping through a few hoops to get the best performance. Cloudflare DNS is one of the best DNS provider available and Cloudflare pages has consistently low latency across the globe. The UX feels barebone and site navigation can be confusing but for the speed you get, I'm sure you can suck it up.

AWS Amplify is a great choice for existing AWS users or people who don't mind getting their hands dirty with AWS. It has a fast build time and good latency across the globe. It integrates with every other AWS offering so you don't have to worry about the limits of the platform as you might with Netlify or Cloudflare. It has a steeper learning curve but the end result of being familiar with AWS is worth it.

Json-ld spices up the staticness of static site generator

chen4119 — Wed, 27 Oct 2021 14:52:43 +0000

The best thing about static site generator is the simplicity. All you need is a couple of markdown files, html templates, and the generator can spit out a speedy website with good old static HTML and CSS. For a lot of websites, this is all you need and that's why static site generators are so popular.

As your website start getting bigger though, the limits of static site generator becomes more apparent. The most glaring limitation is that there is just no easy way to relationalize or join data like you can easily do in a database. To illustrate my point, consider a blogpost markdown

---
title: "My blogpost"
date: 2021-10-17
author:
  name: John Smith
  twitter: @john
---

Content of the blog

The relationship between the author to blogpost is one to many. John can write many blogposts but there is no easy way to normalize the one to many relationship in a static markdown file. You can only duplicate john's info in every blogpost which is not ideal. You might have noticed that the solution many blog themes took is to simply keep the author's info in the global config file.

Here is an example for Gatsby, here is an example for Jekyll, and here for Hugo. Again, not ideal, but it'll work for a personal blog. Once you have more than one author, the UI theme will need a major refactoring.

Of course you can always use a CMS to model your data and then pull those data into your static site generator to generate your webpage. However, this adds another level of complexity and cost. We'll explore how json-ld and the concept of linked data can help make static markdown/yaml files more dynamic.

What is json-ld?

Json-ld is a linked data format based on json. If you have never heard of json-ld, that's ok. The most important thing to know is that it's just plain old json with a few extra special fields. It's also a w3c standard and you can check out the complete spec. We don't really need to understand the whole spec, we're just interested in the way json-ld can reference other data fragments with a url using the keyword "@id "

title: My blogpost
date: 2021-10-17
author:
  "@id": https://example.com/author/johnsmith.yml     // @id is json-ld's way of referencing another data fragment

Using json-ld over json

Since json-ld is just json, it means you can also use it in a markdown or yaml file. Now all of a sudden, static markdown and yaml files that's so prevalent in static site generators are not so static anymore. It can join with other data fragments without a database or CMS. You just need a client side json-ld processor.

Sambal is a static site generator that natively supports schema.org json-ld as the content model. Get started to discover the power of linked data.

Schema.org json-ld static site generator

chen4119 — Sun, 10 Oct 2021 16:04:59 +0000

Sambal natively supports schema.org json-ld as the content model so you can render webpage directly from any schema.org json-ld data. By using the open and well known schema.org vocabularies to structure your content from day one, it saves you the trouble of modeling your own content and later realizing it's not compatible with anyone else's content.

Take the simple example of a blogpost which contains an author, a timestamp, some tags, and the content of the post. However, without standardizing on schema.org vocabularies, there are literally hundreds of ways you can encode a blogpost. Tag can be category, title can be header, summary can be description, etc. This inconsistency in data schema is a big problem that hasn't really been addressed. It's the reason why it's so hard to switch from one theme to another or one static site generator to another when building a website. Everybody uses their own flavor of content model even when the content is as simple as a blogpost.

Schema.org has over 700+ content types and most importantly, it's supported by all the big search engines like Google and Microsoft. It's the ideal content model for the vast majority of websites.

It's also fair to ask, then why introduce a completely new static site generator? You can use schema.org with existing static site generators too. Yes, but existing static site generators do not fully leverage the power of linked data. Schema.org json-ld can reference other pieces of data with a uri, similiar to how a hyperlink links to another webpage. This allows you to do some pretty awesome things that plain old json/yaml data can't. To illustrate what linked data can do, let's start with a simple markdown file for a blogpost that you commonly see.

---
headline: My first blog post
author:
  name: Blue Devil
  email: blue.devil@email.com
publisher:
  name: Blog Publisher
  address:
    streetAddress: 125 Science Drive
    addressLocality: Durham
    addressRegion: NC
---
Content of my post

This blogpost contains some data about the author and publisher but once you start having multiple blogposts by the same author and publisher, you'll need to duplicate the data in every markdown file. There is no standard way to normalize the data in static json/yaml like you can with a database. In json-ld format though, you can! Data fragments can be stored anywhere online as long as it has a resolvable URL. You can simply reference the data using the special "@id " keyword like such

--------
headline: My first blog post
author:
  "@id": https://author.com/bluedevil
publisher:
  "@id": https://organization.com/blogpublisher
--------
Content of my post

You can fetch author and publisher data directly from source and never worry about data becoming stale. Sambal recursively hydrate json-ld data by automatically resolving all @id urls. A url doesn't necessary need to be a https:// either. It can be a AWS s3:// url, ipfs:// url, or pretty much any protocol. Sambal provides an easy way to customize how to resolve any url.

Get started with Sambal to build your linked data JAMstack website.