8

I am wondering if there are example cases where it would make sense to use a typical Node.js client-server app where the blockchain node would be running on the server. At first glance, this would bring back the problems of centralisation related to trusting the server if it's the server itself running the node. However, I was wondering if there are real cases where this would be appropriate (there are questions here of people which seem to be doing this - this, this for example).

For further clarification: I read this post which claims the tools needed for Dapp development are not yet gathered. As such, I was wondering thinking of alternatives which could still leverage the blockchain's features of reliability etc but running in a client-server framework.

Improve this question
3

I think that the answer by @JohnAllen does not make sense to me. The most common practice is precisely to have the front-end UI of a DApp be implemented as a NodeJS application that uses the Web3 Javascript library to communicate with an Ethereum node running locally, i.e. on the same server as the NodeJS application.

Here, the NodeJS server is not itself running the Ethereum node. (Take care to differentiate between the two uses of the term "node" here) Both the Ethereum node (which could be geth, Parity, pyethapp or any other Ethereum client software) and the NodeJS application are running on the same machine. The Ethereum node is a client of the Ethereum blockchain that it is synchronized with. The NodeJS application communicating with a locally running Ethereum node, in fact, reduces centralization, because different applications do not need to trust any particular remote Ethereum node. Also, accounts are always created on a local node because the private keys generated should remain on the local machine. The commands to create and manage accounts are in the web3.eth.personal interface which, by default, is only enabled over IPC (inter-process communication), i.e. can only be run on a local Ethereum node.

ADDITION: If a DApp's front-end interface is served by a NodeJS application running on a particular server, it introduces some centralization. However, as long as the DApp can still maintain its model's state (using "model" in the sense of MVC) even if the NodeJS server goes down, and if anyone else could host the NodeJS application thus restoring the "view" of MVC and providing access to the back-end (contract code deployed on the blockchain), then the disadvantage of centralization is minimized. So, my point is that centralization/decentralization is not a black-or-white classification. Any application lies somewhere on a spectrum. A DApp could have its UI also served in a decentralized fashion, e.g. I have heard Swarm & IPFS suggested for this but I do not know more details on how that would be done. It all depends on the particular case and how much decentralization is really needed.

Improve this answer
6
  • Thanks for the clarifications! I think I understand what you mean. Would it then be correct to state that in a nodejs app then the web3 const web3 = new Web3(new Web3.providers.HttpProvider(provider)); would always be in client-side code and never server-side code. Is this correct?
    – mcansado
    Sep 7 '17 at 18:41
  • 1
    "The most common practice is precisely to have the front-end UI of a DApp be implemented as a NodeJS application" NodeJS is not a front-end or UI at all.
    – JohnAllen
    Sep 7 '17 at 18:48
  • The NodeJS application serves the HTML/JS/CSS to a regular browser that end-users can use to interact with the DApp. It is the front-end to the DApp, where the back-end is the contract code deployed on the blockchain. I will look up a clearer explanation of this.
    – Ajoy Bhatia
    Sep 7 '17 at 19:49
  • In response to @mcansado's comment above, the web3 object could either be in client-side or server-side code, too - referring to the addition to my answer. Those would be different levels of centralization. I think that, if you are running the Mist browser, then the web3 object is on the client-side only.
    – Ajoy Bhatia
    Sep 7 '17 at 20:23
  • @AjoyBhatia. I have a question. If I create my wallet / accounts client-side with web3.eth.accounts how can I "publish" them on my local node? My provider is a websocket.
    – underdog
    Sep 7 '17 at 21:33
0

This mostly doesn't make sense to me, here's why:

where the blockchain node would be running on the server

The definition of a blockchain node is one of many thousands of Ethereum nodes that store the blockchain data and often respond to requests about that data.

So when you have an architecture with Ethereum node and a Node.js server and a client -- what would the Node.js server do?

Typically Node.js is used to respond to server-side requests, execute logic and query a centralized database; but with Dapps, the blockchain and web3 (which is a server or client library) query the blockchain data and an Ethereum node responds with the requested data which is then returned to the client.

You mention storing data in Node.js in a comment. Another option is to store the data in a centralized way or IPFS. You can store a simple hash or CID (content identifier) on-chain and the data that hash points to in a centralized database, query the hashes that are stored on-chain (that has the content encoded in the hash), query your data by hash, run the same hash function on the queried data to verify it is the same and then return that data to your client.

