블로그로 DEV.TO 가져오기

트위터의 소프트웨어나 인터넷 개발자에 관심을 가지면 블로그 플랫폼 미디어를 둘러싼 불평을 발견할 수 있다.그들이 폐쇄식 화원 방식을 채택하고 독자들에게 매달 무료 내용의 비용을 요구하기 시작한 이래로 많은 개발상들이 매체에서 다른 내용으로 전환하는 것을 고려하고 있다.두 가지 유행하는 선택이 자주 논의된다. 개인적이고 맞춤형 블로그를 내놓거나 내용을 다른 유행하는 플랫폼 dev.to로 옮기는 것이다.
이 두 가지 방법은 모두 실행할 수 있고 정적 사이트 생성기의 보편성을 고려하면 실현하기 쉽다.블로그를 만들면 전시를 더욱 잘 통제할 수 있지만, 정기적으로 dev.to에 블로그를 발표하는 장점은 무시할 수 없다.직접적인 장점은 지원과 뜻이 맞는 개인으로 구성된 대형 커뮤니티와 절제된 논평, 검색엔진 최적화, 포지셔닝이 편리한 독자층을 방문하여 당신의 리키 프로그램 내용을 포지셔닝할 수 있다는 것이다.dev.to팀은 그들이 하고 있는 일과 공유할 수 있는 내용도 투명하기 때문에 일의 진전을 항상 볼 수 있다.
지금, 나는 내가 dev.to에 대해 약간의 편견을 가지고 있다는 것을 인정한다.나는 줄곧 그의 발전에 관심을 가지고 있다. 벤 할버른(Ben Halpern)이 실용 개발에 대한 초보적인 개인 블로그에 대한 생각부터 오늘날까지 강력한 플랫폼과 업무까지.가능하다면, 나는 그것을 투자할 것이다. 이것이 바로 내가 이 플랫폼을 얼마나 숭배하는가이다.이 모든 것은 나의 건의에 대해 유보적인 태도를 가지고 있다는 것이다.나는 이것이 내용을 구축하고 지역 사회와 공유하는 좋은 곳이라고 생각한다. 그러나 나는 자신의 사이트에서 자신의 블로그를 가지고 있는 것도 좋은 점이 있을 수 있다는 것을 볼 수 있다.이 문장이 너에게 겸득하는 방식을 보여줄 수 있기를 바란다.

OG 패키지에서
dev.to의 주목받는 특성 중 하나는 올해 5월 초에 발표된 새로운 특성이다.인증된 사용자가 게시물을 작성, 업데이트 및 읽을 수 있도록 하는 직접 RESTAPI입니다.내 개인 블로그를 업데이트할 때, 나는 그것을 사용해서 게시물을 도입하고 전용 페이지에 표시하려고 시도해 왔다. 나는 그것이 많은 것을 제공했다고 생각한다.나는 아직 지금까지 사용할 수 있는 모든 단점을 깊이 연구하지 않았지만, 나는 지금까지 내가 가지고 있는 것을 건드리고 내가 가지고 있지 않은 계획을 토론할 것이다.
제가 여기서 소개한 것은 DEV Articles API와 정적 사이트 생성기를 결합하여 사용하는 규정적인 방법이 아니라 실험적인 전략입니다.비록 코드는 장래에 자신의 현재 실현을 실현하지만, 나는 그것을 하나의 건의로 간주할 것을 건의한다.

앞으로 나아가기 전에 가설과 기술을 빨리 적어 두세요.

As I mentioned before, a lot of the discussion I've seen has mentioned the option of rolling out a blog using a static site generator. Thus, the rest of this article assumes some familiarity with at least one static site generator tool. If you're unfamiliar with what a static site generator is, I highly recommended learning about the JAMStack architecture, and maybe exploring Gatsby or Gridsome, before coming back to this. Static site generators are a massive topic, but I've found these easy to get started with. I've already implemented this using Gridsome, a static site generator built using Vue.js, so my examples will be modeled on that. To the best of my knowledge, most static site generators will have the infrastructure in place to accomplish this, so don't feel locked into any one particular tool.

개발자 게시물 목록 표시

게시글 목록을 얻는 것부터 시작합시다.DEV Articles API는 영패에 액세스할 필요가 없는 게시물을 검색하는 데 사용할 수 있는 검색 노드를 제공합니다.https://dev.to/api/articles에 첨부된 검색 문자열만 필요합니다.

https://dev.to/api/articles # Gets the top 30 "hottest" articles
https://dev.to/api/articles?tag=keyword# Gets articles tagged with "keyword"
https://dev.to/api/articles?username=thatUser # Gets articles written by thatUser
https://dev.to/api/articles?state=fresh # Gets "fresh" articles
https://dev.to/api/articles?state=rising # Gets "rising" articles
https://dev.to/api/articles?top=10 # Gets the top positively-reacted-to
                                   # articles from the past 10 days

