> Google’s thesis is that the mobile-web is dying and people prefer to use apps – therefore making the web faster and more app-like will retain users.
I am not sure, if this is your opinion about Google's view on AMP or is exactly the Google view on AMP, but, Whatever it be, I almost died laughing - what's wrong with these people(Google)?
Either Google is assuming,
- people would only need 1-2 digit numbers of app in their device and rest all of the websites/platform are just hawkers on the street.
OR,
- world is going to be exploded with extreme scalable storage system on mobile/user's devices where people would be able to store hundreds of apps.
The only reason PEOPLE PREFER TO USE APPS in most of the case is the ability of OFFLINE USE CASE for FREQUENTLY used apps, and we know FREQUENT uses are for limited numbers of apps.
Such thesis that people "prefer to use apps" requires citation and contradicts Google's own "search engine" which helps people to explore the world for data. Is that a reason? google prefers to steal the data from various website and show the results in their search engine result page?
If there is any specific video, you can share it here or privately via email mentioned above, we will immediately look into it and start working on it.
For Price, we don't want to charge higher or lower, we just want to first help entrepreneurs with their business - prices do vary and entrepreneurs do understand - we take care of their budget as well - it's a thing we understand as an entrepreneur-friendly developer.
Yes, Nebula Graph supports multiple backend storages by design. So theoretically you are able to use whatever storage you want for whichever graph space in Nebula Graph.
Thanks for asking! Sorry I missed this question earlier.
Nebula doesn't store data multiple times for index.
And here's how the indexing works in Nebula Graph:
You are allowed to create multiple indexes for one tag or edge type in Nebula Graph. For example, if a vertex has 5 properties attached to it, then you can create one index for each if it's necessary for you. Both indexes and the raw data are stored in the same partition with their own data structure for quick query statement scanning. Whenever there are "where" clause/syntax in the queries, the index optimizer decides which index file should be traversed.
Exactly! socket.io was there mostly to speed up prototyping. I plan to replace it with vanilla code soon, to make the frontend app even more lightweight.
