`pkg.gno.dev` - a gno package registry

[zivkovicmilos]

Description

This issue proposes a service similar to pkg.go.dev, but for Gno packages, hosted on:
pkg.gno.dev.

Essentially it would be a 2 part process:

• frontend that displays the data, interacts with a small backend
• backend server that indexes the data (using the tx-indexer), parses it and saves it in a DB (this is super general, but you get the idea). It can utilize the tx-indexer graphQL interface for subscribing to new package deployments, and index them as soon as they become available on chain.

We will need some kind of search engine for the parsed and saved data, to be served quickly to the users

The web app should be chain agnostic, meaning we can specify the chain RPC we want on startup and it will index the packages / realms

cc @alexiscolin @AidarItkulov @sw360cab @Kouteki

[thehowl]

backend server that indexes the data (using the tx-indexer), parses it and saves it in a DB (this is super general, but you get the idea). It can utilize the tx-indexer graphQL interface for subscribing to new package deployments, and index them as soon as they become available on chain.

This is more complex than needs to be; you just need vm/qfiles on a given package

[thehowl]

This is something that has been on my mind since I joined the team, basically. Sadly, it's something that has been shoved in the backlog again and again, due to a lot of other efforts popping up time after time.

I favour much more the idea of having this functionality directly integrated in gnoweb. Why:

• It works offline, and with gnodev out of the box.
• It can be used to replace ?help, with a page that not only helps you construct gnokey queries, but also gives you documentation (through the gnodoc comment) on how to use the realm function.
• It just makes sense for it to be the default view when looking at a package. https://gno.land/p/demo/avl just points to the files today; tomorrow it can just show its contents.
• Users don't have to look on a different website to get information on what they need. Because it's integrated directly in gnoweb, you don't need to have a "network dropdown" as we have for things like the playground, gnoscan, etc.

I dislike the approach of "if we're missing something, let's just build it on the side". I get that creating new stuff is more fulfilling and fun than fixing up the mess we have elsewhere. But it's breaking down the product that we're trying to build into many different websites and tools when the functionality could be condensed down. I feel a similar fate has happened with Gno studio connect. That app could just be a better help page with an integration with the Adena wallet. It is a full web app on a different website.

This is not to discredit the incredible work that DevX has made; but it ignores the simple reality that the homepage of the project on gno.land, and its testnets, uses gnoweb. If a feature falls in the scope of gnoweb and should be part of our core offering as the next generation smart contracting platform, then it should be done there. A web gno doc interface is a part of that core offering. /rant

[zivkovicmilos]

@thehowl

I dislike the approach of "if we're missing something, let's just build it on the side". I get that creating new stuff is more fulfilling and fun than fixing up the mess we have elsewhere. But it's breaking down the product that we're trying to build into many different websites and tools when the functionality could be condensed down. I feel a similar fate has happened with Gno studio connect. That app could just be a better help page with an integration with the Adena wallet. It is a full web app on a different website.

I'm a big supporter of having options, and that people shouldn't be constrained to the tools / services we offer. I try to apply this to most of the tools I've built for gno, where I leave room for adaptability.

I don't see a reason why gnoweb can't have this kind of functionality as well. Why shouldn't we build an alternative, that will probably be more refined and polished? The community will decide what to use.
It's the same situation we have for the faucet, you can use it on gnoweb, but also on the faucet hub. For me personally, the UX on the faucet hub is much better, and in the end for user-facing apps this is the point. Not everyone is a minimalist maxi when it comes to tools and platforms 🤷‍♂️

The DevX team has been crushing it on the "polish" and "refine" part of the project, something we seem to be dropping the ball on with gnoweb, with a "refactor" discussion being brought up quite recently.

I'd also like to mention that gnoweb isn't the product here, the product is the blockchain, gnoweb, Gno Studio Connect, the Faucet Hub etc are just avenues for exploring it

[alexiscolin]

Agree with you both. This feature would be very interesting to be integrated into gnoweb (just like connect by the way! - be able to update a realm and see the result directly though the render function in gnoweb would be very useful and a DX improvement IMO) but also as single app.

Could make sense if we propose a dual approach for the package registry: a standalone service (pkg.gno.dev) offering full functionality with a dedicated frontend for detailed management and search, and a light version integrated into Gnoweb providing basic listing and search features. This hybrid solution ensures flexibility, allowing users to choose between the comprehensive service and a streamlined experience within Gnoweb (that could improve gnoweb with https://gno.land/p/demo/avl for ex), catering to different user needs effectively.

Additionally, the dedicated platform would offer a more specialized and focused environment, ensuring greater customization that might enhance the user experience for those requiring in-depth package management and advanced search capabilities? Moreover, a dedicated platform like pkg.gno.dev could help improving the SEO through better indexing and structured data (gnoweb refactor should help in this topic), and increase the visibility and discoverability of packages and Gno.