|
|
|
|
|
|
by njharman
2577 days ago
|
|
|
Vastly simpler, I understand what Bloom is doing after 10min of reading. I had hard time even understanding all of Varnish's scope in same time. Written in RUST. Uses Redis. Uses custom headers instead of Cache-Control Seems more flexible cache invalidation, but maybe varnish can do this after understanding all of VCL/Varnish. Seems written for an API developer not wanting to write own/reinvent cache layer for their REST API. vs written for a sysadmin who is building a system that is larger/more generic, less tied to one specific app, and who would reach for Varnish being old, reliable and having every feature ever thought of. |
|
|
For Laravel projects at least, a package like spatie/laravel-responsecache makes it super easy to handle caching for GET API routes. I'm sure there are similar packers for other frameworks often used in API development.
I really like Bloom, I'd just rather handle it at the application layer, where I can get the finest level of customization (assuming there's a suitable package to abstract the most tedious work away).
Seems you could keep the associated code to a minimum, and easily maintainable, by using model events to trigger cache updates.
Personally, I'd rather have a little more code than a new dependency (and the resources the Bloom takes from each API worker it's installed on). But in situations where it's non-trivial or inadvisable to do it at the application layer, it seems Bloom could be quite useful.