Alibaba news

Chinese multinational conglomerate specializing in e-commerce, retail, Internet, AI and technology

World latest news

Alibaba And Chinese Software Giant Aerospace Information Team Up For Blockchain Development

Alibaba And Chinese Software Giant Team Up To Promote Blockchain Development Alibaba, the Chinese e-commerce giant, has recently started a partnership with Aerospace Information Co., an important developer from China. Both companies start a joint effort to cooperate on creating blockchain technology and cloud computing, among other highly important technologies. According to the report made […]
Bitcoin Exchange Guide

China’s Alibaba Partners With Chinese Software Giant to Promote Blockchain Development

China’s Alibaba Partners With Chinese Software Giant to Promote Blockchain Development Chinese e-commerce conglomerate Alibaba and Aerospace Information Co., a major software developer and provider, have signed a strategic cooperation agreement for cloud computing, blockchain and other technological services development. Chinese finance publication Securities Daily reported on the deal on March 21. The two parties […] Cet article China’s Alibaba Partners With Chinese Software Giant to Promote Blockchain Development est apparu en premier sur Bitcoin Central.
Bitcoin Central

Fescar: A Distributed Transaction Solution Open Sourced by Alibaba

To support microservice-based development, Alibaba has now launched Fescar, an open source version of its Global Transaction Service solution to the problem of distributed transactions.This article is part of the Alibaba Open Source series.In online systems, microservices have gained recent support from developers as a means of reducing difficulties, enhancing scalability, and facilitating agile development by splitting complex applications into loosely coupled services. However, implementing a seemingly simple function in a micro-serviced system may require calling multiple services and operating multiple databases, introducing a formidable distributed transaction problem for service calls.Currently, distributed transactions are the greatest obstacle to realizing microservices, and also the most challenging of relevant technical issues. To overcome these difficulties, Alibaba initially developed the Global Transaction Service (GTS) solution for its systems. Now, it has expanded this solution by launching an open source version called Fescar, short for “Fast and Easy Commit and Rollback”.To mark its recent release on GitHub, this article looks in detail at Fescar’s fundamentals and its support for microservice-based development.Origins of the Distributed Transaction ProblemTo understand how microservices cause the distributed transaction problem, it makes sense to consider the example of a traditional monolithic app that completes a business process by updating data on a single data source through three modules. Naturally, local transactions guarantee data consistency throughout the business process.As business demands and architecture change, individual applications are divided into microservices. The original three modules are split into three separate services, each of which uses a different data source (Pattern: Database per service). The business process will now be completed by calls to the three services.In this case, local transactions are still able to guarantee data consistency within each service. However, to ensure consistency of global data across the entire business level, a distributed transaction solution becomes necessary.Developing FescarAlibaba is among the earliest enterprises in China to implement a transition to distributed microservices, resulting in a long history of encounters with the problem of distributed transactions under the microservice architecture.In 2014, Alibaba’s middleware team released Taobao Transaction Constructor (TXC) to provide distributed transaction services for intra-group applications.In 2016, TXC was implemented on Alibaba Cloud as a Global Transaction Service (GTS) following productization, becoming the only distributed transactional product on the cloud at the time. As such, it began to serve many external customers through Alibaba’s public cloud and Apsara solutions.Entering 2019, based on the technology accumulation from TXC and GTS, Alibaba’s middleware team launched the open source Fescar project to further build its distributed transaction solution in collaboration with the development community.TXC, GTS, and Fescar all arise from the same origins, and have together produced a distinctive solution to the problem of distributed transactions under the microservice architecture.Original design goalsIn the fast-growing internet era, the ability to quickly undergo trial and error is critical for businesses. On the one hand, the introduction of microservices and distributed transaction support to technical infrastructure should not generate any additional research and development burden on the business level. On the other hand, businesses that introduce distributed transaction support should maintain essentially the same level of performance, and should not be significantly hindered by transaction mechanisms.Based on these criteria, the outset of Fescar’s design involved two crucial considerations. First, it should not cause any intrusion into the business. “Intrusion” here means that the application is designed and modified at the business level because of technical problems caused by distributed transactions. Such design and modification often results in high R&D and maintenance costs for the application. Alibaba needed to solve the distributed transaction problem at the middleware level without requiring extra work to be done on the application at the business level.Second, the design needed to ensure high performance. The introduction of distributed transaction guarantees inevitably brings about additional overhead, causing performance degradation. Alibaba needed to reduce the performance loss caused by the introduction of distributed transactions to the lowest possible level, so that the availability of applications would not be affected by the introduction of distributed transactions.Shortcomings of previous solutionsPrevious distributed transaction solutions can be categorized as those which are intrusive to businesses and those which are non-intrusive to businesses.Among mainstream solutions, only XA-based solutions are non-intrusive to businesses. Nevertheless, XA-based solutions present three problems. Firstly, they require the database to provide support for XA; in the case of databases that do not support XA or that provide poor support, such as MySQL versions prior to 5.7, there is no way to use these solutions. Secondly, they are constrained by the protocol itself, and with them the transaction resource has a long lock-in cycle. Long-term resource locking is often unnecessary from a business perspective, but because the transaction resource manager is the database itself, the application layer cannot intervene. This results in poor performance and difficulty for optimization. Lastly, implemented XA-based distributed solutions rely on heavy-duty application servers like Tuxedo, WebLogic, or WebSphere, making them inapplicable to microservice architectures.XA was in fact the only solution for distributed transactions during early development. It is complete, but in practice it often needs to be given up for a variety of reasons including but not limited to the problems discussed above. For example, eventual consistency solutions based on reliable messages, TCC, and Saga all belong to this category. These solutions’ mechanisms are not explained in this article, due to the availability of information on the internet. In short, they require that distributed transactional technology constraints be considered at the business level of applications’ designs. Usually, each service needs to be designed to implement forward and revers idempotent interfaces; such design constraints often result in high R&D and maintenance costs.Qualities of an ideal solutionIntrusive distributed transaction solutions have been verified widely in practice and can effectively solve problems to play an important role in business application systems across various industries. Still, adopting such solutions should be seen as a distant second choice. Imagining that XA-based solutions could be lighter weight and ensure the performance requirements of businesses, it is unlikely people would willingly take the distributed transaction problem to the business level.Thus, an ideal solution should be as simple as using a local transaction, with business logic only focusing on the needs of the business level and not regarding constraints on the transaction mechanism.Solution Principles and DesignTreating a non-intrusive XA solution as the basis for a solution that is non-intrusive at the business level, the key question that needs to be solved is how XA can be adapted to resolve the issues it presents. The following sections discuss the principles involved in this adaptation in detail.Defining a distributed transactionFirst, a distributed transaction can naturally be viewed as a global transaction that contains several branch transactions. The responsibility of a global transaction is to coordinate the branch transactions under its jurisdiction so that they agree, either by successfully committing together or failing and rolling back together. In addition, the branch transaction itself is usually a local transaction that satisfies the ACID principles. This is a basic understanding of the distributed transaction structure, which is consistent with that of XA.Second, similarly to the XA model, three components are defined to negotiate the processing of distributed transactions:The transaction coordinator (TC) maintains the running state of global transactions and is responsible for coordinating and driving the commit or rollback of global transactions.The transaction manager (TM) controls the boundaries of global transactions, is responsible for opening global transactions, and ultimately initiates the global commit or global rollback resolution.The resource manager (RM) controls branch transactions, is responsible for branch registration and status reporting, and receives instructions from the transaction coordinator to drive the commit and rollback of branch (local) transactions.A typical distributed transaction process works as follows:1. The TM requests that the TC open a global transaction and the global transaction is created, successfully generating a globally unique XID.2. The XID is propagated in the context of the microservice call link.3. The RM registers the branch transaction with the TC and incorporates it into the jurisdiction of the global transaction corresponding to the XID.4. The TM initiates a global commit or rollback resolution for the XID to the TC.5. The TC schedules all branch transactions under the XID to complete the commit or rollback request.Up to this point, Fescar’s protocol mechanism is generally consistent with XA.Differences between Fescar and XAFescar’s first major difference with XA is at the architecture level.The XA solution’s RM is actually at the database level, and the RM is essentially the database itself (available for applications’ use by providing XA-enabled drivers).Fescar’s RM is deployed on the application side as a middleware layer in the form of a second-party package. It does not depend on the support for the XA protocol provided by the database itself, and does not require the database to support the protocol. This is very important for a microservices architecture: the application layer does not need to adapt two different database drivers for the two different scenarios of local transactions and distributed transactions. This design principle strips off the distributed transaction solution’s requirements for database support for the protocol.Fescar’s second major difference concerns two-phase commit. The following shows XA’s 2PC process:Whether Phase 2’s resolution is commit or rollback, the transactional resource locks are kept until Phase 2 is completed.Imagine a normal business with a high probability that more than 90% of the transactions will eventually be successfully committed. Can local transactions be committed in Phase 1? With a percentage of more than 90%, committing earlier can save the lock time in Phase 2 and improve the overall efficiency.As shown above, Fescar’s design reduces the transaction lock time in most scenarios, thus increasing the concurrency of transactions.The next question is of course, how does Phase 2 roll back when Phase 1 is committed?How branch transactions commit and rollbackFirst, the application needs to use Fescar’s JDBC data source proxy, which is Fescar’s RM.Phase 1 works as follows: By parsing the business SQL, Fescar’s JDBC data source proxy organizes the data images of business data before and after the SQL execution into an undo log, and uses the ACID feature of the local transaction to write the update of the business data and the undo log in the same local transaction to commit. In this way, it can guarantee that any update of the committed business data definitely has a corresponding undo log.Based on this mechanism, the local transaction of the branch can be committed in Phase 1 of the global transaction, while the resources locked by the local transaction can be released immediately.Phase 2 works as follows: If the resolution is global commit, then the branch transaction has already completed the commit at the time and no synchronous reconciliation is required. (Only the rollback log needs to be cleaned up asynchronously). Phase 2 can thus be completed very quickly.If the resolution is global rollback, the RM receives the rollback request from the coordinator, finds the corresponding undo log record through the XID and the Branch ID, and generates the reverse update SQL, which it executes by rolling back the record to complete the branch rollback.The transaction propagation mechanismXID is the unique identifier of a global transaction. The transaction propagation mechanism needs to pass the XID through the service call link and bind it to the service’s transaction context. In this way, the database update operation in the service link is registered with the global transaction represented by the XID and is included in the jurisdiction of the same global transaction.Based on this mechanism, Fescar can support any microservice RPC framework, provided that it finds a mechanism in a specific framework that can transparently propagate the XID, for example, Dubbo’s Filter + RpcContext.Corresponding to the Java EE specification and Spring-defined transaction propagation properties, propagations supported and not supported by Fescar are as follows:· PROPAGATION_REQUIRED: supported by default· PROPAGATION_SUPPORTS: supported by default· PROPAGATION_MANDATORY: supported through the API· PROPAGATION_REQUIRES_NEW: supported through the API· PROPAGATION_NOT_SUPPORTED: supported through the API· PROPAGATION_NEVER: supported through the API· PROPAGATION_REQUIRED_NESTED: not supportedIsolationThe isolation of global transactions is based on the local isolation level of branch transactions.Based on the premise that the database local isolation level is “read committed” or above, Fescar is designed to use the global write exclusive lock maintained by the transaction coordinator to ensure the write isolation between transactions, and the global transaction is defined by default on the isolation level of “read uncommitted”.The consensus on isolation levels is that most applications work without problems under the isolation level of “read committed”. In fact, in most scenarios, applications also have no problem working under the isolation level of “read uncommitted”.In extreme scenarios, if the application needs to reach global read committed, Fescar also provides a mechanism for achieving that goal. By default, Fescar works under the isolation level of “read uncommitted”, ensuring efficiency for most scenarios.The ACID attributes of the transaction is a complicated topic in Fescar, and will be explained in-depth in a future article.Application Scenario AnalysisOne important premise for the core principles of Fescar mentioned above is that the resources involved in branch transactions must be relational databases that support ACID transactions. The branch commit and rollback mechanisms depend on the guarantee of local transactions. Therefore, if the database used by the application does not support transactions, or is not a relational database at all, Fescar is not applicable.In addition, there are still some limitations in the implementation of Fescar. For example, the transaction isolation level is supported up to the level of read committed; the SQL parsing does not cover all the syntax; and so on.To cover the deficiency that the Fescar native mechanism does not currently cover, another working mode is defined. The Fescar-native working mode described above is called AT (Automatic Transaction) mode, which is non-intrusive to the business. Another working mode corresponding to this is MT (Manual Transaction) mode, in which branch transactions need to be defined by the business.Basic branch behaviorA branch transaction that is part of a global transaction, in addition to its own business logic, includes four actions that interact with the coordinator:· Branch registration: Before its data operations are performed, the branch transaction needs to register with the coordinator, enabling the upcoming data operations to be included in the management of an opened global transaction. After the branch registration is successful, the data can be operated.· Status reporting: After its data operations are completed, the branch transaction must report the execution result to the transaction coordinator.· Branch commit: The branch transaction completes the branch commit in response to such a request issued by the coordinator.· Branch rollback: The branch transaction completes the branch rollback in response to such a request issued by the coordinator.AT branch behavior modeThe business logic does not pay attention to the transaction mechanism, and the interaction process between the branch and the global transaction is performed automatically.MT branch behavior modeThe business logic needs to be broken down into three parts to form an MT branch and join the global transaction: prepare, commit, and rollback.On the one hand, the MT mode is complementary with the AT mode. On the other hand, its more important value is that through it many non-transactional resources it can be included in the management of the global transaction.Hybrid modeBecause AT branches and MT branches are fundamentally consistent in their behavioral patterns, they are fully compatible; that is, in a global transaction, both AT and MT branches can exist. In this way, the purpose of comprehensive coverage for business scenarios can be achieved. For those that support AT mode, AT mode is used; for those that cannot currently support AT mode, the MT mode is used instead. In addition, MT-managed non-transactional resources can also be included in the management of the same distributed transaction along with relational database resources that support transactions.Application scenario outlookIn terms of the original intent of Fescar’s design, an ideal distributed transaction solution should be non-intrusive at the business level. MT mode is a natural supplement in cases where AT mode cannot fully cover all scenarios. The Fescar team hopes to gradually expand the range of supported scenarios through the continuous evolution of AT mode, while MT mode gradually converges. In the future, Fescar will include native support for XA, and use XA as a non-intrusive way to cover scenarios that are not reachable by the AT mode.Extension PointsMicroservices framework supportThe propagation of transaction contexts between microservices requires tailoring the optimal solution, which is transparent to the application layer, based on the mechanisms of the microservices framework itself. Developers interested in building in this area can refer to the built-in support for Dubbo to support other microservices frameworks.Supported database typesBecause AT involves the parsing of SQL, there are some specific adaptations that work on different types of databases. Developers interested in building in this area can refer to the built-in support for MySQL to support other databases.Configuration and service registration discoveryFescar supports solutions that access different configurations and support service registration discovery, such as Nacos, Eureka, and ZooKeeper.Scenario expansion in MT modeAn important function of MT mode is that the resources of the non-relational database can be incorporated into the jurisdiction of the global transaction through the packaging of MT branches, for example with Redis, HBase, and RocketMQ transaction messages. Developers interested in building in this area can contribute a range of ecosystem adaptation options.High-availability solutions for the distributed coordinatorFor different scenarios, different methods are supported as highly available solutions for the Transaction Coordinator Server side. For example, the persistence of the transaction state can be a file-based implementation of a database-based implementation; state synchronization between clusters can be based on RPC communications or on high-availability KV storage.RoadmapBlueprintIn the above blueprint, green areas have been released and open sourced, while yellow areas will be released by Alibaba in subsequent versions. Blue areas are ecosystem parts jointly built by Alibaba and the community.For support for different databases, developers can refer to the implementation of MySQL.For support for different microservices frameworks, developers can refer to Dubbo’s implementation.For support for MQ and NoSQL, developers can refer to the implementation of TCC.Regarding configuration and service registration discovery, developers can access any framework that can provide such services with a small amount of work.Of course, the community is also welcome to participate in sections outside of the blue area and contribute better solutions.In addition, XA is a standard for distributed transactions and is indispensable for a complete distributed transaction solution. In the vision for its planning, Fescar must add support for XA.Preliminary version planningThe following are planned details for release versions to come.v0.1.0:· Microservices Framework Support: Dubbo· Database support: MySQL· Annotation based on Spring AOP· Transaction Coordinator: Stand-alone versionv0.5.x:· Microservices Framework Support: Spring Cloud· MT mode· Support for adaptation of TCC mode transactions· Dynamic configuration and service discovery· Transaction Coordinator: High-availability cluster versionv0.8.x:· Metrics· Console: Monitoring/Deployment/Upgrade/Extensionv1.0.0:· General Availability: Applicable to the production environmentv1.5.x:· Database support: Oracle/PostgreSQL/OceanBase· Annotation that does not rely on Spring AOP· Optimized processing mechanism for hotspot data· RocketMQ transaction messages are included in global transaction management· NoSQL is incorporated in the adaptation mechanism of global transaction management· Support for HBase· Support for Redisv2.0.0:· Support for XAOver the course of its development, the Fescar team will strongly emphasize priorities voiced in the community, and will communicate its road map accordingly. Readers can learn more on GitHub or through Alibaba Cloud.Fescar: A Distributed Transaction Solution Open Sourced by Alibaba was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unified Application Framework for larger-scale Apps: Alibaba’s Fish Redux Moves to Open Source

