Hi Julian! Our solutions are extremely similar. I had a look through your article, good read - I could have used diagrams like yours to make mine a bit clearer!
I do this so that I am able to use the pre-rendered HTML that Dev.to supplies (body_html in the article object), for some reason it isn't included when you query all your published articles - I saw you're parsing the provided article markdown. I wanted to use the supplied HTML so that I didn't need to parse Markdown just to see if it was viable/make the website simpler.
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.
Hi Julian! Our solutions are extremely similar. I had a look through your article, good read - I could have used diagrams like yours to make mine a bit clearer!
AFAIK the main difference between yours and mine is that for
getStaticPropsI'm calling the Dev.to API that returns the information for a specific article (/articles/:id) whereas you would call get all articles (if not for the cache) (my API call for a single article).I do this so that I am able to use the pre-rendered HTML that Dev.to supplies (
body_htmlin the article object), for some reason it isn't included when you query all your published articles - I saw you're parsing the provided article markdown. I wanted to use the supplied HTML so that I didn't need to parse Markdown just to see if it was viable/make the website simpler.I think if I was to refactor my implementation to make fewer requests I would save the data returned from the get all articles to a cache file in the
getStaticPathsfile, and in thegetStaticPropsfile read the data directly from the cache rather than querying the Dev.to API. I already use a cache file to map the page slug to an article ID. The getStaticPaths function writes the cache with a minified array which is then read by the getStaticProps function to find the article ID for a page.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!