Dev Portal Update: Tutorials, Recipes, and Tweaks, Oh My!

in #devportal6 years ago

DPU 6.jpg

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

Sort:  

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

  1. the reference guide could be generated
  2. We can verify/test code and check for breaking changes
  3. Generate and verify clients from the api specification
  4. Build/contribute additional tooling around the specification

Those would be great.

Incidentally, we actually have tests for verifying stuff like the curl examples 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.

Oh My!

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.

Having so much content being promoted on the trending page lately, sometimes these really important messages don't get the visibility they should have.

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

image.png

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

  1. It's lua
  2. Plugin infrastructure exists for future improvements and extensions
  3. Multiplexing builtin.
  4. Reverse Proxy builtin
  5. Throttling builtin
  6. Authz/Authn builtin
  7. FaaS builtin
  8. Microservice awareness builtin
  9. You just get so much stuff for free you don't need to build anymore and you can just concentrate on building blockchain stuff

Also, it's not just better because the work would be less, but the benefits are greater

  1. Simplified infrastructure
  2. More flexibility design and implementation
  3. Maintained by another community (you just focus on you)

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 genial ver como el equipo de Steemit blogs pone al alcance de los desarrolladores sus códigos para permitir el acceso correcto y no "la ingeniería inversa".
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!
It's great to see how the Steemit blogs team makes their code available to developers to allow correct access and not "reverse engineering". It is good to see how you strive for a day to get better results and better results, the best of the best. To you, a thousand thanks! Again...
THANK YOU!