The final weekend of January 2021 was uneventful in comparison with other years - in the UK we were in full lockdown due to the Coronavirus. It was...
For further actions, you may consider blocking this person and/or reporting abuse
Hi! I'm doing something very similar.
dev.to/juliang/using-dev-to-as-cms...
I'm using disk cache to solve the 429 error "Too many requests".
I would love to know what you think.
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!
This is a risky direction.
In 2035, Dev.to is bankrupt and no longer exists. You still have your Markdowns but you lose the uploaded pictures.
I have a few blog posts written around 2008 where images were uploaded to third party hosting services. In 2017, I discovered that the images hosting service was closed and all these images disappeared.
I had to dig out the original files of these blog posts and re-export the images. The files were in Kingsoft WPS 97 format, and I had to download that application in order to open the files.
I'm still mourning the loss of a few videos from 2006 that I uploaded to now-defunct third party hosting and no longer have a backup myself.
I disagree.
There is nothing wrong or risky in leveraging Dev.to as a CMS, as long as you back up your data.
It would be pretty trivial to set up a service/app to save your articles each day using the Dev.to API and performing a download of any images you've used in your articles.
Why not take advantage of the free platform Dev.to is providing? Just take backups of your data.
loved your website!
Thanks Vinay!
Also love next.js <3
looks amazing dude! great work
Cheers!
Genius.
Hi first time loading the site and it was super fast! Can you do an article of how you did it?
Yes I’m working on one at the moment!