Dev Portal Update: Tutorials, Recipes, and Tweaks, Oh My!
In our previous Dev Portal Update, we described our expanded documentation on Jussi, how Community Contributions work, our improved tutorial structure, and the new Recipes section.
In this update our primary focus was adding new tutorials. We also improved our API definitions, added ImageHoster information, improved mobile support, and completed other minor tweaks.
Tutorials
We added 18 new tutorials. Seventeen of those are Javascript and Ruby. In addition, the beginning of every tutorial now has a link to the executable GitHub repo and a link to the tutorials directory within that repository.
Each tutorial outlines a specific task such as "get all posts by an author" or "claim rewards." These tasks are perfect for developers who want to create a new front-end or improve automation on existing products. We plan to keep adding more solutions to common problems to make it even easier for developers to quickly build amazing applications.
We want to help developers understand these tasks rather than leave them to reverse-engineer the tasks in isolation. Hopefully by fully documenting the most common functionalities, even developers seeking to leverage different languages will find these tutorials helpful.
API Definitions
The API Definitions page lists every method available to developers for accessing the current state of the blockchain. The entire list of methods is broken up into namespaces and listed here: https://developers.steem.io/apidefinitions/
In this update, the definitions now include more detail such as the hardfork, in which a particular method was first introduced, as well as which methods are disabled. Under the hood, we're using steem-ruby to evaluate the current methods, which is much faster than before because it uses json-rpc-batch to get the method signatures.
Image Hoster
We believe that Steem is the best blockchain protocol in the world for powering web applications, and we want to maintain that status by making it even easier for developers to delight their users with amazing experiences. Hosting images is one example of a seemingly simple aspect of every website that is critical for creating a great user experience. That’s why we’ve added documentation for running and using ImageHoster to the Services section. This will be helpful for developers looking to host and proxy images in their own front-end applications.
Improved Mobile & Other Updates
The site’s mobile navigation has been improved with a functional “hamburger” (☰) element, as well as “back to top” footers to keep your thumb from cramping up.
We also added SteemConnect4j to the community resources section, which is a software development kit for interacting with SteemConnect in Android products.
As always, the Steemworks team is working hard to make sure that Steem does too. We’d love to hear from you. Drop in on the SteemDevs discord chat or by email to Steemit’s Developer Advocate at [email protected], with the subject line “devportal - $subject”.
Steem On!
Steemworks Team
Great work on tutorials. Could this mean PRs to the dev portal are being accepted now?
Developer's reference is really good as well. I hadn't realized until now how often I'm actually digging through the source code as a reference instead of referring to the documentation.
I think one tutorial that is really missing here is a high-level for creating your own language binding for json-rpc. I'm sure there are some devs out there that would love to traverse transactions with R.
Like creating an ideal Steem client specification?
https://github.com/steemit/devportal/issues/256
Yeah. I think that nails it. If we had something like an openapi specification or Swagger spec
Those would be great.
Incidentally, we actually have tests for verifying stuff like the
curlexamples in the API Definitions. If you want to try the tests yourself, they're right over here:https://github.com/steemit/devportal#tests
And we also generate/verify the API Spec here:
https://github.com/steemit/devportal#managing-api-definitions
When I said generated, I meant from the actual source code. I'm basically suggesting a literate programming approach with specification as code.
Like if @inertia made changes to the json-rpc, then specification changes would be accepted in the same PR. In the next CI build, documentation could be generated, but that's not what's important. What's important is that now the specification itself is deployed with the software and can be used to generate/verify a client.
From a single change, you have now affected several facets.
Haha, looks like you're having fun working. That's a good sign! Keep it up :-)
Thanks for the update. Is the dev portal actually something that's been set up in preparation of SMTs? I guess all the information and tutorials you provide will be especially valuable for those who're planning to create their own token?
Not so much in preparation for SMTs. The goal is much broader. If you can use the API to do it, we want to document it on devportal. There will be SMT specific methods and operations, for example:
https://github.com/steemit/steem/issues/2235
Once these are merged to a public endpoint, we'll add them to devportal:
https://developers.steem.io/apidefinitions/broadcast-ops
Awesome! Thanks a lot for your detailed response @inertia.
Sometimes I think it'd be great to have a "news window" or something like that on Steemit.com for all these informations that are related with the progress of the platform. Having so much content being promoted on the trending page lately, sometimes these really important messages don't get the visibility they should have. Maybe that's something to think about some day.
WORD!
The tutorials are fantastic - I was just trying to figure out how to do some of those exact things over the past week and could have really used those tutorials then! Luckily the steemdevs community on discord came to the rescue :-)
Good documentation is key for building a strong third-party developer community. Keep up the good work!
Keep develop Steemit! one day blockchain will explode!
Cool. I'm happy to see this back in the post creation window
Made no sense to me to hide it away in the settings and not make aware the current setting, cheers!
Yeah, when I saw it popping up I was actually thinking about you :-))
oh reallyyyyyy :P
I'm happy it has returned to its rightful place!
Ugh!? Why reinvent the wheel with jussi? Why not build block support into an api gateway like kong? Now I have to run my apps behind kong and jussi. This kind of infrastructure redundancy is not good.
Can you host kong on a raspberry pi? You can with jussi. The reason you might want to do this is for tinkering, maybe, not serious a hosting solution. But I find it useful in development to have the option of pointing to my raspberry pi as if it was running a full node.
My point is that jussi can be deployed on a seriously wide variety of hardware.
Waiting to run something like this on any hardware is a common request. That's why kong exists. It's openlua on nginx. It's ridiculously flexible and powerful. Best of all, it exists and is supported by a greater community.
IMHO, it simplifies things because now I can reduce my footprint by having either a reverse proxy and/or load balancer. That is, I can funnel requests through my reverse proxy before hitting the load balancer, or I could build my multiplexing into my load balancer cluster.
Regarding the tinkering use case, I think kong was created for specifically that because of the openlua foundation. It's meant for fail-fast development. Or rather, it's meant for you to be able to develop your plugins on a running application in just the kind of environment that a raspberry pi will create for you.
I think though that if I were going to tinker, I would use docker for tinkering unless it were IoT. Raspberry Pi really only makes sense when you have hardware you want to modify with software, but you haven't the means. You can forcibly add a software solution to your hardware (ironically with more hardware). For example, I want to connect my home security system to steemit and multiplex with kong/jussi on my raspberry pi, that would make sense. If I just wanted to try out jussi/kong to see how many apps I could connect before seeing resources constrained, I would use docker.
Check it out https://konghq.com/kong-community-edition/
If I wanted to add the ability to cache a json-rpc-batch request coming from the client, that is, write a plugin for kong to accept the request and cache the upstream response, how much time would you estimate one would have to spend writing this functionality in lua, along with the ability for anyone in the community to use the same plugin for their own deployment? You know, generalized and ready for production.
Keep in mind, this hypothetical kong plugin would need to be blockchain aware. It would need to know things like if each TTL for each block being requested in the batch is before or after the last irreversible block or not. Stuff like that.
If you want to do a real cost-benefit here, you'll have to compare actual work on both sides, but then also weigh what you're getting.
I'm basically saying that the amount of work to build the same functionality currently in jussi, but in kong would be less simply because
Also, it's not just better because the work would be less, but the benefits are greater
Whenever the question is "Should we reinvent the wheel?" the answer is almost always, "no".
You should totally write that plugin.
Actually, I had started a kong plugin, but it's not for this. It's for pricing out app access to private nodes. Another reason why I would really like "full-blown" kong support.
It's on my list. Just after "super suit."
I estimate it would have taken less time than it would have to build/design/maintain jussi. A lot less
So, challenge accepted? :D
LOL. You're right. It's a lot easier to complain and hindsight is always 20/20. You want to actually see it. All I can say is, I've been working on a refined steemit infrastructure that provides turnkey solutions for app developers. I may be all talk though because I have so many ideas and I like to go in all directions simultaneously. It's a character flaw.
Oh my god it's me. Only at business dev level, not hardcore software development
Where is the SMT dev related stuff residing?
I'm looking at a project that will be suitable for SMT's and need to know more in-depth information. Has an updated whitepaper been published?
Hmmm, I found this from 2017 https://smt.steem.io/smt-whitepaper.pdf and are wondering if it's still relevant?
This is definitely a step in the right direction.
All that hard work will not go unnoticed, thank you very much to everyone who helped do that...
I see you're using dsteem in the tutorials. Are you moving away from steem-js??
From what i've learnt from recent updates, yes that would be the case, and that dsteem performs and scales much better than steemjs. Steemjs is left for some sort of legacy I guess. Not sure if they completely removed it though from the official documentation already, as there were few references to it last I checked.
Es bueno ver como se esfuerzan día a día para obtener mejores resultados y brindarnos siempre, lo mejor de lo mejor.
A ustedes, mil gracias!