Comments (22)
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?
from realworld.
I would think docker-compose would be great for this? Assuming we standardize each stack's specification using Docker.
from realworld.
from realworld.
@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.
from realworld.
Somewhat related, what about fullstack frameworks like Meteor? Would they be acceptable too?
from realworld.
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.
from realworld.
@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!
from realworld.
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?
from realworld.
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.
from realworld.
@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 ❤️
from realworld.
@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?
from realworld.
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 😃
from realworld.
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.
from realworld.
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.
from realworld.
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? :)
from realworld.
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.
from realworld.
@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?
from realworld.
from realworld.
@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!
from realworld.
You could also use submodules for frontend and backend in a master repo with branches for the different combos.
from realworld.
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.
from realworld.
@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!
from realworld.
Related Issues (20)
- [SWAGGER] register and login response schema issue HOT 1
- [Bug]: Line breaks not showing correctly HOT 1
- [Bug]: Immediately signed out after logging in HOT 3
- [Backend] Remove Response Envelopes HOT 5
- [Bug]: When try to build HOT 5
- User registration success status code is 200, but docs/swagger show 201 HOT 1
- [Bug]: server ERROR 500 HOT 2
- [Bug]: CORS Error HOT 9
- [Feature Request]: offline functionality HOT 2
- [Bug]: Demo server status is 503 HOT 1
- [Feature Request]: Vuetify in Realworld example HOT 1
- [Bug]: Continuous modification of user information results in an error HOT 4
- Try this HOT 1
- [Bug]: demo APIs down? HOT 2
- [Bug] initialData.data from route loader is always undefined HOT 1
- API server doesn't work HOT 1
- [Bug]: Heroku Deployment failed
- [Bug]: API doesn't work HOT 4
- [Bug]:CORS Issue HOT 1
- [Bug]: Demo backend is down HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from realworld.