But let me clarify coooouple of details. Maybe I misunderstood something
smart contract is basically a core backend. Since it services CRUD (create, read, update, delete) operations. Without delete in this case.
smart contract is a piece of solidity code, which lives inside blockchain
smart contract describes everything - data (entities. blog post only in our case) and logic (data manipulation)
smart contract stores base data - map of post ids to ipfs hash and vice versa.
Here I have first real questions
What does Post storage post means in smart contract code?
Where all this data is actually stored? Let's say I have 10k posts in my blog. That's 10k pairs id => string and another 10k pairs of string => id. Where are they stored exactly? Inside blocks of blockchain? Does it mean that this "array" will be scattered across huge amount of blocks? And every consecutive call on fetchPosts will be literaly slower and more expensive every day, since physically, data will be distributed across many-many-many blocks?
The whole "data on blockchain" thingy means I (as an author of a blog) will need to pay (quite literally) for each action - create/update post?
Also that means that there is no point (aside from using grpah later) in published field, since every post will be accessible through fetchPosts method of a smart contract. Is that correct?
Actual data of blog post is a JSON file put up on IPFS. Which brings a next set of questions
I edit my post 1k times, I will upload 1k json-files to IPFS, which makes every draft accessible to everyone who knows the hash
1 edit = 1 transaction
1 transaction means I need to pay for it
1 transaction also means that it will be in blockchain "forever" and since every transactions is public, so as a blog (smart contract) address, then everyone can see the list of transactions and therefore whole 1k of json-files (hashes in IPFS)
there is absolutely no guarantee that my blog posts will be there after a couple of months. if nobody will fetch them and/or pin them on their IPFS nodes, that means that chunks of my json-files will be marked as "useless grabage" and will be deleted on next node clean up. is that correct?
There is no pagination for this blog. So if I have 100k posts they all will fetched and displayed at once at one page.
Deploy via deploy.js deploys only smart-contract? What about all other js? Where it will be stored? Where from and how user will download that? How user will be able to access this blog via browser? I can do that from dev env with proper prod config and I can even post there. But who and how will read it?)
Subgraph part. So we
"listen to contract events" - postCreated, `postUpdated
go to IPFS to fetch latest json
populate Post model and store it (in the graph?)
About grpah itself
how it is stored internally?
how it provides fulltext search capabilities?
does it support multiple languages in one text?
does it support multiple languages at all?
every save costs something? isn't it? transaction fee or something
every query costs something? or not?
how do you even integrate this graph into blog?
what about "reindexing" or indexing first time after I already have 1k posts?
how reliable is that?
how fast?
In general.
if I want to support images inside posts not only cover. I will need to come with format (inside json) and store them on IPFS? What about reliability? thumbnails? different sizes and different types (png, jpeg, webp...)
where does the real frontend lives? how user will get js/css/html?
storage - stores info on-chain. memory - while executing a function
yup. blog @ blockchain means I need to pay for every action that I want to be permanent - creating/editing posts in this example
yes. each edit is a new json-file in ipfs.
you still need a real domain name with real server to serve js and stuff
ipfs is slow
Side thoughts
amount of "e-waste" (waste of storage, electricity, cpu, bandwidth...) on ipfs is tremendous
there are no real guarantees that your content will be available in couple of months (on ipfs)
amount of "e-waste" on blockchain is mind-boggling. "history of every action" is no small thing and it's ever growing
there is no real concept of "deleting something" from ipfs or blockchain. enter endless pool of moderation problems
smart contracts are complex and error-prone (as all software basically; and solidity is still far from version 1.0). have trouble reading documents? now try to read code ;)
blockchain by itself is very old idea (~50 years). there is nothing new really.
private chains have their limited applications in very specific conditions (because in general all the same problems could be solved by a set of agreed upon APIs)
web3 is ~20 years old. and it was about semantic web, not "dApps"
"web3 stack" and technology landscape decades behind of what we have now in "traditional web" in every aspect
........
Thanks for comprehensive piece.
But let me clarify coooouple of details. Maybe I misunderstood something
Here I have first real questions
Post storage postmeans in smart contract code?fetchPostswill be literaly slower and more expensive every day, since physically, data will be distributed across many-many-many blocks?The whole "data on blockchain" thingy means I (as an author of a blog) will need to pay (quite literally) for each action - create/update post?
Also that means that there is no point (aside from using grpah later) in
publishedfield, since every post will be accessible throughfetchPostsmethod of a smart contract. Is that correct?Actual data of blog post is a JSON file put up on IPFS. Which brings a next set of questions
There is no pagination for this blog. So if I have 100k posts they all will fetched and displayed at once at one page.
Deploy via
deploy.jsdeploys only smart-contract? What about all other js? Where it will be stored? Where from and how user will download that? How user will be able to access this blog via browser? I can do that from dev env with proper prod config and I can even post there. But who and how will read it?)Subgraph part. So we
postCreated, `postUpdatedPostmodel and store it (in the graph?)About grpah itself
In general.
Couple of answers to myself
Side thoughts
You forgot that every logo on Web3 websites need to be a jpg monkey :)