Realworld: Should We Add An Isomorphic Framework Category?

[Cameron-C-Chapman]

Should we add a category that frameworks like Meteor have a spot on the README?

I personally like the idea but am curious of everyone else's thoughts. @gothinkster/realworld-admins

[anishkny]

If this were a category, then arguably Firebase could be added to it because it is awkward to fit Firebase into a the RealWorld API.

[barriehadfield]

Please consider http://ruby-hyperloop.org/ which is a 100% Ruby Isomorphic framework. This represents very modern application design which does not fit a FE/BE construct as we have specifically moved away from that for spectacular simplicity and productivity improvements.

[tony-shannon]

Would be very interested to see isomorphic frameworks in the mix, with adherence to the "same API spec" as everything else in realworld.io

[catmando]

@tony-shannon the problem is that a big advantage of "isomorphic frameworks" is that they don't need APIs to communicate between server and client. So while you can certainly call APIs, and create API end points, doing so defeats one of the great advantages.

For example to display a list of Articles in Hyperloop you would have the following code:

...
  Articles.each do |article|
    LI { article.title }
  end
...

Likewise to follow another user the code would be:

...
  # this line is probably in a button click event handler, where user, and article are locals vars
  user.favorite(article) 
...

The code just accesses and updates the models directly, without having to write reducers and stores on the client side, and API endpoint controllers on the client side. Internally the isomorphic framework uses a meta transport/synchronization mechanism that keeps the browsers and database in sync, so there is no need for the explicit API.

So when comparing isomorphic frameworks, with traditional FE/BE frameworks, you would need to compare say hyperloop with React (FE) + Rails (BE). Of course, you can also compare hyperloop with say meteor.

[tony-shannon]

thanks @catmando

Interesting.. & I can see advantages
yet one of the purposes of realworld.io is to compare/contrast between approaches based on adhering to an API spec.

So I'm wondering how can anyone compare/contrast the code of an isomorphic framework to any other approach in this "Conduit Blog to the Realworld API spec" challenge ..?
How can u verify that the blog functionality is like for like?
With user acceptance testing? of the user profiles, articles, comments, tags etc?
Don't you end up with a load of isomorphic based blogs being developed with little/nothing in common.. or what do they have in common?

If you dont adhere to the realworld API spec why exhibit here? Why not an isomorphic framework showcase somewhere else?

Playing devils advocate as the isomorphic advocates seem to be missing key aspect to the realworld.io libraries.. the common API to ensure frameworks can be directly compared/constrasted.

This is an interesting discussion .. thanks

[anishkny]

How can u verify that the blog functionality is like for like?
With user acceptance testing? of the user profiles, articles, comments, tags etc?
Don't you end up with a load of isomorphic based blogs being developed with little/nothing in common.. or what do they have in common?

The commonality can be the user-experienced frontend as validated by some browser based acceptance tests. I have a repo showing how to test a full RealWorld (NodeJS BE + React/Redux FE) stack using Chrome Puppeteer and Jest.

https://github.com/anishkny/realworld-e2e-test

We can formalize this as a requirement for isomprphic/full stack implementations.

[catmando]

I think the acceptance test would be a great add to RealWorld anyway. Also it would promote people doing more e2e testing by showing how.

[tony-shannon]

thanks @anishkny @catmando and agree with you both.. thats a very nice idea..
It promotes the User Experience as a standard to comply with..
It helps ensure "like for like" functionality is produced, so codebases can then be reasonably compared
It helps educate folk in E2E testing..
Good thinking, thanks