RFC for Pizzly 2.0: We want your input

[rguldener]

Hey Pizzly community,

we are Bastien and Robin, the new stewards of Pizzly 🐻

Pizzly became popular because it is one of the fastest and simplest ways to get started with APIs that use OAuth. Currently Pizzly has some issues with the latest version of node and the code has been largely unmaintained for 1+ year.

We want to fix and improve Pizzly, but for this we need your help:

• Do you have experience with the Pizzly code base & features? We would love to talk to you!
• Are you a current or former user of Pizzly? We would like to understand:
  • How do you use Pizzly? (which APIs, how does it fit into your app etc.)
  • How do you host Pizzly? How happy are you with this setup?
  • What do you like most about it?
  • What annoys you/gets in the way?
• Anything else you wanted to share with us for the future of Pizzly?

Your inputs will be super valuable to shape the future of this project.

If you want to get involved with contributing and designing the next version please join our Slack community: We would be happy to have you as part of the core team.

We look forward to hearing from you in the comments and building a better Pizzly together!

[rcknr]

Hi Robin,

It's great that you have convinced guys at Bearer to revive the repository! I have also reached out to offer my help in maintaining Pizzly but they said they had decided to archive it.
There were a couple of issues/PRs before the project got archived. I think it makes sense to look over these for some feedback first. Here are my personal observations about Pizzly:

• It'd be great to have multiple APIs supported within one provider and organize them in one filterable list
• Also would be great to add and maintain guidance for creating app credentials for each provider
• Could use alternative storage backend to decrease running cost
  I'm glad that the project is getting a new start and hope it stays active. I'd be glad to help where I can.

Cheers,

Sergii

[bastienbeurier]

Thank you for chiming in and offering to contribute!

I will go through previous issues & PRs as you advised. Also, feel free to create issues (or even PRs) if you want some of your suggestions to be implemented soon.

We are currently focusing on refreshing/fixing the repo for local development, but it would be great to have your input as we move towards improving it.

We've created a Slack room dedicated to Pizzly in our Slack community in case you want to follow Pizzly news more closely and discuss ongoing work. We will ask the community's opinion and share plans on a regular basis there.

[bastienbeurier]

Hi all,

As we start working on Pizzly, we wanted to consult you about a couple topics that will determine how we go about maintaining Pizzly:

Direct token access vs. request proxy?

Today, Pizzly executes API requests for you via a proxy. Do you like this? Would you rather have direct access to access tokens (via API/SDK) to do your own requests? We would still abstract away the token refresh, always sending you a fresh token that’s ready to be used. Eventually we could offer both options, but which one would you prioritize?

Migration vs. rewrite?

Pizzly is a larger code base than it could be, with legacy code and an unfinished migration from Bearer’s old internal use case. We could take the approach of a full rewrite to make Pizzly smaller and simpler, accelerating future development. Do you have anything against this? Do you anticipate any hurdles in the migration process?

In-code vs. UI-based configuration?

Today, Pizzly offers a dashboard to enable and configure APIs. Would you rather have this in-code or do you want to keep the UI? Again, we could maintain both in the future, but looking to understanding your priorities.

Cloud option

Would you be interested in having a Cloud option for Pizzly, not having to self-host it yourself? To be clear: Pizzly will stay open source with easy free deployment options. But we want to get a sense of whether a Cloud option could make Pizzly accessible to more folks.

Thanks in advance for your much needed input 🙂

[mikestaub]

1. prioritize proxy as that is how 80% of dev will likely use this tool
2. do NOT rewrite. At least not until the API surfaces are solid and the tool has more traction. This techt debt should not be paid at this time.
3. in-code. This is a dev tool, no need to maintain a UI, someone else can do that
4. Just create a docker image. This should not be prioritized at this stage

[bastienbeurier]

Thank you for your input @mikestaub!

1. Understood, we've heard this from other Pizzly as well!
2. After taking a 1st pass at the codebase and finding it hard to maintain, we actually already took a pass at the rewrite last week. We will release it today and plan to have feature parity next Monday.
3. Great, this alines with the rest of the feedback as well.
4. Agreed, we've done this as part of the rewrite actually.

[Simcon]

100% what @mikestaub says.

It should be completely configurable in code so configs can be versioned.

[MattRiddell]

1. Agreed with @mikestaub
2. I could go both ways on this. If you're being significantly slowed down by working on a codebase that doesn't match your internal tooling, it may be worth it. Hah just saw your comment. Cool.
3. Hmm, I'm not 100% sure about going code only. When I first started using it, there was something magic about click click click, you're done. We host it in Nomad, and it just works. Possibly again agree with @mikestaub that someone else can maintain that. In the Asterisk community, we had APIs that made it possible for many other pieces to be built.

I do wonder though, with such a small surface area, whether it would even make sense to expose the api via api 😂

Couldn't we just throw something together in tailwind in an afternoon and call it good?
4. We host a docker image in nomad. However, it really depends on who the target audience is, right? Like most people who use it are probably trying to avoid learning or using oAuth and are looking for a prepackaged solution.

If it helps the project to remain liquid, I'm all for it.

Regarding @Simcon comment, I think you could basically do it like vscode no? Provide a skeleton of the most commonly used features via a UI and let people configure the underlying code if they see fit

[bastienbeurier]

Thanks a lot for voicing your opinions about Pizzly’s future (here and on the #pizzly Slack channel). There seems to be a pretty nice consensus around important features.

Last week, we started a full rewrite of Pizzly on a branch (v0.3) to make the code more maintainable and accelerate future development. It already works, and supports:

• OAuth 1 & 2
• a Docker container for the Pizzly server
• a CLI to configure integrations
• a Node SDK + REST API to fetch fresh tokens
• a frontend SDK to initiate OAuth flows

During the past week, you expressed interest in the following additional features:

• Proxy server for API requests
• A free 1-click deployment solution (Heroku is no longer free)
• In-code (versioned) configuration (additionally to the CLI)

The new Pizzly is also currently missing:

• An API key to secure Pizzly
• More logs and friendly error outputs
• Better comments in the code
• Tests
• More integrations (currently has 25 but we will quickly backfill + add new ones)

We would love to have you involved in building these features, or others that you have in mind. If you are interested, please let us know what you would like to take on. And if you have additional/different thoughts, please share them here or on the #pizzly Slack channel.

We want to quickly get to feature parity with the old Pizzly so that we can start making nice improvements!

[bastienbeurier]

We have created individual issues for the Roadmap items mentioned above (#268 to #273).

Additionally, you can follow our public roadmap: https://github.com/orgs/NangoHQ/projects/1/views/2

Lastly, please join the #pizzly Slack channel or create/comment on issues if you want to have a part in Pizzly's roadmap.

Contributors are more than welcome. We actually tagged most of the issues with 'Help Wanted' in case you want to get started.