The future of bypass

[ream88]

Hey everybody,

Today @MSch and I had a nice talk about the future of bypass. And we have awesome news to share: I will join the bypass team and help shape its future from now on! Of course @MSch and the rest of the awesome @PSPDFKit team aren't going anywhere, but for now I'll be the primary contact person for all your bypass related things.

For the start we want to clean up the backlog by releasing a new major version (2.0?). I want to collect all issues and improvements which should definitely be in the next major version into the list below.

If you have any ideas and suggestions, feel free to comment here!

All the best, and a happy Monday! 😊

---

Code and maintenance improvements:

• Extend the test matrix to include more recent versions of Elixir: Extend test matrix #89
• Format code with mix format: Format code with mix format #90
• Format example code
• Add links to source code from docs: Add links to source code from docs #79

Breaking changes:

• Switch from :simple_one_for_one to DynamicSupervisor: Switch from :simple_one_for_one to DynamicSupervisor #87
• Require at least Elixir 1.6
• Replace gun with mint: Replace gun with mint #99

New features:

• Allow the redefinition of routes: Allow the redefinition of routes #80
• Make listen interface configurable: Make listen interface configurable #70
• Add SO_REUSEPORT: Add SO_REUSEPORT #77
• Add support for parametric routes: Parametric route #93

[mhsdef]

Yay! Props to you and @MSch both. Thanks for your efforts.

[lucacorti]

TLS support with automatic SSL certificates setup.

I need this to test my HTTP/2 implementation and would be willing to contribute.

[chrismcg]

Thanks for taking this on. I love bypass and it's great to see it getting updated.

[ream88]

@chrismcg just give me a few more days, I want to go through all issues in the backlog! 😊

[chrismcg]

@ream88 please don't take my comment as any kind of pressure to ship! I'm just happy to see a great lib get some love. I came here to see if there was a PR for the DynamicSupervisor deprecation warning so to see all the work that's been done in addition to that is great.

[agramichael]

@ream88 any possibility of making it so that within one test I can stack two expect_once's so that the first call to the given route gets my first expect_once and the second call gets the second expect_once?
Currently the second expect_once would just redefine the first expect_once and I would get an error because the route is called twice.

[ream88]

@agramichael Is #80 fixing this for you? Can you try out the master branch? 😊

[agramichael]

@ream88 that fix has been very helpful! But it's not quite what I was thinking. That allows users to redefine what the response is for the route but still doesn't allow setting multiple responses for the same route, and consuming them in order.

[mrdougwright]

@ream88 that fix has been very helpful! But it's not quite what I was thinking. That allows users to redefine what the response is for the route but still doesn't allow setting multiple responses for the same route, and consuming them in order.

I believe I'm having the exact same issue. We've added a Plug to our main controller that calls (and caches!) out to our graphql API. This now adds an extra call to all of our controller tests, which breaks their call expectations.

Since the route is the same, if we could set and check multiple responses for the same route, we could update our Bypass wrapper in one place.

[ream88]

@agramichael @mrdougwright I moved the conversation to a new issue: #95