Unified Application Framework for Larger-scale Apps: Alibaba’s Fish Redux Moves to Open SourceFish Redux has eliminated pain points and enabled configurable assembly for Alibaba’s Xianyu trading platformThis article is part of the Alibaba Open Source series.During its early stages, Alibaba’s Xianyu( 闲鱼) second-hand trading platform relied heavily on the Flutter mobile app SDK for its development. Developers encountered a number of persistent difficulties, especially strong business code coupling and poor code maintainability. To support its business scenarios, Xianyu needed a unified application framework capable of solving development dilemmas.As a high-level assembled Flutter application framework based on Redux data management, Fish Redux offered an ideal solution to Xianyu’s early problems, proving especially well-suited to medium and large-scale complex applications. With the primary feature of configurable assembly, it is easy to write in, easy to maintain, and makes collaboration easy. Inspired by renowned frameworks including Redux, React, Elm, and Dva, Fish Redux improved on Redux’s focus, division, reuse, and isolation functions.As it is soon to be open sourced, this article looks in detail at Fish Redux’s architecture, components, dictionary, and other mechanisms to illustrate its value for application development.Architecture Overview of Fish ReduxAs the following diagram shows, Fish Redux is divided into three layers from the bottom up.Each layer is used to solve problems and resolve contradictions at a specific level. The following sections discuss these layers in detail.Redux layerRedux is a state management framework created by the front-end development community that is predictable, centralized, easy to debug, and flexible. Redux handles all operations such as adding, deleting, revising, and querying data.In terms of design and implementation, Redux is a functional state management framework. Traditionally, object-oriented programming (OOP) deals with state management using beans, each bean exposing several public APIs to manipulate internal data (hyperemia model). The functional approach is more abstract. Data is defined as struct (anemic model) and the method of manipulating data is unified into a reducer with the same function signature:(T, Action) => T. FP: Struct (anemia model) + reducer = OOP: bean (hyperemia model).Meanwhile, Redux adds the middleware (AOP) mode and “subscribe” mechanism commonly used in FP, which gives the framework strong flexibility and scalability. (More information on the anemia and hyperemia models is available on Wikipedia.The original Redux has a number of disadvantages. The first is the contradiction between Redux’s centralization and its division of components. Second, Redux’s reducer requires manual assembly layer by layer, which is cumbersome and prone to errors.Fish Redux does away with these issues. It is only related with data management, regardless of specific use scenarios, offering centralized, observable data management through Redux. Beyond this, it offers better and higher abstraction than the original Redux in terms of usage in lateral development scenarios for the client-end Flutter page.Each component is made up of a data point (struct) and reducer. At the same time, there is a parent-child dependent relationship between the different components. Fish Redux uses this dependent relationship to resolve the conflict between centralization and partitioning. Fish Redux also transforms the reducer’s layer-by-layer manually combine function to provide automatic framework completion, significantly simplifying Redux usage. Finally, this helps achieve the results of centralization while using partitioned code.The concepts of state, action, reducer, store, and middleware mentioned above are consistent with the community’s ReduxJS, retaining all of the original Redux’s advantages. More information on Redux is available at the Redux Github page.Component layerComponents are packages for local presentations and functions. Based on Redux’s principles, functions are subdivided into two kinds, one that modifies data (reducers) and another that does not (side-effects). The result contains three parts: 1) the view; 2) the effect; and 3) the reducer, which are called the three elements of a component. They are responsible for the display of the component, the behavior of non-modifying data, and the behavior of modifying data, respectively.This subdivision is oriented both to the present and to the future. The current Redux regards subdivision as “data management” and “other”, while future-oriented UI-automation regards subdivision as “UI expression” and “other”. UI expression is now about to enter a black box era as far as programmers are concerned, leading R&D engineers to increasingly focus on the behavior of non-modifying data and modifying data.Components are the division of views and the division of data. Through layer-by-layer division, complex pages and data are divided into small modules that are independent of each other, facilitating collaborative development within teams.1. The viewThe view is simply a function signature: (T,Dispatch,ViewService) => Widget. It primarily contains information with three characteristics.First, the view is completely data-driven.Second, event/callback generated by the view is issued with “intentions” through the dispatch without a specific implementation.Lastly, component dependencies are needed with it, which are called in a standardized manner, for example through ViewService (in a typical view signiature-compliant function).2. The effectAs a standard definition for non-modifying data behavior, the effect is a function signature: (Context, Action) => Object. It primarily contains information with four characteristics.First, the effect receives “intentions” from the view, including the corresponding lifecycle callback, and then makes a specific execution.Second, its processing may be an asynchronous function, and the data may be modified in the process. This means that data should not be held; rather, the latest data should be obtained through the context.Third, it does not modify data, and if necessary should send an action to the reducer for processing.Lastly, its return value is limited to bool or future, which corresponds to the processing flow that supports synchronization functions and coroutines (such as good coroutine support).3. The reducerThe reducer is a function signature that fully conforms to the Redux specification: (T, Action) => T. The following shows a signature-compliant reducer:Meanwhile, the widgets and adapters that large components depend on are registered in an explicit configuration; this dependency configuration is called dependencies.The following formula results: component = view + effect (optional) + reducer (optional) + dependencies (optional). A typical assembly is shown below:Through abstraction of the component, complete division, multi-latitude reuse, and better decoupling are achieved.Adapter layerThe adapter is also a package for local presentations and functions. It was created for the high-performance scenarios of ListView and is a change in the component implementation aimed to solve three problems the component model faces in flutter-ListView scenarios.The first problem is that putting a “Big-Cell” in the component means being unable to enjoy the ListView code’s performance optimization.Second, the component cannot distinguish between appear/disappear and init/dispose.Finally, the coupling between the effect’s life cycle and the view does not meet the intuitive expectations present in ListView scenarios. In short, what is needed is an abstraction of local presentation and functional encapsulation that is a ScrollView in terms of logic and a ListView in terms of performance. Such a separate layer of abstraction is only considered in terms of its actual effect. The framework is not used for the page, and is instead used for the component and for the component + adapter baseline performance comparison.The reducer is long-lived, while the effect’s lifespan is in middle-range and the view is short-lived. Constant testing is used to make comparisons, as in the following example with an android device:Before using the framework, the baseline FPS in the details page is at 52FPS. With the use of the framework in the case of using only the component abstraction, the FPS drops to 40 and encounters the “Big-Cell” trap. With the use of the framework as well as the adapter abstraction, the FPS rises to 53, which is above the baseline and makes a small improvement.DictionaryThe recommended directory structure in Fish Redux is as shown as follows:The upper layer is responsible for assembly, while the lower layer is responsible for implementation. Meanwhile, a plug-in is provided to be quickly filled out. The following scenario from the Xianyu platform offers an example of the assembly:Here, there is complete independence between components and other components and between components and containers.Communication MechanismFish Redux’s communication mechanism provides for component communications within adaptor and for component communications between adaptors.In the above, a broadcast clip with priority processing is used. The issued action will first be self-processed, or it will be broadcast to other components and Redux for processing. Finally, all communication requests within components and between components (parent-child, child-parent, sibling-sibling, and so on) will be completed through a simple, intuitive dispatch.Refresh MechanismFish Redux’s refresh mechanism provides both data refreshing and view refreshing.Data refreshingData refreshing involves local data modification and layer-by-layer data copying.In local data modification, a shallow copy of the upper layer data is automatically triggered layer-by-layer. This data is transparent to the upper layer business code.Layer-by-layer data copying is on the one hand strictly compliant with Redux’s data modifications, and on the other is strictly compliant with data-driven representation.View refreshingView refreshing sends all flattened notifications to all components, while components determine whether they need to be refreshed through shouldUpdate.Key Advantages of Fish ReduxFish Redux’s first advantage is its centralized, observable management of data through Redux, in which all of the original advantages of Redux are retained. During reducer merging, Redux operations are transformed to be completed automatically by the framework, greatly simplifying the more tedious aspects of using Redux.Secondly, it excels in the division management of components. Components exist not only as divisions of views, but also as divisions of data. By dividing complex pages and data layer-by-layer, Fish redux divides these into independent small modules, enabling collaborative development within teams.Third, it provides isolation between the view, effect, and reducer, splitting components into three stateless, non-dependent functions. Because these are stateless functions, they are easier to write, debug, test, and maintain. Meanwhile, this brings greater possibility for combination, reuse, and innovation.Fourth, it offers declarative configuration assemblies. Components and adapters are assembled through a free configuration, including components’ view, reducer, effect, and child-relationships it depends on.Fifth, it offers strong scalability. The core framework maintains its own three-tier core focuses which it is concerned with alone, meanwhile maintaining flexible scalability for the upper layer. The framework does not have a single line of printed code, but data flow and component changes can still be observed through standard middleware. Beyond the framework’s three core layers, mixins can also be added to the component and adapter layers by “dart” to flexibly enhance their customization and capabilities of their upper-level applications. Further, the framework is connected to the SDK. There is no barrier between the SDK and the framework, and they are freely assembled by the upper layer.Finally, Fish Redux is simple and easy to use, requiring only about 1000 lines of code. After a few small functions and assembly tasks the code is finished running, and then it is ready for complete use.The value of Fish Redux is well demonstrated in the development of Xianyu. Fish Redux offers a unified application framework capable of solving persistent dilemmas.(Original article by Wu Jifeng邬吉风)Alibaba TechFirst hand and in-depth information about Alibaba’s latest technology → Facebook: “Alibaba Tech”. Twitter: “AlibabaTech”.Unified Application Framework for larger-scale Apps: Alibaba’s Fish Redux Moves to Open Source was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
More news sources