요청마다 일반적으로 되돌아오는 게시물을 30개씩 페이지로 나눈다.다음 30개 문장을 얻으려면 page 검색 문자열을 추가해야 하기 때문에 지난 10일 동안 31~60위를 차지한 문장은 다음과 같다.

https://dev.to/api/articles?top=10&page=2

반환된 배열의 각 JSON 객체에는 문자열 매개변수 질의에 적합한 각 게시물의 메타데이터와 프런트엔드 내용이 포함됩니다.따라서 만약 우리가 브라우저에서 https://dev.to/api/articles?username=cdvillard을 사용한다면, 우리는 이 빨판의 수조를 얻을 수 있을 것이다.

{
  type_of: "article",
  id: 90594,
  title: "RTFC: Why patience is a developer's best friend",
  description: "Patience as a virtue can mean a lot to a developer.",
  cover_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--Rqg-VarX--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/36d4a4hhje64epv8248d.jpg",
  published_at: "2019-03-12T22:24:53.528Z",
  tag_list: [
    "edit",
    "beginners",
    "productivity",
    "cdvillard"
  ],
  slug: "rtfc-why-patience-is-a-developers-best-friend-l95",
  path: "/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  canonical_url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  comments_count: 0,
  positive_reactions_count: 11,
  published_timestamp: "2019-03-12T22:24:53Z",
  user: {
    name: "Charles D. Villard",
    username: "cdvillard",
    twitter_username: "cdvillard",
    github_username: "cdvillard",
    website_url: "http://cdvillard.github.io",
    profile_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--cX9wiyae--/c_fill,f_auto,fl_progressive,h_640,q_auto,w_640/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg",
    profile_image_90: "https://res.cloudinary.com/practicaldev/image/fetch/s--xG2hWmsO--/c_fill,f_auto,fl_progressive,h_90,q_auto,w_90/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg"
  }
}

만약 당신이 이전에 DEV에 어떤 글을 발표한 적이 있다면, 나는 당신이 당신의 글이 어떤 모습인지 시험해 보라고 격려합니다.
선택한 정적 사이트 생성기의 권장 방법에 따라 검색하려는 글에 GET 요청을 작성합니다.이것은 XMLHttpRequest으로 완성할 수 있지만, 나는 Axios 라이브러리를 사용하여 자신에게 좀 더 쉽게 할 수 있다.

  // Starts a GET request to the DEV API
  axios.get("https://dev.to/api/articles?username=cdvillard&tag=cdvillard")
      .then(response => { // When a response is received
        this.blogList = [...response.data]; // Add that to my Vue data
      })
      .catch(err => { // If something goes wrong
        console.log(err); // Log it to the console
      })
  }

당신은 내가 요청에서 나의 사용자 이름을 조회할 뿐만 아니라, 또한 하나를 조회하는 것을 이미 알아차렸을 수도 있습니다.내 사용자 이름?왜?알겠습니다. DEV-API는 글의 모든 내용을 되돌려줍니다.여기에는 토론으로 표시된 모든 게시물이 포함되며, 이는 DEV가 포럼 게시물과 유사한 방식을 나타냅니다.내 사용자 이름으로 내가 표시하고 싶은 문장을 표시하는 것은 단지 이런 내용을 필터하는 해결 방법일 뿐이다.
이 데이터를 전방으로 가져오는 것은 특정 정적 사이트 생성기의 구조에 달려 있지만, 접근하는 방법을 배우면 교체할 수 있습니다.결국 정적 사이트 생성기의 대부분 기능은 사이트를 신속하게 구축하고 실현할 수 있다는 데 있다. 이것은 순환적으로 교체 표시를 만드는 추가 기능을 의미한다.Gridsome에서 이것은 Vue의 v-for 명령을 사용하여 데이터를 호출하고 각 대상에 구축한다는 것을 의미한다.

<!-- The v-for creates an instance of each "blog-preview" component 
for each "blog" in the "blogList" we got earlier, 
and attaches each property from the "blog" to an associated property 
of the "blog-preview" component. Kind of like connect-the-dots. 
If you want to learn more about Vue components and props, start with 
the Vue documentation at https://vuejs.org/v2/guide/components.html -->
<blog-preview v-for="blog of blogList"
  :key="blog.id"
  :blog-title="blog.title"
  :blog-description="blog.description"
  :blog-link="blog.canonical_url"
></blog-preview>

