Live data from Hacker News

Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

takeshape.io

31–40 of 41 posts

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#31

Earlier quoted context omitted.

> I am kind of sold on "static" sites, but why is this particular stack and set of solutions so exciting? (As opposed to using, say, Rails on Heroku It's exciting because it's a static site and not using something like Rails? The static site approach still isn't that well known. Right now, I try to use static sites wherever I can because of their reduced complexity.

> The static site approach still isn't that well known Static sites predate web apps. In fact, the first websites were purely static. > reduced complexity you're telling me webpack + react + node_module hell + graphql reduces complexity?

>> Right now, I try to use static sites wherever I can because of their reduced complexity.

> you're telling me webpack + react + node_module hell + graphql reduces complexity?

You are using the word _complexity_ in a different sense. The complexity you are talking about is the complexity of developing and building web pages. However, once they are built they are simple static files that can be served from anywhere. As opposed to the complexity mentioned in the parent post, which is the complexity of running a typical web application that includes a backend server and likely a database. Even such plain and commonplace technology as a Wordpress installation has a higher complexity of running than a Gatsby-based site.

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#32
post #31

Earlier quoted context omitted.

> The static site approach still isn't that well known Static sites predate web apps. In fact, the first websites were purely static. > reduced complexity you're telling me webpack + react + node_module hell + graphql reduces complexity?

>> Right now, I try to use static sites wherever I can because of their reduced complexity. > you're telling me webpack + react + node_module hell + graphql reduces complexity? You are using the word _complexity_ in a different sense. The complexity you are talking about is the complexity of developing and building web pages. However, once they are built they are simple static files that can be served from anywhere.…

People tend to find things that they have done for a long time less complicated than something new despite it actually being quite complicated. I always ask people when they are debating stuff like this to think about how they would explain it to someone who knew next to nothing about either approaches.

JAM stack development puts the complexity on the build side but pays it back on the operational aspect and performance. I have been a Ruby developer for over 10 years and I will say that React/GraphQL is indeed much easier than a full blown Rails app both operationally and development wise. Heroku is a black box that runs Rails and provides databases/load balancers to back it. Here you are pushing your generated pages to a CDN, and using them to host your GraphQL endpoints.

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#33

Sharing a blog post that my team wrote on some of the benefits we saw from using Gatsby / a static frontend architecture when building https://shopflamingo.com : https://medium.com/harrys-engineering/how-we-used-gatsby-js-... In short, being able to scale to as many requests as your CDN can handle, with none of the operational overhead of a traditional web server, is really really nice.

Thanks for that post. That is impressive that you went with the best/fastest tech available today rather than just leverage what was done with Harrys. I am interested with what you actually used for the e-commerce part of it. Are you interacting with your systems that you made for Harrys with GraphQL or did you use a JAM stack orientated solution like gocommerce?

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#34

Sharing a blog post that my team wrote on some of the benefits we saw from using Gatsby / a static frontend architecture when building https://shopflamingo.com : https://medium.com/harrys-engineering/how-we-used-gatsby-js-... In short, being able to scale to as many requests as your CDN can handle, with none of the operational overhead of a traditional web server, is really really nice.

Thanks for that post. That is impressive that you went with the best/fastest tech available today rather than just leverage what was done with Harrys. I am interested with what you actually used for the e-commerce part of it. Are you interacting with your systems that you made for Harrys with GraphQL or did you use a JAM stack orientated solution like gocommerce?

Thank you! We have plans to build many more frontends in the coming years, so it felt like an appropriate time to step back and see what other solutions were out there.

For the e-commerce part of it, it's a custom API written in Scala that handles our inventory, warehouse, and fulfillment needs. As well as interfacing with Stripe for actual order processing. Want to get that team to write their own blog post as several people have asked about it!

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#35
post #16

Earlier quoted context omitted.

> I am kind of sold on "static" sites, but why is this particular stack and set of solutions so exciting? (As opposed to using, say, Rails on Heroku It's exciting because it's a static site and not using something like Rails? The static site approach still isn't that well known. Right now, I try to use static sites wherever I can because of their reduced complexity.

> it's a static site and not using something like Rails There's nothing "static" about this site. You're still querying a back-end database, you've just outsourced it to a third party. And looking at the example site, it doesn't exactly seem "simple" to me. Hell, instead of just using one (heroku) this one relies on TWO (netlify and the authors, takeshape). This "stack" seems to be mainly being pushed by the people t…

Well, that's not entirely correct. The database querying only happens at build time. The output is just static HTML/js/CSS that can be hosted on any CDN (or anywhere else) relatively easy.

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#36
Gatsby did a great job incorporating Mikhail Novikov's work on the Gatsby Source GraphQL plugin. Kudos!

If you want to see another example of Gatsby powered by a GraphQL native CMS, check out the following tutorial: https://docs.graphcms.com/tutorials/developers/gatsby_and_gr...

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#37

I have a vague idea of why this may be useful, but I wish people who upvote a new(ish) tech would take the time to put it in context as to why they upvoted it, why it is interesting, and why anyone should read about it. I am kind of sold on "static" sites, but why is this particular stack and set of solutions so exciting? (As opposed to using, say, Rails on Heroku (which I use as a default baseline), or even the alte…

TL;DR: It enables you create much more complex websites without the overhead they've required in the past, letting you focus more on client-side experience. Two years ago I went with TakeShape as my publication's CMS, for two key reasons. The first was that TS gave us a interactive visual front-end for managing content, which we could then publish as a static (i.e. pre-rendered HTML/CSS/JS files hosted on S3) website…

thanks for the detailed answer and examples

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#38
post #20
post #7

Earlier quoted context omitted.

JAMstack Javascript APIs Markup Coined by Matt Biilmann, Co-founder of Netlify

> Javascript APIs Markup In other words, every single page application ever built?

The https://jamstack.org/ page lists some examples of apps that are not JAMstack. Isomorphic sites and sites built with a CMS are examples.

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#39
post #16

Earlier quoted context omitted.

> I am kind of sold on "static" sites, but why is this particular stack and set of solutions so exciting? (As opposed to using, say, Rails on Heroku It's exciting because it's a static site and not using something like Rails? The static site approach still isn't that well known. Right now, I try to use static sites wherever I can because of their reduced complexity.

> it's a static site and not using something like Rails There's nothing "static" about this site. You're still querying a back-end database, you've just outsourced it to a third party. And looking at the example site, it doesn't exactly seem "simple" to me. Hell, instead of just using one (heroku) this one relies on TWO (netlify and the authors, takeshape). This "stack" seems to be mainly being pushed by the people t…

This approach absolutely does produce static web sites, just like any other static site generator. The querying of a back-end database doesn’t take place when a page gets loaded, it takes place when the static site is being built.

This article is just talking about one approach to taking one’s content and assembling it into a static website. The same basic workflow one should expect when dealing with any static site generator, the only difference being in the particulars of content aggregation and the build process.

Re: Use Gatsby.js and Headless GraphQL CMS to Make Your JAMstack Site Sweeter

#40
post #22

Earlier quoted context omitted.

Can you say a little about your use case. Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)?

> Are you equally excited about Gatsby and Jekyll(/Hugo/Pelican)? Gatsby, Jekyll and Hugo are all in roughly the same category of static site generators. However. The exciting thing about Hugo is how incredibly fast it builds. The exciting thing about Gatsby is how ridiculously pleasant it is to work with for a modern frontend developer. It has hot module replacement, built in (so you don't need to reload the page to…

I think Jekyll's entire advantage at this point is it's integration with GitHub pages.
Post reply on HN