search

DemocracyOS / democracyos

Democracia en Red is focusing on specific implementations of DemocracyOS. We are working now working with governments and activists all over Latin America. If you are interested in our online participation tools you can check them out on our site.
https://democraciaos.org/en/
GNU General Public License v3.0
1.77k stars 616 forks source link

Dev-love addition ideas💡 #1214

Closed mjlescano closed 6 years ago

mjlescano commented 8 years ago

This issue is to discuss new techs to add, or to change the way we do things. Here we can generate a resume (wish-list?) of the things that are coming tech wise.

Dev Process 📋

Code Quality 🎨

Testing ✅

Docker 🐳 ✔

Techs 💾

Security 👮

franciclo commented 8 years ago

Module bundling

dogonbeach commented 8 years ago

Is a simple Api for accessing the system via an external third party web and mobile app a possibility? We discussed this last year not sure if it was implemented.

gvilarino commented 8 years ago

@VictorW1 I think so, but still, our backend is a REST API in itself, so I'd like to discuss more on that matter. What would you expect from that? Are you referring to having some sort of API-only token-based auth for REST calls?

SebastienDaniel commented 8 years ago

Testing

I totally approve of Mocha, Chai, Sinon. They're proven and ubiquitous unit testing solutions.

Module bundling

I'm partial to browserify, but that's just a question of habit. I've hit some issues/limitations with it where my compilation steps are become unnecessarily hackish. If WebPack can circumvent that, I'm all for it.

Techs

Redux is a godsend when state is becoming complex. I totally approve of it.

Code quality

I'm all for standardized syntax & linting, I think it's critical in any decent-sized project.

But for the love of god, I cannot comprehend the pseudo-standardization of no-semicolons, which is a core syntax element of almost all c-based languages. Even in their spec they say to prepend IIFEs with a semicolon. And for that reason alone I am against Javascript Standard Style.

my two cents :)

mjlescano commented 8 years ago

Thanks @SebastienDaniel, added Sinon to the list :)

About ;'s: Oh no! this all over again.

There's no gain on discussing it, so, I'm totally in for reacting to this comment and count the votes:

SebastienDaniel commented 8 years ago

Oh, I don't want to start a debate, I think we've all read plenty on the pros/cons of that question that generates flame more than anything. Above all, when enforcing a coding style, consistency is key and that's always what I'll go for.

If the brunt of the dev team opt for no-semicolons, I'll adapt and so should others. I'll not take this to religious extremes, I promise :)

dogonbeach commented 8 years ago

Is there good documentation on the API? I'm not a nodejs developer, but I'd like to be able to hook into it from external apps. For example iOS and android apps that can do things like : sign up, forget password, make a topic, vote on a topic, etc when fired at the server. Good api documentation and a quick start guide would be amazing.

asbjornenge commented 8 years ago

Ref. @VictorW1's comment above. Maybe it's a good idea to have a cleaner separation between the APP and the API, both in documentation and code?

gvilarino commented 8 years ago

I agree with a cleaner separation on the docs; they're semi non-existing on the API (btw, you can check our public docs here).

I would argue, nonetheless, for the choice of keeping every module under lib: we like to keep our codebase organised as modules, where each module has its set of responsibilities -them being front end, back end or both- and is self-contained, exposing an API. This way not only code addition is simple (you want a new feature, code a new module) but also our modules become completely or partially reusable (just the front-end parts, all parts, just the styles, etc.). This also lays the ground for a (very desired) plugin architecture, or even breaking it all into microservices, in the future.

In my personal opinion, breaking the codebase into a /site and /api structures end up bringing more complexity than what's needed, especially when we want to be as succinct as possible.

That being said, hell yea for docs. I've been looking closely at stuff like Readme.io, readthedocs and apiary.io recently to think about how this should happen. Thoughts?

gvilarino commented 8 years ago

What about something like stylelint.io for linting our stylus files?

mjlescano commented 8 years ago

Already here :D houndci.com doesn't implement it; but we could add gulp css:lint to travis.

gvilarino commented 8 years ago

Maybe publish-please for releasing?

bhack commented 8 years ago

I think we need to evaluate how to easy setup a scalable microservice deployment. See the opensource initiative at https://dcos.io. But node.js api for mesos seems not to be maintained anymore https://www.npmjs.com/package/mesos.

bhack commented 8 years ago

Also we will need a little bit of Machine learning at some point to scale on large depolyments. I don't think that we could solve all the issues of a collaborative politic scaling system with crowdsourcing (i.e. we will need clustering, collaborative filtering etc..). Using a micro service infrastructure could let to complement Democracyos with other micro services like Spark, elasticsearch etc.

gvilarino commented 8 years ago

Agree on that last part @bhack , though I think we'll need to see how this plays out on a large-enough scale in order to make proper decisions for ML.

Regarding microservices deployment, I think the way to go is Docker Compose + Swarm as it is extremely popular, community backed and very easy to learn, whereas Mesos is super strong although the learning curve and maintenance effort seems tougher.

bhack commented 8 years ago

Yes but in dcos flavour it is very easy

gvilarino commented 8 years ago

@mjlescano what about snyk.io?

gvilarino commented 8 years ago

What about helmet for API security?

gvilarino commented 8 years ago

We can check sagui for some additional inspiration on this matter

franciclo commented 6 years ago

Closing this, since we already take some of the technologies described here for coming versions. This discussion has been very useful, thank you all, surely we will be opening new discussions soon.