만약 모든 것이 순조롭다면, 너는 너의 문장이 너의 선택 페이지에 열거된 것을 보아야 한다.만약 내가 어떻게 이 점을 했는지 알고 싶다면, 마음대로 my repo here을 보세요.

현재 진행 중인 작업 자리 표시자와 게시물

개발자 게시물 표시

그래서 우리는 게시물과 링크 목록을 얻었지만, 실제로 우리는 적당한 게시물을 표시하지 않았다.이를 위해서는 서로 다른 API 노드를 호출해야 합니다. 특히 우리가 찾고 있는 글의 id을 호출해야 합니다.API의 이 부분에서 처리해야 할 표면은 많지 않지만, DEV의 markdown 렌더기에서 생성된 HTML을 포함한 문장에 대한 모든 정보를 얻었습니다.https://dev.to/api/articles/90594에 요청하면 다음 JSON 객체로 돌아갑니다.

{
  type_of: "article",
  id: 90594,
  title: "RTFC: Why patience is a developer's best friend",
  description: "Patience as a virtue can mean a lot to a developer.",
  cover_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--Rqg-VarX--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/36d4a4hhje64epv8248d.jpg",
  readable_publish_date: "Mar 12",
  social_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--ENrc8Sz1--/c_imagga_scale,f_auto,fl_progressive,h_500,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/36d4a4hhje64epv8248d.jpg",
  tag_list: "edit, beginners, productivity, cdvillard",
  tags: [
    "edit",
    "beginners",
    "productivity",
    "cdvillard"
  ],
  slug: "rtfc-why-patience-is-a-developers-best-friend-l95",
  path: "/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  canonical_url: "https://dev.to/cdvillard/rtfc-why-patience-is-a-developers-best-friend-l95",
  comments_count: 0,
  positive_reactions_count: 11,
  created_at: "2019-03-12T22:22:46Z",
  edited_at: "2019-05-18T13:24:39Z",
  crossposted_at: null,
  published_at: "2019-03-12T22:24:53Z",
  last_comment_at: "2019-03-12T22:24:53Z",
  body_html: "<p>I'm typically not a patient person. It's a flaw I cop to a lot, and it's something I actively...",
  ltag_style: [ ],
  ltag_script: [ ],
  user: {
    name: "Charles D. Villard",
    username: "cdvillard",
    twitter_username: "cdvillard",
    github_username: "cdvillard",
    website_url: "http://cdvillard.github.io",
    profile_image: "https://res.cloudinary.com/practicaldev/image/fetch/s--cX9wiyae--/c_fill,f_auto,fl_progressive,h_640,q_auto,w_640/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg",
    profile_image_90: "https://res.cloudinary.com/practicaldev/image/fetch/s--xG2hWmsO--/c_fill,f_auto,fl_progressive,h_90,q_auto,w_90/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/11581/9217c42f-218d-4a3c-b565-9a7e9b597cd1.jpg"
  }
}

body_html 속성은 당신의 눈길을 끌 수 있습니다. 왜냐하면 그것을 사용하면 블로그 게시물을 포맷하는 많은 번거로움을 줄일 수 있기 때문입니다.

DEV에 게시하고 게시물 업데이트

API를 사용하여 DEV에 게시하는 것에 대해 이야기할 때, 나는 내가 아직도 그것을 사용하는 것을 배우고 있다는 것을 인정해야 한다.나는 아직 그것으로 실험을 진행하지 않았지만, 이것이 바로 DEV의 API가 진정으로 강한 곳이라고 생각한다.이론적으로 정태적으로 생성된 사이트를 가진 사람은 자신의 사이트를 유지하는 동시에 dev.to에 교차 발표할 수 있다.구체적으로 어떻게 해야 하는지는 또 다른 블로그 글의 문제이지만, 우리가 JAMstack에서 일하고 있다는 것을 감안하면 서버 기능이 작용하지 않는 곳일 가능성이 높다.앞으로 며칠 동안 Netlify와 기능 서비스를 시도해 보겠습니다. 이 점을 어떻게 실현하는지 보겠습니다.

여기서 어디로 갑니까

그 중에서 DEV API가 얼마나 유연한지, 그리고 DEV.to에 자신의 블로그와 게시물을 어떻게 게시하는지 알 수 있기를 바랍니다.본문을 작성할 때, 나는 이렇게 하는 것이 검색엔진 최적화에 미칠 수 있는 영향에 대해 논평할 수 없지만, 나는 어떠한 중대한 부정적인 영향도 없을 것이며, 데이터가 당신을 찾도록 추진하지 않을 것이라고 예상한다.개인적으로 나는 너희들 중 생각이 있는 사람이 이 지역사회에 가입하여 그것이 더욱 재미있어지도록 도와주기를 바란다.소리가 많을수록 좋다.