phoenix-ecto-append-only-log-example::memo:逐步示例教程,显示如何构建所有数据都不可变

  • a5_183930
    了解作者
  • 90.5KB
    文件大小
  • zip
    文件格式
  • 0
    收藏次数
  • VIP专享
    资源类型
  • 0
    下载次数
  • 2022-05-07 03:35
    上传日期
Phoenix Ecto仅附加日志示例 一个分步示例,可以帮助任何人学习如何构建Phoenix Apps,其中所有数据都存储在仅附加日志中。 为什么呢 如果需要,请阅读/学习此内容: 对关键任务代码充满信心; 确切知道发生了什么! 调试应用程序变得更加容易,因为您可以一直跟踪应用程序中的请求/更改! 应用程序内置的分析功能,因此您可以轻松导出用户行为指标,即同类群组分析 数据/记录(及其创建者)的所有更改历史记录,因此您的App用户可以轻松地“撤消”更改。 如果您曾经在程序中使用过“撤消”功能,那么您将体验到仅追加日志的强大功能。 当数据存储在仅追加(不可变)日志中时,如果对某些数
phoenix-ecto-append-only-log-example-master.zip
内容介绍
<div align="center"> # Phoenix Ecto Append-only Log _Example_ [![Build Status](https://img.shields.io/travis/dwyl/phoenix-ecto-append-only-log-example/master.svg?style=flat-square)](https://travis-ci.org/dwyl/phoenix-ecto-append-only-log-example) [![codecov.io](https://img.shields.io/codecov/c/github/dwyl/phoenix-ecto-append-only-log-example/master.svg?style=flat-square)](http://codecov.io/github/dwyl/phoenix-ecto-append-only-log-example?branch=master) <!-- [![HitCount](http://hits.dwyl.io/dwyl/phoenix-ecto-append-only-log-example.svg)](https://github.com/dwyl/phoenix-ecto-append-only-log-example) --> </div> <br /> A **_step-by-step_ example** to help _anyone_ learn how build Phoenix Apps where all data is stored in an **_append-only_ log**. <br /> ## _Why_? Read/learn this if you want: <br /> + **Confidence** in your mission-critical code; know _exactly_ what's going on! + **Debugging** your app to be **_much_ easier** as you can _trace_ a request/change all the way through your app! + **Analytics _built-in_** to your App so you can _effortlessly_ derive **user _behaviour_ metrics** i.e. **cohort analysis** + **_All_ history** of changes to data/records (_and who made them_) so _users_ of your App can "***undo***" changes with ease. <br /> If you have ever used the "***undo***" functionality in a program, you have _experienced_ the power of an Append-only Log. <div align="center"> <a href="http://www.poorlydrawnlines.com/comic/undo/" rel='nofollow' onclick='return false;'> <img src="https://user-images.githubusercontent.com/194400/46946840-f2030980-d070-11e8-853e-906f8734ce75.png" alt="poorly drawn lines comic: ctrl + z"> </a> </div> <br /> When data is stored in Append-only (_immutable_) Log, if a change is made to some data it always creates a _new_ state (_without altering history_). This makes it _easy_ to return/rewind to the _previous_ state. _Most_ functional programming languages (_e.g: Elixir, Elm, Lisp, Haskell, Clojure_) have an "_immutable data_" pattern; data is always "transformed" never _mutated_. This makes it _much faster_ to build reliable/predictable apps. Code is simpler and debugging is considerably easier when state is _always_ known and never over-written. The "immutable data" principal in the Elm Architecture is what enables the ["_Time Travelling Debugger_"](http://elm-lang.org/blog/time-travel-made-easy) which is an incredibly powerful way to understand and debug an app. By using an Append-only Log for _all_ data stored by our Elixir/Phoenix apps, we get a "time-travelling debugger" and _complete_ "analytics" _built-in_! It also means we are **_never_ confused** about how data/state was transformed: <div align="center"> <a href="https://twitter.com/jessitron/status/333228687208112128" rel='nofollow' onclick='return false;'> <img src="https://user-images.githubusercontent.com/194400/46946485-c4699080-d06f-11e8-9b1e-30982cfb5c25.png" alt="@Jessitron (Jessica Kerr) tweet: Mutability leaves us with how did I get to this state?"> </a> </div> <br /> > **Note**: If any these terms are unclear to you now, don't worry, we will be clarifying them below. <br /> The main thing to remember is that using an Append-only Log to store your app's data makes it _much_ easier to build the app because records are never modified, history is preserved and can easily be referred to Once you overcome the _initial_ learning curve, you will see that your apps become _easy_ to reason about and you will "_unlock_" many other possibilities for useful features and functionality that will _delight_ the people using your product/service! You will get your work done much faster and more reliably, users will be happier with the UX and Product Owners/Managers will be able to _see_ how data is transformed in the app; _easily_ visualise the usage data and "flow" on analytics charts/graphs in _realtime_. ## Who? This example/tutorial is for _all_ developers who have a basic understanding of Phoenix, general knowledge of database storage in web apps and want to "level up" their knowledge/skills. People who want to improve the _reliability_ of the product they are building. Those who want to understand more ("advanced") "distributed" application architecture including the ability to (optionally/incrementally) build on this by using IPFS and/or Blockchain in the future! ## What? Using an Append Only Log is an _alternative_ to using Ecto's regular ["CRUD"](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) which allows overwriting and deleting data without "rollback" or "recoverability". In a "regular" Phoenix app each update _over-writes_ the state of the record so it's impossible to retrieve it's history without having to go digging through a backup which is often a time-consuming process or simply _unavailable_. ### Append-only Logs are an _excellent_ approach to data storage _because_: + Data is _never over-written_ therefore it cannot be corrupted or "lost". + Field-level version control and accountability for all changes is _built-in_. + All changes to columns are _non-destructive additions_; columns are never deleted or altered so existing code/queries never "break". This is _essential_ for "**_Zero Downtime_ Continuous Deployment**". + A database migration can be applied ***before*** the app server is updated/refreshed and the existing/current version of the app can continue to run like nothing happened. + Data is stored as a "time series" therefore it can be used for analytics. 📊 📈 + "Realtime backups" are hugely simplified (_compared to standard SQL/RDBMS_); you simply stream the record updates to multiple storage locations/zones and can easily recover from any "outage". ### _Examples_ where an Append-only Log is _useful_: - **CMS/Blog** - being able to "roll back" content means you can invite your trusted readers / stakeholders to edit/improve your content without "fear" of it decaying. 🔏 - **E-Commerce** - both for cart tracking and transaction logging. 🛒 + Also, the same applies for the Product catalog (_which is a specific type of CMS_); having version history dramatically increases confidence in the site both from an internal/vendor perspective and from end-users. This is _especially_ useful for the reviews on e-commerce sites/apps where we want to be able to detect/see where people have updated their review following extended usage. e.g: did the product disintegrate after a short period of time? did the user give an initially unfavourable review and over time come to realise that the product is actually exceptionally durable, well-designed and great value-for-money because it has lasted twice a long as any previous product they purchased to perform the same "job to be done"? ⭐️ ⭐️ ⭐️ ⭐️ ⭐️ - **Chat** - a chat system should allow editing of previously sent messages for typos/inaccuracies, but that edit/revision history should be transparent not just a "message edited" banner (with no visibility of what changed). ✏️ - **Social Networking** - not allowing people to delete a message without leaving a clarifying comment to promote accountability for what people write. In many cases this can reduce hate speech. 😡 💬 😇 + ***Healthcare***: a patient's medical data gets captured/recorded once as a "snapshot" in time. The doctor or [ECG machine](https://en.wikipedia.org/wiki/Electrocardiography) does not go back and "update" the value of the patients heart rate or electrophysiologic pattern. A _new_ value is sampled at _each_ time interval. + **Analytics** is _all_ append-only time-series events _streamed_ from the device to server and saved in a time-series data store. + Events in Analytics systems are often _aggregated_ (_using "views"_) into charts/graphs. The "views" of the data are "temporary tables" which store the _aggregated_ or _computed_ data but do not touch the underlying log/stream. + **Banking/Finance** - _all_ transactions are append-only ledgers. If they were not accounting
评论
    相关推荐
    • BlockChain:该存储库包含关于区块链的项目
      区块链存储库包含有关Blockchain的项目。 区块链最初是区块链,是越来越多的记录列表,称为区块,这些记录使用密码术进行链接。 每个区块都包含前一个区块的加密哈希,时间戳和交易数据
    • 数字资产区块链:该项目旨在为数字资产加盖时间戳并将其存储区块链
      私人区块链应用 您以区块链开发人员的身份开始旅程,该项目可让您证明您已熟悉区块链平台的基本概念。 像这样的概念:-区块-区块链-钱包-区块链身份-存在证明 您是否需要描述区块链框架中一些最重要的组件,为什么不...
    • 区块链资料
      区块链资料22222222222222222222222222222
    • 核心:Compendia区块链的主要存储
      存储库包含构成Compendia Core的所有模块。 如果要开始开发自己的插件,请查看我们以获取有关所有可用插件以及插件的信息。 文献资料 API文档 安全漏洞奖励/漏洞赏金 学分 由 ( )创建 基于 。 执照 :...
    • 塔塔姆区块链连接器
      存储库用作查找集成到Tatum API中的所有区块链连接器的地方。 结构体 有一个blueprint文件夹,其中为您准备了一个示例连接器。 您应该扩展*Controller.ts和*Service.ts文件并实现所需的方法,并希望通过Tatum API...
    • MedicalCards:医疗卡存储区块链项目
      用于存储医疗卡数据的区块链项目 英文变体doc即将推出 给我发邮件,如果您有任何疑问
    • 区块链编程
      区块链相关编程学习资源,有部分代码,及软件使用方法介绍
    • Python区块链应用
      可以添加多个节点,每个节点都有自己的本地存储区块链,一个公钥和一个私钥。 区块链存储在本地的.txt文件中。 钱包保存,加载和交易签名验证 块的真实SHA256哈希和工作量证明。 可以将硬币转移到其他钱包/...
    • 区块链文献
      区块链的相关参考文献
    • emsi-blockchain:区块链存储
      霍尔伯顿学校项目的Emsi区块链存储