👨💻 TL;DR: Django, Postgres, Redis, Vue.js, Webpack
We try to keep our stack as simple and stupid as possible. Because we're not very smart either.
The trickiest part of our stack is how we develop the frontend and backend as a single service. We don't use SPA, as many people do, but only make parts of the page dynamic by inserting Vue.js components directly into Django templates. This may seem weird, but it actually makes it very easy for one person to develop and maintain the entire site.
You don't really need to understand how the magic of webpack <-> django communication works under the hood to develop new components. Just run django runserver and npm run watch at the same time and enjoy your coding.
Feel free to propose "state of the art" refactorings for UI or backend code if you know how to do it better. We're open for best practices from both worlds.
-
Install Docker
-
Clone the repo
$ git clone https://github.com/nDmitry/RationalAnswer.club.git $ cd RationalAnswer -
Run
$ docker-compose up
This will start the application in development mode on http://127.0.0.1:8000/, as well as other necessary services: postgres database, queue with workers, redis and webpack.
The first time you start it up, you'll probably need a test account to get right in. Go to /godmode/dev_login/ and it will create an admin account for you (and log you in automatically). To create new test user hit the /godmode/random_login/ endpoint.
Auto-reloading for backend and frontend is performed automatically on every code change. If everything is broken and not working (it happens), you can always rebuild the world from scratch using docker-compose up --build.
For more information on how to test the telegram bot, run project without docker and other useful notes, read docs/setup.md.
We use standard Django testing framework. No magic, really. You can run them from PyCharm or using Django CLI.
See docs/test.md for more insights.
We don't have UI tests, sorry. Maybe in the future
Automatic CI/CD pipelines are building and testing the app on each PR. They also deploy changes to production on merge to main (only a maintainer can do it).
These pipelines are made as github-actions. Explore the .github folder for more.
☝️ We still need someone to improve and optimize our CI workflows. They work but they're really poor :D
Contributions are welcome.
The main point of interaction is the Issues page.
Our CI/CD pipelines have to take all the dirty work. They build, test and deploy changes to production on every merge to main (only official maintainers can do it).
We also run the public Github Project Board to track progress and develop roadmaps.
We're open for proposals on how to improve our deployments without overcomplicating it with modern devops bullshit.
- 🆕Open a new issue.
- 🔦 Please use the search to check if there is an already existing issue!
- Explain your idea or proposal in all the details:
- If it's a new feature:
- 🖼 If it's UI/UX related: attach a screenshot or wireframe.
- Please mark this issues with prefix "Фича:"
- 🐞 If it's a bug:
- make sure you clearly describe "observed" and "expected" behaviour. It will dramatically save time for our contributors and maintainers.
- For minor fixes please just open a PR.
- Please mark this issues with prefix "Баг:"
- If it's a new feature:
Contributions are welcome.
The main point of interaction is the Issues page.
Here's our contribution guidelines — CONTRIBUTING.md.
We also run the public Github Project Board to track progress and develop roadmaps.
The official development language at the moment is Russian, because 100% of our users speak it. We don't want to introduce unnecessary barriers for them. But we are used to writing commits and comments in English and we won't mind communicating with you in it.
- Open our Issues page to see the most important tickets at top.
- Pick one issue you like and leave a comment inside that you're getting it.
For big changes open an issues first or (if it's already opened) leave a comment with brief explanation what and why you're going to change. Many tickets hang open not because they cannot be done, but because they cause many logical contradictions that you may not know. It's better to clarify them in comments before sending a PR.
- good first issue — good tickets for first-timers. Usually these are simple and not critical things that allow you to quickly feel the code and start contributing to it.
- bug — if something is not working, it needs to be fixed, obviously.
- critical — the first priority tickets.
- improvement — accepted improvements for an existing module. Like adding a sort parameter to the feed. If improvement requires UI, be sure to provide a sketch before you start.
- new feature — completely new features. Usually they're too hard for newbies, leave them for experienced contributors.
- idea — discussion is needed. Those tickets look adequate, but waiting for real proposals how they will be done. Don't implement them right away.
- ¯\_(ツ)_/¯ - special label for questionable issues. (should be closed in 60 days of inactivity)
- [no label] — ticket is new, unclear or still not reviewed. Feel free to comment it but wait for our maintainers' decision before starting to implement it.
If you think you've found a critical vulnerability that should not be exposed to the public yet, you can always email me directly on Telegram @vas3k or by email: me@vas3k.ru.
Please do not test vulnerabilities in public. If you start spamming the website with "test-test-test" posts or comments, our moderators will ban you even if you had good intentions.
First of all, this is a fork of another project originally developed by @vas3k. So thanks to him and their top contributors for the great amount of work done!
Take some time to press F and give some respects to our best contributors, who spent their own time to make the club better.
In other words, you can use the code for private and commercial purposes with an author attribution (by including the original license file).
Feel free to contact us via email contact@rationalanswer.club.
❤️