Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] Mockit Project Architecture #25

Open
samrith-s opened this issue Apr 24, 2019 · 0 comments
Open

[Enhancement] Mockit Project Architecture #25

samrith-s opened this issue Apr 24, 2019 · 0 comments

Comments

@samrith-s
Copy link

I have dived into Mockit's code. Overall the idea seems awesome. But I have a few discrepancies to list regarding the project and it's execution:

Problems

  • Docker seems like an overkill for this. We can simple have node scripts run which will do exactly what Docker is doing.
  • While development it is a big pain as the client HMR does not work as expected. For it to work effortlessly, one needs to go into the client folder and run yarn start or the likes.
  • For one to use Mockit, they need to clone the entire repository. This is counter-productive, since I cannot run separate instances of Mockit.
  • We can do something similar (though it does not have a UI, but still good to mock) using Glitch (https://glitch.com/). So we do need to determine the scope of this project.

Solutions

What I propose is, for the project to be meaningful and to be integrated into a proper development workflow, we should do the following:

  • Define the scope of the project. Right now it's too cluttered and closely knit with this repository itself.
  • Split out the project into client, server and CLI separately.
  • Build a better dashboard with more controls.
  • Make it into something like CRA, such that multiple instances of Mockit can be deployed.
  • Introduce some code formatting guidelines. Right now, the project has no linting. This is difficult as every file, formats as per the contributor's IDE specs.

Additionally, we should create an org on GitHub, under which everything will reside. We could follow a mono-repo structure sans Docker, and use Lerna instead. I believe that will solve a lot of the problems, and help give out more meaningful messages in the console to the contributor during development.

Do let me know what you think!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant