Realworld: [Important] What's in the core spec / what gets defined as "extra credit"

[EricSimons]

There have been a ton of great ideas proposed for additional "real world" examples that could be demonstrated with Conduit: i18n, feed recommendations, microservices, testing, and more.

This has spawned discussions about the core spec itself: is it a "real world" example if it doesn't include tests? What about supporting internationalization? These are common parts of many production codebases, especially ones that touch large numbers of end users.

However, it's important to remember that "real world" is a relative term — it means different things to different people, especially under different contexts. That's why we designed the core spec to be as barebones as possible, as we needed a set of functionality that everyone could agree on. From the spec:

The quality & architecture of Conduit implementations should reflect something similar to an early stage startup's MVP: functionally complete & stable, but not unnecessarily over-engineered.

This is basically just saying that every single Conduit app needs to, at a minimum, have the bare functionality working. This seems pretty reasonable. What's the point otherwise?

However, it notably doesn't prescribe a solution to the other interesting possibilities that have been surfaced as of late (testing, i18n, etc).

To solve this problem, I actually don't think we should change the core spec that all base stacks must adhere to. Instead, I think we should encourage people to fork off of the completed base stacks to demonstrate _any other_ real world examples.

Imagine someone forking the Node/Express stack and adding oauth, someone forking the Ember app and adding i18n... the list goes on. The base repo's could list out links to all of the forked versions, making it easy to see all the various "real world" examples that people have built on top of them so far.

Instead of the core spec limiting what devs can demonstrate, the core spec would actually just be a _minimum_ for what can possibly be demonstrated.

We'd essentially be encouraging devs to use Conduit as the base application for any real world demos, examples, & tutorials that they create.

Of course, we always want to have & maintain a barebones codebase for each stack that everyone can fork off of. But beyond that, the sky is the limit.

Should we have new specs for the testing, i18n, etc to ensure all forks are identical? I don't think so — not yet at least. Implementation details, best practices, tooling, etc vary greatly between stacks, so having a spec for certain topics might do more harm than good.

Would love to hear thoughts on this!

[Cameron-C-Chapman]

TLDR: Keep the spec exactly like it is, stress community review and buy in, and add a spec for at least one passing unit test so the unit test architecture is demonstrated.

I think the spec as it stands now is perfect for what realworld is trying to accomplish. The only thing I think is worth consideration for adding would be unit testing.

Here's what I would say a realworld implementation should accomplish before being considered for listing as an official project:

• Fully adheres to the front end or back end spec and all functionality works as expected
• Does not require any complicated setup and running requirements (other than perhaps the environment itself, a node implementation can expect you have node installed etc.)
• Has been reviewed and signed off on by some one active in the community. I actually think this is really important and serves as a way for realworld to feel comfortable that it's a project that's been developed with that frameworks best practices in mind.
• Personally I think at least a unit test should be written. Not necessarily 100% code coverage but unit tests are one of those things that often take years to realize the importance of but are extremely important as a developer matures. I think asking devs that want to represent a framework to some degree to at least show the structure, libraries, and architecture that writing unit tests require would represent realworld positively to newer devs as well as experienced devs who have extremely strong opinions about these types of things.

I think anything other than that type of implementation could still go through a similar process with community buy in and review but instead of being included as an implementation option it could be listed and linked to in a list of extended implementations that people are open to explore that are interested.

[Alonski]

I think having these as Extra Credit is a good idea.
We at Realworld-Ember are implementing Tests gradually and trying to get good code coverage from the start as Ember gives us so much without much work on our side.
It would be a shame if we didn't utilize it.
I am not sure if each Extra Credit should be in a different branch, for example testing isn't in a different branch as explained.
i18n thought could be in a different branch and could be finished after the whole spec is followed.

[EricSimons]

TLDR: Keep the spec exactly like it is, stress community review and buy in, and add a spec for at least one passing unit test so the unit test architecture is demonstrated.

^ bingo. I def think this is the right way to proceed. 💯

Regarding testing — I think @Cameron-C-Chapman's idea to enforce a bare minimum of one unit test is brilliant. It ensures that all testing infra req'd for that framework will be included out of the box on day 1, and will ensure anyone who PR's additional tests doesn't have to fiddle around with tooling/etc.

To @Alonski's point, having a full set of tests is definitely a win, so the _minimum_ number of unit tests an implementation can include is _one_. We'd love it if every implementation had full testing coverage, but the only hard requirement is that you include _at least_ one example of a unit test.

So in conclusion, testing would be the only thing we're adding to the core spec (minimum of 1 unit test), and all other ideas (i18n, etc) would be demonstrated via forks of the base repo's.

That sounds good to me — what do y'all think?

[lolripgg]

Sounds reasonable. Where do we go from here? Probably best to turn this into a philosophy doc (as mentioned) or part of the README. Next question is how do we increase the probability that creators will see this?

[EricSimons]

I think including the testing/philosophy updates in the spec should ensure new creators see this, and I'll also ping all current WIP folks on gitter/etc and let them know as well :)

[entrptaher]

If this is the case, then there can be something called spinoff or uses where different people uses realworld to solve different problem which will not be much moderated, but used to show how realworld is actually being used on realworld contexts.

This is already written as Community created resources but doesn't have any forks or spinoffs listed under that. Thus this is still an empty space to be filled.

[Cameron-C-Chapman]

@entrptaher We're definitely open to people using the real world spec to demonstrate specific use cases. We don't really have the first example of that yet, I almost think once we get a good example of someone using realworld to demonstrate specific ideas we can figure out how to categorize that.

At the very least we would definitely get it on the main readme and call attention to it. I agree it should probably be called out a little more specifically than just Community Created Resources.