I have been organizing the Papers We Love Beijing Chapter with a group of engineers. It is a good place to share wonderful ideas that are not necessary useful.
I have always been trying to make an Elixir version of a screeps-like game. Every unit is just an actor, sending messages to other units, based on the GenServer behavior. You can upload a new version of the unit controller with Beam hot code reload.
I think PWA pattern is bad for most website, they are not designed to run offline, just pretend to be available while actually not. ServiceWorker mess up app lifecycle and cache control. I just wish Chrome allow me to just disable all ServiceWorkers.
This PRPL is even worse, just makes the stateless HTML page stateful, keeping more active connections, and is a lot more complicated.
If you want a fast to load page, please keep it simple.
You are either using the service worker api wrong or don’t understand how slow and spotty Internet connections can be for a majority of users around the world. PWAs are a massive improvement of experience on the web—it lets you think of the end-user more than the developer experience.
It looks like one of those technologies that are useful in theory, but difficult enough to implement correctly that 90% of implementations will be worse than not using it (endless scroll being a notorious offender).
Looking at the TileDB docs, I like the idea that you can store and manipulate array efficiently. It works like a columnar storage, but organized in tiles. I am not clear how it could scale to multiple nodes and how to do queries. Maybe it should be integrated into postgres.
TileDB fully supports multi-writer/multi-reader, so scaling compute to multiple nodes is mostly about choosing the computation layer. We have integrations with Spark, Dask and PrestoDB for distributed compute. In our cloud product we also offer serverless UDFs and SQL (via MariaDB) to allow for scaling out computations elastically without managing your own clusters.
On the postgres side, we are looking at eventually adding a postgres storage engine, now that the new storage support is in PostgresSQL 11. To start with we have built a storage engine for MariaDB, as MariaDB has an excellent storage engine API, which I have past experience with. We hope to upstream the storage engine to MariaDB after the MariaDB 10.5 release.
