saurabhnanda

I keep hitting the following problem over & over again:

- Build a mobile app (mostly some sort of CRM/ERP kind of app), where ALL the features need to work offline - This means that all the data (for the currently logged-in user) needs to reside on the mobile device. - This also means that any CRUD operation needs to hit the local data-store first, and should be synced in the background with a remote data-store. - This also means that if the user signs into another mobile device, a relevant subset of the remote datastore should be "restored" on the mobile device. - Probably a few other subtleties that I haven't thought through yet.

Is there any stable/production-grade DB that solves this problem? Bonus points if it's an RDBMS, because building reports for a CRM/ERP is 10x easier on top of an RDBMS vs a document/JSON DB.

Honest question. When someone says a blockchain can be used for anything OTHER than financial transactions, for example - supply chain, health records, etc - what is the actual underlying data that is being stored on the blockchain?

When it comes to a quasi-banking or quasi-wallet system, I find it easy to visualize that the blockchain holds accounts with balances, and there are transactions which move money between accounts. Blockchain's decentralization and write-only properties help because no single entity can make your money disappear, and no entity can rollback a transaction.

What is going on with other use-cases of blockchain? What does a supply-chain system actually store on the blockchain? The SKU list? The price of each SKU? The stock level of each SKU in each warehouse? What?

Further, how do the unique properties of a blockchain make it better than a centralised (or federated DB) for a SPECIFIC non-financial use-case (would appreciate actual details here)?

A number of website builder (or web hosting) companies advertise unlimited bandwidth, possibly along with unlimited storage. Most of them have fine print in their T&C which cap these "unlimited" bandwidth/storage offers using some other technique. For example:

- BlueHost: https://www.bluehost.com/unlimited-hosting & https://my.bluehost.com/hosting/help/2274

- DreamHost: https://www.dreamhost.com/legal/acceptable-use-policy/

- Squarespace - https://www.squarespace.com/acceptable-use-policy/

- Vercel - https://vercel.com/docs/v2/platform/fair-use-policy

I can understand unlimited storage (with prohibition for things like file sharing, image hosting, etc), because storage nowadays is very cheap. However, that is not the case with bandwidth, especially when you're using 3rd party CDNs.

Wix seems to be using a mixture of Fastly and Cloudfront, but doesn't seem to put any rider/fine-print on bandwidth usage. Consider their support page on storage and bandwidth: https://support.wix.com/en/article/about-storage-and-bandwidth

How are they able to deliver on this promise? Isn't this a liability sitting on their balance sheet? Or, if you cross some unspecified bandwidth threshold, do they terminate your account using some other generic clause in their legal T&C? Has anyone faced this first-hand?

I know this is a highly subjective, and possibly loaded, question. But here are the related questions at the back of my mind when I ask this:

- Do I really need to use React (a client-side framework) to generate static websites? What's wrong with Ruby + Liquid (that I'm familiar with), or anything similar (Python, PHP, etc)?

- Assuming that the static website doesn't include a lot of JS in the first place, exactly how much faster is the Lighthouse/PageSpeed score for static websites built with Gatsby/Next JS? Are there any benchmarks available? Do these frameworks optimize the CSS delivery as well (remove unused CSS, inline the CSS, etc)?

- What are the chances that the JS community will jump to the "next new thing" in 2 years and I'll be stuck with a pile of unmaintained mess?

- Are there frameworks for Ruby/Rails that do a similar job? Does Jekyll (or Hugo) come close?

- Are Gatsby / Next JS really for static website, or for mostly static websites with a sprinkling of dynamic elements (eg. e-commerce, travel booking, etc), that people unnecessarily wrote in React, and ended-up creating a problem where none existed?

- What is truly the sweet spot for this kind of technology? Google search results are full of blog posts where people are just discovering these frameworks (or by companies who are pushing them).

At my company we have about 80,000+ LoC of AngularJS (v1) in production, which we still actively develop and maintain. We've also dabbled with Angular2/Typescript & Elm for the newer features. However, off-late, I am getting increasingly put-off with the amount of complexity SPAs bring into the stack. Especially for user-interfaces that aren't very interactive (or don't need to maintain a lot of state in the browser).

I remember Rails apps from 5-7 years ago where the entire HTML was rendered by the server. Where required, there was pjax/turbolinks and some hand-written jQuery for client-side validations or show/hide buttons. What is the current state-of-the-art for these kinds of apps?

Think about the billing page of a typical SaaS app [1]. Does it really require to be an SPA communicating with the backend only via APIs? Can't it be made of simple HTML pages that do FORM POSTs? What's the best way to handle the following in 2019 (or 2020!), without resorting to full-fledged SPAs:

  - Showing/hiding UI elements
  - Possible values of one dropdown depending on the value selected in some other dropdown
  - Copying billing address to shipping address
  - Value of a radio button showing/hiding some form fields
  - (I hope you get the point...)

PS: Having some type-safety would be an added bonus, because I've been recently bitten by the Haskell bug :)

[1] Display list of available plans, let the user pick & configure the plan, make a payment, and move on. Typically it will be used once or twice in a user's lifetime.