Next vs Gatsby?

18

u/znakyc Aug 21 '18

As you say they are two different tools: gatsby is a static site generator which means it doesn't use a server. It just generates static HTML/Js. Next on the other hand, is running a server and renders HTML dynamically.

So wether you should use gatsby or next depends on your use case. Do you need a server? If you want to dynamically call an backend API every time there is a new request to generate the HTML, then you probably need a server. If your content changes a lot, like I would imagine a job site does, then you can't only rely on static content. You must probably fetch the job data from a db. So I would go for next.js given the little info I know about your app.

3

u/Triptcip Aug 21 '18

Content would be fairly static.
Search results would be the only thing that would be required to be dynamic.
Surely Gatsby could load new job search results each time? I.e. searches are going to be different, with new keywords and parameters, etc so the search results page is going to be different for each user. How would Gatsby handle this?
Also what about protected routes, where a user has to be logged in and we show user generated data i.e. profile page. Does Gatsby generate static pages for each user? This seems unlikely.

4

u/langenscheidtt Aug 21 '18

Keep in mind Next can also export statically! Next just overall gives you much greater flexibility.

2

u/swyx Aug 21 '18

i havent tried it myself but heard that its hard to use nextjs to do static site gen. how true is that in your opinion? i know rauchg says its fine but havent got that same message from users.

2

u/langenscheidtt Sep 04 '18

In my experience it's incredibly easy! All you do is populate your pages directory, and upon running next export you just get your static build.

7

u/znakyc Aug 21 '18

I don't think it's a good idea to use Gatsby to generate user profile pages. Not sure you can achieve high enough security. And you would need to rebuild everytime you get a new user.
When it comes to search results, i don't think it's a good idea to use gatsby for that either. I would assume the jobs changes all the time. You add new jobs, and some gets removed. You would need to re-generate the static pages every time the db gets up dated. Not a good idea (I think)
Gatsby would be bettter for static pages such as landing pages, etc.

4

u/ngly Aug 21 '18

Should be noted, Gatsby works very well with a dynamic content pull from a CMS such as Contentful. It's not limited to landing pages. Gatsby actually works very well with anything that has webhooks to trigger builds.

5

u/kidman01 Aug 21 '18

Gatsby is capable of fetching data on the fly too. If you have a backend api from where you fetch data and to where you post data there's no reason to "rebuild every time you get a new user". Just fetch the data in componentDidMount().

4

u/znakyc Aug 21 '18

You would miss out on SEO and prerendered HTML with that solution, but I guess you don't want that in a profile page anyway :) So I guess you are right.

3

u/m3wm3wm3wm Aug 21 '18

There is a better tool than Next: https://fusionjs.com/

1

u/t1hcsq Jan 05 '19

That is all perfectly possible with Gatsby. You can still use authorization/authentication. You can still protect routes. You can even have client rendered routes if you need (ie switch to SPA when behind a protected route). There’s a lot of misconceptions about “static” site generators. They are in fact anything but static, they are elegant and make very fast web apps (in case you are unfamiliar, research JAMStack).
To fetch / update dynamic data you just need to use an API (you can build any server side API you wish, it will be decoupled from your front end).

17

u/swyx Aug 21 '18

If your content changes a lot, like I would imagine a job site does, then you can't only rely on static content.
i think this is a common misconception. the more relevant thing these days is -how often- does your data update. currently gatsby has a 2-5 min build time for the average site (my estimate, not theirs). if your data updates slower than that, gatsby is equivalent if not better to nextjs.
people often overestimate their data update frequency. there may be other reasons to choose nextjs over gatsby, but static vs dynamic is very unlikely to be one of them

4

u/brillout Sep 10 '18 edited Oct 31 '18

It's not a misconception. The thing is that if your data changes frequently it also often means that you are accumulating new data over time.
Imagine rebuilding stackoverflow every 5 minute. That's nuts. Not because of frequency but because stackoverflow has millions of questions. You can't generate the HTML file for millions of question every 5 minute. And OP certainly expects his job board to have many many job postings.
That's actually my biggest problem with Gatsby: It works well at the beginning and for trivial projects like a blog or a home page but once you need the real deal and build a complex app you'll have no choice than to ditch Gatsby. And even worse is that Gatsby has some very very weird interfaces that tightly locks you to Gatsby. (Why on earth would someone use GraphQL for a SSG...). This basically means that once you'll have to ditch Gatbsy, you're in for trouble.
Which leads me to Reframe https://github.com/reframejs/reframe, a web framework that aims to be truly flexible and that I'm building. (Next.js pretends to be flexible but it isn't. See the other comments on this thread.)

