Sparks.Network / Frontend
This repo contains the front end application for The Sparks.Network.
The backend can be found at: sparks-backend.
The Sparks.Network is a new platform that engages volunteers with the people who need them.
We're not just a volunteer management app, and we're not just a craigslist for volunteers. We're solving volunteering in the same way that Uber, Airbnb, and other sharing economy apps: by connecting those that have, with those that need, and giving them the tools to work together.
Volunterism is a fundamental part of our company ethos, and open source is just another expression of that. As we continue to develop this application, we are constantly looking for ways to extract things into more reusable libraries that we can give back to the community. If you see anything like that in the code, open an issue and let us know!
Development is driven by in-house developers at the Sparks.Network. Public participation (up to and including pull requests) are welcome. We are investigating ways to reward outside contributions to the code with both cash and equity. Please email Steve DeBaun with suggestions!
Yes, we are hiring! The Sparks.Network is a startup with seed funding that is making the world a better place. We are currently hiring part- or full-time developers. Want to know more?
We are currently using:
Firebase is our BaaS data source, wrapped in our own simple driver.
Babel with stage-0 to transpile ES6
Webpack and several glorious loaders to handle packaging the application
Gulp for development, build, and deployment automation.
This project was started with the cyclejs-starter boilerplate.
From the command line:
git clone https://github.com/sdebaun/sparks-cyclejs && cd sparks-cyclejs && npm run start
We're using several services to manage deployment:
CircleCI is configured to test all commits to all branches in the repository. It also has two automagic deployments:
release branch is deployed to
master branch is deployed to
- surge.sh is serving up both of those servers.
All credentials are stored in the services that use them. Currently that consists of SURGE_NAME and SURGE_TOKEN, stored in CircleCI; they let the
gulp deploy task do its magic.
gulp serve: run a local webpack development server at
gulp build: use webpack to compile into dist/
gulp deploy --domain <domain>: use surge.sh to deploy to the specified host.
TODO: Describe use of firebase, auth$, queue$, router, DOM drivers