일단 하나를 해보자

GraphQL은 Facebook에서 개발하고 오픈 소스로 제공하는 API(애플리케이션 프로그래밍 인터페이스)용 쿼리 언어 및 런타임입니다. API 구축을 위해 REST(Representational State Transfer)에 대한 보다 효율적이고 강력하며 유연한 대안을 제공합니다.

GraphQL API에서 클라이언트는 필요한 데이터를 지정하는 요청을 하고 서버는 고정된 데이터 집합이 아닌 요청된 데이터만 반환합니다. 이렇게 하면 데이터를 과도하게 가져오거나 적게 가져오지 않고 필요한 데이터를 정확하게 검색하고 여러 요청이 아닌 단일 요청으로 데이터를 받을 수 있습니다.

GraphQL은 또한 클라이언트와 서버 간에 교환되는 데이터에 대한 유형 시스템을 제공하여 요청과 응답이 실행되기 전에 유효성을 검사할 수 있도록 합니다. 그 결과 성능이 향상되고 복잡성이 감소하며 API가 더 예측 가능해집니다.

GraphQL의 또 다른 주요 기능은 실시간 업데이트 및 구독 지원으로, 실시간 및 협업 애플리케이션 구축에 매우 적합합니다.

전반적으로 GraphQL은 API를 구축하는 보다 효율적이고 유연하며 강력한 방법을 제공하며 특히 여러 데이터 소스 및 서비스와 상호 작용해야 하는 모바일 및 웹 애플리케이션을 위한 최신 애플리케이션 개발에 널리 사용되는 선택이 되었습니다.

GraphQL is a query language and runtime for APIs (Application Programming Interfaces) that was developed and open-sourced by Facebook. It provides a more efficient, powerful, and flexible alternative to REST (Representational State Transfer) for building APIs.

In a GraphQL API, the client makes a request specifying the data it needs, and the server returns only the requested data, rather than a fixed set of data. This makes it possible to retrieve exactly the data you need, without over- or under-fetching data, and to receive the data in a single request, rather than multiple requests.

GraphQL also provides a type system for the data being exchanged between the client and the server, making it possible to validate the requests and responses before they are executed. This results in better performance, reduced complexity, and a more predictable API.

Another key feature of GraphQL is its support for real-time updates and subscriptions, which makes it well-suited for building real-time and collaborative applications.

Overall, GraphQL provides a more efficient, flexible, and powerful way to build APIs, and has become a popular choice for developing modern applications, especially for mobile and web applications that need to interact with multiple data sources and services.

axios는

지원하는 브라우저가 더 많고 

에러핸들링이 좋고

자동으로 데이터가 json형태로 되어 넘어간다

Automatic JSON data transformation

As we saw earlier, Axios automatically stringifies the data when sending requests (though you can override the default behavior and define a different transformation mechanism). When using fetch(), however, you’d have to do it manually.

Compare:

// axios
axios.get('https://api.github.com/orgs/axios')
  .then(response => {
    console.log(response.data);
  }, error => {
    console.log(error);
  });

// fetch()
fetch('https://api.github.com/orgs/axios')
  .then(response => response.json())    // one extra step
  .then(data => {
    console.log(data) 
  })
  .catch(error => console.error(error));

fetch는 직접 json화를 해줘야하지만

지원하는 브라우저 문제 등을 충분히  해결할 수 있다.

결론

Axios는 대부분의 HTTP통신 요구사항을 위해 컴팩트 패키지로 사용하기 쉬운 API를 제공한다.

하지만 fetch()메소드를 사용해서도 Axios 라이브러리의 주요기능을 완벽하게 재현할 수 있다.

는 글

https://blog.logrocket.com/axios-vs-fetch-best-http-requests/

https://medium.com/@dongha.sohn/bitcoin-8-%ED%95%A9%EC%9D%98-consensus-90e879d80b16

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=gitacademy01&logNo=222027103524 

(이거는 비교조건/p2p개념 링크)

주의!

나름의 이해라서 백퍼 맞지 않을 수 있음ㅎㅎ

(이해를 돕기 위해 설명해준 학우분 감사합니다.)

수업에서 블록생성하고 연결하고 검증하고 서버열어서 블록보여주고 이런 걸 해봤는데

드는 생각이 왜 p2p를 하지? 였음

노드간의 통신을 작동해야된다는데

local3001 서버 열고 여기서 블록생성하고 검증하면 여기가 중앙서버고

노드, 참여자용 서버로 만든 6001, 6002,6003은 블록 생성해서 중앙서버가 검증자해주는 건가? 

잉 그러면 탈중앙화가 아닌데? 혼돈;;;

내가 이해를 잘못하고 있었음

"먼저 블록 채굴에 성공한 채굴자는 해당 블록을 주변에 전파하게 된다. 중요한 사실은, 이때 전파하는 블록은 채굴에 성공했다고 확신할 수 없는 블록이며 검증을 거쳐 블록체인에 연결되어야 한다. 거래는 노드들에게 전파되며 검증의 과정을 거치듯, 블록 또한 검증을 거치게 되며 검증의 조건은 다음과 같다....."

우리 p2p하려고 웹소켓 써서 주고받는 통신하잖아

그 전에는 기본 포트는 컴퓨터 내에서 물리적으로 연결되어있으니까 접속이 가능한거고

웹소켓으로 내 컴퓨터를 3개의 컴퓨터로 분리하다고 치고 6001, 6002, 6003에 하나씩 컴퓨터가 있고

실제로는 하나니까 물리적으로 3001에 연결될 수 있는거라 서버는 3001만 열어도 될거같기도하고..

암튼 결론은!

내가 연 3001은 그냥 이 모든게 보이는 용도로만 쓰이는 보여주기용 서버이고 

실제로 블록 생성, 검증은 

노드들이 하는거임

노드들의 서버 6001, 6002, 6003

그니까 얘네끼리 통신하는 p2p서버로 하는거지.

처음에 시작했을 때 

제네시스 블록을 모든 노드들이 갖고 시작하고 

그 뒤에 줄줄이 블록을 생성하는 거임

이제 검증과정을 거쳐서 서로블록을 비교하고

황금블록 발견한 애꺼가 당첨되면 원본 블록체인에 연결되고

나머지는 허탕치고 다시 다음블록 만드는 거임

그 checkedValid 코드부분은 

//블록구조 유효한지
//현재 블록의 인덱스가 이전 블록의 인덱스보다 1만큼 큰지
//이전블록의 해시값과 현재 블록의 이전해시가 같은지
//데이터 필드로부터 계산한 머클루트와 블록헤더의 머클루트가 동일한지
//이 조건 다 맞으면 올바른 구조체이다

이 조건들로 블록이 진짜인지 증명하는거고

진짜 블록이어도 아직 당첨은 안된거지 원본에 연결안된거

이제 비교해서 당첨될라면

p2p끼리 통신..

누구꺼를 연결할걸로 할지...

chainedBlock에 

replaceChain 함수 주석처리 해놨는데 이거가 

p2pServer.js에서 이렇게 함수호출되어있음

이걸로 누구꺼 연결할지 찾는거 아닐까 짐작..

블록들 비교까지 한다면

 어떻게 하는지는 모르겠다 어렵다!!!

아무튼 해야되는거는 

블록마이닝(채굴)/ 지갑생성/ 현재 상황 시각화 / DB 채굴 저장

사실상 지갑생성까지 수업때 한거긴한데

위같은 비교검증은 없어서

완전한 블록체인은 아닌거같고..흠