When Hive was first launched, an early topic of discussion among all of Hive’s devs was “How should we create a next generation API for Hive?”. To answer that question, we started looking at the current API to see what kind of problems it had. In this post, I’ll walk through the problems we found and our solution to those problems.
What’s an API?
If you’re not a programmer (and maybe even if you are), the first question you may be asking is “What is an API?”. API stands for Application Programming Interface, but that probably doesn’t help you much :-)
In the modern web-based programming world, software often needs to talk to other software. This allows people to take advantage of features in your software when they create their own software.
If you want to allow other software to talk to your software, you program it with an API. This API defines the ways in which other programs can talk to your software. The API defines the set of function calls that can be made to the software by external programs to either tell it to do something or get some information from the software. Not every piece of software has an API, however, because it takes extra programming work to support an API.
Software programs with APIs are often considered “backend” or “middle-ware” software, because they frequently don’t have their own user-interface (users don’t “talk” to them, only other programs do). In such case, users interact with other programs that then talk to the software that has the API.
But this isn’t a hard-and-fast rule: some software with its own user-interface may also have an API. In such cases the API is often used to by scripts that mimic the behavior of a bunch of user actions (these scripts are often called macros). If you’ve used a spreadsheet program, you may be familiar with its language for creating macros. That’s an API for the spreadsheet software, although in this case the API isn’t used by other programs, but directly by users themselves.
What does this have to do with Hive programming?
The core software that maintains the Hive network is a backend program called hived. Witnesses, exchanges, and other “power users” run hived nodes that receive user transactions, put these transactions into blocks, and communicate with each other over the internet. Hived doesn’t have a user interface. Instead it has an API that is used by “front-end” programs such as hive.blog, peakd, ecency, splinterlands, etc.
Problems with the original API
Back in the Steem days, hived (called steemd back then) directly implemented the entire Steem API. Unfortunately, this solution wasn’t scalable in two ways: 1) as more API calls were made to a node, the node had to do more work and too many requests could cause a node to fail and 2) modifications to the API required modifications to the core code, which risked problems whenever the API was changed or extended to support new API calls.
A mismatch between hived’s database design and an API’s needs
Hived’s original database stored all its data in memory (instead of on a hard disk). But this data needed to be kept around when a hived node was shutdown, so a specialized database called chainbase was created that allowed this data to be kept in memory (or even on a hard disk) after the program was shutdown.
Unfortunately, while chainbase did solve the problem it was designed for, it lacks many of the useful features of a traditional database.
One particularly severe problem is that chainbase only allows one thread at a time to write to the database, and while that thread is writing to the database, no other thread can do anything, including even reading information in the database. So hived has only one thread that collects new transactions and blockchain blocks and writes to the chainbase database.
It also allows the creation of many other threads that can read this database. Whenever hived receives an API call from another piece of software, one of these “read threads” reads the database and returns the requested info to the calling program.
Thousands of programs talking to a hived node create a performance bottleneck
Whenever a hived node is being used as an “API server”, it is is constantly receiving many calls from other programs. For example, the entire Hive network only has around 10-20 public API nodes, but there are tens of thousands of programs talking to these nodes (each person browsing a Hive-based web site such as hive.blog is running one of these programs that talks to hived). And when you look at a single web page on these sites, that site will generally make several calls to Hive’s API (the number of calls made can depend on many things including what Hive account is browsing the page).
As mentioned previously, hived can’t write anything to its database while any API call is reading from chainbase. But it is imperative that hived is able to write to its database in a timely manner, otherwise the node won’t be able to keep up with other nodes in the network. So hived prioritizes the writer thread that writes to the database: once it requests access to the database, all reader threads are blocked until the writer thread finishes. But all existing reader threads still get to finish doing any work they were doing, so the writer thread still may have to wait a while.
In a traditional database, such as a SQL database, this kind of problem doesn’t happen as much. In a traditional database, reader threads are able to read any part of the database that isn’t being directly written to by a writer. And they also allow multiple writer threads to run simultaneously, as long as they are writing to different parts of the database. Unfortunately, chainbase’s design essentially treats the whole database as one single huge piece of data, so reading and writing by multiple threads can easily become a performance bottleneck.
To get around this problem, Steemit used to run many API nodes and distributed the API calls across these nodes, but this required a lot of computers to be rented to run all these nodes (i.e. it was costly).
Hivemind as a partial solution to the performance bottleneck of chainbase
Steemit created a new program called hivemind to act as an “intermediary” for API calls to steemd nodes. Hivemind makes API calls to a steemd node to read some of the data from new blockchain blocks and stores that data in its own SQL-based database.
Hivemind still has to read the data one time using the node’s API, but after that web sites and other programs can read the information from hivemind’s SQL database instead of from the node’s chainbase. In this way, chainbase bottlenecks are avoided for all the API calls supported by hivemind, since SQL allows individual locking on different pieces of data in the database. The number of API calls to steemd are drastically reduced, giving the node more time to write to its own database.
The rise of Hive and the need for cheaper API servers
While hivemind reduced the load on the blockchain nodes, the blockchain nodes still needed to do a lot of work. First to respond to API calls that were not handled by hivemind and second to handle the calls made by hivemind itself. This meant that Steemit still had to run a lot of blockchain nodes to respond to API calls from web apps.
When the Hive network was started, there was no longer a centralized company that was economically incentivized to run such a large number of API servers. So Hive devs needed to figure out how to lower the number of servers required to support the Hive user base.
The first step just involved reconfiguring the internal software components of the API servers to run more efficiently while consuming fewer resources.
Next, devs began migrating the functionality of more Hive API calls from the blockchain nodes (i.e. hived nodes) to hivemind servers. This was a lot of work, because it meant new information had to be added to hivemind that it didn’t have previously, and the code had to be written in a different language since hived is written in C++ and hivemind is written in Python and SQL. But the payoff was far fewer calls being made to hived nodes and it also reduced the amount of memory used by them.
Of course, the hivemind servers now had to handle more API calls, but they were already better suited to do this because of the underlying SQL database, and Hive devs also devoted significant effort to speeding up the handling of API calls by hivemind. These changes enabled hivemind servers to process more than 10x the amount of API calls they could previously handle. Nowadays, a single properly-configured Hive API node can handle all the traffic of the entire Hive network.
Wanted: a better API for Hive
Once the immediate need to reduce the costs of running the Hive network was completed, Hive devs started looking at how to decentralize the development of Hive software. All Hive apps rely on the Hive API to interact with the Hive network, but this API was defined by just two pieces of software: hived and hivemind. Anyone who wanted to extend the Hive API needed to change one of them. This required a programmer to spend a lot of time understanding these two pieces of software, and any change would potentially break them. So there were relatively few programmers willing to take on this challenge even though pretty much all the devs thought the API needed improvements.
Hivemind to the rescue?
So in order to decentralize the evolution of the Hive API, the API needed to be easier to change and it had to be more resistant to breaking during modifications. And hivemind already suggested a way to accomplish the first goal of making the API easier to change, because there are more programmers who know Python and SQL than know C++.
But hivemind was still challenging to work with, because it wasn’t easy to know if making a change one place might break other parts of the code. But software engineers have long had a solution to this particular problem: it is called modular design. In a modular design, software is broken up into distinct pieces, where each piece is responsible for just a few related things, and changes to one piece doesn’t affect the other pieces.
Hivemind already had some aspects of a modular design: there was one piece of software that fetched data from hived and put the data in hivemind’s SQL database (this piece is called an indexer) and another piece of software that implemented the API calls that read from this database (this piece is hivemind’s server process).
But all of hivemind’s API calls are implemented by this one piece of server code and there is no clear separation of which API calls use which tables in the database (tables are a way of separating the storage of different types of data in a a database).
The birth of HAF (Hive Application Framework)
So Hive devs started looking at ways of creating a new, more modular version of hivemind. This new piece of software (eventually dubbed HAF) would allow developers to individually define their own clearly defined set of tables and API calls they wanted to create, and it encourages that these new API calls could be developed independently (modularly) from the API calls created by other devs.
When we compare hivemind and HAF, we see that several important design changes were made.
HAF keeps more blockchain data than hivemind
Perhaps the most important change is that a HAF server keeps a raw copy of all the Hive blockchain data, so virtually any blockchain data that someone may need to create a new set of API calls is available. Hivemind only kept a subset of this data and it sometimes stored it in an altered form from which the original data wasn’t always reproducible. By making all this data available to HAF apps, these apps no longer have any need to talk directly to a hived node. This is very important, because this eliminates the scalability bottleneck that chainbase imposed on apps that talk directly to hived.
HAF is immune to forks
Another important change is that hivemind wasn’t resilient against forks. A fork occurs in a blockchain network when one or more blocks that have previously been accepted by blockchain nodes get replaced by another set of blocks in a longer chain. To workaround this problem somewhat, hivemind delayed processing of new blocks, so that hivemind nodes would only get “bad” data if a fork longer than a few blocks occurred (this is relatively uncommon, but it does happen). But when such forks did occur, hivemind would still have data from blocks that were no longer part of the blockchain, which obviously isn’t a good thing. The only way to fix such a hivemind node was to replay the entire blockchain from scratch, which takes days (even far longer before hivemind was speeded up).
HAF gets around this problem by keeping track of the changes made to the HAF database by each block, so if blocks get replaced by a fork, all the changes made by the old blocks can be reversed prior to applying the new replacement blocks to the database. This completely eliminates the possibility of bad data from orphaned blocks. As a side note, the chance for long forks was also mostly eliminated with Hive’s introduction of one-block irreversibility (aka OBI).
Each HAF app maintains its own set of database tables (ensures modular design)
In SQL, a set of logically related tables is called a “schema”. Each schema is assigned its own name when it is created. Schemas are an important way to ensure that your database is designed in a modular way.
In hivemind, there was one schema used by all API calls. In HAF, there is still a schema called “hive” that stores all the “raw” blockchain data written to the database by hived. Each HAF can read from the hive schema, but they cannot write to it (only hived can write to this common schema). But each HAF app then creates its own separate schema where it stores any additional data that it needs (normally this additional data is computed by a HAF app from the raw data stored in the hive schema).
Another way to look at a HAF app is that it is the implementation of a set of related API calls, running on top of a HAF server. With each app having its own schema, changes to one HAF app can’t break other HAF apps, thus achieving the desired design modularity and ensuring that devs can create their own new API calls without breaking the API calls developed by other devs.
“Old” Hivemind polled hived, hived pushes to HAF
Hivemind would periodically ask its hived node for more blocks by making a get_block API call. For somewhat technical reasons, this call requires additional computation by hived nodes and is a rather expensive API call (although Hive devs have lowered the cost of this call somewhat nowadays). This could be particularly problematic when a hivemind node is being setup for the first time, because it needs to fetch all the existing blockchain blocks to fill its SQL database. Making all these get_block calls would significantly slow down a hived node and it could only reply so fast, so it would take quite a while for a new hivemind node to get all the block data it needed.
To resolve this problem, HAF communicates with hived in a different way. Instead of making get_block API calls to hived, hived tells HAF about new blocks as it gets them. This does have a disadvantage: it requires that a hived node be replayed to fill a HAF database, whereas hivemind could get its data from a normally operating hived node. But a big advantage is that hived can push blocks much more efficiently to the HAF server, so the HAF server can be filled much faster. As another benefit, hived sends new blocks faster to HAF servers (because it doesn’t have to wait to be asked), so HAF servers can process new blocks as soon as they are received or produced by the hived node.
The current state of HAF and the Hive API
Nowadays we have defined several new APIs using HAF apps:
The first HAF app was Hafah, an app that replaces the rather expensive account history API that previously relied on direct calls to hived nodes. Hafah’s implementation of the account history API is faster and can handle many more simultaneous calls (and most importantly these calls no longer place a load on the hived node). Running Hafah is particularly cheap for HAF servers since it doesn’t create any new data, it just uses data available in the common “hive” schema of HAF. This also means that this HAF app requires no syncing before it can start serving up date from a synced HAF server.
There is also a HAF app called balance_tracker that provides API calls for graphing Hive account balances over time (over each block even). This was originally created as an example app to demonstrate how to create a pure SQL-based HAF app, but it was later found to be useful for the development of a new block explorer for Hive, so its functionality has increased over time.
There is another HAF app called block_explorer that provides an API for the kind of data needed by Hive block explorers.
And, of course, not to be forgotten is the largest existing HAF app: a rewrite of hivemind, which implements all the API calls of hivemind, but doesn’t suffer from the potential forking issues faced by the old hivemind.
We’ve also created a new “query_supervisor” for HAF that allows rate-limiting of API calls to a HAF server. We’re currently testing this functionality soon on our public HAF server, enabling direct queries to the HAF database.
The above HAF apps were all developed by the same team that created HAF itself, but we’re also seeing other developers beginning to develop HAF apps. Most recently, @mahdiyari developed a HAF app that supports the same API as Hive SQL. We are hoping that with the recently developed query_supervisor acting as a rate limiter, public Hive API servers will be able to reasonably support the HIVE SQL set of API calls.
Should every new Hive API be developed with HAF?
The short answer is “yes”, but right now this isn’t yet true. Several new APIs have been developed over time before HAF existed. These often were developed with a somewhat similar design methodology to the original hivemind: they make get_block calls to get data from hived and they make other API calls to get data from hivemind, then they write their own data to a local database. They are already modular, like HAF apps, in the sense that they maintain an entirely separate database for storing their data.
So why do I think these APIs should be turned into HAF apps? There’s a couple of reasons, some the same as the reason why we made hivemind a HAF app: they generally aren’t designed to handle forking and they make many expensive get_block API calls to hived nodes when a new server for the API is being established.
But there’s a much more fundamental reason why I’d like to see these APIs implemented as HAF apps…
Decentralizing Hive’s API server network
Right now, the so-called “core” API of Hive is decentralized, because we have around 20+ public API servers that Hive apps can make calls to. But for “new” API calls implemented without using HAF, generally only the original developer runs a server for that API. But if new APIs are developed as HAF apps, then it becomes very easy for the public API servers to add support for these new APIs.
HAF-based APIs increase software re-use
If APIs are available across multiple public nodes, it is much more likely that application developers will be comfortable making calls to those APIs. If only one server supports a set of API calls, then your app stops working when that server goes down. If there are many servers supporting the API, then your app can seamlessly switch to another API server, and it is safer to use the calls provided by that API. This technique is already used by all the main social media apps of Hive because they primarily rely on the Hive API supported by the public API servers.
HAF apps are the new Hive API
When Hive first got started, devs were asking each other, how should we create a next generation API for Hive? We wanted a new API that incorporated all the lessons that were learned from developing the original API, including fixing problems with existing API calls.
But it quickly became obvious that API servers for a platform such as Hive that can serve many diverse software applications will need an API that can easily evolve to meet future needs. So we needed to allow for many developers creating their own specialized APIs in a way that the work done by independent teams wouldn’t conflict with each other (i.e. we needed a very modular design).
We also wanted to encourage the use of best practices when new API calls were implemented, so that the API calls were as efficient and scalable as possible and also robust against forks.
By achieving these three goals (scalability, robust operation during forks, and modularity), it becomes safe for public API servers to quickly add support for new API calls without worrying about breaking existing functionality or introducing too much loading on their server.
HAF meets these three goals and is also implemented using a programming methodology that is familiar to many developers. To further ease the effort required for Hive API servers to add support for new Hive APIs, each HAF app is normally deployed inside a separate docker container. This means that a HAF server can add support for a new HAF app/API with a single command. With a dev-friendly programming environment, guard rails to protect against mistakes that can take down servers, and easy deployment, HAF apps are perfectly designed to meet the future needs of Hive-based software.
Great work and I know this is going in the right direction and I have a specific request.
If this is possible:
We need absolutely drop dead simple instructions for running the most lightweight HAF based API server that can be run on the absolute bare minimum $10 VPN.
Something as simple as editing a
.envand thendocker compose up -dis what I'm looking for.In the last couple of years while you were building HAF I wrote and deployed my own code called Pingslurp to keep track of all Podping custom_jsons. This code has got 6 months of my podpings in but the MongoDb is only 1.6Gb which is perfectly manageable on really cheap hardware.
All my code really does it look for and save the data on chain I'm interested in a reasonable format. I must admit I do some cools stuff with time series information which I have no idea how to do in SQL.
I only built this because every time I looked at the HAF docs the first step was getting a machine with specs I will never need for this app to hold social data I don't need because all I want are my custom_jsons.
Just to make this clear and why up to know I've not even tried using HAF, each time I looked, the base spec made me cry!
The base spec for a HAF server is extremely small (something like 6GB of storage space).
So I suspect you're looking at the storage needs to store the entire blockchain (theoretically around 3.5TB, but in practice only around 1.2TB using zfs with lz4).
But like I said, the above storage space is only needed for a full API server that needs access to all the blockchain data. When you setup your HAF server for your HAF app, you just need to add a line to your hived config.ini file to filter out all but the operations you want. Then you'll have a super small database.
As far as docker goes, the recommended way to setup a HAF server is using docker nowadays. We're also creating a docker compose script for a setup of a full API node, but for setup of a simple HAF server, it all fits in one docker container, so no need for docker compose.
Does the database run in the same docker container? I will look again at the docs thank you!
The database software runs in the same container as hived (this is the "haf" docker), but by default you end up bind mounting your hived workdir and the database's storage to a local directory. If you use the script to create the docker it handles this process (command-line options to override defaults) or if you use the as-yet-unreleased docker compose script, you edit associated .env file.
Great write-up explaining some of our biggest problems.
Now this gave me an idea... Maybe a multi-regional public HAF servers for people to play with wouldn't be too bad. Could help with development by wiping state every X hours (since it's so easy to get a HAF server running nowadays) giving devs an opportunity to test their apps before releasing them into the public with their own HAF apps (and hopefully, several supporting nodes), or other node owners to test out custom HAF apps hosted on the nodes (i.e. public HAFSQL instance, balance tracker or the explorer even) will mull over this idea for a bit.
I'm hoping that public nodes will run most or even all the current HAF apps.
As for public access to a HAF server for development purposes, as you suggest, this may also be feasible, but it is probably best to run it on a node that's not acting as a regular public Hive API node. We're basically planning to do that with one of our HAF servers (well, we've done it already once, planning to put up a new one soon) that uses the query_supervisor as a rate-limiter to protect against rogue queries. A multi-regional one might also be useful to reduce latency during app testing.
I am planning to run HAF apps that will definitely be beneficial to the community on all my nodes (over 8 nodes worldwide) so I am hoping it would both help the availability of the apps and the capacity it can handle. (Balance tracker so far has been the most requested one by a lot of people, so that is a must at the very least :))
Looking forward to the publicly available release (in terms of ease-of-use and access) for the aforementioned HAF apps and query supervisor (I believe its still WIP) so I can do a major upgrade and update sweep in one go.
The public release should be very soon, we've already been begun testing release candidates and we're also finishing up development of docker compose scripts for easy deployment of all the needed dockers :hived/haf docker and dockers for all the various haf apps, plus some optional monitoring tools (pghero, etc).
This is by far the best explanation I've read about the basics of the blockchain and I'm quite sure even someone completely blind about code, making a sketch (I use to sketch when I don't understand completely or it is to much information) of what you've wrote can have a quiet good understand of what is in the base of the blockchain and how it works. Congrats! Impressive document here!
Question: Since hivemind will be in the middle and there is another modular layer of code (HAF), couldn't hivemind rewriten in C++, isn't it C++ must powerful than Python?
I actually thought about adding a drawing or two, but I'm not fast with drawing tools and I was too lazy :-(
Hivemind consists of two parts: some python wrapper code and a lot of SQL code. The SQL code is the bulk of hivemind. We could eliminate the python wrapper code, but it just doesn't do a lot, so replacing it wouldn't speed things up too much. Probably the most useful thing to do would be to replace the existing python-based web server with a postgresT-based one: we've already found that this speeded up performance in some of the other HAF apps we've created.
The way you've explained it's not necessary, I think.
For someone quiet lost in explanation own sketch might help.
Don't know if you've ever read 100 Years of Solitude from García Márquez, 7 generations of same family, a "ton" of people with the same name and surname, I have to read twice and make a sketch to not get lost lol.
Ok understood, it's mainly SQL.
I haven't read it, but I can imagine the problems that result :-)
My biggest read challenge so far!
Yes, it's mainly SQL, and we did spend a lot of effort speeding up that SQL code (as well as refactoring it for easier future development).
Great!
Thanks for sharing this information, especially for writing it that even someone with very very basic dev knowledge can understand it which really isn't easy to write in such a way!
I tried my best, although on a re-read I still see a lot of unexplained terms like docker containers. But hopefully the gist of it is clear.
To be honest there are indeed still some very specific terms but I managed to understand the main message, so good job!
Great work!
One word: Efficiency
So many Devs don't bother thinking about efficiency or UX, so HUGE thanx to you guys who do.
Api node admins have got to be excited about this too! Drop resource requirements and their expenses can drop at the same time. Modularity of course is super smart; It abstracts and let's devs call just what's needed, and bolt-on just what an app user might request at any moment. mimo lowers latency to the clients too, and that means happier users all around.
Yes, higher efficiency, low cost deployment, freedom to safely innovate together without a central point of control: these are all critical needs for the success of decentralized software.
Yep, absofreakinlutely.
So much information. Thanks for keeping us up to date on hive development.
I am curious as to where I could read more about the chain development. If I can grasp the concepts I would like to help out. It sounds like it could be fun.
The repo for hived is located at https://gitlab.syncad.com/hive/hive .
The repo for HAF is located at https://gitlab.syncad.com/hive/haf .
Oh wow these are some great updates. Do you guys ever rest? Haha thanks so much for working on the improvements.
Actually several of our devs are on vacation now, which is a bit painful for me as I await their return :-)
don't forget to give them a payback... once they are back go on your own vacation hahaha. wish you guys all the best. :)
Imma have to reread this again later and it sounds great but
when next non-dev post? :D
I'm actually hoping most non-devs can understand this one as I tried hard not to assume too much prior knowledge, but you're right the main audience is Hive devs. As to true non-dev posts, not sure yet, but hopefully not too long away.
This is a hive-archeology proxy comment meant as a proxy for upvoting good content that is past it's initial pay-out window.
Pay-out for this comment is configured as followed:
Does the API going to be REST or GraphQL? I have not done much programming on the Hive and graphene blockchain end but I was always curious on the part of the blockchain able to allow the API on GraphQL. So thought I should ask if there is any development on that end?
HAF doesn't place any restrictions on the shape of the API. So it is certainly possible to use GraphQL with HAF and it can be done without much effort.
All details are here!
Are you part of d devs?
I'm the lead dev for one of the Hive development teams (the BlockTrades team).
Does this mean I can finally ditch BEEM? I can get to grips with anything Python if there's decent documentation and working examples.
BEEM is a library for making calls to the existing Hive API. HAF lets you define new API calls that can be made. So they do somewhat different things, and HAF doesn't necessarily replace existing API libraries for different languages (although it will create more work for those library maintainers as it should speed up the process at which new API calls are created and need support in those libraries).
That said, depending on your application, it is possible to skip using an API library and just have your application talk directly to a HAF database. In that case, you can just develop your own app-specific API, which will often have some performance advantages. Creating your own API does require some experience writing SQL queries, however. There are several python libraries for talking to SQL databases (e.g. SQLAlchemy).
Congratulations @blocktrades! Your post has been a top performer on the Hive blockchain and you have been rewarded with this rare badge
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
This is my first time to know that API have a great contributions here in our platform. The write up and presentation and discussion regarding with this topic helps us a lot here.
Thanks for this awareness, at least it has brought us up to speed, we that are not programmers, at least from this article we now know little on how the hive Blockchain really works,
When I started reading the article I was like, I know what APR and APY which one is API.
Really you guys are doing an amazing job behind the scenes which we don't know, thanks for sharing
Congratulations @blocktrades! Your post has been a top performer on the Hive blockchain and you have been rewarded with this rare badge
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
Thank you for your 90-day delegation. I received your message stating that it will end in 48 hours. You've been a great help in getting me started with my curation activities on HIVE. It's unfortunate that you're closing, but that's how life goes. I wish you all the best in the future.
Do you know of any other places where I can request delegations like you used to provide?
I'm not sure what's available nowadays, there used to be a service by buildteam.
!PGM
!LOLZ
BUY AND STAKE THE PGM TO SEND A LOT OF TOKENS!
The tokens that the command sends are: 0.1 PGM-0.1 LVL-0.1 THGAMING-0.05 DEC-15 SBT-1 STARBITS-[0.00000001 BTC (SWAP.BTC) only if you have 2500 PGM in stake or more ]
5000 PGM IN STAKE = 2x rewards!
Discord
Support the curation account @ pgm-curator with a delegation 10 HP - 50 HP - 100 HP - 500 HP - 1000 HP
Get potential votes from @ pgm-curator by paying in PGM, here is a guide
I'm a bot, if you want a hand ask @ zottone444
lolztoken.com
I still wonder what she saw in him.
Credit: reddit
@blocktrades, I sent you an $LOLZ on behalf of hive-103505
(3/10)
ENTER @WIN.HIVE'S DAILY DRAW AND WIN HIVE!
Where can I read about using HAF in depth?
Readme's in these repos are good starting points:
And a good example app is located here: https://gitlab.syncad.com/hive/balance_tracker
Congratulations @blocktrades! Your post has been a top performer on the Hive blockchain and you have been rewarded with this rare badge
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
I can't add anything technically useful, but this was an interesting read. Some of it I knew earlier, but a lot is new.
Does this create any vulnerability?
No, there is no vulnerability created because each HAF app is isolated to its own set of tables (its own schema). Each haf app runs as a separate role (like a separate user on a multi-user computer system), so it only has permission to write to its own tables.
About the worst thing that can happen is that a HAF app may be implemented inefficiently so that its queries are slow, slowing down access to the database to other apps.
But this can be mitigated by the new query_supervisor which kills queries that take too long or use too many resources. And if a HAF app adds too much load, HAF server operators will likely disable it until the app's devs make it faster.
This is good to know. Thank you very much for the explanation.
As a non-coder I deeply appreciate the great and successful effort you have undertaken to explain these mechanisms and their improvement in layman's language. You have clearly edited this post with care, as I found only one typo, which is more than I can say for this coemmnt.
The text '...blockchain data that someone may new to...' may not actually be a typo, but it makes no sense to me, and the rest of the post is so well written that even I felt well able to grasp it's meaning. The word 'need' seems appropriate in that sentence, at least to my unschooled eye.
I further appreciate what seems to be very beneficial strategies and good application of them in decreasing node expense and fragility of the platform, also dramatically increasing scalability, so that if flaggots ever quit driving good creators off the platform all of us can benefit from rapid growth and a shot at the moon. I confess I wondered what would have happened to Hive had the traffic that quickly drove Meta's Threads to ~100M users, or even a fraction of it, wandered thisaway, but it seems we have been well insulated from such potential trauma by those diligent beavers damming the flow of new users and retention that might flood our little pond.
We are well afforded scalability by your endeavors so that if they ever slack off we can prosper thereby (unless I have misunderstood your statement regarding one node being able to handle all current Hive traffic), and I am grateful.
Thanks!
Good catch, you're correct. It was supposed to be need, not new. I've fixed it now. I do try my best to avoid mistakes, but I sometimes go back and edit sentences to try to improve their readability and that can ironically increase the chance for typos of various sorts.
Yes, you shared the same concern I've always had: the original code just wasn't scalable enough to handle a lot more traffic without expenses increasing dramatically. That's why we've put so much work into improving scalability: otherwise there would have been no point to trying to really grow the user base. And you've correctly understood that one node can currently easily handle all of Hive's traffic, so we've made a lot of progress on that front.
Great news.
Excellent