🆘 Open sourcing getd.io
Tags: discuss, webdev, opensource, help
Published: 2019-09-06 17:31:19

I'm planning to open source [getd.io 🚀](https://getd.io), a free and online REST API builder that I built weeks back. You can read more about it [in this post](https://dev.to/getd/getd-io-an-online-api-request-tester-builder-with-cors-support-3d3m).

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/p5oca7k10m5x9qkj4n10.png)

While being *super excited* 😍 , as someone who has never open sourced anything in my life, I also want to make sure the project is in a good shape before it goes open source. 

The front-end is trivial so I think open-sourcing it would be as simple as opening up code access in github. The back-end, however, is a bit tricky that I could really use some help from the awesome dev.to community ❤️ on open-source best practices.

For viewers who didn't know [getd.io](https://getd.io), the unique feature of this project, comparing to other Postman alternatives, is that it uses a back-end server as a proxy to send and receive API requests, thus bypassing CORS (Cross-Origin Resource Sharing) restrictions on the browsers. I also plan to add more features such as:

- Create and save personal/team workspaces.
- An API explorer to share and play other people/company's public APIs, e.g., Spotify APIs, or Twitter APIs.
- and more...

As you can quickly tell, the backend has a bit of complexity around user auth, database, and other things. So my list of questions follows:

# API Keys

*Update: I did some research and answered this part of the questions in [this post](https://dev.to/getd/how-to-manage-secrets-and-configs-using-dotenv-in-node-js-and-docker-2214)*

I have (and will have) several API keys for this project. E.g., there is a Github API key for user sign-ins. There will be API keys for services such as Spotify for users to try out Spotify APIs. Currently these keys are stored in a version-controlled json and read via the `config` npm package at runtime. Questions:

1. What's the best practice to move these keys out of my repo, but still feed them at runtime? E.g., use ENV + docker-compose? Should I put the keys in a private repo?
2. Is there a way to share some development API keys (probably a bad idea) so contributors won't have to go through the hassle of applying and managing their own keys?

# Database

The project uses mongoDB. For local dev, it uses a free-tier mongoDB from Atlas. For prod, it uses a docker mongo running on my server. Questions:

1. Is it common to ask contributors to set up their own mongoDB for developing on the repo?
2. I figure sharing a dev mongoDB instance would be a terrible idea, because people will see other people's tokens. But is there a way for sharing a dev mongoDB so contributors won't have to set up their own?

# License

I heard MIT are gud. Any other suggestions?

# Lastly,

Just in general:

1. What are some pro-tips for first-time open-source creator (me)?
2. Is it a good idea to open source a project that still has many pending features that need design, or should I hold until the project is more mature?
2. How to make contributor's life easier so they can focus on coding, not spending hours setting up environments?
3. How to collaborate with contributors on features, especially complex ones? E.g., the feature of 'creating personal workspaces' would involve many complex database schemas, API schemas, UIs, etc. How does that work?

**Thank you in advance! I can't wait to open source [getd.io](https://getd.io) and see awesome things happen! 🎉🎉🎉**