Improve this answer
6
  • 1
    I am also not sure (hence the question) but it could it be that if the app only relied on the blockchain for some of its functioning, it could be beneficial to have the node server to handle the rest (which it can do fast), only using the blockchain for critical data. For example, you could store large data in centralised storage and integrity checks on the blockchain which could be used whenever needed.
    – mcansado
    Sep 7 '17 at 17:33
  • Yeah that is one possible pattern. You can store the hash of content on the blockchain and the content in centralized solutions. We almost went this route at Disten.se but decided on IPFS to store content (and store just a hash in a contract: github.com/Distense/distense/blob/…) If you store your data in a centralized way you could allow or make convenient rehashing the content so users could verify the content is the same.
    – JohnAllen
    Sep 7 '17 at 17:37
  • Thanks for the answer! My follow-up question here though is: sure a server could be used for handling connections to a centralised DB and routing. In such a case, whenever a document/record is created, a hash would have to be generated client-side and sent to the blockchain. Given this, whenever the server responded we could calculate a hash of the response and compare it with the one we stored on-chain in the first place. However, none of this would work if the server is the one running the node. If the access to the chain is via server, than the integrity of the hash etc could be questioned.
    – mcansado
    Sep 7 '17 at 18:02
  • (ran out of characters). In this case, the architecture which would make most sense is client-server using node but allowing clients running a node to the blockchain at the same time. The server wouldn't need to run one. Is this correct? Sorry for the lengthy comments, just want to make sure I understand this properly.
    – mcansado
    Sep 7 '17 at 18:05
  • if the server is the one running the node <- Do you mean if the geth node and the Node.js server are running on the same machine the hash could be compromised on the way to being stored on-chain? That is probably the case, but then basically everything could be compromised. Just remember the Node.js server and geth node are two very separate, different things
    – JohnAllen
    Sep 7 '17 at 18:09
0

In a decentralized world, it makes lots of sense to have blockchain nodes in all sorts of places. Sometimes your client will have access to one, sometimes they won't. Hopefully, they will more and more often, but while we wait for lighter clients and more scalable networks, it's very valid to consider times you might want to also run a blockchain client on a server.

Really, client-side blockchain clients really only make sense when the user is a human with a web browser. In any machine-to-machine transaction, a NodeJS process would make more sense.

Also, while Web3 is very convenient because the API may exist in the user's browser already, it is far from an optimal lookup API. You might run a server-side node just to index information relevant to your app, so you can serve it to users faster.

As for signing, I definitely think it's safer to leave keys in the user's hands, but it's not unreasonable to expect some services to sign on users' behalf, from a server-side process.

A blockchain client is just some software that allows another context to access the blockchain. There's nothing about it that forces it into one context or another, and if the decentralized web really takes off, and delivers on scalability and performance, I think the harder question to answer will become: "What context would you ever NOT want a blockchain client in?"

Improve this answer
0

I was wondering thinking of alternatives which could still leverage the blockchain's features of reliability etc but running in a client-server framework.

You can build hybrid web apps that use Python/Node/whatever as a centralized back end server for some tasks and make use of the blockchain for other tasks.

An over simplified example for hybrid dapps would be a dapp for mortgaging an ERC20 token in exchange for ETH. Now, the lender and the borrower wish to negotiate interest rates and duration of the loan. The borrower also wants to know if anyone is willing to offer him better rates. This discovery process can happen through a centralized service without having to spend ETH on gas for every message. There could be a degree of censorship at this point where lenders offering lower rates aren't shown to you for some reason but you have not taken on any risk and can still walk away from the process.

Once the negotiation is complete both the lender and the borrower can just click on a button on the web page and create a smart contract on the blockchain that has information about all the terms of the mortgage and will behave accordingly. At this point you don't have to trust the centralized website or the lender to keep your collateral safe since it would be locked up in a contract.

So you're sacrificing trustlessness for speed and cost in one step and making use of trustlessness for security in another step.

Improve this answer
0

Sure. E.g. Imagine that you have ecommerce store (e.g. selling smarphones) written in node.js. You would like to have it connected to blockchain to control e.g. payments. So customers will pay on your address via Metamask or Mist and your store backend will be connected to Ethereum node (which might be on the same server) to check it the payment was done and proceed the order further.

In this use case server with ethereum node is not a way of centralizing app, it's just a way to access smart contracts/accounts by the computer system not the human itself.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.