Yes. I'm "fetching" all the articles every time (but caching) because I had these two requirements:
custom slugs (which you solve with the cache in getStaticPaths)
no rebuilds / no redeployments (I can add an article to dev any time and my blog will pick it up without having to regenerate, because it's using Incremental Static Regeneration)
Nice one, yeah I opted to use the Webhook calling Vercel Deploy hook on an article create/update rather than using Incremental Static Regeneration so that I don’t call the API when no changes have been made. The only downside with the webhook is that even if I edit and save without any changes, a deployment is kicked off.
I think in the near future (perhaps this weekend) I’ll change my website to call the API once to get all the articles, cache them, then convert the cached markdown and display - should solve my ‘429’ error! Thanks for the help
I was just wondering why dev.to API has different route options to display same data and you guys answered it for me! I am building my website and it's my first time using getStaticProps and getStaticPaths.
Yes. I'm "fetching" all the articles every time (but caching) because I had these two requirements:
getStaticPaths)Nice one, yeah I opted to use the Webhook calling Vercel Deploy hook on an article create/update rather than using Incremental Static Regeneration so that I don’t call the API when no changes have been made. The only downside with the webhook is that even if I edit and save without any changes, a deployment is kicked off.
I think in the near future (perhaps this weekend) I’ll change my website to call the API once to get all the articles, cache them, then convert the cached markdown and display - should solve my ‘429’ error! Thanks for the help
I was just wondering why dev.to API has different route options to display same data and you guys answered it for me! I am building my website and it's my first time using getStaticProps and getStaticPaths.
Thank you for clarifying some things for me!
Happy I could help!