Yes, we are working on Polls feature, thought it would be good to use similar approach like you guys proposed, suggested few simplifications. Why keep it simple without considering other future expansions, because you cannot simply think about future use cases in details. Content_type for example, unnecessary logical complication in code, when you add different content types, you will have to re-think entire json structure again anyway.
The point is that we can all use the same system instead of everyone building the same feature separately. One polls system for all of Hive - the same polls will be available and can be voted on from any frontend. Together we can make something better that everyone can use. And you can save yourself the time of creating something that has already been created, if you can simply use it and given that it does everything you need, do you think?
Yes, of course, you cannot think about future use cases in details, but you can develop things with future flexibility and general (not detailed) use cases in mind. Thinking in advance can save a tremendous amount of time later on. We are of course not thinking about the whole json structure - I absolutely agree that would be getting into too much detail and unnecessary. But just making a standard content_type field which can be used (and it already is used by various apps) to specify the type of content can really help development, actually. Because when we pull data from HafSQL, we want to pull only the posts with the right content_type, so it really makes it easier this way. But if you want to implement these polls, you don't have to do this yourself, you can simply take the data from the API and all that work is already done for you - the polls are there, validated, and the results interpreted.
It is still in progress, this is just a first working prototype. But we don't want to make breaking changes (unless we really have to) that would create work for frontends to accommodate the changed structure.
There is a very small backend node which will be made open source. It fetches the polls data, validates, calculates the interpretations, and provides the API. So absolutely, multiple people will be able to run such a node so that there is redundancy.
I will add the ability to search polls by author. Does this seem enough?
Imagine someone opening post, then you would want to fetch author & permlink combination. Both for stats as well, you won't know trx_id from front-end hence my suggestion was to use author/permlink.
Could you please update post with latest format for both poll and action you guys are using, so we can design our indexer to work same way?
Imagine someone opening post, then you would want to fetch author & permlink combination. Both for stats as well, you won't know trx_id from front-end hence my suggestion was to use author/permlink.
OK, we can switch to author/permlink if that would indeed be easier. I was imagining the frontend would show the feed with posts, and would in advance show that a certain post is of the type poll. So the polls would be in the same feed and would be designated as such by the frontend, even before the user opens any one poll post. But in any case, we can change to whatever will be the easiest to work with for frontends, no problem to do that.
Could you please update post with latest format for both poll and action you guys are using, so we can design our indexer to work same way?
I think it will be best to open the code repository so that the latest version is always there for reference. I will discuss this with the team. But why do you want to create your own indexer instead of simply running a node with what we've already created?
I think it will be best to open the code repository so that the latest version is always there for reference. I will discuss this with the team. But why do you want to create your own indexer instead of simply running a node with what we've already created?
Is it ready? What is hardware requirements? We already have indexer, for us it would be easier to add this change but if codebase is ready and stable, then we can run your code as well. It is not a big deal really.
OK, we can switch to author/permlink if that would indeed be easier.
From your examples, yes you can see that author permlink combination is easier regardless. That's why initial suggestion was to use that instead of transaction id.
Yes, we are working on Polls feature, thought it would be good to use similar approach like you guys proposed, suggested few simplifications. Why keep it simple without considering other future expansions, because you cannot simply think about future use cases in details. Content_type for example, unnecessary logical complication in code, when you add different content types, you will have to re-think entire json structure again anyway.
OK, great. We have a first functional prototype of the polls API, which any frontend can plug into: https://polls.hivehub.dev/rpc/polls
The point is that we can all use the same system instead of everyone building the same feature separately. One polls system for all of Hive - the same polls will be available and can be voted on from any frontend. Together we can make something better that everyone can use. And you can save yourself the time of creating something that has already been created, if you can simply use it and given that it does everything you need, do you think?
Yes, of course, you cannot think about future use cases in details, but you can develop things with future flexibility and general (not detailed) use cases in mind. Thinking in advance can save a tremendous amount of time later on. We are of course not thinking about the whole json structure - I absolutely agree that would be getting into too much detail and unnecessary. But just making a standard
content_typefield which can be used (and it already is used by various apps) to specify the type of content can really help development, actually. Because when we pull data from HafSQL, we want to pull only the posts with the rightcontent_type, so it really makes it easier this way. But if you want to implement these polls, you don't have to do this yourself, you can simply take the data from the API and all that work is already done for you - the polls are there, validated, and the results interpreted.Looks like API has different structure than what you have on this post.
We would like to create our own indexing for polls also so there is redundancy for fallback in case one API is down.
Imagine someone opening post, then you would want to fetch author & permlink combination. Both for stats as well, you won't know trx_id from front-end hence my suggestion was to use author/permlink.
Could you please update post with latest format for both poll and action you guys are using, so we can design our indexer to work same way?
OK, we can switch to author/permlink if that would indeed be easier. I was imagining the frontend would show the feed with posts, and would in advance show that a certain post is of the type poll. So the polls would be in the same feed and would be designated as such by the frontend, even before the user opens any one poll post. But in any case, we can change to whatever will be the easiest to work with for frontends, no problem to do that.
I think it will be best to open the code repository so that the latest version is always there for reference. I will discuss this with the team. But why do you want to create your own indexer instead of simply running a node with what we've already created?
Is it ready? What is hardware requirements? We already have indexer, for us it would be easier to add this change but if codebase is ready and stable, then we can run your code as well. It is not a big deal really.
From your examples, yes you can see that author permlink combination is easier regardless. That's why initial suggestion was to use that instead of transaction id.