I would love to see an app store for Resin.io apps. Docker just opened up the Docker store (https://store.docker.com) and it would be nice if we had somewhere we could easily publish our work for others to use without having to go through the git clone/remote add resin/push resin dance.
Taking unnecessary steps out of the middle may lead to broader adoption, and make Resin more generally accessible to less technical folks.
I think the ideal process would look like this:
Image and install the SD card
Create an app in the Resin dashboard
User has the option of using an existing, published app or getting a git endpoint to deploy their own
If the user selects a pre-made app, they get an email notification when a new version is published and has a visual call to action, in the dashboard page for the application, to upgrade their app to the latest version.
Hey @ashmastaflash, interesting idea. Could think of a couple of hackish ways to test some of the aspects out.
I know it does not go all the way, but if would it help somewhat if people could deploy apps directly from github? Then it would be a matter of fork+deploy, something like:
Create an application
Download and flash the SD card image
Fork an appās repo on github, and use a (not yet created) integration to tie it to the app
Deploy (single click or automatic)
Future versions can me merged from upstream, and deployed the same way.
Not a full solution of course, though, might have an advantage for some of the apps that thereās a clear place to build a community around it (github/issues/pull requests/forks & network/gitter chat integration), which might get them to a larger audience too. This compared to when apps āliveā inside resin.io and need to be curated, maintained, etcā¦
The notifications are also pretty doable (probably:) in this case as well.
These are just some thoughts how to get going and try it out the quickest. Do you have some ideas what apps youād like to see? If yes, some could be good testing ground, build some proof-of-concept solutions (either as above, or any other way based on the experience building it). Iām excited
Do you need the āforkā part? In the app case, lots of people would be deploying apps they didnāt intend to change the images for. You could plausible set up an integration that lets projects add a āDeploy to Resinā button to their Github projects, identically to the Deploy to Heroku buttons for web apps.
With that, you get the forking workflow for free on top too (after you fork it the button is still there and valid, itās just now itās in your repo so you can push updates too).
I think itās the matter of what is available for GitHub integrations. Those mostly work on your own repos, not other peopleās repos. So my own repo should be associated with my own resin.io user. On the other hand, I can imaging an external service that can get around the forking. The use cases can be tricky, though, just as a starter, would you always-always want to run the latest version of a code? If itās self service like the GitHub workaround, then Iād like to have a way to use known-good versions (which the fork enables).
The community side of that was, that with the fork project creators know when their application become popular and been used by others. Just a potential upside.
Still yeah, needs more thinking (and prototyping, Iām sure)
Iād be interested in hearing more about how folks would want to see an app store for resin.io work. To @imrehg and @timās point, would people be interested in modifying the applications before deploying them or simply grabbing something that exists and pushing it to devices? (I suppose if all you needed to change were configuration values of some sort you could use environment variables with no code change.)
@ashmastaflash, do you have an example of what youād want to see this working with? E.g. a user story about an app youād want to deploy and how the process would work.
Hi @mccollam!
It would be awesome if a user could browse apps in a store-like environment (think https://store.docker.com/) but instead of checking out images, the user has a call to action that instantiates the app within their own Resin account. That app would be less verbose as far as the web UI goes- you wouldnāt see build logs or the git remote add bit. Put an app upgrade link in the upper-right that flashes if a newer version of the app is available, and let the consumer decide when to upgrade it. Ideally, the user will not have to touch the CLI for anything at all. Just check out the app, configure environment variables, and image the SD card. Using git doesnāt intimidate me, but I can see others being intimidated by the whole process. If you can stay away from the CLI, you can enable less technical folks to use the service. This will go a long way toward enabling a developer to deliver an application through your service to non-technical users.
An example app would be https://github.com/sitch-io/sensor . Nothing important happens between cloning down and pushing to resin, itās just a thing that you do to get the app built in Resin. If a user could just image devices and configure device variables, it would go a long way toward flattening the learning curve, and getting the app in the hands of the user without requiring an understanding of the technology used to deliver the service.
Interesting. Thanks for the description, @ashmastaflash!
I think we would need to consider what the UX would need to be for all of this but most of the underpinnings are there already ā you can share applications with other users and move devices from one app to another in the platform as it stands. I think what you described is a sort of special case of this workflow in fewer discrete steps.
Iāll mention @shaunmulligan who might be interested in this as well!