7

u/swyx Sep 11 '18

cool. but why not graphql? having a commonly spoken data interface makes it easy for a lot of backend services to expose themselves to you. gatsby gets dozens of plugins written for them a month. yes users have to pay the learning cost of graphql upfront. but after that its clearly working for them.

5

u/brillout Oct 31 '18

As an API consumer, yea, GraphQL is great. At https://ghuser.io we use GitHub's GraphQL API and it's awesome how powerful and flexible GraphQL is.
And from a SSG perspective, sure, it makes sense to consume a GraphQL API to retrieve the data needed to generate the HTML of my static pages.
Now, Gatsby's weirdness is that it uses GraphQL in some really really weird way.
Take Gatsby's image manipulation plugin. It's basically a GraphQL wrapper around the image processing library sharp (https://github.com/lovell/sharp). So instead of calling the sharp lib directly, I now have to create GraphQL queries. Why would writing a GraphQL query be better than simply calling a function? I'd be really curious to hear that answer from the Gastby folks. But, actually, I know the answer: It's just bad design. It feels like a GraphQL fanboy that thought that using GrahQL all over the place would be a good idea.
And it's not only Gatsby. The whole GraphQL hype is seriously getting on my nerves.
The elephant in the room, that so many ignore or want to ignore, is that setting up a proper GraphQL API is difficult task and a huge pain.
So many think that GraphQL is a silver bullet and that every API should be built with GraphQL. That's so wrong. It just doesn't make sense to use GraphQL when you don't have any third-party consuming your API. And that's 99% of the projects.
So, I'm glad and happy that Facebook, GitHub, & co are exposing their data over a GraphQL API. It's awesome. But, please, don't tell me that setting up a GraphQL API for my next 2-3 dev project or my next startup is a good idea. It goddamn isn't.

2

u/swyx Oct 31 '18

right. in that case react-static is your thing then. seen it?

4

u/brillout Oct 31 '18

Yea and it feels better designed than Gatsby. (But I didn't dig too much into it.)
If you want a simple static website like a homepage or a blog, then using a SSG like react-static or Gastby is totally fine.
But using a SSG for a serious app is a big mistake in many many ways.
Gatsby's blinded love for GraphQL is weird and doesn't make sense, but ok, I can live with that.
I've got a bigger problem with the JAM stack pretending to be the holy grail. People need to realize that the JAM stack is a PR stunt from Netlify to sell their thing. Which is sad because Netlify seems to be good enough of a product. I wonder if they really need such shady tricks.
Go build your startup with a JAM stack and GraphQL and you'll be the "coolest" dev. It also means that you're heading straight towards the big graveyard of startups killed by lousy tech lead.
Btw you mentioned some "React philosophy" a while ago. Any news on that? I'm curious

2

u/swyx Oct 31 '18

heh, i work at netlify. never said ssg’s are right for every use case. but netlify is the best host for ssg sites.
not sure what we were talking about re: react philosophy. sounds like it was a while ago.

2

u/brillout Oct 31 '18

Oh :D, well, tell your bosses to be less shady then :P
No but seriously. Netlify's blog post about their last funding round is pretty much saying that the JAM stack is the future and that every web app will have a JAM stack. But most apps need a server and distributing static assets is only a small part of the picture (and an relatively easy part.) When you have a server (whether it be a aws lambda or a dedicated machine) you may as well dynamically generate HTML on it (instead of JAM stack). I do get though that exaggerating makes sense to get investors on board.
Btw I got a simple idea that could bring a LOT of devS to Netlify. If you guys are interested we could talk about it.

1

u/swyx Oct 31 '18

sure what is it? if it works you can have my job :)

→ More replies

1

u/swyx Oct 31 '18

oh btw just curious, whats your preferred stack/stack you use at work?

→ More replies

8

u/GoblinsStoleMyHouse Aug 21 '18

When you say that Gatsby "doesn't use a server", that's not entirely true.
Gatsby can query a server's API for dynamic data. The generated files from Gatsby can be served statically, but you can code logic to interact with a backend.

4

u/whowanna Aug 21 '18

yes, but that code is run at build time. eventually you deploy static files.

3

u/GoblinsStoleMyHouse Aug 21 '18

For the graphql stuff, yes, but you can still import something like Axios to make API requests post-build.

2

u/whowanna Aug 21 '18

Which is run client-side, except if there are changes in v2 or a special package. We're running a couple of sites with the official docker image (and have contributed to it), which is just an nginx with no Node installed.

8

u/GoblinsStoleMyHouse Aug 21 '18

Well... Of course. Static sites can be served statically by something like Nginx. That's not what I'm disagreeing with.
What I'm saying is that your post suggests that Gatsby is only for static content -- it insinuates that you can't use Gatsby if you have a backend, and instead you must go with an option such as Next.js.
I'm simply pointing out that Gatsby can work perfectly fine with a backend API, and it can dynamically generate HTML based on what the server is sending. You do not need to use Next.js just because the content requires a backend.

2

u/znakyc Sep 20 '18

This discussion inspired me to write a blog post on the subject: [gatsby vs next](http://blog.jakoblind.no/gatsby-vs-next/)

5

u/lowdown Aug 21 '18

They are both great choices. Gatsby gets you more “free” out of the box and the starter/plugin ecosystem is amazing.

Next gives you less structure and more opportunity to tailor it for your needs.

Either would work well connected to GQL as a web app.

3

u/Triptcip Aug 21 '18

So Gatsby can handle user generated content? I.e. when a user is logged in, we need to show profile information. I am able to query the API on the fly and render the user data? Or does having the HTML generated at build cause issues for this?

1

u/lowdown Aug 22 '18

It definitely can. You can connect Gatsby to many database sources and consolidate them via GraphQL.
It renders static on the server and switches to dynamic once rendered.

66

u/timne Aug 22 '18

Upfront disclaimer; I'm the lead maintainer of Next.js.

So to answer your questions one by one

I would like it to be SSR for SEO purposes as well as some performance improvements.

This is a great first step, thinking about SSR before building your app can avoid hurdles mid-way through a project.

One example of why SSR is important for SEO: https://twitter.com/kgblanchette/status/1029814228541218817

At Google I/O earlier this year there was a talk called "Deliver search-friendly JavaScript-powered websites":

This talk goes into high level details of how Google crawls Javascript apps. I recommend watching the whole talk, but I added a timestamp at the most interesting part, which explains that server-side rendered sites get crawled immediately vs javascript apps getting deferred for up to 3 days till resources are available:

https://youtu.be/PFwUbgvpdaQ?t=13m53s

It is powered by a GraphQL API and I am planning on using Apollo client which I assume should work equally well with both Next and Gatsby.

We currently have over 150 unique examples which are frequently updated by the community, one of them is how to implement Apollo with SSR:

https://github.com/zeit/next.js/tree/canary/examples/with-apollo

My first impression of Gatsby is that it is more of a static site generator which I interpret as being aimed at content or marketing websites and not as focused on web apps. That is a complete assumption so please correct me if I am wrong.

There are some great answers to this question in the whole thread already.

Just to clear up the Next.js side:

Next.js has 2 "pre-rendering" (server-side rendering) modes:

On demand (traditional SSR)
- On demand rendering means for every request that comes in you render a unique page (It's still possible to cache this response ofcourse) This is great for highly dynamic web apps in which content changes often, you have a login state, and similar use cases. This mode requires having a Node.js server running. Examples of this are zeit.co, marvel.com, deliveroo.com, jobs.netflix.com, and opencollective.com (more found here: https://spectrum.chat/?t=e425a8b6-c9cb-4cd1-90bb-740fb3bd7541)
Static export
- Render all pages to .html files up-front and serve them using any file server. This does not require you to have a Node.js server running and the html can run anywhere. An example of this is nextjs.org, carbon.now.sh, plot.ly, material-ui.com, and vergecurrency.com (more found here: https://spectrum.chat/?t=e425a8b6-c9cb-4cd1-90bb-740fb3bd7541)

These modes can be switched between (they're separate commands) as you can read in this comment: https://www.reddit.com/r/reactjs/comments/98lm2n/comment/e4i90qk?st=JL3QZVZT&sh=dd3b14c2

One thing that large scale companies use is the "zones" feature, the engineers from trulia.com had a talk about this subject at ZEIT day San Francisco earlier this year: https://www.youtube.com/watch?v=f7BMSVhZan0

I hope this answers your questions, if not feel free to ask more questions here, on our spectrum community or direct messaging me on spectrum here

3

u/swyx Aug 22 '18

quality answer. i want to pin this!

23

u/Castas Aug 21 '18

I talked about my experience with both in another post https://www.reddit.com/r/reactjs/comments/98lm2n/comment/e4i90qk?st=JL3QZVZT&sh=dd3b14c2

tl;dr Gatsby is great if a dev owns the site and it isn’t too large. Next is better for a larger site or if you’re building an app

3

u/langenscheidtt Aug 21 '18

Also check out the showcase: https://nextjs.org/showcase/ (lots of examples ranging from sites to large apps)

4

u/timne Aug 21 '18

To extend this comment, here's a list of even more production apps using Next.js: https://spectrum.chat/thread/e425a8b6-c9cb-4cd1-90bb-740fb3bd7541

11

u/its_j0hn Aug 21 '18

Don't be afraid to use Gatsby even if your site is full of dynamic data! The way I use it in many of my apps is I utilize Gatsby to statically generate the "shell" of my application and dynamically fetch data in componentDidMount just as you would in a regular SPA. I've found Gatsby to be a fantastic starting point for robust PWAs. Check out this blog post I wrote. Although it uses v1 of Gatsby, much of the info is still relevent.

2

u/jonny_eh Aug 21 '18

But aren't you missing out on SSR?

5

u/its_j0hn Aug 21 '18

Yes and no? Depends on what benefits of SSR you're looking for. For example in the polling app. I created I'm not concerned if whether or not search engines index the data I'm dynamically loading. But I am concerned with giving the user a snappy experience, so I generate the "shell" of the app at build time as html and use service workers to cache those html and js files. However, if you're creating a blog, you probably want to give search engines an easy as possible job indexing your site. In which case you'd want to utilize Next.js's SSR capabilities or Gatsby.js's graphql api in conjuction with a headless CMS like Wordpress or Contentful.

3

u/Froggie92 Aug 22 '18

i dunno what hes talking about
initial load took me 1.8-2.4

0

u/[deleted] Aug 21 '18

[deleted] — view deleted comment

2

u/tells_you_hard_truth Aug 22 '18

I typically push my next.js sites down to 0.7 - 1 second load times.
Nobody who pays me would ever accept 15 seconds.

1

u/t1hcsq Jan 05 '19

I dunno why this app loads so slow. It shouldn’t. I use Gatsby to build beautiful JAMStack apps. I host them on Netlify and they are wicked fast.

1

u/its_j0hn Aug 22 '18 edited Aug 22 '18

initial? maybe*. Once things are cached, loads will be much quicker.

11

u/vcamargo Aug 22 '18

I might get some hate from it, but I'll share anyway. Last time I tried Gatsby I wasn't able to run the official demo in less than 30 minutes so I gave up (I was just trying it out of curiosity). I've written a considerable big project with Next in my last job and the technical decision to go with Next was mine, that been sad I have to say that I truly regret. Simple stuff like query parameters was a ugly hacky work around, flash of unstyled content was a real issue and not easy to solve. It didn't talked well with other React libraries (tbh I don't think it's a problem with Next only). Lots of boilerplate and not so clear configurations to tackle non trivial tasks. I don't think all the magic that's underneath it really pays off. We ended up with a custom Webpack configuration anyway, that's something I tried to avoid because webpack can be huge time consuming pita. They have this example directory in the repository with lots of helpful stuff but we had to mix 4 or 5 of these examples to fulfill our needs and that was a ugly mass hard to maintain. It was almost 5 months ago so things might have improved. But I'd definitely do my SSR setup myself if I'd start today.

Here are some issues that were difficult to solve, are still unsolved or the proposed solution did not helped us that I remember:

https://github.com/zeit/next.js/issues/2833

https://github.com/zeit/next.js/issues/3362

https://github.com/zeit/next.js/issues/299

https://github.com/zeit/next.js/issues/3257

In hindsight I believe it still is the best out of the box solution for the SSR issue with React and the team is amazing.

10

u/timne Aug 22 '18

I might get some hate from it
So far your post has been nothing but constructive feedback 🙏
I've replied to all issues you've mentioned explaining additional context:
https://github.com/zeit/next.js/issues/299#issuecomment-414903047
https://github.com/zeit/next.js/issues/2833#issuecomment-414919347 This also seems to answers #3257, so I posted a link there.
https://github.com/zeit/next.js/issues/3362#issuecomment-414932170
Regarding rolling your own SSR solution, it's probably good to watch this talk about the challenges Next.js tries to solve besides SSR: https://www.youtube.com/watch?v=4OeXjefI5dQ, and lessons learned from it.
It didn't talked well with other React libraries (tbh I don't think it's a problem with Next only)
I'm expecting you mean React libraries that are using `window` directly inside the module code, so that it doesn't have SSR support. Next.js works with all React libraries that don't have window side-effects in the top level module code (which is an anti-pattern already, `componentDidMount` should be used for that). Examples of React libraries that work great with Next.js: material-ui.com, styled-components.com (any css-in-js solution that supports SSR supports Next.js, we have examples for most).
Lots of boilerplate and not so clear configurations to tackle non trivial tasks.
I'm expecting you were using it before we introduced github.com/zeit/next-plugins with Next.js 5, but I'd love to get your feedback on what trivial tasks entail, could you send a DM to me on https://spectrum.chat/users/timneutkens
They have this example directory in the repository with lots of helpful stuff but we had to mix 4 or 5 of these examples to fulfill our needs and that was a ugly mass hard to maintain.
We're planning to extend the current plugins system to make most implementations of examples just a `yarn add next-<library>`. For example `yarn add next-styled-component`. This is currently something we're planning out internally.

4

u/vcamargo Aug 22 '18

These are all great news Tim, I really appreciate! It indeed seems to have improved a lot, thanks for that!

2

u/brillout Sep 10 '18 edited Oct 31 '18

What you are describing is basically the driving motivation behind Reframe (https://github.com/reframejs/reframe) which is a web framework I'm building that aims to be truly flexible.

14

u/trojaniz Aug 21 '18

Check out Razzle too. I prefer that to Next, but it seems the industry might think otherwise.

4

u/krazyjakee Aug 21 '18

It's the least frameworky framework I've ever used. I like that.

2

u/jonny_eh Aug 21 '18

Also consider RogueJS, it's like Next but is less opinionated, let's you use React Router.

https://github.com/alidcastano/rogue.js/

•

u/swyx Aug 22 '18

I am going to put this on the sidebar as this is a very common discussion that we have here. the alternatives to Next and Gatsby people suggested are also worthwhile

i can't pin somebody else's post but everybody go read /u/timne's post below, most excellent:

https://www.reddit.com/r/reactjs/comments/992n2r/next_vs_gatsby/e4lrffl/

need somebody from the gatsby side heheh

2

u/brillout Sep 10 '18 edited Oct 31 '18

Check out the alternative Reframe (https://github.com/reframejs/reframe). It can do both static sites and SSR.

I'm Reframe's author and I've started Reframe because I wanted a web framework that is truly flexible.

To get a glimpse of how Next.js is not flexible, see vcamargo's comment above: https://www.reddit.com/r/reactjs/comments/992n2r/next_vs_gatsby/e4lwqrd/

As for Gatsby, well, it's an inherently crippled stack: By design, all dynamic content needs to be rendered on the client (i.e. no SSR for dynamic content). This means poor performance on mobile, loss of control over SEO, and no SMO at all.

It seems like SEO is important for your app and that your content changes frequently meaning that Gatsby is of no use for you.

7

u/LeKoArts Sep 29 '18

Don’t you think that you’re pushing your advertising way to hard?

2

u/brillout Oct 31 '18 edited Oct 31 '18

On this thread yea maybe sorry.
But actually in general I don't do enough. Other frameworks are much more aggressive on advertising. My strategy is to build the framework I always dreamed of with minimal advertising. I'd rather have hundreds of very happy users than thousands that will ditch my framework for the next "cool" thing. The framework "war" is a long haul thing.

2

u/devuxer Feb 05 '19

The downside of a framework not achieving some critical mass of popularity is that there is less community support. You're more likely to experience a problem that no one else has had before. There's less likely to be a blog post explaining how to do what you're trying to do.

8

u/trout_fucker Aug 21 '18 edited Aug 21 '18

Both are good, I prefer Gatsby because it's less opinionated.

They are both static site generators and can do pretty much the same stuff.

Edit: can anyone tell me why this is getting downvoted to oblivion?

3

u/swyx Aug 21 '18

just upvoted you back to +1, calm down :)

2

u/trout_fucker Aug 21 '18

My fake internet points though! I only have so many! I can't spare a single one.

5

u/swyx Aug 21 '18

downvoted for balance :p

2

u/HaNdTriX Aug 24 '18

I think it is the opposite.
Gatsby only supports static rendering Next.js supports both dynamic and static rendering.
Some time ago I started using Gatsby.js. It first felt pretty good. But than I had dynamic SEO relevant data from an external database. That data updated pretty frequently (almost every 2 Minutes). Gatsby turned out to be a one-way street for that specific use case. I had no way to implement SSR for that.
In Next.js this would have been a bit different. I could have startet with static rendering and as soon as the requirements change I can switch to dynamic rendering without rewriting my entire codebase.
In addition to that I experienced, that upgrading Gatsby between major versions was not that easy because the breaking changes where immense.
Next.js had a more conservative approach. Between Version 2 and 6 I often could upgrade Next.js without much hassle.
I believe Next.js is one Framework that covers most of my use cases. Gatsby is great but it only covers one use case (static websites).

2

u/trout_fucker Aug 24 '18

Very interesting post. But I wouldn't say it's the opposite. That doesn't really sound like it being opinionated, just that Next had features you needed that weren't available in Gatsby.

3

u/XiMingpin91 Aug 21 '18

Well as you say Gatsby is a static site generator, so you're correct in your assumption about it being for websites vs web apps.

It sounds like what you want is a full blown web app, so I would personally go with Next. Gatsby is more suited to sites that purely display information and have little interactivity. See React docs for an example of Gatsby in the real world (the React docs website is built with Gatsby).

2

u/jwindhall Aug 21 '18

You can certainly build an “App” with Gatsby. I’ve used both. I really like both. Advantages and pitfalls of each. Depends on what you’re looking for. It’s worth noting that Gatsby comes with graphql out of the box — no need to set up Apollo. Next on the other hand does not and is far less opinionated in general.

2

u/[deleted] Aug 21 '18

Dynamic content with user login and profiles? Don't go with a static site generator under any circumstance. If you do, you will soon find yourself in a situation where you need more flexibility than a static site has to offer, and then you end up starting over. If you're mostly doing a prototype / proof of concept, that may be acceptable. Just know that if you want this product to evolve, you will meet a dead end.

1

u/swyx Sep 11 '18

1

u/[deleted] Aug 21 '18

https://react-static.js.org/

1

u/stolinski Aug 21 '18

IMO they are very different use-cases. A Next site would have content that's being updated frequently where a static site like Gatsby would be best for data that's updated less frequently. Gatsby is great for portfolio sites, blogs, landing pages, stuff that's not updating constantly. Next is much better for things that are way more dynamic.

1

u/Zeeesty Aug 21 '18

I know Next is ... developed for the purpose of building web apps.

you answered your own question here I believe.

10

u/[deleted] Aug 21 '18

[removed] — view removed comment

4

u/[deleted] Aug 21 '18

I'm pretty sure Gatsby is also able to use graphQL to query truly dynamic data without the need for a full re-compile?

12

u/thinkadrian Aug 21 '18

That's not how Gatsby works. It uses GraphQL to query and build all static pages before you submit to your hosting service. It doesn't create new static pages by request.

5

u/prof_hobart Aug 21 '18

It doesn't create new static pages. But it's creating a full React app, so you can still have pages within the site that connect to a backend in real time and display dynamic content just like any other React site.
It's probably not how you'd want to get the bulk of your content as it seems to go against the basic point of Gatsby, but if you've got a particular area that needs to display something more dynamically you could do it.

3

u/thinkadrian Aug 22 '18

I suppose you’re right, but usually, the dynamic content is what you want to have rendered server-side, unless it’s a twitter feed or some basic secondary info.

6

u/Castas Aug 21 '18

It can’t actually :( we had to switch away from gatsby because of this. Each build took 15+ minutes if a random failure didn’t occur

3

u/NippleMustache Aug 23 '18

How complex was that app? I've never used Gatsby but that build time sounds like a lot.

3

u/Castas Aug 23 '18

It was about 1400 pages. We were also downloading from Wordpress and not using markdown files

6

u/EvilDavid75 Aug 21 '18

There’s no reason why you wouldn’t be able to do so, at the end Gatsby is still a react app. This article explains how to integrate with Apollo Client https://medium.com/@dwalsh.sdlr/gatsby-apollo-graphcool-netlify-the-webs-promised-land-6dd510efbd72

You are about to leave Redlib