3 ms·

Considering most CMS systems barely reach 100req/s (uncached), I think we can say raw database speed is less of a problem than bad query patterns. Or if you pre

Considering most CMS systems barely reach 100req/s (uncached), I think we can say raw database speed is less of a problem than bad query patterns. Or if you prefer, the use of a SQL db is no guarantee for performance. Maybe mongodb will perform better, free of joins, than MySQL/Wordpress/whateverCMS... or maybe the data access pattern will suck and make it slow (and maybe it would be slow with a SQL db too, like other CMSs). Ideally (in terms of performance), a single K/V request would be needed for each page, and the CMS would handle all the denormalization (and tens of thousands of req/s). I don't know how they've designed their data model... All in all, a CMS is the most cachable web app ever, as it's more or less meant to replace static pages ;-) The poor performance of existing CMSs has always been hidden by caching layers...

therealmarv 10y ago
100% agree. But there is not a single word about caching or how to integrate it with Relax either. I understand it is a young project but if I need a CMS I want it to have it a little tested and scaling questions not open. Caching is totally NOT trivial with React,Redux,GraphQL (at least I totally don't know how to do it but maybe I'm not smart enough) ... maybe it is even harder with such an architecture. I'm just saying I doubt a littlebit the cool and shiny architecture justifies the purpose (many questions open).
- bruno12mota 10y ago
  Hey! Relax creator here. Thanks for your input :) Saying PostgreSQL is a better fit in terms of performance is a bit controversial in my opinion, there are quite a lot of tests between the two and most say it is the exact opposite https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-server-2008-performance-showdown/ https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-s... Despite that, can't say for a fact that's the case for Relax since I haven't test both on it. Mongo is behaving really well though, our demo instance has been getting a pound lately (dozens of users at a time) and it's running smoothly even though our machine is not really powerful. Also in terms of scaling, Mongo also has a great solution for horizontal scaling https://docs.mongodb.org/manual/sharding/ https://docs.mongodb.org/manual/sharding/ Having this said, not entirely against having different database layers supported in Relax. Since we're using GraphQL would be a matter of creating an abstraction when accessing the data on the queries and mutations resolves. Not on our priorities for now but we're always open for contributions :)

therealmarv 10y ago

100% agree. But there is not a single word about caching or how to integrate it with Relax either. I understand it is a young project but if I need a CMS I want it to have it a little tested and scaling questions not open. Caching is totally NOT trivial with React,Redux,GraphQL (at least I totally don't know how to do it but maybe I'm not smart enough) ... maybe it is even harder with such an architecture. I'm just saying I doubt a littlebit the cool and shiny architecture justifies the purpose (many questions open).

bruno12mota 10y ago
Hey! Relax creator here. Thanks for your input :) Saying PostgreSQL is a better fit in terms of performance is a bit controversial in my opinion, there are quite a lot of tests between the two and most say it is the exact opposite https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-server-2008-performance-showdown/ https://blog.michaelckennedy.net/2010/04/29/mongodb-vs-sql-s... Despite that, can't say for a fact that's the case for Relax since I haven't test both on it. Mongo is behaving really well though, our demo instance has been getting a pound lately (dozens of users at a time) and it's running smoothly even though our machine is not really powerful. Also in terms of scaling, Mongo also has a great solution for horizontal scaling https://docs.mongodb.org/manual/sharding/ https://docs.mongodb.org/manual/sharding/ Having this said, not entirely against having different database layers supported in Relax. Since we're using GraphQL would be a matter of creating an abstraction when accessing the data on the queries and mutations resolves. Not on our priorities for now but we're always open for contributions :)