If you don't have any experience with functional reactive programming, we strongly recommend to gain some basic overview first with ReactiveX intro or with The introduction to Reactive Programming you've been missing written by @andrestaltz.
If we think closely how typical HTTP API works we can quickly recognize that it deals with streams of asynchronous events also called as HTTP requests. Describing it very briefly - typically each request needs to be transformed into response that goes back to the client (which is our event initiator) using custom middlewares or designated endpoints. In reactive programming world, all those core concepts we can translate into very simple marble diagram:
In this world everything is a stream. The core concept of Marble.js is based on the event flow of marble diagrams which are used to visually express time based behavior of HTTP streams. Ok, but why the heck we need those
To view the example project structure, visit the example repository.
We strongly believe that open source is all about the people. Thats why we are looking for brave passionates of RxJS and Node.js who can help us with creating new middlewares for Marble.js. There are many things that you can help us with! We've got a list of middlewares that we would like to see in future releases, but we are open for new cool ideas!
So, how can I contribute to Marble.js middlewares?
- Read the CONTRIBUTING guideance first!
- We use monorepo architecture for entire framework-related packages - each middleware resides in main Marble.js repository
- For reference code structure just look at example middleware implementation.
- Each middleware package should follow the naming convention:
- If you have an idea and would like to contribute, just open an issue and describe the middelware idea that you would like to work on. We'll discuss the internals and proposed features there.
- Open a Pull Request and...
marble.js is MIT licensed