Alibaba news by Finrazor


Hot news

Hot world news

Maximine Coin Surge, eToro Adds TRON, Rakuten and Yahoo, Boss Crypto - Cryptocurrency News

Maximine coin is up more than 700% within the past 30 days. eToro also announced yesterday that they will add Tron TRX to its platform with more than 10 million registered users. Mattie will also talk about Rakuten and Yahoo continuing Mainstream Progression Towards Cryptocurrency as well as Boss Crypto, a crypto investment and education platform. ----------------------------------------------------------------------------------- Connect with us on Social Media: Twitter: Facebook: Telegram: ---------------------------------------------------------------------------------- Looking for the best cryptocurrency wallets? Check these out: BitLox: CoolWallet S: Trezor: Ledger Nano S: KeepKey: Read about them here: --------------------------------------------------------------------------------- References: BossCrypto – Crypto Investment and Education Platform Boss Crypto Yahoo and Rakuten Continue Mainstream Progression Towards Cryptocurrency Rakuten Wallet Launch Announced for March 30, 2019 Here’s Why Crypto Maximine Coin (MXM) Jumped 754.5% in March eToro adds Tron TRX to its Platform with More than 10 Million Users -------------------------------------------------------------------------------- DISCLAIMER The information discussed on the Altcoin Buzz YouTube, Altcoin Buzz Ladies YouTube, Altcoin Buzz Podcast or other social media channels including but not limited to Twitter, Telegram chats, Instagram, facebook, website etc is not financial advice. This information is for educational, informational and entertainment purposes only. Any information and advice or investment strategies are thoughts and opinions only, relevant to accepted levels of risk tolerance of the writer, reviewer or narrator and their risk tolerance maybe different than yours. We are not responsible for your losses. Bitcoin and other cryptocurrencies are high-risk investments so please do your due diligence and consult the financial advisor before acting on any information provided. Copyright Altcoin Buzz Pte Ltd. All rights reserved.
Altcoin Buzz

