If so, then we can add your own functions to the public node by adding it to the main repo. If you have a feature that's dependent on custom_json ops then get in touch through the contact form on the landing page and we'll assist you.
Do I understand that right? When a custom_json occurs in which I am interested in, you start firing a function that I previously defined. So, you providing some event-driven, serverless function management like AWS or Azure but just for the HIVE network?
Yes, you define the functions and which custom_json ops to look at and how to store the data, and also define the API endpoints you want to access and we add them to https://plug-play.imwatsi.com/docs.
I recommend designing your custom_json ops according to this standard I published, it will make future upgrades easy to implement because it has versioning in-built: https://github.com/imwatsi/haf-plug-play/blob/master/docs/op_standard.md. It's ok if you have historical ops, like Podping, we can integrate them as well.
I'm writing a post to explain the custom_json op standard in more detail.
That all sounds really well thought. But a question left: I still need a second, own server to run periodically requests to your API and listen for these events or do you alert them via Webhooks likewise?
It depends on your app design... If your app just needs API access when someone accesses the frontend, then the endpoints will be enough. In most cases you won't need a second server unless you want to do data manipulation that you can't put on Plug & Play.
Webhooks is an interesting suggestion, but I haven't implemented it. I'll look into it.
Ahh, now I understood it. I was just thinking to much as a backend developer. So, this is really something with huge potential because some dapps could nearly ignore their backend and just get the data from you - brilliant!
I also like the opportunity to host such a node by your own. That's why I definitely will support your Proposal
Thanks. Do you mean custom SQL functions?
If so, then we can add your own functions to the public node by adding it to the main repo. If you have a feature that's dependent on
custom_jsonops then get in touch through the contact form on the landing page and we'll assist you.Do I understand that right? When a custom_json occurs in which I am interested in, you start firing a function that I previously defined. So, you providing some event-driven, serverless function management like AWS or Azure but just for the HIVE network?
Yes, you define the functions and which
custom_jsonops to look at and how to store the data, and also define the API endpoints you want to access and we add them to https://plug-play.imwatsi.com/docs.Check out the first Podping endpoint I did and SQL functions and tables. I wrote all that for them.
I recommend designing your
custom_jsonops according to this standard I published, it will make future upgrades easy to implement because it has versioning in-built: https://github.com/imwatsi/haf-plug-play/blob/master/docs/op_standard.md. It's ok if you have historical ops, like Podping, we can integrate them as well.I'm writing a post to explain the
custom_jsonop standard in more detail.That all sounds really well thought. But a question left: I still need a second, own server to run periodically requests to your API and listen for these events or do you alert them via Webhooks likewise?
It depends on your app design... If your app just needs API access when someone accesses the frontend, then the endpoints will be enough. In most cases you won't need a second server unless you want to do data manipulation that you can't put on Plug & Play.
Webhooks is an interesting suggestion, but I haven't implemented it. I'll look into it.
Ahh, now I understood it. I was just thinking to much as a backend developer. So, this is really something with huge potential because some dapps could nearly ignore their backend and just get the data from you - brilliant!
I also like the opportunity to host such a node by your own. That's why I definitely will support your Proposal
Much appreciated man!