Mike Bifulco

Posted on Jun 22, 2019 • Originally published at mike.biful.co

Do you have your own Gatsby site? Let's brainstorm a dev.to cross-poster

#react #discuss #opensource #productivity

So, like all good things, the idea for this post comes from a tweet:

This is something I've been ruminating on for a bit. I've even tried to build it - a few rtimes! I keep starting in on the work and getting lost in the millions of directions I could take it.

Here's what I'd like: When I publish a new post to my gatsby site, I'd like for that post to appear here on dev.to automatically.

It should:

recreate my post verbatim, from its original markdown source
use the canonical_url frontmatter field to make sure I retain SEO goodness on my post
happen without my intervention
be agnostic of where my posts are coming from. I use takeshape.io as a headless CMS for my site, so my individual posts aren't in source control
only take posts from my master branch, since I use feature branches for draft posts from time to time
use the dev.to API, of course

Nice to have:

maybe posts should be set to published: false at first, so I can preview/review/update them as needed for dev.to?

Possible approaches for this:

Tap into GitHub's webhooks somehow, and fire off a post here
Come from a job kicked off after CI, maybe? I use CircleCI, but would like this feature to be fairly implementation agnostic.
Use a GitHub App?
or a GitHub Action?
Perhaps just a lamba function deployed to AWS or Netlify Functions.

So - here's where I ask for your help. Surely there's a simple approach here I haven't thought of, or maybe it's a matter of collecting a few scenarios and building something based on 80/20.

What else am I missing here? I'd love your help. What use cases would you have for a crossposter from your gatsby site? How would you implement it? How can we help each other?

Top comments (22)

Shawn McElroy • Jun 22 '19

As long as you have an RSS feed Dev can already pull in your posts, auto populate the canonical_url and leave it unpublished in your drafts. No need to make an api. Just make sure your RSS feed is being generated

Abhishek Ghosh • Jun 24 '19

+1. My first instinct was to suggest this. I played around with this a little bit (I have some drafts lying around, haven't actually posted publicly so far) and it works like a charm. There can be some content editing required from time to time, so I strongly agree that it's important that posts start off as drafts and have a manual intervention for public posts.

I like this approach since its not too tightly coupled between gatsby<-->dev.to and works using a industry standard API (RSS) that's proven and can work as a generic solution across the board between various sources and sinks... Not to mention it's readily available without too much effort for gatsby!

There may be some specific use-case enhancements we envision that this may lack but I guess this is at least a great 80-20 scenario that works well :)

Mike Bifulco • Jun 23 '19

Ah, that's really cool! I didn't realize that was a thing.

Do you know if it updates your posts on dev if the RSS feed gets updated? Are there limits to the types/lengths of content that can be imported via RSS?

Shawn McElroy • Jun 23 '19

I don't believe it will update posts that were already published. But I have not tried that

Abhishek Ghosh • Jun 24 '19

The dev.to/settings/publishing-from-rss says so - at least for unpublished posts is what I'm guessing (it did for me).

Tim Smith • Jun 23 '19

In addition, there’s a gatsby plugin which automatically creates an RSS feed for your site. gatsbyjs.org/packages/gatsby-plugi...

Todd Chaffee • Jun 22 '19 • Edited

I think the approach you outlined so far is solid. I started out using netlify-cms so my deploys to Netlify are already automatic. One thing I would need is to transform is the frontmatter the top of my .md files. I also use a code formatter that allows me to highlight specific lines, and that breaks the code formatter here. I fix it manually each time. I would say start a repo and let's move the discussion there. A prototype shouldn't take long at all. It would also be easy enough to try out some different approaches you suggested to understand the pros and cons.

Amber Wilkie • Jun 22 '19

Have you thought about an IFTTT webhook? Push to Github and trigger an API call...?

Charles D. Villard • Jul 27 '19

It's funny how so many people can start thinking about the same thing in a given timespan. The folks at StackBit have a formal project working with The Practical Dev called #projectbenatar for a similar purpose, and I've personally been trying to write a script to manage this on build.

In my case, I have a Gridsome site using Netlify CMS for editing and Netlify for hosting. My goal has been to run a script after the build step to pull the latest file content from a posts folder, transform that into a POST request, and send that along to the DEV API. With GitHub's v3 Content API, you can retrieve a base64-encoded version of the file content, but then that means a lot of decoding and string manipulation.

Corey Alexander • Jun 22 '19

I like this idea alot! And I agree that we should get a repo going so that maybe we can all hack on this together!

I'm gonna subscribe to this post so I can help brainstorm and see if we can get this rolling!

Cheston • Jun 22 '19 • Edited

Is there any way to yoink the markdown files while your gatsby site in its build process on netlify(or wherever your build runs)

Iv never tried to run arbitrary JS in gatsby-node/gatsby-ssr. Guess it also depends on what netlify allows you to do when they build your site.

But I guess they would allow it because they already are making calls to headless cms to get the markdown in the first place.

But this way, you would just need a Gatsby-Dev-Plugin, that takes your markdown from whatever source you're using at build time and makes a post to Dev with your markdown on your behalf, all on Netlifys server(or whatever build server you use).

Mihail Malo • Jun 25 '19

A little confused: How do you use feature branches for draft posts if your posts are in a CMS API, not the repo?
Do you make a branch where the only difference is that it fetches and renders "draft" posts in addition to "published"?

Mike Bifulco • Jun 25 '19

Yeah, that's a great question! So while I do like using a CMS to keep my content online, I like the idea of keeping a copy of my actual blog content in the repo, so future migrations aren't a total headache. My (somewhat convoluted) workflow is currently as follows:

I author the post in my repo locally using typora. These posts go in the /src/posts/drafts folder in the repo, and are generally added to source control by way of a PR from a branch with a name like draft/post-name.
Once the post is ready to go, I create a header image using SketchApp
I make the post public by publishing it via TakeShape
I then cross-post to dev.to by starting a new post from the markdown in my repo, and uploading any missing images, and setting the canonical_url to my own blog

Jeky • Nov 29 '19

I'm using DEV as a headless CMS with stackbit.com/

All in-one-solution.

Not sure if it works with Gatsby tbf, but could be worth looking at for anyone interested.

leob • Jan 23 '20

Easiest way: use dev.to itself as your headless CMS - so, you blog on dev.to and then automatically cross-post contents to your Gatsby site ... actually someone already made a complete solution:

dev.to/geocine/creating-your-blog-...