DEV Community

TechBos😎 for getd.io/ - Postman without native apps

Posted on • Updated on

🆘 Open sourcing getd.io

I'm planning to open source getd.io 🚀, a free and online REST API builder that I built weeks back. You can read more about it in this post.

Alt Text

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, 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

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?
  3. How to make contributor's life easier so they can focus on coding, not spending hours setting up environments?
  4. 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 and see awesome things happen! 🎉🎉🎉

Oldest comments (4)

Collapse
 
krusenas profile image
Karolis

Hi, I was in a similar situation with webhookrelay.com (for a long time client was open source and was considering open sourcing server side). I would suggest just considering whether you will be getting contributions. If not - then it doesn't make much sense open sourcing it :)
Most of the time people won't contribute and it might just make a little bit harder for you to do breaking changes (for example database schema and other things).

Collapse
 
techbos profile image
TechBos😎 • Edited

Thank you for sharing your experience! I just checked out webhookrelay.com. Very interesting!

The reasons I'm considering open-source getd.io are:

  1. I feel all the 'easy' features are complete and now the project is at a critical turning point that it either dies silently, or grows quickly with many yet-to-come new features.
  2. There is no good way to collect feedbacks and I was hoping to open source it, get some more attention, and at the same time gather feedbacks from the community about where it should go next.
  3. Me doesn't scale. I was hoping to publish a roadmap, get people excited, and build this project faster with help from community.

just considering whether you will be getting contributions.

It's a chicken-egg problem :) I don't know if I will be getting contributions. It seems to me the only way to know is to open source it first.
Another signal is that since this post didn't get as many responses as I'd hoped, maybe open sourcing this project is not a good idea :D

Most of the time people won't contribute

True. I also looked at other popular repos, even with thousands of stars. It seems most time contributors would only work on small-scope, simple tasks. E.g., UI tweaks, or quick improvements for usability. It's rare to see people spend time properly contributing an end-to-end feature, which to be fair is difficult to do even for the creator.

Collapse
 
anshsaini profile image
Ansh Saini

What stack did you use to build this?
I love the idea and would love to contribute!

Collapse
 
techbos profile image
TechBos😎 • Edited
  • Front: react.js + react-router + semantic-ui-react + apollo client + typescript
  • Back: express + passport + node.js + mongoose + apollo server + graphql

Thank you for the support! I will for sure let you know when this goes open.