Archive old Motoko examples

[jessiemongeon1]

Overview
Why do we need this feature? What are we trying to accomplish?

Requirements
What requirements are necessary to consider this problem solved?

Considered Solutions
What solutions were considered?

Recommended Solution
What solution are you recommending? Why?

Considerations
What impact will this change have on security, performance, users (e.g. breaking changes) or the team (e.g. maintenance costs)?

[chenyan-dfinity]

Why do we want to move these examples under archive? Some of these examples are used by playground, we will need to coordinate to prevent breaking playground.

[jessiemongeon1]

@chenyan-dfinity We're cleaning up the examples repo and removing examples that are duplicates, outdated and not maintained, or do not showcase a meaningful app. Some of these are small Motoko examples (actor-reference and counter are two examples) that are duplicated across the Motoko docs in several places, and it is not meaningful for them to have their example in this repo that will soon contain more complex and comprehensive app samples.

Is there an easy path to migrating these examples to the new URLs in Playground?

[chenyan-dfinity]

It's easy to update the URL in the playground, and I agree that most of the apps here are out dated. But small/minimal examples do have values, in particular counter, classes, and whoami. It's best to learn from small examples.

[jessiemongeon1]

counter is a duplicate of minimal-counter-dapp which includes a frontend, classes is used in the Motoko docs page for Actor classes (so it can still be easily found/used) and it doesn't showcase a specific use case, and whoami is a duplicate of the Internet Identity integration sample, which includes a frontend.

Ideally, all examples should have a frontend, so these duplicates without a frontend are being archived in favor of the versions with a frontend.

[chenyan-dfinity]

classes is used in the Motoko docs page for Actor classes (so it can still be easily found/used) and it doesn't showcase a specific use case

I think it's the contrary, we want to have everything mentioned on the docs page to be available in the example repo, so that people can try out. classes shows how to spawn a child canister with actor class in Motoko, which is a unique feature only available in Motoko.

Ideally, all examples should have a frontend

I think some examples may benefit without having a frontend, so that readers don't get distracted. A few examples come to mind: http outcalls and pub-sub. Having a frontend can make it harder to see the underlying concept. whoami is another example. II is only one way to do make non-anonymous calls. If the example only contains II, it can make a wrong impression for the new comers.

[jessiemongeon1]

What would your proposed change be for this PR?

[rvanasa]

If the goal is for each example in this repository to have a direct use case, maybe we could move the Motoko-specific language feature examples to the dfinity/motoko repository in an examples directory? This would give us the flexibility to include more of these minimal examples to showcase individual language features. This would also make it simple to continue these examples in Motoko Playground, and we could include the examples in the testing workflow to make sure they remain up to date.

[chenyan-dfinity]

I may be missing context, is there a doc to discuss the examples revamp? We can discuss from there.

[jessiemongeon1]

No, there is not a currently a doc, this was a task given to me as part of the Web IDE project.

The task was to take an inventory of our current examples, determine which examples showcased full applications (frontend/backend), which could be improved to become full applications (i.e., add a frontend), and which examples were duplicates or outdated. The idea is that each example we have in the repo (ideally) becomes a project template for the Web IDE and users can pick one when they enter the Web IDE. There are also plans to create several new examples that showcase use cases for everyday activities, such as writing, art, fitness, etc.

For some examples, such as the classes example, providing that as an option for a new user to get started building in the Web IDE would not make much sense, since they would not have much initial context of Motoko and why the classes feature is important.

I agree with Ryan's idea that it might be better to move the Motoko-specific examples to the Motoko repo and maintain them there, rather than archive them in this repo.

[chenyan-dfinity]

For some examples, such as the classes example, providing that as an option for a new user to get started building in the Web IDE would not make much sense, since they would not have much initial context of Motoko and why the classes feature is important.

Web IDE can cherrypick examples from this repo, it doesn't have to show all projects from here. When the users read the classes example from the doc, there should be a way to open the Web IDE and try out that example. Naturally, this kind of examples stay in the example repo, and it's okay for the Web IDE to deploy a backend only project.

Moving them to the Motoko repo would make it harder to find the examples, e.g., which examples stay in the example repo and which ones stay in Motoko repo? Examples repo is a collection of projects satisfying different needs. It cannot be only for the Web IDE gallery. We even have C and raw wasm examples here.

In terms of deprecation, I feel like many of the examples need a rewrite, instead of archiving. Let me comment on the spreadsheet.