Usually we organize our javascript apps either by what they are or by what they do. The first is like rails: separate directories like components, containers, reducers, etc. And the second more or less like feature/DDD: user, cart, and so on. Tho both of these options are very mainstream and solid they contain some constraints.
When you structure the code files tree by what they are you tend to keep every component of the same feature so distant that it’s very difficult to connect the pieces. Therefore you dive into some troubles like the path hell; a lot of require('../../../etc') in your code. And everything is extremely coupled to the directory structure.
In the other hand, when you are driven by what they do everything is more isolated and maintainable. But there’s a lot of duplication. And the communication between the features either is based on a weak contract or depends upon some infrastructure. Both of these options are prone to raise some bugs.
Pods it’s an evolution of the last one. You can think about pods like the microservices of the front applications. A pod is an isolated and completely independent microapp which can communicate 100% with other pods. Therefore, you get code base which is composable, extendable, reusableand extremely easy to test. Tho, the main benefit is that you completely erase the inter components side effects. Once a pod is failing you are totally sure that it’s because itself has something wrong; not an external piece.
A pod is an isolated and completely independent microapp which can communicate 100% with other pods
The unique requirement of the pods is to driven all the pods intercommunication through an event bus. If you’re already using any Flux pattern, lib or framework it’s gonna be very easy to lead this communication to the dispatcher; which is actually a single point for the events.
For a pod is not mandatory to have the logic, presentational and communication layers. Can have all of just one of them. Imagine a router pod. It has the logic and communication layer but doesn’t expose any view. Or the opposite, a form pod which only exposes a presentational layer and depends 100% on the arguments received (see React props).
Because every pod acts like and independent application we place the tests inside them. This means two things: stop duplicating the files tree, and making code coverage meaningful. When you have 100% coverage with a pod you know that it won’t fail. No side effects.
In a nutshell, by working with pods you get a secure and very flexible structure. Very easy to test and without side effects. It scales from 0 to millions without worrying about big refactors due to the fact that every pod is isolated but available to communicate with all the other pods.
In case you want to see some code here’s a Github repository with a simple pod architecture. Give it a look and check the benefits the pods can offer. If you have some doubts or proposals don’t hesitate to open an issue or comment here. This is a living pattern. We’re using the pods at Ulabox and they’re proving to be the solution to a lot of structural codebase problems. Tho, we’re willing to listen about your thoughts and concerns.
The journey is long, take some pods.