Fullstack repo about realworld

[Cameron-C-Chapman]

I wonder if some standardized sections in the readme like "startup prerequisites" and "startup" along with some standardization around things like port numbers to use could help? That way if a project is getting merged those startup instructions can be validated and the port numbers are always common so swapping out backends is trivial. Say for example front ends are always 9000, backends are always 9001, and the db's are always the db specific default?

[anishkny]

I would think docker-compose would be great for this? Assuming we standardize each stack's specification using Docker.

[jamesbrewerdev]

Server side rendering sounds reasonable to me. We just need to find someone to take point.

…

On Sat, Apr 29, 2017 at 8:46 AM James DiGioia ***@***.***> wrote: Related to the Meteor question, but what about implementations with server-side rendering? That explicitly couples the FE/BE, and the current projects don't handle that (I don't think...). It would also require changes to the FE routing, as the current hash-based routing can't be handled by the server. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD5-rOCaIIGAlxXKi-kZMJknyYMsfzwNks5r01thgaJpZM4NIE8k> .

[battila7]

@EricSimons Thought the same with the CLI, it would've been a small wrapper for something like Docker or Vagrant, nothing OS or env-dependent.
But in any form, I absolutely agree with this idea.

[SachaG]

Somewhat related, what about fullstack frameworks like Meteor? Would they be acceptable too?

[jamesbrewerdev]

I don't think this is realistic because that would require n^m repositories.

Chances are we can solve this by improving each repo individually, as needed. Regarding the issue you mentioned: this looks to be an error caused by not locking Angular to the correct version. That's a trivial fix.

If this becomes a big deal then it makes sense to re-visit. For the moment though, it sounds like a lot of work to fix a small problem.

[jamesbrewerdev]

@SachaG It's probably best to move your question to another issue. It's definitely a valid question. I'm not sure how much consideration frameworks like Meteor have been given. Feel free to create one!

[EricSimons]

Agree with @BRWR here, but I think I get the essence of what @anishkny is getting at: I want to be able to run this stuff locally with zero room for failure. I'm 100% on board with that. I feel like the best solution might be creating a vagrant/docker/etc image that can boot any of our backends/frontends, because then you could even bundle DB into it as well. Thoughts?

[jamesbrewerdev]

I love the idea! Especially since we'd get to bundle the DB. But Docker/Vagrant/etc have their own set of problems. Specifically, I'm worried about dealing with cross-platform issues when it comes to getting Docker set up.

That said, I suppose we would at least localize all of the potential issues to Docker.

Maybe we could hack something together over a weekend? Happy to help with that. We can get it front of a few folks and see how things go.

[EricSimons]

@SachaG would definitely love to see meteor on here! We already have other non-REST implementations like GraphQL as WIPs that require full rewrites for FE&BE, so this would be a similar to that I'd imagine.

Were you thinking of starting Meteor implementation for RealWorld? If so, feel free to fork the starter kit and create a new issue for it 🎉

PS - huge fan of Discover Meteor, still one of my fav tuts ever ❤️

[EricSimons]

@BRWR that sounds good to me!

@anishkny would love to hear your thoughts -- would a common docker image solve that pain point you were having?

[anishkny]

I don't think this is realistic because that would require n^m repositories.

Hey, did you mean n*m instead of n^m? But yeah point taken, it would be a high enough number not to be practical.

I feel one hard API requirement should be that each implementation has to tell me exactly what steps I need to follow to bring up the full stack (either BE or FE) to make it usable against anything else (other FE, BE, Postman, whatever).

Right now even the NodeJS reference repo does not tell me how to spin up MongoDB (I tried, it was non-trivial 🤕, hence opened issue#12).

If we were able to standardize in API how each stack is supposed to be started (say everyone has to give a "start.sh" script in repo root, or "npm start" or whatever), we could even do a static HTML UI which lets you select FE/BE/DB etc from various option selectors, press abutton and boom! gives a list of commands to be run for setting the whole stack up! I dunno a bit pie-in-the-sky maybe 😃

[battila7]

If the requirements were modified as @Cameron-C-Chapman said and Docker were dropped in (as a requirement too) then a CLI tool would be able to start up an appropriate backend and frontend as asked.

[Cameron-C-Chapman]

I also think there is a potential for a cli here that could be really cool. It would be difficult for sure but the idea of being able to do something like "realworld start --frontend=angular --backend=go" could make the process of experimenting with different stacks really seamless.

[EricSimons]

I feel one hard API requirement should be that each implementation has to tell me exactly what steps I need to follow to bring up the full stack (either BE or FE) to make it usable against anything else (other FE, BE, Postman, whatever).

Right now even the NodeJS reference repo does not tell me how to spin up MongoDB (I tried, it was non-trivial 🤕, hence opened issue#12).

Yikes. This is a really good point — every stack should have very thorough instructions for installing/running. I think this is important enough to split out into a separate issue (hence #62)

Regarding creating a CLI, etc — the problem with that is the same as what I was describing before. Managing a custom install script(s) for all these stacks will be an enormous challenge because every stack uses different languages, package managers, frameworks, etc that have varying levels of interop between operating systems, etc and that doesn't even include standard setup of running DB instances.

This problem is precisely what Docker/Vagrant were made for, so I feel like it would make the most sense to have an image that you can just download and every stack "just works". And we could even add a simple UI like @anishkny described that could boot the stacks within that image 💪💪

Yay/nay? :)

[Cameron-C-Chapman]

I'll move the discussion to #62 but I agree with the consensus here. Docker is probably the best tool to look at solving the problem of managing so many different environments.

[EricSimons]

@battila7 OHH gotchya, I love that idea — I wonder how hard it would be to wrap docker install/run functionality (reliably) with a custom CLI. Anyone have deep experience w/ docker who could comment?

[jamesbrewerdev]

After Docker is set up, it's just a bunch of CLI calls. That is easy to do for a specific OS. The trouble is making it work cross-platform. @EricSimons Let's take a look when you get back?

…

On Wed, Apr 26, 2017 at 10:52 AM Eric Simons ***@***.***> wrote: @battila7 <https://github.com/battila7> OHH gotchya, I love that idea — I wonder how hard it would be to wrap docker install/run functionality ( *reliably*) with a custom CLI. Anyone have deep experience w/ docker who could comment? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD5-rLSxK6KccvHz2dYRpOxNyaX6HXoxks5rz4RAgaJpZM4NIE8k> .

[EricSimons]

@BRWR Sounds good — would be a cool weekend hackathon project :) If anyone else wants to do some R&D/experimentation on this in the meantime, by all means feel free to start!

[pixelbandito]

You could also use submodules for frontend and backend in a master repo with branches for the different combos.

[mAAdhaTTah]

Related to the Meteor question, but what about implementations with server-side rendering? That explicitly couples the FE/BE, and the current projects don't handle that (I don't think...). It would also require changes to the FE routing, as the current hash-based routing can't be handled by the server.

[EricSimons]

@pixelbandito totally — we were thinking of doing that with this repo originally, but it unf left out the problem of OS compatibility, database setup, etc :( Hence why we're thinking docker is a good solution here!