Maximine Coin [MXM] Jumps 30% Higher While Top Currencies Continued Bleeding

In a continuous declining market, there’s one coin that stood out higher. Maximine Coin or MXM Coin broke a new record of entering into the graph of Top 40 cryptocurrencies with a spike of 30 percent over the past 24 hours. Why MXM Coin Pumped Higher? The value surge is quite surprising because the top crypto assets including Bitcoin, Ethereum, XRP, Litecoin, EOS, Bitcoin Cash, Binance Coin, and many other cryptos are on the way out. Nevertheless, the major concern comes after the spike of MXM Coin trading volume on CoinBene exchange which suspects to have wash trading activities. Despite this decline drive, Maximine Coin’s MXM token is ruling with rising volume among the top 40 cryptocurrencies. At the moment, the MXM’s average trading value counts $159,653,386 which has gained 30.11 Percent over the last 24 hours. Moreover, the coin is trading at $0.096818. Maximin Coin or MXM is presently available at a handful of crypto trading platforms including CoinBene, HitBTC, Coinbit, and Livecoin. Among these exchanges, the highest trading volume is split among CoinBene and HitBTC with pair of USDT, ETH, and BTC respectively. Is there anything Related to CoinBene’s Suspected Wash Trading? Looking closer at the coinmarketcap, the highest trading volume of MXM coin can be seen on CoinBene, the exchange which was once noticed of involving with wash trading activities as reported by Bitwise Asset Management. Reports further revealed that the volume is faked by the exchange itself that results to inflate actual numbers to catch user’s attention. Moreover, the exchange registered in Singapore and doesn’t need KYC for a user to have an account with. To note, the Bitforex exchange where MXM Coin will soon be listed is also based out in Singapore – moreover, Maximine Coin is reportedly registered in the same country. Additionally, recent reports reveal that the coin had gained mainstream concern from Bitforex, a Singapore based trading platform. The firm announced to list MXM coin on its exchange which many speculate and relate the coin’s significant performance with. Heard the news? 👂🏼 Seen the papers? 👀 If you haven't, keep your eyes glued to the screen and your ears wide open because @maximinecoin is coming to @bitforexcom ! 🍻🙌🏼 Details in link below! 👇🏼 — MaxiMine (@maximinecoin) March 26, 2019 What do you think about CoinBene and its trading contribution to Maximine Coin? share your opinion with us  The post Maximine Coin [MXM] Jumps 30% Higher While Top Currencies Continued Bleeding appeared first on Coingape.
By continuing to browse, you agree to the use of cookies. Read Privacy Policy to know more or withdraw your consent.