REULAY’s virtual therapeutic platform for reducing workplace stress and anxiety leverages brain science and machine learning to deliver personalized evidence-based digital interventions

Reulay

reulay

The success of The Merge and the subsequent Shapella hard fork showcased Ethereum's ability to smoothly ship significant network upgrades. However, this transition was not without its challenges and learning curves. Over the past year, Ethereum’s journey has been punctuated by encounters with malevolent entities, unintended software anomalies, and disparities in value distribution. As we mark the one-year anniversary of The Merge, we wanted to take a moment to review some of the significant advancements that have redefined the Ethereum ecosystem as well as their positive and negative impacts on the network, its end-users, and the critical actors in the MEV supply chain. TL:DR several of the key lessons we learned included: The pursuit of maximum profits fuels centralization at the core of the network. Vertically integrated Searcher/Builders have proven positive economics, while credibly neutral Builders struggle to find margin and hence revenue/profitability. MEV-Boost Relay operations are effectively a 100% risk, 0% reward situation. Based on the latest in ePBS research, trusted third-party Relays at the core of the network will be a fact of life for the foreseeable future. Sanctions – and OFAC SDN specifically – played an unexpected role in shaping the staking and PBS landscapes. Promises of ‘protecting’ users from the adverse effects of MEV remain to be fully proven. MEV-Boost and Proto-PBS The Merge and the migration from Proof-of-Work to Proof-of-Stake was the most consequential upgrade to the Ethereum network so far. The Merge brought , enabling the decoupling of the technically intensive act of block building from the decentralized consensus act of block proposal. Proposer/Builder Separation (PBS) In-protocol PBS – aka enshrined PBS – was not ready at The Merge. To enable the outsourcing of block production, the Ethereum Foundation partnered with Flashbots to develop a ‘temporary’ outside-the-protocol block auction approach known as MEV-Boost . MEV-Boost bridged the gap between Block Builders and Block Proposers – that is, the Validator who is randomly selected to be the tip of the chain and hence proposes the contents of the next block to the network. MEV-Boost introduced net-new actors known as Relays to act as trusted intermediaries between Block Builders and Proposers. These Relays effectively serve as block auctioneers that make sure Builders are honest in their bids to Proposers, and that Proposers cannot steal the MEV bundles from Builders or Searchers. MEV-Boost and Relays saw explosive adoption among validators thanks to the increase in block value that specialized Block Builders can generate. In the last 30 days, that landed on-chain were outsourced to independent Block Builders via the MEV-Boost network, with the average MEV-Boost block being than locally created blocks. 96% of all blocks 5.57x more valuable Occasionally, a rare high-value block could pay out tens of thousands of dollars, with even rarer single block rewards going as high as – over $1.0 million USD (!!) at the time. 691 ETH Block Building: The Fight to Stay Competitive Block building has become increasingly competitive, given the current full-block auction model of MEV-Boost. That is, each block auction results in a single auction winner who wins the exclusive right to build the entire block – and many auction losers. To gain an edge, some Block Builders have become vertically integrated with Searchers, adding proprietary order flow to their blocks and enabling differentiated MEV profits. This has resulted in neutral builders struggling to sustain revenue. In the last 14 days, ~75% of the blocks on the Ethereum network were built by just three block builders—two of which are vertically integrated Searcher/Builders. Source: https://mevboost.pics/ Slashing: How a New Attack Vector Enabled a Malicious Validator to Steal Millions On April 3rd, the Ethereum network witnessed a new class of attacks . The attack broke the assumed atomicity of MEV bundles and extracted roughly $25 million in gains from a handful of unprotected MEV Searcher bots. from a malicious Validator In response to this class of attack, Relays now publish their blocks to the beacon network before returning them to the Proposer. And if this fails, the Relay network does not return a payload to the Proposer at all. MEV-Boost Relays Today: 100% Risk, 0% Reward In the world of Proposer/Builder Separation, Relays play a pivotal yet undervalued role. Relays impact the entire MEV supply chain, from Searchers to Block Builders to Validators, connecting these untrusted stakeholders in a symbiotic, permissionless transaction ecosystem. Through Relays, Validators can outsource block production to Block Builders, enhancing the ecosystem's efficiency and economic security while measurably increasing Validator revenue. Yet, despite this critical role, . In practice, Relays sometimes have negative rewards. Relays are essentially operated as public goods. Relays currently lack any economic rewards Today, the Relay landscape is increasingly centralized, with just seven unique Relay operators controlling more than 1% of the MEV-Boost network. If Relays fail to do their job(s), Validators suffer missed slots, or worse, malicious actors can exploit the network. MEV-Boost Relays are effectively 100% risk with 0% reward, with a small number of actors participating. While Relays were only meant to be temporary until ePBS, they have proven to be critical for the security and orderly operation of the chain and are unlikely to go away for the foreseeable future. It might be only a matter of time before we see vertically integrated Searcher/Builder/Relays as Relay operators cast about for sustainable economics. A Rise in MEV Awareness and MEV Protection Over the last year, MEV awareness has grown. Transaction originators began to understand the negative impact frontrunning and sandwich bots had on transaction settlement. Innovative products emerged to combat these negative externalities, such as: Private transaction RPC endpoints that enable users to send transactions privately to Block Builders Order Flow Auctions (OFAs) that enable private transactions to be backrun by MEV searchers with a percentage of the profit being shared with the user : Blocknative’s MEV protection aggregator that enables sending to all available builder and OFA RPCs. Transaction Boost The network has seen a surge in private transactions as users attempt to shield themselves from MEV, with private transactions on-chain jumping from about 5% pre-Merge to nearly 15% today. However, the MEV protection ecosystem has a ways to go to truly protect users. An analysis using the has shown that private transactions receiving front-running protection do not necessarily result in better settlement. Blocknative Mempool Archive Counterintuitively, our analysis of public and private transactions revealed that many users who sent their transactions privately incurred more slippage than those who sent them publicly. We expect the MEV protection market to continue to evolve. In the long run, users should not have to worry about the complexities of MEV. We believe that forward-thinking wallets will play a critical role in protecting their users from the ill effects of MEV and providing the best settlement outcomes. Looking Ahead By building and operating a Block Builder and Relay from scratch, we have learned from the complexities of the MEV supply chain firsthand as an active, in-the-transaction-flow participant. These insights have inspired us at Blocknative to create new functionality to help protect Web3 users.

Ethereum Merge One Year Later: What We've Learned about Block Building, MEV-Boost, and Relays

Fusión de Ethereum un año después: lo que hemos aprendido sobre la construcción de bloques, MEV-Boost y retransmisiones

Fusion d'Ethereum un an plus tard : ce que nous avons appris sur la construction de blocs, le MEV-Boost et les relais

एक साल बाद एथेरियम का विलय: हमने ब्लॉक बिल्डिंग, एमईवी-बूस्ट और रिले के बारे में क्या सीखा है

1 年後のイーサリアム マージ: ブロック ビルディング、MEV ブースト、リレーについて学んだこと

Ethereum Merge um ano depois: o que aprendemos sobre Block Building, MEV-Boost e Relays

Hợp nhất Ethereum một năm sau: Những gì chúng tôi đã học được về Xây dựng khối, MEV-Boost và Rơle

以太坊合并一年后：我们对区块构建、MEV-Boost 和中继的了解

Event-driven architecture (EDA) is a software design pattern that emphasizes the production, detection, consumption, and reaction to events that occur within a system or across multiple systems. It is a style of architecture where the flow of data and the triggering of actions are driven by events. offers several benefits like higher scalability, modularity, and resilience due to the loosely coupled services compared to Request-Driven Architecture. Event-driven architecture However, it introduces some unique testing and monitoring challenges compared to traditional architectures: Events in an event-driven architecture may be processed asynchronously and can arrive out of order, and might be lost or duplicated. Testing and monitoring should include scenarios to validate how the system handles these situations. Event Ordering and Consistency: In event-driven systems, workflows are often driven by events. Coordinating the behavior of different services, validating event propagation, and ensuring correct data transformation across different workflows make End-to-End and Integration Testing much harder. Event-driven Workflow Validation: Events may evolve over time, with changes to their payload structure or schema, making it hard to ensure the compatibility of events across different versions. Event Payload and Schema Evolution: Event-driven architectures often involve services that are triggered by specific events. Generating and managing event simulations can be challenging, especially when dealing with a large number of events and complex workflows. Testing Event-Triggered Services: A great way to test these Event-driven systems is to use a record-replay strategy. Recording and replaying events allows you to capture real or simulated events and later replay them during testing to verify the behavior and correctness of the system. Here’s an overview of the steps involved in recording and replaying events: : Identify the events that need to be recorded for testing purposes. These can be actual events from a live system or simulated events generated specifically for testing and involves setting up a mechanism to capture and store the events in a suitable format for retrieval. This can be achieved by creating a dummy consumer for the topic we want to replay, which can store events in persistent storage like DB. Event Recording import kafka

# yield events from start_time to end_time

def record_events(self, start_time, end_time):
  consumer = kafka.KafkaConsumer(**(self._configs))
  
  #find offset for each partition which is just after start time
  
  seek_points = find_seek_points(start_time)
     
        try:
            # Set up a the consumer to fetch all desired partitions from their seek points
            
            for tp, offset in six.iteritems(seek_points):
                consumer.seek(tp, offset)
            
            while len(partitions) > 0:
                record = next(consumer)
                if not record:
                    partitions = set()
                else:
                    last_timestamp = record.timestamp
                    if last_timestamp > end_time:
                        partitions.discard(record.partition)
                        tp = kafka.TopicPartition(topic=record.topic, partition=record.partition)
                        if tp not in consumer.paused():
                            consumer.pause(tp)
                    elif (record.partition in partitions and last_timestamp >= start_time
                          and last_timestamp <= end_time):
                        # Send the record to the client if it's within the specified time range
                        yield record Source: https://github.com/SiftScience/python-kafka-replayer : Set up the test environment with a message queue and services configured. Add a dummy producer which reads the events from DB and adds them to the queue. Event Replaying from kafka import KafkaProducer

#read events from DB
events = recordedEvents.stream()

#send next event 
def generate_message():
    return events.next()

# Kafka Producer
producer = KafkaProducer(
    bootstrap_servers=['localhost:9092']
)
if __name__ == '__main__':
    # Infinite loop - runs until you kill the program
    while True:
        recorded_event = generate_message()     
        producer.send('messages', dummy_message) You can extend this simple setup by — adding delays, event duplication, and data corruption to analyze the system’s performance, resilience, and behavior under different event scenarios. By recording and replaying events, you can simulate real-world scenarios, edge cases, or failure conditions, providing a comprehensive testing approach for event-driven architecture. It helps uncover bugs, validate event processing, and ensure the system functions as intended when exposed to various event sequences and scenarios. Also published here.

Record-Replay Strategy for Testing Event-Driven Architecture

In the rapidly evolving landscape of web development, understanding the differences between state management solutions is crucial. Two prominent options in the JavaScript ecosystem are Relay and Redux. While both Relay and Redux are powerful tools for managing state in JavaScript applications, they differ in architecture, purpose, and functionality. This article aims to explore the nuances of and , highlighting their core concepts, approaches to data fetching and management, considerations for performance, integration with React, support from the developer community, and key factors to consider when choosing between them. By the end of this article, you will have a comprehensive understanding of Relay and Redux, empowering you to make an informed decision for your upcoming project. Relay Redux Understanding Relay and Redux Before delving into the details, let us commence with a concise overview of Relay and Redux. Relay serves as a client-side framework, meticulously designed for constructing data-centric applications. Its primary emphasis lies in proficient data retrieval and caching, empowering developers with a declarative methodology for managing the data flow within their applications. GraphQL In contrast, Redux serves as a dependable state container that facilitates the management of the application state within a centralized store. It places significant importance on maintaining a singular source of truth, thereby guaranteeing that state alterations are handled in a foreseeable and sustainable manner. Architecture and Purpose Relay differentiates itself from Redux through its distinctive architecture and objectives. As a client-side GraphQL framework, Relay effectively utilizes the capabilities of GraphQL’s query language to establish a schema and seamlessly retrieve data from a server. It is explicitly designed for the development of data-driven applications, where the data prerequisites are conveniently integrated with the components responsible for rendering that data. By prioritizing efficient data retrieval and caching, Relay enhances network requests, while also offering automatic mechanisms for data caching and invalidation. On the contrary, the fundamental structure of Redux revolves around the concept of a centralized store. This architectural approach provides a reliable container for the application’s state, ensuring that it is stored in a singular location. Redux strongly emphasizes immutability, which guarantees that any updates to the state are handled in an immutable manner. By employing Redux, a clear segregation is established between actions, which define state changes, reducers, which manage these changes, and the store, which holds the entirety of the application’s state. Key Concepts and Functionality Relay presents the notion of GraphQL schema and queries, wherein the schema delineates the data structure and relationships within the application. Queries in Relay empower developers to precisely define their data requisites and retrieve solely the pertinent information. The declarative data fetching methodology employed by Relay streamlines the task of specifying the desired data while entrusting optimization to the framework. Essential to Relay’s functionality are its automated data caching and invalidation mechanisms, which intelligently handle data updates and synchronize them with the user interface. Furthermore, Relay advocates for the amalgamation of data requirements with components, enabling developers to explicitly specify their data dependencies within the components themselves. In Redux, the fundamental principles revolve around actions, reducers, and the store. Actions are JavaScript objects that succinctly define modifications to the application’s state. Reducers, which are pure functions, are responsible for processing these actions and modifying the state accordingly. The store functions as a centralized repository for storing and retrieving the state. Redux advocates for immutability, which guarantees that state updates transpire in an immutable manner. This approach facilitates debugging and facilitates change tracking. Middleware in Redux grants developers the ability to introduce supplementary logic to handle side effects, such as asynchronous API calls, in an efficient manner. Data Fetching and Management Relay revolutionizes the process of data fetching and management by leveraging GraphQL queries and fragments. Through queries, developers can precisely specify the data requirements, eliminating the issues of excessive or inadequate data retrieval. Fragments offer a reusable means of defining data dependencies for multiple components. To optimize data fetching, Relay efficiently batches requests and implements network optimizations, such as parallelizing requests and minimizing redundant data transfers. The framework also handles store updates and provides mechanisms for optimistic UI, allowing for optimistic updates to the user interface before receiving the server’s response. Furthermore, Relay includes built-in support for pagination and infinite scrolling, simplifying the management of large datasets. In Redux, the process of retrieving and controlling data is commonly achieved through the utilization of asynchronous actions and thunks. Asynchronous actions enable developers to effectively manage API requests and responses, facilitating the retrieval of data from external sources. Thanks, to being functional, empowers the implementation of intricate logic and the handling of side effects within Redux. In the event of data retrieval, Redux promotes the practice of normalizing and updating the state, ensuring a well-organized and efficient representation of the application’s data. Middleware tools, such as Redux Saga or Redux Thunk, can be employed to effectively manage the data flow and introduce supplementary functionality. Performance and Efficiency Relay demonstrates exceptional performance through its highly efficient data retrieval and caching mechanisms. Through the consolidation of queries and optimization of network requests, Relay significantly reduces the need for multiple interactions with the server, thereby minimizing latency and enhancing the application’s responsiveness. The automatic caching and invalidation of data guarantee local storage and updates occur only when required. By colocating data requirements with components, Relay accurately discerns data dependencies, resulting in optimal data retrieval. Furthermore, Relay fully embraces incremental rendering and streaming, enabling the application to commence rendering partial data even before the complete response is received. In the context of Redux, performance considerations center around the principles of immutable state updates and memoization. Redux promotes the concept of immutable state updates, which enables components to accurately determine the need for re-rendering based on state changes. By embracing immutability, Redux effectively minimizes unnecessary renders and improves the overall performance of the application. Libraries like reselect facilitate selective data updates by offering memoized selectors, allowing efficient computation of derived data. Additionally, Redux middleware can be leveraged for performance optimizations, such as caching API responses or optimizing data flow within the application. Integration with React Relay establishes a seamless integration with React via Relay Modern and React Hooks. Relay Modern, the most recent iteration of Relay, is specifically crafted to harmonize with React’s functionality. React Hooks offer a convenient mechanism to engage with Relay’s capabilities and effectively manage data retrieval within functional components. Relay advocates for the separation of concerns between data retrieval and presentational components, facilitating container and component composition. The utilization of fragments empowers developers to define data dependencies in a detailed and reusable manner. Moreover, Relay’s integration encompasses render-as-you-fetch and Suspense integration, optimizing the loading process to ensure a seamless and efficient user experience. The integration of Redux and React is made possible through the utilization of the React-Redux library and hooks. React-Redux offers a range of tools that enable the connection of components to the Redux store, facilitating access to the state and dispatching of actions. Through the implementation of React-Redux, developers can ensure that components are automatically refreshed when relevant portions of the state change. By establishing a connection between components and the Redux store, data seamlessly flows from the store to the components, facilitating efficient management of the application’s state. Dispatching actions and accessing the state become simplified, while the utilization of selectors allows for the efficient extraction of specific data from the state, thereby minimizing unnecessary rendering. Community and Ecosystem Relay benefits greatly from the unwavering support of both the Facebook and GraphQL communities. Being an integral part of the GraphQL ecosystem, Relay consistently receives updates and enhancements in tandem with GraphQL. The community actively engages in bolstering the framework by developing specialized tools and libraries that augment its capabilities. Extensive learning resources and meticulous documentation, including official guides and illustrative examples, are readily accessible. The flourishing community guarantees that developers have a reliable avenue to seek assistance and exchange knowledge while utilizing Relay. Redux is highly embraced by the JavaScript community, being widely used as the preferred method of managing state by numerous developers and frameworks. Consequently, a considerable assortment of packages and libraries associated with Redux has emerged, serving diverse purposes and meeting various needs. The Redux community remains actively engaged, with developers exchanging their insights, generating valuable assets, and actively enhancing the ecosystem. Extensive and informative resources, both official and community-driven, furnish thorough instructions for effectively employing Redux. Choosing Between Relay and Redux It is important to take into account the project’s requirements and level of complexity. Relay excels in handling intricate data flow situations, making it a great option for applications that involve a lot of data. Conversely, Redux’s simplicity and centralized store approach make it a good fit for applications that require less complicated state management. The learning process and the skill level of the developers should also be considered. When it comes to integrating Relay with GraphQL, developers need to learn and understand GraphQL concepts and syntax. On the other hand, Redux has a simple structure, making it easier for developers who are already familiar with JavaScript and state management concepts to approach. The performance and scalability requirements differ from one project to another. When an application requires efficient data retrieval, caching, and real-time updates, Relay’s enhancements make it an appealing option. Redux, which emphasizes immutability and performance improvements, is also capable of handling various scenarios. The integration with preexisting tools and libraries is an important factor to consider. If you have already incorporated GraphQL extensively into your project, the seamless experience offered by Relay’s strong integration with GraphQL may be a favorable option. Conversely, if you have already established a robust infrastructure around Redux or heavily rely on Redux-related libraries, it would be pragmatic to continue utilizing Redux. Difference between: Redux and Relay Aspect Relay Redux Architecture and Purpose Client-side GraphQL framework Predictable state container Optimized for data-driven applications Centralized store for application state Key Concepts and Functionality GraphQL schema and queries Actions, reducers, and the store Declarative data fetching Immutable state updates Automatic data caching and invalidation Middleware for side effects Data Fetching and Management GraphQL queries and fragments Asynchronous actions and thunks Batched requests and optimizations API request handling Store updates and optimistic UI State normalization and updates Performance and Efficiency Query batching and caching Immutable state updates for rendering Colocation of data requirements Selective data updates with reselect Incremental rendering and streaming Memoization and performance optimization Integration with React Relay Modern and React Hooks React-Redux library and hooks Container and component composition Connecting components to the store Render-as-you-fetch and Suspense Dispatching actions and accessing the state Community and Ecosystem Facebook and GraphQL community support Widely adopted in the JavaScript community Relay-specific tools and libraries Large ecosystem of Redux-related packages Extensive learning resources and docs Learning resources and documentation Choosing Between Relay and Redux Consider project requirements and complexity Consider project requirements and complexity Assess the learning curve and developer expertise Assess the learning curve and developer expertise Evaluate performance and scalability needs Evaluate performance and scalability needs Examine integration with existing tools and libraries Examine integration with existing tools and libraries Conclusion Relay is ideal for data-driven apps Redux is versatile for a wide range of projects Provides efficient data fetching and caching Emphasizes predictable state management Extensive community and documentation Wide adoption and extensive ecosystem Choose based on project requirements Considerations for project requirements Difference between: Redux and Relay In Table Format Originally published here.

Relay or Redux? Choosing the Right State Management Solution

If you follow me for a while, you know that one of my pet peeves is comparisons between GraphQL, REST, tRPC, and other technologies that fail to mention Relay and Fragments. In this post, I will explain why I think Relay is a game-changer, how we make it 100x easier to use and adopt, and why you should give it another look. What makes Relay so special? Stop thinking for a moment about APIs from the perspective of the server. Instead, think about consuming APIs from the frontend perspective and how you can build scalable and maintainable applications. That's where Relay shines, that's where you can see a significant difference between Relay, , tRPC, and other technologies. REST If you haven't used Relay before, you probably never realized how powerful can be when combined with Relay. The next section will explain why. GraphQL At the same time, a lot of people are scared of Relay because it has a steep learning curve. There seems to be a sentiment that Relay is hard to set up and use, and that's true to some extent. However, you don’t require PhDs to use it. That's exactly why we built a first-class Relay integration into WunderGraph that works with both NextJS and pure React (e.g. using Vite). We want to make Relay more accessible and easier to use. Essential features like Server-Side Rendering (SSR), Static Site Generation (SSG), persisted Queries (persisted Operations), and Render-as-you-fetch (aka Suspense) are built-in and work out of the box. Before we dive into how we've made Relay easier to use, let's first take a look at what makes Relay so special. Collocation of Data Requirements using Fragments The typical data fetching pattern in applications like NextJS is to fetch data in the root component and pass it down to the child components. With a framework like tRPC, you define a procedure that fetches all the data you need for one page and passes it down to the children. By doing so, you implicitly define the data requirements for the component. Let's say you've got a page that displays a list of blog posts, and each blog post has a list of comments. In the root component, you'd fetch the blog posts with comments and pass the data down to the blog post component, which in turn passes the comments down to the comment component. Let's illustrate this with some code: // in pages/index.tsx
export default function Home({ posts }: { posts: Post[] }) {
  return (
    <div>
      {posts.map((post) => (
        <BlogPost key={post.id} post={post} />
      ))}
    </div>
  );
}

// in components/BlogPost.tsx
export default function BlogPost({ post }: { post: Post }) {
  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
      <div>
        {post.comments.map((comment) => (
          <Comment key={comment.id} comment={comment} />
        ))}
      </div>
    </div>
  );
}

// in components/Comment.tsx
export default function Comment({ comment }: { comment: Comment }) {
  return (
    <div>
      <h2>{comment.title}</h2>
      <p>{comment.content}</p>
    </div>
  );
} As an example, the component has two data dependencies: and . Let's say we're using this component in 10 different places in our application. If we want to add a new field to the component, e.g. , we have to figure out all the places where we're using the component, navigate to the root component, find the procedure that fetches the data, and add the new field to it. Comment title content Comment author Comment You can see how this can quickly become a huge maintenance burden. The problem that leads to this is that we're fetching data top-down. The result is a tight coupling between the data-fetching logic and the components. With Relay and Fragments, we're able to collocate the data requirements with the component, while simultaneously decoupling the data fetching logic from the component. Together with data masking (next section), this is a game-changer, because it allows us to build reusable components that are decoupled from the data fetching logic. It's worth noting that GraphQL itself doesn't solve this problem. Moreover, most GraphQL clients don't encourage this pattern, leading to the same problems we've seen with REST APIs. So-called "God Queries" that fetch all the data for a page is a common pattern with GraphQL clients. Without Fragments, it's really just the same problem as with REST APIs or tRPC, just with a different syntax and the added overhead of GraphQL. Let's take a look at how we can achieve this with Relay and Fragments. // in pages/index.tsx
export default function Home() {
  const data = useFragment(
    graphql`
      query Home_posts on Query {
        posts {
          ...BlogPost_post
        }
      }
    `,
    null
  );

  return (
    <div>
      {data.posts.map((post) => (
        <BlogPost key={post.id} post={post} />
      ))}
    </div>
  );
}

// in components/BlogPost.tsx
export default function BlogPost({ post }: { post: Post }) {
  const data = useFragment(
    graphql`
      fragment BlogPost_post on Post {
        title
        content
        comments {
          ...Comment_comment
        }
      }
    `,
    post
  );

  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
      <div>
        {data.comments.map((comment) => (
          <Comment key={comment.id} comment={comment} />
        ))}
      </div>
    </div>
  );
}

// in components/Comment.tsx
export default function Comment({ comment }: { comment: Comment }) {
  const data = useFragment(
    graphql`
      fragment Comment_comment on Comment {
        title
        content
      }
    `,
    comment
  );

  return (
    <div>
      <h2>{data.title}</h2>
      <p>{data.content}</p>
    </div>
  );
} In this example, the component is completely decoupled from the data-fetching logic. It defined its data requirements in a Fragment that's collocated with the component. We can use the component in as many places as we want, it's completely decoupled from the data-fetching logic. Comment Comment If we want to add a new field to the component, like the field, we can simply add it to the Fragment and the component will automatically receive the new field. Comment author Comment Turning around our perspective to the data fetching logic, we can see that the component doesn't care about what exact fields the component needs. This logic is completely decoupled from the component through the use of Fragments. Home Comment Home That said, there's one more thing to make truly de-coupled components possible: Data Masking. Re-Usable Components through Data Masking Let's say we've got two sibling components that both use comment data. Both define their data requirements in a separate Fragment. One component only needs the field, while the other component requires the and fields. title author content If we were to directly pass the comment data to both components, we might accidentally use the field in the component that didn't define it in its Fragment. In doing so, we'd introduce a dependency between the two components. title To prevent this, Relay allows us to mask the data before passing it to the component. If a component didn't define a field in its Fragment, it won't be able to access it, although it's theoretically available in the data. To my knowledge, no other API client has this feature, which is why I think you shouldn't dismiss GraphQL without having tried Relay. GraphQL and Relay come at a cost if you compare it to e.g. tRPC. It's important to understand the benefits to make an informed decision on whether it's worth it. A lot of people think that GraphQL and Relay are only useful for huge applications. I think that's a misconception. Building reusable components is a huge benefit for any application, no matter the size. If you've wrapped your head around Fragments and Data Masking, you really don't want to go back to the old way of doing things. We'll take a look after the next section at how easy we made it to get started with Relay and Fragments. Compile-Time GraphQL Validation & Security Another benefit of using Relay is that the "Relay Compiler" (recently rewritten in Rust) compiles, validates, optimizes, and stores all GraphQL Operations at build time. With the right setup, we're able to completely "strip" the GraphQL API from the production environment. This is a huge benefit for security because it's impossible to access the GraphQL API from the outside. Moreover, we're able to validate all GraphQL Operations at build time. Expensive operations like normalization and validation are done at build time, reducing the overhead at runtime. How does WunderGraph make using Relay easier? You might not yet be convinced of the benefits of Relay, but I hope you're at least curious to try it out. Let's see how the integration with WunderGraph makes it easier to get started with Relay. Setting up Relay + NextJS/Vite with WunderGraph is easy We've tried to setup Relay with NextJS and Vite ourselves. It's not easy. In fact, it's rather complicated. We found npm packages that try to bridge the gap between Relay and NextJS, but they were not well-maintained, documentation was outdated and most importantly, we felt like they were too opinionated, e.g. by forcing the use of which is deprecated in NextJS. getInitalProps So we've taken a step back and built a solution that works with Vanilla React and frontend frameworks like NextJS and Vite without being too opinionated. We've built the necessary tooling to make Server-Side Rendering (SSR), Static Site Generation (SSG), and Render-as-you-fetch easy to use with any frontend framework. Additionally, we've made sure to choose some reasonable defaults, like enforcing persisted Operations by default with zero setup, giving the user a secure-by-default experience without having to think about it. So, what does a simple setup look like? // in pages/_app.tsx
import { WunderGraphRelayProvider } from '@/lib/wundergraph';
import '@/styles/globals.css';
import type { AppProps } from 'next/app';

export default function App({ Component, pageProps }: AppProps) {
	return (
		<WunderGraphRelayProvider initialRecords={pageProps.initialRecords}>
			<Component {...pageProps} />
		</WunderGraphRelayProvider>
	);
} That's it. All you need to do is wrap your app with the and pass the prop. This works with NextJS 12, 13, Vite and others as it doesn't rely on any framework-specific APIs. WunderGraphRelayProvider initialRecords Next, we need to configure the Relay Compiler to work with WunderGraph. As you'll see, WunderGraph and Relay are a match made in heaven. Both are built with the same principles in mind: Declarative, Type-Safe, Secure-by-default, and Local-first. Relay is the frontend counterpart to WunderGraph's backend. WunderGraph ingests one or more GraphQL & REST APIs and exposes them as a single GraphQL Schema, which we call the virtual Graph. Virtual, because we're not really exposing this GraphQL Schema to the outside world. Instead, we're printing it into a file to enable auto-completion in the IDE and to make it available to the Relay Compiler. At runtime, we're not exposing the GraphQL API to the outside world. Instead, we only expose an RPC API that allows the client to execute pre-registered GraphQL Operations. The architecture of both WunderGraph and Relay makes the integration seamless. It feels like WunderGraph is the missing server-side counterpart to Relay. Relay Compiler Configuration with out-of-the-box support for persisted Operations So, how do we wire up the Relay Compiler to work with WunderGraph? As mentioned above, WunderGraph automatically persists all GraphQL Operations at build time. In order for this to work, we need to tell the Relay Compiler where to "store" the persisted Operations. On the other hand, Relay needs to know where to find the GraphQL Schema. As WunderGraph stores the generated GraphQL Schema in a file, all we need to do is wire up the two using the section in the . relay package.json {
  "relay": {
    "src": "./src",
    "artifactDirectory": "./src/__relay__generated__",
    "language": "typescript",
    "schema": "./.wundergraph/generated/wundergraph.schema.graphql",
    "exclude": [
      "**/node_modules/**",
      "**/__mocks__/**",
      "**/__generated__/**",
      "**/.wundergraph/generated/**"
    ],
    "persistConfig": {
      "file": "./.wundergraph/operations/relay/persisted.json"
    },
    "eagerEsModules": true
  }
} With this config, the Relay Compiler will assemble all GraphQL Operations in the directory, generates the TypeScript types, and stores the persisted Operations in . Each stored Operation is a pair of a unique ID (hash) and the GraphQL Operation. WunderGraph will automatically read this file, expand it into files and store them in , which will automatically register them as JSON-RPC endpoints. ./src ./.wundergraph/operations/relay/persisted.json .graphql ./.wundergraph/operations/relay/ Additionally, the WunderGraph code generator will generate a for you, which internally implements fetch to make the RPC calls to the WunderGraph API. WunderGraphRelayEnvironment : Here's an abbreviated version of the internals const fetchQuery: FetchFunction = async (params, variables) => {
		const { id, operationKind } = params;
		const response =
			operationKind === 'query'
				? await client.query({
						operationName: `relay/${id}`,
						input: variables,
				  })
				: await client.mutate({
						operationName: `relay/${id}`,
						input: variables,
				  });
		return {
			...response,
			errors: response.error ? [response.error] : [],
		};
	}; The function creates JSON-RPC requests from the Operation ID and the variables, no GraphQL is involved at this point. fetchQuery Server-Side Rendering (SSR) with NextJS, Relay and WunderGraph Now that we've configured the Relay Compiler, we can start integrating Relay into our NextJS app, e.g. with Server-Side Rendering (SSR). import { graphql } from 'react-relay';
import { pagesDragonsQuery as PagesDragonsQueryType } from '../__relay__generated__/pagesDragonsQuery.graphql';
import { Dragon } from '@/components/Dragon';
import { fetchWunderGraphSSRQuery } from '@/lib/wundergraph';
import { InferGetServerSidePropsType } from 'next';

const PagesDragonsQuery = graphql`
	query pagesDragonsQuery {
		spacex_dragons {
			...Dragons_display_details
		}
	}
`;

export async function getServerSideProps() {
	const relayData = await fetchWunderGraphSSRQuery<PagesDragonsQueryType>(PagesDragonsQuery);

	return {
		props: relayData,
	};
}

export default function Home({ queryResponse }: InferGetServerSidePropsType<typeof getServerSideProps>) {
    return (
        <div>
            {queryResponse.spacex_dragons.map((dragon) => (
                <Dragon key={dragon.id} dragon={dragon} />
            ))}
        </div>
    );
} Render as you fetch with Vite, Relay, and WunderGraph Here's another example using Vite with Render-as-you-fetch: import { graphql, loadQuery } from 'react-relay';
import { getEnvironment, useLiveQuery } from '../lib/wundergraph';
import { Dragon } from './Dragon';
import { DragonsListDragonsQuery as DragonsListDragonsQueryType } from '../__relay__generated__/DragonsListDragonsQuery.graphql';

const AppDragonsQuery = graphql`
	query DragonsListDragonsQuery {
		spacex_dragons {
			...Dragons_display_details
		}
	}
`;

const dragonsListQueryReference = loadQuery<DragonsListDragonsQueryType>(getEnvironment(), AppDragonsQuery, {});

export const DragonsList = () => {
	const { data } = useLiveQuery<DragonsListDragonsQueryType>({
		query: AppDragonsQuery,
		queryReference: dragonsListQueryReference,
	});

	return (
		<div>
			<p>Dragons:</p>
			{data?.spacex_dragons?.map((dragon, dragonIndex) => {
				if (dragon) return <Dragon key={dragonIndex.toString()} dragon={dragon} />;
				return null;
			})}
		</div>
	);
}; Conclusion Your key takeaway should be that GraphQL and Relay bring a lot of value to the table. Together with WunderGraph, you can build modern full-stack applications on top of three solid pillars: Collocation of components and data requirements Decoupled re-usable components using Data Masking Compile-time Validation & Security What's more, with this stack, you're not really limited to just GraphQL APIs and React. It's possible to use Relay with REST APIs, or even SOAP, and we're also not limited to React, as Relay is just a data-fetching library. If you want to learn more about WunderGraph, check out the . documentation Also published here. : This is really just the beginning of our journey to make the power of GraphQL and Relay available to everyone. Stay in touch on or join our Community to stay up to date, as we're soon going to launch something really exciting that will take this to the next level. One more thing Twitter Discord

Why You Should Relay (Really👀) Give GraphQL Another Chance

1 Auto Recording Amazon IVS Live Streams to S3 2 Archiving Web Chat Messages with Amazon IVS Chat Logging 3 Amazon IVS Live Stream Playback with Chat Replay In our last few posts, we've looked at how to auto-record Amazon Interactive Video Service (Amazon IVS) live streams to Amazon S3, and how to log messages sent to an Amazon IVS chat room (see links above). In this post, we'll bring these two concepts together to complete the user experience and create on-demand playback of past live streams with full chat replay. As seen in our last post, chat messages that are logged to the logging destination include a GMT based timestamp representing the date and time that the event was posted by the Amazon IVS chat room. To accomplish a true on-demand replay of a live stream complete with interactive chat replay of a message at the closest moment in time possible, we need to obtain a regular stream of GMT based timestamps from the recorded stream that we can use to determine what chat messages should be visible at any given point in time in the stream playback. There's not currently a documented source that provides this information, but let's poke around with the Amazon IVS and see if we can find something that will help us out with this task. player SDK Amazon IVS Stream Metadata When trying to solve this problem, my first thought was to take a look at the metadata associated with a live stream to see if there is any valuable information hidden within it. Thankfully, there does appear to be a value in the regular stream of metadata that can be used for our chat playback purposes. In my testing, each stream contains ID3 metadata that appears to be injected by the Amazon IVS transcoding process. These ID3 tags contain a helpful timestamp that we can use to help with chat replay. To listen for these events, we can attach a handler that listens for the event type. This event type documented, but the don't say much about it or make any guarantees about what it may contain. IVSPlayer.MetadataEventType.ID3 is docs ? If you're concerned about using an undocumented feature, you could with the proper timestamp when new messages are posted into your Amazon IVS chat rooms. Keep in mind that there are events via the API. Want to Avoid Undocumented Features inject your own timed metadata into your live stream limits to the size and frequency of posting PutMetadata Listening for Metadata Events Let's set up an Amazon IVS player to playback a recorded stream using the Player SDK. First, we'll include the latest Amazon IVS player SDK via a tag. <script> Check out the blog series . If you have questions on getting started, post a comment on any post in that series (or below)! New to Amazon IVS? Getting Started with Amazon Interactive Video Service <script src="https://player.live-video.net/1.16.0/amazon-ivs-player.min.js"></script> As usual, we'll need to include a element in our HTML markup that will be used for playback. <video> <video id="video-player" muted controls autoplay playsinline></video> Now we can create an instance of the IVS player. I'm hardcoding the URL below, but you can obtain this URL via the method described in this post [todo: link]. const streamUrl = 'https://[redacted].cloudfront.net/ivs/v1/[redacted]/[redacted]/2022/11/17/18/6/[redacted]/media/hls/master.m3u8';
const videoEl = document.getElementById('video-player');
const ivsPlayer = IVSPlayer.create();
ivsPlayer.attachHTMLVideoElement(videoEl);
ivsPlayer.load(streamUrl);
ivsPlayer.play(); As mentioned above, to be useful for this purpose, we need a regular stream of timestamps. To figure out how often the ID3 metadata is received, let's add some timing. First, let's capture a timestamp as soon as the stream starts playing. ivsPlayer.addEventListener(IVSPlayer.PlayerState.PLAYING, (evt) => {
  window.time = Date.now();
}); Next, we'll add the ID3 event listener, log the timing, and reset the timer. ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  const now = Date.now();
  console.log(`${(now - window.time) / 1000} seconds since last event`);
  window.time = now;
}); Now we can start playback and observe the console to see how often the events are fired. In my testing, the events are fired every 1-2 seconds. It's not realtime, but it's probably good enough for most scenarios. Now let's take a look at the event to see what data it contains. window.ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  console.log(evt);
}); When we start playback with the listener above attached, we can see the following information logged to the browser console. This is very interesting info, but a bit cryptic. Based on my testing, seems to be timestamp that we're after. Let's modify the event handler to grab that timestamp and log it. transc_s window.ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  const segmentMetadata = evt.find((tag) => tag.desc === 'segmentmetadata');
  const segmentMetadataInfo = JSON.parse(segmentMetadata.info[0]);
  const timestamp = segmentMetadataInfo['transc_s'];
  const timestampWithMs = timestamp * 1000;
  console.log(timestampWithMs);
  console.log(new Date(timestamp));
}); This produces the following output for my test. If I seek to a random moment in the video, the proper timestamp is always correct. This means that every 1-2 seconds we know a valid GMT timestamp of the moment in time that the event was capture in the stream. This means that we can assume that all chat messages that were sent prior to this timestamp have been posted to the chat and should be visible in the chat container. Retrieving the Chat Logs When my page loads, I can utilize the method outlined in the previous post [todo: link] in this series to retrieve the entire chat log for the stream and render it in the chat container . Since no messages should be visible at the very start of the stream, I'll make sure that they call contain a class that hides them from the user and store a data attribute with the proper timestamp so that I can know which messages should be visible given any timestamp in the stream. <div> window.chatLog = await getChatLogs(logGroupName, chatArn, startTime, endTime);
renderChat(); My function handles posting each message to the chat container. renderChat() const renderChat = () => {
  const chatContainer = document.getElementById('chat');
  window.chatLog.forEach(msg => {
    const msgTemplate = document.getElementById('chatMsgTemplate');
    const msgEl = msgTemplate.content.cloneNode(true);
    const ts = new Date(msg.event_timestamp).getTime() * 1000;
    msgEl.querySelector('.msg-container').setAttribute('data-timestamp', ts);
    msgEl.querySelector('.chat-username').innerHTML = msg.payload.Attributes.username;
    msgEl.querySelector('.msg').innerHTML = msg.payload.Content;
    chatContainer.appendChild(msgEl);
  });
}; Now I can modify the ID3 listener to call a function and pass it the current timestamp. replayChat() window.ivsPlayer.addEventListener(IVSPlayer.MetadataEventType.ID3, (evt) => {
  const segmentMetadata = evt.find((tag) => tag.desc === 'segmentmetadata');
  const segmentMetadataInfo = JSON.parse(segmentMetadata.info[0]);
  const timestamp = segmentMetadataInfo['transc_s'];
  const timestampWithMs = timestamp * 1000;
  replayChat(timestampWithMs);
}); In , I can find all of the chat nodes that contain a timestamp less than or equal to the current timestamp from the recorded stream and show/hide any chat message based on that timestamp. replayChat() const replayChat = (currentTimestamp) => {
  Array.from(document.querySelectorAll('[data-timestamp]')).forEach(node => {
    const chatMsgTs = Number(node.getAttribute('data-timestamp'));
    const isVisible = chatMsgTs <= currentTimestamp;
    if (isVisible) {
      node.classList.remove('d-none');
    }
    else {
      node.classList.add('d-none');
    }
  });
  const chatContainer = document.getElementById('chat');
  chatContainer.scrollTop = chatContainer.scrollHeight;
} At this point, we have achieved the goal of playing back a recorded Amazon IVS live stream with a full chat replay. Summary In this post, we looked at how to combine recorded Amazon IVS live streams with logged chat messages to create an on-demand replay of a stream with properly timed chat messages.

Create On-Demand Past Live Stream Playback w/Full Chat Replay on Amazon IVS

Cree reproducción de transmisiones en vivo pasadas bajo demanda con reproducción completa de chat en Amazon IVS

Créez une lecture de flux en direct passés à la demande avec une relecture complète du chat sur Amazon IVS

Amazon IVS पर ऑन-डिमांड पास्ट लाइव स्ट्रीम प्लेबैक w/Full Chat Replay बनाएं

Amazon IVS でフル チャット リプレイを使用して過去のライブ ストリーム再生をオンデマンドで作成する

Crie reprodução de transmissão ao vivo anterior sob demanda com reprodução completa do bate-papo no Amazon IVS

Tạo Phát lại luồng trực tiếp trước đây theo yêu cầu với Phát lại toàn bộ cuộc trò chuyện trên Amazon IVS

在 Amazon IVS 上创建带完整聊天重播的按需过去直播流媒体播放

A great deal of hype surrounds the impending launch of Apple’s Private Relay, a browser-based encryption boost that is set to be offered as a “public beta” to iCloud+ subscribers this fall. Current iCloud subscribers will automatically be upgraded to iCloud+ at no charge. Private Relay will automatically be downloaded to iPhones or other Apple iCloud-enabled devices and will become available on forthcoming iOS and MacOS devices. While more is unknown than is known about Apple’s newest addition, many non-technical users of Apple products might breathe a collective sigh of relief that Apple seems to be doing everything they can to add greater privacy in a world that seems less than secure. The Advantages of Private Relay If Apple’s implementation of this new feature actually lives up to its lofty promises, then Private Relay will offer a high level of privacy, both on the provider side and on the user side. Private Relay is designed to encrypt all information about the user, such as who you are, where you are, and what websites you visit. They’re planning to do such a thorough job of this that even Apple won’t know who you are. This is unlike traditional Virtual Private Network (VPN) providers, which typically have this information. VPNs first became available for web users more than twenty years ago, and many savvy Internet browsers use them to hide their IP address. VPNs have long allowed people to ward off hackers, keep their identity totally private, and even watch Netflix movies in countries that have banned certain content. Lately, companies have also gotten on the privacy bandwagon—especially post-pandemic, when many of their employees have been working remotely from home. Private Relay, although not technically a VPN, seems to be Apple’s way of getting in on the trend toward greater privacy. The real advantage of Private Relay is that it will have a very simple interface that is understandable enough for even a general, non-techie audience. Since it is built right into the operating system for iCloud+ subscribers, Apple customers will trust it to keep them safe and secure while browsing. Also, it may very well work better than a third-party VPN application used on Apple and may not slow down the speed of your connection like VPNs sometimes can. Last, it’s free for iCloud+ users. The Disadvantages of Private Relay From a strategic perspective, Private Relay, at least in its first iteration, won’t be totally effective for all users. First of all, this feature allows you to choose your general IP address or simply choose an IP address somewhere in your country and/or time zone. Because of this, Private Relay will not allow you to geo-hop, meaning the service still uses your approximate existing geographic location, making it more impossible to do things like stream Netflix content from a different country. Apple has a vested interest in working cooperatively with content providers and has no desire to estrange them by infringing on the regional blocking schemes already in place. Also, since there is no change of region, and Apple will transfer the information about the user’s region to the website, advertisers will still be able to target a user based on their location. Secondly, this feature will not be available in all countries. Apple has already announced that they will comply with local regulations and so will be unable to offer Private Relay in China, Belarus, Colombia, Egypt, Kazakhstan, Saudi Arabia, South Africa, Turkmenistan, Uganda, the Philippines, and Russia. Third, even though Apple execs have been depicting Private Relay to be a plausible runner-up to commercial VPNs, it is not in fact a VPN and thus has diminished functionality. For instance, this encryption boost will only perform the function of privacy and anonymity. Other functions are not clear, and we don’t yet know exactly how this interface will work. Because of this, users who want to rely on Private Relay as though it’s a true VPN might be opening themselves up to risk. In addition, there will be almost no settings for users to choose from. That is, it will be almost impossible to adjust the specific condition of how Private Relay works for individual users and their needs. Time will tell what risks might occur from this initial set-up, and not all cases will be tested immediately and will need to be fixed gradually. Fourth, Private Relay will only be available for Safari users, so those who use Chrome or Firefox will be unprotected. This means Private Relay is not a one-stop-shopping solution for privacy and does not encrypt data across all apps on your device. Many people might not realize this and think they are more fully protected than they actually are. In addition, this service is only available for those with iCloud subscriptions. Yet another disadvantage of this encryption service is that Apple surely knows everything about its users. Since many users are worried about privacy and staying anonymous online, many commercial VPN providers solve this problem by not physically storing logs. If Apple does store information about its users, then what happens if the government asks for information about customers? Does Apple need to provide this data? Will Private Relay Kill the VPN Market? From my standpoint as the founder and CEO of a company that focuses on privacy, security, and safety, I believe that Apple’s Private Relay will not kill the VPN market, but it could affect some of the market players and will surely create more competition. Although this feature can provide some anonymity for users, and should be easy enough to turn on and off, making you anonymous/not anonymous, it still will be unusable in countries where privacy is most at risk (like China). In such cases, VPNs will remain the most effective solution. Also, since the service is so new, and a lot is unknown about how it will work, we can’t yet be sure about the level of anonymity promised to Apple’s customers. As such, the VPN providers still wear the pants in the privacy household. Private Relay will not be a negative addition to Apple’s features and might prove helpful for those not particularly tech savvy. However, those who want fuller protection might want to combine this service with a traditional VPN. The Future for VPN Providers Now That Apple Is In the Game Apple’s release of this built-in virtual private network might trigger some companies—like tech behemoth Cisco, for instance—to release a full security system. Other OS vendors could also think to get into the game, creating similar systems for themselves. If other companies begin offering their versions of security services, then current VPN providers will face greater competition in the years ahead. In general, however, Private Relay should not hurt the VPN industry that drastically. For those who truly need a VPN, the set of features offered by Apple’s new offering will not be enough. Also, there’s bound to be some overlap in emerging technologies. For instance, storing passwords for browsers did not hurt the market caps of top password management companies, even though almost all browsers have this option now.

How Apple’s Upcoming Private Relay Feature Will Affect End Users and The VPN Market

This short tutorial explains how to replay the captured browser’s network offline using Python. Once you have captured the browser’s network as a HAR file, you can set up a proxy server in order to provide the responses for certain requests which exist in the HAR. Let’s start with creating a dictionary from the HAR. json
dict_url_response = {}
fob = open( , )
data = json.load(fob)
fob.close()
entries = data[ ][ ] entry entries:
    url = entry[ ][ ]
    response = entry[ ]
    dict_url_response[url] = response import "har/cap1.har" "r" "log" "entries" for in "request" "url" "response" Now create a class which we will be using for interception in the proxy. mitmproxy.net.http Response, Headers :
            url = flow.request.url
            har_response = dict_url_response[url]
            text = har_response[ ][ ]
            byt = str.encode(text)
            list_headers = [] obj har_response[ ]:
                list_headers.append((str.encode(obj[ ]), str.encode(obj[ ])))
            headers = Headers(list_headers)
            response = Response(
                http_version = str.encode(har_response[ ]),
                status_code = har_response[ ],
                reason = str.encode(har_response[ ]),
                headers = headers,
                content = byt,
                trailers = ,
                timestamp_start = ,
                timestamp_end = ) KeyError:
            print( )
            headers = Headers([
                ( , ),
            ])
            response = Response(
                http_version = str.encode( ),
                status_code = ,
                reason = str.encode( ),
                headers = headers,
                content = str.encode( ),
                trailers = ,
                timestamp_start = ,
                timestamp_end = )
        flow.response = response from import : class Interception : def request (self, flow) try "content" "text" for in "headers" "name" "value" "httpVersion" "status" "statusText" None 0. 1. except "Request URL not found in HAR" b'Content-Type' b'text/plain; charset=utf-8' "http/2.0" 200 "OK" "Request URL not found in HAR\n" None 0. 1. Finally, we just have to start the MITM proxy with the interception. mitmproxy.options Options mitmproxy.proxy.config ProxyConfig mitmproxy.proxy.server ProxyServer mitmproxy.tools.dump DumpMaster threading asyncio
intercept = Interception() asyncio.set_event_loop(loop)
    m.run_loop(loop.run_forever)
options = Options(
    listen_host= ,
    listen_port= ,
    http2= )
m = DumpMaster(
    options,
    with_termlog= ,
    with_dumper= )
m.addons.add(intercept)
config = ProxyConfig(options)
m.server = ProxyServer(config)
loop = asyncio.get_event_loop()
t = threading.Thread(
    target=thread_func,
    args=(loop, m)
)
t.start() from import from import from import from import import import : def thread_func (loop, m) '0.0.0.0' 8080 True True True The is used in order to keep the proxy server running. The proxy server listens on . thread_func 127.0.0.1:8080 In order to test the HAR replay you have to make the browser go through the proxy server, e.g. for Chrome the command would be: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --proxy-server=127.0.0.1:8080 Sometimes the requests that are captured in the HAR are gzip or brotli compressed. In this GitHub repository such cases are taken into account: https://github.com/endgame-is-on/HAReplay Also published on Medium's endgame-is-on

Follow These Steps To Replay Browser’s Network Offline

Article written by Vincent Le Gallic - CTO @Rockside If you are a developer or a network user, you have probably already encountered the issue of stuck transactions. It could be described as an endless waiting for processing. Including a transaction in a block can give a headache. As the blocks’ size is limited, miners will prioritize transactions with the highest gas price. Photo by Arron Choi on Unsplash How do we end up in this situation, and why, by a chain reaction, does this obstruct every new transaction sent with the same account? What can a transaction relayer bring to prevent that? Why can it be hard to include transactions in a block? Quick reminder: transactions on Ethereum are scheduled by a number associated with the transaction called a "nonce". Each account on the chain has a "nonce" which is incremented with each transaction. Thus, the first transaction done by an account will have the nonce 1, and the third will have the nonce 3. Transactions must be executed in the right order of nonces: the third transaction made by an account cannot be included in a block and executed before the second transaction. If several accounts compete to execute their transaction as soon as possible, the will suddenly increase. Imagine a scenario where an account has submitted a transaction with a gas price too low, the transaction will then be stuck by the inflow of more profitable transactions for minors. gas price As the account counter (nonce) is no longer incremented, all account transactions issued since the incident are also stuck. To get out of this situation within a reasonable time, you must either cancel or replace the stuck transaction with a new one using the same nonce and a higher gas price. The operation must be repeated while increasing the gas price until the transaction is included in a block. Finally, except if you can force a sequential use of the account (which is impossible if the transactions are issued from a user's wallet for example), you will have to manage all the pending transactions of the account with a gas price potentially decorrelated from the new market price. Made famous by Cryptokitty and the ICOs, this challenge has now to be faced by the decentralized finance protocols. Fortunately, these problems remain occasional on Ethereum. But when they do occur, it is a critical bug for the application. On the user side, the frustration is similar to what you feel when a payment does not work on an e-commerce website. On the application side, in addition to the support it generates, this generally results in a loss of income. Users and developers have inherited an inextricable problem on Ethereum 1.x. This probably contributed to tarnishing the image of the protocol. It also showed that the community can gather to propose improvements,  such as the use of meta-transactions. A meta-transactions based solution Photo by on Brett Jordan Unsplash The meta-transaction concept allows users to interact with the blockchain with only a pair of public/private keys. This mechanism is often used to send gasless transactions, that is to say, a transaction sent from an account (EOA) without Ether. On the user side, sending a meta-transaction is similar to sending a standard transaction (from, to, value ... and signature) except that instead of sending it directly to the Blockchain, it sends the meta-transaction to a third party who will take care of the gas. This third party builds a new transaction that contains the meta-transaction and sends it to a smart contract proxy (it can also be a proxy function in a contract). The contract checks the validity of the meta-transaction (thanks to its signature) before executing it. This mechanism is more and more used by applications to improve users’ onboarding. It allows them to sponsor the gas for their users while keeping the benefits of a decentralized system (non-corruptibility, non-repudiation, etc.). You might wonder: if the application can relay the transactions by itself for its users, when and why do we need a relayer? The dilemma between “do it yourself” or “buy a solution” is well known to developers and the answer always depends on the context. Pizza Hut continues to deliver its pizzas when the majority of restaurants use Uber Eat or Deliveroo. Well as it is the case for food delivery, build and maintain relay infrastructures is very complex and costly. Indeed, more and more applications choose to integrate APIs to relay their transactions instead of doing everything by themselves. Send your meta transactions, the relayer takes care of the rest! To keep its promise, and in addition to improving the path of transactions in the blockchain, relayers can facilitate the implementation of gasless transactions. How does a relayer improve the transaction outcome in the blockchain? As explained above, for a given account, transactions must be ordered and validated sequentially. For example, if you want to send 3 transactions, transaction #3 will remain pending until number 1 and number 2 have been processed. The number of pending transactions for an account is limited by the node (on Geth, the default limit is 64 for instance). Beyond this limit, the node can arbitrarily delete transactions from its queue. To avoid these limitations, a relayer can dispatch its meta-transactions and send them from multiple accounts. Indeed, if you have three accounts, the number of transactions that can be pending on a node goes from 64 to 192 when using Geth. In addition, when a transaction is stuck on one of the accounts, the relayer can displace it to one of the two remaining accounts and thus keep sending its transactions. Another thing to consider is the nonce system used by the relayer smart contract. The nonce system is used to avoid a replay attack. The chosen nonce system solution will impact the way transactions are processed. For instance, if you wish to anchor certificates, you want to be able to send a large number of transactions simultaneously and the order doesn’t matter. Indeed, some applications might require to send transactions sequentially and others simultaneously. Depending on the usage, and the volume of transactions, some cases might require to optimize the cost of storing a replay attack protection system, where others might not need such complex implementations. Relayers allow developers to get rid of these complex issues by providing simple and ready-to-use services. How does a relayer facilitate the implementation of gasless transactions? It is necessary to have Ether on your account if you want to change a smart contract or send a transaction or do anything on Ethereum. This makes user onboarding and user experience painful. There is no way to have a high conversion rate when the users have to buy Ether before being able to use the application. To overcome that, some applications simply offer to pay gas on behalf of their users. This approach is often disregarded by developers as it is far from the philosophy of the protocol, which aims to guarantee independence in the network. In such a traditional model, the application considers gas as an infrastructure cost, just like CPU consumption on AWS for instance. Since income generation is generally correlated to the use of smart contracts, it is an economically viable model in most cases. The application and the users might also agree with each other on-chain for an automatic reimbursement of gas costs implied. With the emergence of DeFi's services, more and more users own tokens without Ether. And some systems allow their users to pay for their transactions with an ERC20 token. The application can also distribute its own tokens to its users at the time of registration. This mechanism is comparable to the distribution of free coupons that can only be used on application contracts. A relayer will help to put in place the right gas reimbursement strategy without requiring heavy investments in research and development. How to use a relayer? Ideally, all of these services should work transparently for the developer, that is to say without modifying their smart contracts or the code of their application. Relay services are usually exposed via a classic web API. They can also be available as a proxy in front of a "web3 provider" between the application and the node to facilitate their use with libraries like web3js. Finally, the design of the solution must allow its users to verify that the relayer can neither replay, nor modify the meta-transaction data. Actually, the relayer function is quite similar to a node waitlist, but it adds several essential features for live applications on the Mainnet. Is there a standard for relayers? Photo by Daniel Jensen on Unsplash Decentralization, privacy, security, simplicity, etc. Choosing how to relay a transaction on Ethereum implies taking into account a lot of criteria and again, depending on the context, different choices have to be made. GSN (Gas Station Network) is one of the most visible initiatives in this area. This solution allowed the construction of a network of decentralized relayers. When using a relayer hub, the players that are ready to process transactions for a commission can compete against one another. GSN requires significant integration efforts. It is a very suitable solution when the use of a P2P relay network is a prerequisite. To understand why there is no consensus around a standard, let's compare two wallets: MetaMask and Argent.xyz. The first manages the identity of its users with an EOA, while the second uses smart contracts. Naively implementing a “relay proxy” on transactions sent from MetaMask is more complex than what it looks like. The use of msg.sender in the contracts used by the application would be banned because it would contain the address of the relayer instead of the user’s public address. On the other hand, Argent.xyz uses an account contract that must be deployed for each user. This is an additional cost for Argent.xyz but the verification and relay of transactions are done directly in this contract, without the need for any modification on the destination contracts. Application contracts can also directly verify and execute the signature of meta-transactions by implementing two functions. One to protect against replay attacks and the other to verify and execute the transaction. This solution has many advantages but remains unusable for already deployed contracts. To go further on the different relay philosophies on Ethereum, recently proposed the idea of a “Minimal And Extensible Meta Transaction Forwarder” . This EIP shows how huge this topic is and how much the debate is active in the community. @wighawag # 2585 Conclusion Applications that require large transaction volumes systematically pay way too expensive network commissions. And this extra cost does not prevent them from having to intervene when a transaction is stuck. For smaller and under construction applications, building and maintaining a relay infrastructure requires too much investment. PSPs (Payment Service Providers) like Paypal or Stripe have made it easier for developers to accept payments on the Internet. And even if Ethereum allows you to remove or limit the power of third parties, this protocol must acquire gateways to simplify its usage. The power of relayers is limited “by design” by meta-transactions, thus they perfectly meet the current challenges of developers on Ethereum. At Rockside.io, we decided eight months ago to build the best relayer on Ethereum. We already process hundreds of transactions daily for startups and large accounts and thus we know that the need is real among developers. The increasing use of relayers also shows that the relationship between companies and the blockchain is evolving. We have moved from a desire to understand to a desire to actually use the technology.

What Is A Transaction Relayer And How Does It Work?

¿Qué es un repetidor de transacciones y cómo funciona?

Horrible aviation accidents and incidents occur all over the world annually. After a plane crashes or explodes, usually, one of the most important issues is finding the plane's flight recorder. Everyone is hoping it to be still intact and its stored data be retrievable. Unfortunately, this data is the only clue to discover the secret of the plane crash in many cases. In this article, we will show that such important and vital data can be sent to one or more blockchain networks during flight, in addition to storing on the plane's black box. Of course, the data encryption is done inside the aircraft and the blockchain technology will ensure the safety and accuracy of the stored data. This article was written in May 2020 by and in two editions in English and Persian. Somayyeh Gholami Mehran Kazeminia Persian Article Backup of the flight recorder's data A black box (flight recorder) is a device used for airplanes, ships, and helicopters, and despite its name, it has a bright orange color to make it easier to find after a crash. The flight recorder of aircraft is usually located at the tail of the aircraft, as this area is a low risk of collision. The aircraft's flight recorder has two parts; the first is the flight data recorder (FDR) which records and stores data about instructions sent to the aircraft's electronic system. The second part is the cockpit voice recorder(CVR) in the cockpit, which stores the pilot's conversations, wireless communications, and other types of sounds in the cockpit. The subject matter of this article is merely the feasibility study to create a backup on blockchain networks and there is no difference between the types of flight recorder data to do so in practice. In other words, if this proposal put into action, all information generated during the flight will be encrypted and immediately sent to blockchain networks in separate blocks. In this case, the chain of blocks is formed only based on the arrival time on the blockchain network, and later on, it is impossible to change or tamper with the contents of these blocks. Basically, in a blockchain network, the hashed contents of each block will be placed inside the following block, and with the slightest change in the contents of each block, the same block and all subsequent blocks will be invalid, and therefore no flaw or violation is possible. For more information on this topic, you can refer to the blockchain articles. The feasibility to create a backup It's been several years that airline passengers can use wifi to connect the internet easily during the flight. While the plane in the sky, the airline passengers check their email or stock market prices, post on social media, or even trade Bitcoin. But still, the file of the audio environment of the cockpit stored only and only in the flight recorder. That makes no sense at all because for whatever reason that plane crashed, the plane manufacturer, its owner, the country where the plane crashed, and plane occupants' families should be waiting to retrieve the flight recorder's information to find out the main cause or the culprit of the plane crash. Unfortunately, in many cases, the black box data is damaged when the plane crashed or exploded. In some cases, falls occur in impassable areas or deep oceans so it's arduous to find a black box. There are also often legal, political, and even military problems with finding and retrieving the black box information. So really, why this crucial information not sent to a safe place other than inside the plane? In the following, we will examine the answers to the likely arguments against this proposal. A- Only the moment of the crash is important, and when it crashes, the Internet is likely to shut down. That's why the backup will be incomplete and doesn't matter much. This argument is not compelling. A review of several recent crashes shows that from the beginning of the flight, all the pilot's conversations, the control tower, all the instructions sent by the pilot for the system, etc. can be of paramount importance. For this reason, in addition to complying with the protocol, pilots of passenger planes usually turn on the flight recorder manually even before the automatic recording of it started, to record the conversations with the control tower before turning on the aircraft engines. Meanwhile, by utilizing blockchain technology, such information is continuously encrypted in the airplane computers and prepared to be sent as the block. If the airline's internet is disconnected and reconnected intermittently for any reason, it's okay, after reconnecting a  few blocks will be sent with a time lag. But if the Internet would no longer be connected, for instance, when a crash or explosion occurs, one or more of the last blocks might never be sent. This is the main challenge of this approach, and you should keep an internet connection during or even after the crash. Of course, the status quo is maintained by this proposal, and the original version is still on the flight recorder(black box). But with a simple and inexpensive method, we were able to have a pretty complete backup. B- Sending the data out of the aircraft could jeopardize the data security, also the risk of manipulation far outweigh the benefit. This argument cannot be correct either because using blockchain technology, all information encrypted, and has a public and private key. It means, that only the holder of a private key can access confidential information which predetermined who has a private key, for example, the manufacturer or the owner of the aircraft or any other legal entity. Also, as mentioned earlier, no one can change or tamper with the data after storing it on the blockchain network. C- Technically, connecting the plane to the Internet and sending data out continuously is impossible or even costly. The above argument also is not credible at all. Internet service provider companies have made significant progress so far. Rising demand led the world's major airlines in cooperation with technology and telecommunication companies, to provide Wi-Fi Internet on board for a large number of planes. Even, Gogo(inflight internet provider) has recently promised its customers 5G technology, Albeit, some airlines have not equipped yet. There are two ways to connect to WiFi on the Internet. The first method is much like the way cell phones use it. It means that the plane has an antenna under its body and is connected to telecommunication towers located on the ground. The sending and receiving equipment is installed on the same telecommunication towers which serve for mobile phones. The only difference is that the equipment transmits waves to the sky and the planes. Along the way, the plane shifts connection among the nearest telecommunication towers to keep the Internet connection as much as possible and provide it to passengers. Of course, this method has a big problem, for example, if the plane is passing over the oceans and seas, the connection of passengers to the Internet will be cut off. But, the second method is through satellites. The planes are connected to the nearest satellite using an antenna above their bodies. This method has much fewer disconnection and interruption problems. Even, it is well thought out about aerodynamic issues of the antenna above the fuselage and these antennas work well. However, the quality or tariffs of airline internet are never to compete with the regular urban internet, and the regular urban internet will always be faster and cheaper. Nevertheless, today, it's possible to transmit the compressed and encrypted data of the plane to the reliable servers at a low cost. What are we waiting for? Somayyeh Gholami Mehran Kazeminia

Could A Periodic Relay of Flight Data To The Blockchain Make Flights Safer? [Deep Dive]

At the F8 event, Facebook announced a complete overhaul of the Facebook app. The new app is not just a redesign, it’s powered by the latest technology, and built for scalability in order to deliver a better user experience. Facebook has . Just think about it: 2 BILLION 😳. But, Facebook has issues — besides privacy, and misinformation. Indeed, . And we have to admit it, it’s a bit cumbersome in terms of UI, and also regarding how the website is built. For instance, the soon to be . If you want something to compare, it’s a bit like a bad Wordpress theme 🙈 over 2 billion monthly active users the current Facebook is built on legacy infrastructure old Facebook homepage has an uncompressed CSS file size of 2.4 Mb A fresh start with React, GraphQL, and Relay Facebook needed a fresh start in order to get rid of the legacy infrastructure. And that’s how they started to work on technologies such as React, GraphQL, and Relay. The brand new Facebook design presented at F8 2019 is composed of . At the time of writing, React has . So it has a huge community and many websites are built using this technology. I won’t comment it that much here, because the big announcements at F8 were concerning mostly GraphQL and Relay… which are used with React to simplify data fetching. Data fetching is what happens for example when you (the user) opens the Facebook homepage and your timeline loads. But what are GraphQL and Relay? a single webpage app powered by React, GraphQL, and Relay 128,393 stars on Github What is GraphQL? **GraphQL is a declarative query language used for requesting data on a server.**It is agnostic to how you store your data in the backend and provide a unified type-safe layer of all your server data. It is made to be easily queried by multiple clients over time. . Have you wondered why my website loads so fast? It’s because . After clarification on Twitter by , it appears that Gatsby uses GraphQL only for build-time. So . What makes this website fast is that it does behind the scenes such as prefetching, pending navigation, image optimization, and so on. GraphQL is used to power the new Facebook.com I use Gatsby @endiliey GraphQL acts as a data management layer various optimizations By the way, if you want to test a website’s performance you can do this using . It’s a great (and free!) tool provided by Google. Here is my latest audit report: web.dev OK, now back to GraphQL. Here is : an example of the syntax that is included at the end of my blog posts pages export const pageQuery = graphql`
  query BlogPostBySlug($slug: String!) {
    site {
      siteMetadata {
        title
        author
      }
    }
    markdownRemark(fields: { slug: { eq: $slug } }) {
      id
      html
      timeToRead
      frontmatter {
        title
        date(formatString: "MMMM DD, YYYY")
        spoiler
      }
      fields {
        slug
        langKey
      }
    }
  } . GraphQL “provides a complete and understandable description of the data in your API, , makes it easier to evolve APIs over time, and enables powerful developer tools (…) While typical REST APIs require loading from multiple URLs, . Apps using GraphQL can be quick even on slow mobile network connections.” And what about Relay? GraphQL is essentially a query language for your API gives clients the power to ask for exactly what they need and nothing more GraphQL APIs get all the data your app needs in a single request What is Relay? Relay is a JavaScript client used in the browser to fetch GraphQL data. It is built with scalability in mind in order to power complex applications like Facebook. The ultimate goal of GraphQL and Relay is to deliver instant UI-response interactions. Relay is a JavaScript framework developed by Facebook for managing and fetching data in React applications. . So we save network from sending multiple requests by querying the data we need in a single round-trip. A Facebook page contains several elements and React components, which have different data requirements. GraphQL allows to list all the data we need to generate a page in a single top level query But what if we want to use a component (for example a Facebook post) in several pages? We need to make sure that the queries are updated on all the pages where the component appears, otherwise we could end up over-fetching or under-fetching data. There is a sustainability issue, and that’s where Relay comes in. The data requirements for the components are declared inside the components. With Relay, components and their data requirements are no longer separate. This means that the components declare the data that they need. Here is an example for a Facebook post component: function Post(props) {

	const data = useFragment(graphql`
		fragment Post_fragment on Post {
			title
			body
		}
	`);

	return (
		<Title>{data.title}</Title>
		<Body bodu={data.body} />
	);
} Relay helps to make sure that a component has the data that it needs when it renders. So we know what data are needed for any given page, even if the data requirements change over time. In the new Facebook, Relay is used everywhere. Pre-fetching and parallelization of work with GraphQL and Relay With , we: traditional fetching Download the code Render the code while fetching data Render the final content , and this allows faster loading times. Basically, we: GraphQL and Relay allow the parallelization of work with pre-fetching Download the code and… fetch data at the same time Render the final content Deferred queries with Relay . This is particularly useful to render a page like the Facebook news feed where you find a long list of posts, Relay also allows deferred queries because you need to define priorities, in order to define some data as the most critical data that we need. Here is an example of deferred queries with Relay: fragment HomepageData on User {
	name // Most critical data
	first_post { ... } // Most critical data

	...AdditionalData @defer // Less critical data

} By doing so, So hopefully it will be possible to show content sooner. the server can deliver data as soon as possible in separate payloads without having the whole query to be completed. Scheduling delivery of data with data-driven code-splitting There are many types of Facebook posts. They main contain text, pictures, videos, and so on. Components need to know when to render which variation of a post. Generally, we tend to download unnecessary information that we end up not using. It’s a waste of time for the end user… (and a waste of money for Facebook 🙊 ). In order to avoid downloading all the resources upfront, a strategy is needed in order to download resources only when they are need. But this can dramatically hurt page loading performance, and thus the overall user experience. With the traditional lazy fetching, you download the initial resources, and then download the additional resources needed in separate requests. For example, if we use lazy fetching and the first post on the Facebook timeline is supposed to be a video, the additional resources need to render the video will be loaded at the end. How? By modelling the different variations of the UI and describe the types of post a post can be. GraphQL helps as it allows to download the resources needed thanks to queries on matched types. exact Here is an example of queries on matched types: ... on Post {

	... on PhotoPost {
		photo_data // Request photo data if the post is a photo post
	}

	... on VideoPost {
		video_data // Request video data if the post is a video post
	}

	... on SongPost {
		song_data // Request song data if the post is a song post
	}

} But there is one issue here as we still need to wait for the moment we start rendering before we fetch the extra code that will load photos, videos, or songs in our example… Duh! And that’s where Relay comes in. Here is an example: Relay adds data-driven code-splitting. This means that we can specify which component code we will need in order to render the data that matches a specific type. ... on Post {

	... on PhotoPost {
		@module('PhotoComponent.js') // Download the photo component code if the post is a photo
		photo_data // Request photo data if the post is a photo
	}

	... on VideoPost {
		@module('VideoComponent.js') // Download the video component code if the post is a video
		video_data // Request video data if the post is a video
	}

	... on SongPost {
		@module('SongComponent.js') // Download the song component code if the post is a song
		song_data // Request song data if the post is a song
	}

} Thus, we can render the data much quicker. Let’s have a look at an additional example of code splitting with A/B experiments: Here is the old way to do an A/B Experiment: function MyComponent(props) {
	...
	if (InExperiment('AB')) // We determine that we are doing an A/B experiment in the middle of the code
		import('Feature'); 
	...
} And here is the new way to do an A/B Experiment: const Feature = importCond('AB', 'Feature'); // We do a quick check at the beginning of the request to see what the user needs
function MyComponent(props) {
	...
	if (Feature)
		Feature.use();
	...
} Relay local cache **Relay also keeps a local memory cache of the data that we have fetched so far.**So when we need to fetch data from the server, if we have data that is already stored locally, we can reuse it to instantly give feedback to the user when they perform an action and render the page. As more data is fetched from the server we can show more content. Server-Side Rendering Facebook is experimenting with various optimizations on the server side in order to load pages faster. Code size is analyzed for each pages in order to detect opportunities of code-size improvements. Regarding this topic, Facebook showed a tool called JS Graph Explorer. I understand the importance of having such a tool when you scale, but right now I am more interested in GraphQL and Relay 🙃. CSS and Atomic Stylesheets The old Facebook site was sending too much CSS. Over the years, it became really heavy. Remember, an uncompressed size of 2.4 Mb for the homepage 🙈. This what CSS looks like on most websites and the old Facebook: <Component1 classNames=".class1"/>
<Component1 classNames=".class2"/>

.class1 {
	background-color: var(--fds-active-icon);
	cursor: default;
	margin-left: 0px;
}
.class2 {
	background-color: var(--fds-gray-25);
	cursor: default;
justify-self: flex-start;
	margin-left: 0px;
} Here is an example: The problem in the snippets above is that rules are duplicated throughout the stylesheets and that means wasted bytes. Instead, the new Facebook will generate atomic stylesheets, which means that each rules will be defined only once. <Component1 classNames=".classA .classC .classD"/>
<Component1 classNames=".classA .classB .classD .classE"/>

.classA { cursor: default; }
.classB { background-color: var(--fds-active-icon); }
.classC { background-color: var(--fds-gray-25); }
.classD { margin-left: 0px; }
.classE { justify-self: flex-start; } Consequently, . no matter how many components and stylesheets we have on a website, the amount of CSS will plateau at a certain level Loading Experience improved with the new React Suspense component The best practice is to load content is in the order that we read: top-down and left to right. . Historically, it was hard to load content and follow this best practice at the same time, but a new React component called React Suspense will help doing so Let’s say we have a post, and we wrap it in React Suspense boundaries like this… <React.Suspense
fallback={<MyPlaceholder />}> // Loading state
	<Post> // Full content
		<Header />
		<Body />
		<Reactions />
		<Comments />
	</Post>
</React.Suspense> … then . The suspense boundary works like a JavaScript try-catch: React can coordinate if we show the loading state or the full content React will try to render the content. If one of the components from the post hasn’t loaded yet (for example the body with an image)… … then the user will see the loading state with the placeholder. Then, when the content is ready, the loading state is replaced with the final content. React boundaries simplifies how code is loaded. And the good thing is… they can be nested 🔥 So we can create the top-down and top to bottom experience that we are looking for. CSS Variables They can be useful for theming… and especially dark modes 😈 Here is an example of CSS variable: --white: #FFFFFF;
color: var(--white); Conclusion A great User Experience (UX) starts with a great Developer Experience (DX). Companies like Facebook, Google, and Salesforce understand it very well, and they share a lot of their research work and best practices. Technologies like React, GraphQL, and Relay are accessible to everyone and that’s why I am writing about them here. Time will tell, but I think these technologies have a huge community and will power a lot of websites in the future. They have strong advantages. I am already using React and GraphQL a bit, but I am really interested in learning more about Relay and would like to get more experience by implementing it on my website as it will grow in terms of content. I have included links below if you want to dig deeper. If you want more stories like this one, please check out . my blog Sources and links Facebook Relay: Relay · A JavaScript framework for building data-driven React applications Facebook Relay (Github): facebook/relay Article about Facebook’s new design on The Verge: Facebook is redesigning its core app around the two parts people actually like to use Video: F8 2019 keynote in 12 minutes F8 2019 video — Building the new Facebook.com: Facebook for Developers — Building the New facebook.com with React, GraphQL and Relay

GraphQL and Relay: what are they and why do they matter?

Although the Bancor Protocol is unique, you don’t need a degree in quantum computing to understand it. The protocol introduces a new standard for enabling liquidity between tokens through a network of interconnected smart contracts. Each contract, known as a , acts as an on-chain liquidity pool that performs pricing and conversions between any integrated token in the network, with predetermined and foreseeable terms. Bancor “relay” Traditional exchanges work by matching buy and sell orders in a bid/ask system using order books or a matching engine to fulfil trades. When there are enough buyers and sellers of a token, this system generally works well; however, it assumes a given level of volume and interest in a token. If a token has low volume at any time, it not only becomes difficult to buy or sell, but individual transactions can cause unpredictable price swings, reducing a token’s usability and adoption. Because relays don’t rely on matching buyers and sellers, and instead use on-chain “reserves” as always-available liquidity pools, they have the potential to remove a token’s dependency on trade volume and ensure liquidity for tokens. Even low-volume tokens can offer frictionless conversions for their users — in their earliest days or during periods of decreased volume. constant In order to understand how relays work, let’s first consider a thought experiment. Imagine you had to find the fair market value of watermelons priced in terms of grapes. How many grapes equal one watermelon? Cryptocurrency markets face similar issues when converting between tokens. Bancor Protocol suggests a solution for price discovery and token liquidity through the use of relays. Relays are programmed to receive and dispense tokens according to a predetermined formula which continuously measures the supply of tokens staked to the network. To achieve this functionality, a relay maintains two token “reserves”, each holding a specific type of token. Relays adjust the prices of each token in terms of the other, in order to maintain a fixed 50/50 ratio between the two reserves. For example, a relay created with and will allow a user to sell a watermelon to the relay and receive grapes in return. Such a transaction would add a watermelon to the relay’s watermelon reserve, and withdraw grapes from the relay’s grape reserve. In order for the relay to maintain its 50/50 reserve ratio, the relay rebalances prices to the price of the sold token (watermelons) and the price of the purchased token (grapes). This continuous rebalancing is designed to reflect real-time supply and demand for watermelons and grapes in the network. watermelon tokens grape tokens decrease increase Here’s a quick video by explaining this process: EOS Weekly body[data-twttr-rendered="true"] {background-color: transparent;}.twitter-tweet {margin: auto !important;} That time used watermelons & grapes to explain the Bancor Protocol & automated liquidity. 🍉🍇 Full Video: #DeFi #Tokens @eosweekly https://t.co/ZnaT7FxBhq https://t.co/ElzavqYOqB — @Bancor function notifyResize(height) {height = height ? height : document.documentElement.offsetHeight; var resized = false; if (window.donkey && donkey.resize) {donkey.resize(height); resized = true;}if (parent && parent._resizeIframe) {var obj = {iframe: window.frameElement, height: height}; parent._resizeIframe(obj); resized = true;}if (window.location && window.location.hash === "#amp=1" && window.parent && window.parent.postMessage) {window.parent.postMessage({sentinel: "amp", type: "embed-size", height: height}, "*");}if (window.webkit && window.webkit.messageHandlers && window.webkit.messageHandlers.resize) {window.webkit.messageHandlers.resize.postMessage(height); resized = true;}return resized;}twttr.events.bind('rendered', function (event) {notifyResize();}); twttr.events.bind('resize', function (event) {notifyResize();});if (parent && parent._resizeIframe) {var maxWidth = parseInt(window.frameElement.getAttribute("width")); if ( 500 < maxWidth) {window.frameElement.setAttribute("width", "500");}} The amount of liquidity staked in a relay (a metric known as “ ”) depends on how much the liquidity provider deposits in the smart contract. If a user performs a large conversion relative to a token’s liquidity depth, the conversion will cause the price of the desired token to move as the conversion is processed, also known as price “ ”. While slippage is expected in nearly every token conversion (albeit in infinitesimally small amounts for highly liquid tokens), a unique characteristic of Bancor relays is that they pre-calculate a token’s slippage prior to a user submitting a conversion, giving users the ability to see how much of an asset they’ll receive for any conversion with compared to solutions based on order-matching. liquidity depth slippage far greater accuracy Relays are just one implementation of the Bancor Protocol, characterized by their fixed 50/50 reserve ratio. Upcoming blog posts will explore additional implementations of the protocol with different and dynamic reserve ratios. Reserve functions can be designed to favor certain market behaviors or promote certain economic incentives. A “ ” emerges when there are two or more relays connected to one another by holding the same token in one of their reserves. Through transference, if one relay holds tokens A and B, and another relay holds B and C, token A becomes convertible for token C via token B. Liquidity networks allow integrated tokens to be autonomously convertible for one another without the need for a central entity, across an unaffiliated and unlimited community of network users. liquidity network Today more than 140 relays form the Bancor Network, with each relay funded by an independent “liquidity provider” who serves as a node in the network . To on the Bancor Network, a liquidity provider stakes an amount of one type of token (ERC20 or EOS-based) along with Bancor’s Network Token (BNT) in a smart contract. BNT is the mechanism through which in Bancor’s liquidity network, automating on-chain convertibility across 1000s of live token pairs, including . Until now, liquidity providers have collectively staked over $12.7M in ERC20 and EOS tokens to the Bancor Network. set up a relay relays connect cross-blockchain conversions The figure below shows a simple implementation of a liquidity network consisting of only two Bancor relays (Token A and Token B), where the price of each token as well as BNT is set to $1: Token A is converted into Token B by: Sending one Token A to Token A Relay, increasing the Token A supply in the Relay to . 11 As Token A Relay sends one BNT, decreasing the supply of BNT to . 9 BNTs This creates an imbalanced Relay. To balance it, the Relay decreases the price of the sold Token A — setting its price using the Relay’s new token balances . 9(BNT)/11(A) or $0.81 The withdrawn BNT is automatically sent to the Token B Relay, which increases the supply of BNT inside the Token B relay to . 11 BNTs Token B relay sends one Token B to the user, which decreases Token B supply to . 9Bs This once again creates an imbalanced relay. To balance it, the relay increases the price of the purchased Token B to . 11(BNT)/9(B) or $1.22 As shown above, tokens on Bancor their price when they are and when they are , so users know they are always getting a fair price based on real-time token supply and demand. increase purchased decrease sold Since its creation in 2017, Bancor Protocol has enabled billions in conversions for tokens of all sizes, providing automated liquidity through an open and decentralized protocol — similar to how protocols like HTTPS and SMTP unlocked open access to Internet and email services. Using relays, the Bancor Protocol reimagines asset conversions from a human-mediated process to an automated process that occurs fully on the blockchain between a user and a smart contract. In the future, any user will be able to add a token to the Bancor Network via self-service functionality, allowing even crypto beginners to create instantly liquid tokens and tokenize new kinds of online ecosystems — without worrying about creating enough volume or securing listings to ensure liquidity from day one. About The Bancor Protocol is an on-chain liquidity protocol revolutionizing the way people create and share value by enabling constant convertibility between tokens. Conversions via Bancor Protocol are executed against on-chain liquidity pools using automated market makers to price and process transactions without order books or counterparties, allowing for faster, cheaper and more predictable conversions across 9700+ ERC20 and EOS token pairs, including non-custodial conversions between blockchains. Bancor How to get involved with Bancor to the Bancor Network. Add your token Checkout , jump in and contribute code. Github Build a dApp with the . Bancor APIs Support us on . social media . We have new positions posting all the time. Join our team

How Bancor Relays Work

I first wrote a version of this article just over 16 months ago, and it’s pretty impressive how much the GraphQL community has achieved in that time. First of all, the question is no longer Apollo or Relay, but rather Apollo or does one even need a fancy client at all. If you’re just testing the waters with GraphQL and don’t want to change your existing app too much, you can just use in your component like so: really fetch fetch('/graphql', {  method: 'POST',  headers: {    'Content-Type': 'application/json',    'Accept': 'application/json',  },  body: JSON.stringify({query: "{ hello }"})})  .then(r => r.json())  .then(data => console.log('data returned:', data)); The main benefit to adopting a GraphQL client is the cache implementation. Using fetch is fine to begin with, but you don’t want to be using it in an app where users quickly jump between views. In we use Apollo to cache query results — which gives us quite a noticeable boost in performance. How it works in practice: OnlineOrNot User opens a list of their GraphQL applications -> this list gets cached User opens a list of tests -> client has already fetched data about the applications, so it adds the tests to each application User now visits their list of applications again -> no new GraphQL request is made, all results are already in memory Essentially, the more the user clicks around your application, the faster your user experience becomes. On Bundle size One of the biggest complaints I hear about adopting Apollo is the bundle size (Apollo Boost, the “easiest way to get started with Apollo Client” weighs in at 30.7 kB min+gzipped), so luckily there are also alternative lightweight clients to consider: No article on GraphQL clients would be complete without mentioning . Though Amplify does take an ‘everything but the kitchen sink’ approach to features, and you get included with it: AWS Amplify everything Authentication Analytics API GraphQL Client Storage Push Notifications Interactions PubSub Internationalization Cache Thus Amplify may not suit your needs unless you’re building a whole product experience that relies on GraphQL and don’t want to customise your approach. Why I like Apollo Client The setup is considerably easier than Relay — it involves installing one package, and adding the to the root of your React tree. ApolloProvider The API is nice — they have an equivalent to Relay’s QueryRenderer called that does what it says: Query <Query    query={gql`      {        rates(currency: "USD") {          currency          rate        }      }    `}  >    {({ loading, error, data }) => {      if (loading) return <p>Loading...</p>;      if (error) return <p>Error :(</p>;      return data.rates.map(({ currency, rate }) => (        <div key={currency}>          <p>{`${currency}: ${rate}`}</p>        </div>      ));    }}  </Query> It can be used to manage state in your React app — that is, you can directly write to Apollo’s Redux-like store and consume that data in another part of the React tree. Though with React’s new Context API, and React’s best practices of you probably won’t need it. Lifting State Up import React from 'react';import { ApolloConsumer } from 'react-apollo';import Link from './Link';const FilterLink = ({ filter, children }) => (  <ApolloConsumer>    {client => (      <Link        onClick={() => client.writeData({ data: { visibilityFilter: filter } })}      >        {children}      </Link>    )}  </ApolloConsumer>); Downsides to Apollo It’s huge. It weighs in at 10x more than the smallest GraphQL client I’d consider using, and 3x more than urql Quirks Apollo is not without quirks however: Since Apollo uses to build its cache, forgetting to include in your query can cause some interesting bugs and error messages id id Why I dislike Relay Setup The main benefit to using Relay is that doesn't get included in your frontend bundle, saving your user from downloading the whole GraphQL parser - it "pre-compiles" the GraphQL queries at build time. relay-compiler What annoys me about Relay is that it requires a fair bit of work to even add to a project. Just to get it running on the client side, you need to: add a relay plugin to your config .babelrc set up relay-compiler as a yarn script setup a “relay environment” (essentially your own utility to pass data to the relay-runtime), and fetch add components to the React Components you wish to pass your data to QueryRenderer On the server side, you need to: Ensure the IDs your app returns are unique across all of your types (meaning you can’t return nice ID values like , they need to be like ) 1, 2, 3 typename_1, typename_2 Developer Experience The developer experience itself is pretty unpleasant too — needs to run each time you modify any GraphQL query, or modify the schema. In large frontend teams this means teaching everyone to run every time you change branches in Git, since almost all of our work involves fetching data from GraphQL in some way. relay-compiler relay-compiler Quirks Being one of Facebook’s Open Source projects doesn’t necessarily mean issues get fixed quickly. Occasionally, things break in unexpected ways: Using an old version of graphql breaks : relay https://github.com/facebook/relay/issues/2428 Errors don’t get sent via the error object in GraphQL when using QueryRenderer, instead one needs to create an type, and send the errors through the data object: error https://github.com/facebook/relay/issues/1913 Originally published at onlineornot.com on December 15, 2018.

Apollo vs Relay Modern: Which GraphQL Client to consider using in 2019

RxJS for Beginners:  Mastering Observables, Subjects, and Operators for Reactive Programming

Omnity Network, the first fully on-chain Bitcoin asset hub, plans to provide Bitcoin liquidity and security to any connected chain. The Bitcoin interoperability hub, launched after the Bitcoin halving, was the first protocol to support Runes interoperability with its Red Envelope HOPE YOU GET RICH Runes token ($RICH.) Omnity's omnichain hub is built on the Internet Computer (ICP). ICP's Chain Fusion Technology allows Omnity to read and write directly to the Bitcoin network, sidestepping the congestion and high user fees. Ordinal NFT and Runes asset standards have increased Bitcoin's potential as a general-purpose settlement layer, but these assets can bottleneck the Bitcoin network. Omnity says it has solved this problem without compromising security or decentralization. It is now expanding its scope to include Bitcoin staking and shared security to become the "Liquidity and Security Hub of the Bitcoin Ecosystem." Omnity's novelty lies in its ability to achieve a user experience comparable to trust-based bridges without relying on off-chain witnesses or relayers due to its 100% end-to-end on-chain tech stack. As the liquidity and security hub of the Bitcoin ecosystem, Omnity's goal is to support Bitcoin Shared Security Services for execution chains or Layer-2s (L2s) by providing L2s multibillion-dollar-level security at a modest cost. Any end-user-facing, highly usable blockchain that deals with Bitcoin assets and needs to peg security to the Bitcoin Network could then be connected through Omnity. Armed with ICP's Chain Fusion, Omnity acts as the "bond" between the Bitcoin settlement layer and unlimited execution layers, ready to handle massive transactions because ICP is infinitely scalable. Omnity's roadmap includes the launch of Bitcoin Staking in Q3 2024, followed by Bitcoin Shared Security in Q4 2024. Omnity's Service Nervous System (SNS) governance token, $OT, will also be released in Q4, granting voting rights via $OT SNS staking. The SNS framework is the Internet Computer's built-in solution for creating and maintaining decentralized autonomous organizations (DAOs) to govern Dapps. Omnity’s SNS DAO shall implement voting rights for determining protocol upgrades, blockchain connections to the Omnity Interoperability Network, and Bitcoin L2 connections to use Omnity's shared security. "We hope that Bitcoin will be the settlement layer for the world economy because it is a common good. No one can control Bitcoin. It's an impartial and non-abusable settlement layer," said Louis Liu, Founder of Omnity. "Similarly, Omnity is an ‘unopinionated infrastructure.’ We don't care what type of blockchain it is. We care about what our users are willing to use. If it can bring some utility, entertainment, or profit to Bitcoin asset holders, Omnity will direct Bitcoin assets to that blockchain." From a technical perspective, Omnity relies on ICP's Bitcoin integration to bring Bitcoin assets, BTC, or Runes to ICP. A dedicated subnet has made ICP an impartible part of the Bitcoin network. Dfinity Foundation has a world-class cryptography research team that supported the development of Chain Key Cryptography, the cornerstone of ICP and the Bitcoin integration, safeguarding assets worth billions in USD. However, connections to all other blockchains rely fully on the Omnity team's extensive experience with IBC Protocol implementations and on-chain light clients. "As the only team to implement IBC-ICS 28 on Rust/Wasm chains, Omnity has transplanted many kinds of on-chain light clients, such as Tendermint, Substrate, and NEAR light clients, to enable trustless interoperability,” says Liu. Omnity can immediately support Tendermint-based, Substrate-based, and Polygon CDK-based blockchains, with plans to include OP stack-based L2s and others. Omnity Network , the first fully on-chain Bitcoin asset hub, plans to provide Bitcoin liquidity and security to any connected chain. The Bitcoin interoperability hub, launched after the Bitcoin halving, was the first protocol to support Runes interoperability with its Red Envelope HOPE YOU GET RICH Runes token ($RICH.) Omnity Network Omnity Network Omnity's omnichain hub is built on the Internet Computer (ICP). ICP's Chain Fusion Technology allows Omnity to read and write directly to the Bitcoin network, sidestepping the congestion and high user fees. Internet Computer Internet Computer Chain Fusion Technology Chain Fusion Technology Ordinal NFT and Runes asset standards have increased Bitcoin's potential as a general-purpose settlement layer, but these assets can bottleneck the Bitcoin network. Omnity says it has solved this problem without compromising security or decentralization. It is now expanding its scope to include Bitcoin staking and shared security to become the "Liquidity and Security Hub of the Bitcoin Ecosystem." Omnity's novelty lies in its ability to achieve a user experience comparable to trust-based bridges without relying on off-chain witnesses or relayers due to its 100% end-to-end on-chain tech stack . As the liquidity and security hub of the Bitcoin ecosystem, Omnity's goal is to support Bitcoin Shared Security Services for execution chains or Layer-2s (L2s) by providing L2s multibillion-dollar-level security at a modest cost. 100% end-to-end on-chain tech stack 100% end-to-end on-chain tech stack Any end-user-facing, highly usable blockchain that deals with Bitcoin assets and needs to peg security to the Bitcoin Network could then be connected through Omnity. Armed with ICP's Chain Fusion, Omnity acts as the "bond" between the Bitcoin settlement layer and unlimited execution layers, ready to handle massive transactions because ICP is infinitely scalable. Omnity's roadmap includes the launch of Bitcoin Staking in Q3 2024, followed by Bitcoin Shared Security in Q4 2024. Omnity's Service Nervous System (SNS) governance token, $OT, will also be released in Q4, granting voting rights via $OT SNS staking. The SNS framework is the Internet Computer's built-in solution for creating and maintaining decentralized autonomous organizations (DAOs) to govern Dapps. Omnity’s SNS DAO shall implement voting rights for determining protocol upgrades, blockchain connections to the Omnity Interoperability Network, and Bitcoin L2 connections to use Omnity's shared security. Service Nervous System (SNS) Service Nervous System (SNS) "We hope that Bitcoin will be the settlement layer for the world economy because it is a common good. No one can control Bitcoin. It's an impartial and non-abusable settlement layer," said Louis Liu, Founder of Omnity. "Similarly, Omnity is an ‘unopinionated infrastructure.’ We don't care what type of blockchain it is. We care about what our users are willing to use. If it can bring some utility, entertainment, or profit to Bitcoin asset holders, Omnity will direct Bitcoin assets to that blockchain." From a technical perspective, Omnity relies on ICP's Bitcoin integration to bring Bitcoin assets, BTC, or Runes to ICP. A dedicated subnet has made ICP an impartible part of the Bitcoin network. Dfinity Foundation has a world-class cryptography research team that supported the development of Chain Key Cryptography , the cornerstone of ICP and the Bitcoin integration, safeguarding assets worth billions in USD. Dfinity Foundation Dfinity Foundation Chain Key Cryptography Chain Key Cryptography However, connections to all other blockchains rely fully on the Omnity team's extensive experience with IBC Protocol implementations and on-chain light clients. "As the only team to implement IBC-ICS 28 on Rust/Wasm chains, Omnity has transplanted many kinds of on-chain light clients, such as Tendermint, Substrate, and NEAR light clients, to enable trustless interoperability,” says Liu. IBC Protocol IBC Protocol Omnity can immediately support Tendermint-based, Substrate-based, and Polygon CDK-based blockchains, with plans to include OP stack-based L2s and others.

Omnity Network's Fully Onchain Hub Announces Bitcoin Staking and Shared Security

ওমনিটি নেটওয়ার্কের সম্পূর্ণ অনচেইন হাব বিটকয়েন স্টেকিং এবং শেয়ার্ড সিকিউরিটি ঘোষণা করেছে

Der vollständig Onchain-Hub von Omnity Network kündigt Bitcoin-Staking und gemeinsame Sicherheit an

El centro totalmente en cadena de Omnity Network anuncia participación y seguridad compartida de Bitcoin

Le hub entièrement en chaîne d'Omnity Network annonce le jalonnement Bitcoin et la sécurité partagée

ओम्निटी नेटवर्क के पूर्णतः ऑनचेन हब ने बिटकॉइन स्टेकिंग और साझा सुरक्षा की घोषणा की

オムニティネットワークの完全オンチェーンハブがビットコインのステーキングと共有セキュリティを発表

Omnity Network의 완전 온체인 허브, 비트코인 스테이킹 및 공유 보안 발표

Hub Fully Onchain da Omnity Network anuncia piquetagem de Bitcoin e segurança compartilhada

Полностью ончейн-концентратор Omnity Network объявляет о стейкинге биткойнов и общей безопасности

Omnity Network'ün Tamamen Zincir Üzerindeki Merkezi, Bitcoin Staking ve Paylaşımlı Güvenliği Duyurdu

Trung tâm Onchain hoàn chỉnh của Omnity Network công bố đặt cọc Bitcoin và bảo mật chia sẻ

Omnity Network 的 Fully Onchain Hub 宣布推出比特币质押和共享安全

What are DePINs? Decentralized Physical Infrastructure Networks (DePINs) are real-world infrastructures on-chain. In more depth, DePINs offer a community-driven, cost-effective means of scaling projects without relying on traditional, centralized models. They are platforms where organizations and individuals can benefit from higher levels of control over their data and products through decentralized infrastructure. As for the term "DePIN,” this gained prominence in 2023 and continues to grow in mention into 2024. Initially, Web3 was used to reference projects focused on networks (replicating Web2 internet networks, but decentralized) but has since expanded to include all crypto or blockchain work, resulting in the need for this specific terminology. DePIN 101 On a fundamental level, DePINs function as bridges between physical facilities and the blockchain ecosystem. They operate through three main components. These are physical infrastructure controlled by a provider, a middleware connection to the blockchain, and a public ledger. These connections are managed by record-keeping and offering remittances to both the provider and the user.The physical infrastructure could be a smart agriculture system where farmers use IoT (Internet of Things) devices such as soil moisture sensors, weather stations, and crop health monitors to gather data about their fields. The middleware would then relay this information to the blockchain. Then, based on the data provided by the middleware, the blockchain would distribute rewards to the provider and users in the form of tokens. Additionally, for DePINs to operate effectively, four distinct parties must be involved in the network. This includes: Hardware (PRNs & DRNs): a physical component connecting networks to the real world
Hardware operators (Providers): Contributors buying or lending their hardware to the given network
Token: A financial incentive paid out to hardware operators based on data provided by the middleware
Users: DePINs need users who are willing to use and pay for the service The Current DePIN Landscape DePIN projects operate in six core business niches: compute marketplaces, wireless coverage, wholesale data, services marketplaces, energy services, and vertical ad networks. At present, there are several existing projects emerging in all six of these business models, including Filecoin, Helium, Hivemapper, Braintrust, Entheos and Sweatcoin. Out of these six sectors, compute marketplaces are where the most potential is seen, making up the majority of the market capitalization of DePIN crypto projects. Unpacking a DePIN example As we can see from the current DePIN landscape, there are many sectors in which DePINs currently operate. One real-world example that makes sense, at its core, is a decentralized energy grid. The basis for this is that traditional energy grids are often centralized, owned, and operated by utility companies, which can lead to inefficiencies and a lack of flexibility in distribution. Contrastingly, a decentralized energy grid built on blockchain technology could enable peer-to-peer energy trading between consumers and producers. Imagine a scenario where homeowners could sell excess energy to neighbors from their solar panels. This would facilitate more efficient use of renewable energy resources and incentivize individuals and communities to invest in sustainable energy production. By leveraging blockchain and smart contracts, this DePIN could ensure transparent and secure transactions while empowering users to have more control over their energy usage and production. The Flywheel Effect The concept of the flywheel effect is crucial to understanding DePINs potential for network growth and scalability. Unlike traditional models that require massive upfront capital investments, DePINs rely on grassroots efforts and community-driven initiatives to scale. Tokens play their part in these ecosystems by serving as an incentive for the community to contribute to the maintenance of the network. The Flywheel (above) visualizes the different steps involved in this maintenance and also helps to explain how DePIN projects can utilize the flywheel effect to catalyze their network growth.There are several different ways projects can increase the value of their token. For example, a stake-weighted random selection algorithm can be utilized to increase the value of a token, as providers must stake the project's token to get user deal flow. This adds an added incentive for contributors to continue building out the network. Therefore, the native token will increase in price as the network grows, resulting in more rewards for providers and a higher attraction for investors to invest. Fundamentally, this flywheel creates infrastructure networks that get stronger as they get bigger. As explained above, the flywheel effect of DePINs offers an alternative approach to traditional business models that fundamentally makes sense. However, we must consider the obstacles DePINs face in their journey to realizing their potential. The Future of DePINs By leveraging blockchain technology and tokenomics (The Flywheel Effect), DePINs are expected to disrupt existing IoT business models and enable on-chain communities to build innovative decentralized networks and applications. However, some limitations are currently holding DePINs back. There are several architectural considerations for scaling DePIN applications on-chain that need to be addressed if DePINs are going to be the bridge between decentralized technology and the real world. The most significant challenges to overcome are scalability, interoperability, security, and usability issues. The on-chain infrastructure needs to be able to handle a high volume of transactions and data throughput effectively to support the requirements of decentralized physical networks. To then communicate and exchange this data effectively, seamless interoperability with other blockchain networks and traditional systems is required. Robust security mechanisms, including encryption and authentication, are vital to safeguarding sensitive information and ensuring the integrity of DePIN networks. On top of this, DePINs must have systems in place, ensuring the security of external data feeds (oracles) used to verify real-world information and the prevention of Sybil attacks, where malicious actors create fake identities to gain undue influence within the network. A final consideration is that specialized technical knowledge is currently required to participate in a DePIN ecosystem. A more usable interface and intuitive design will be required for further adoption. The future of DePINs relies heavily on collaboration among stakeholders and ongoing technological innovation to address these challenges and unlock their full potential. What are DePINs? What are DePINs? Decentralized Physical Infrastructure Networks (DePINs) are real-world infrastructures on-chain. In more depth, DePINs offer a community-driven, cost-effective means of scaling projects without relying on traditional, centralized models. They are platforms where organizations and individuals can benefit from higher levels of control over their data and products through decentralized infrastructure. As for the term "DePIN,” this gained prominence in 2023 and continues to grow in mention into 2024. Initially, Web3 was used to reference projects focused on networks (replicating Web2 internet networks, but decentralized) but has since expanded to include all crypto or blockchain work, resulting in the need for this specific terminology. DePIN 101 DePIN 101 On a fundamental level, DePINs function as bridges between physical facilities and the blockchain ecosystem. They operate through three main components. These are physical infrastructure controlled by a provider, a middleware connection to the blockchain, and a public ledger. These connections are managed by record-keeping and offering remittances to both the provider and the user. The physical infrastructure could be a smart agriculture system where farmers use IoT (Internet of Things) devices such as soil moisture sensors, weather stations, and crop health monitors to gather data about their fields. The middleware would then relay this information to the blockchain. Then, based on the data provided by the middleware, the blockchain would distribute rewards to the provider and users in the form of tokens. Additionally, for DePINs to operate effectively, four distinct parties must be involved in the network. This includes: Hardware (PRNs & DRNs): a physical component connecting networks to the real world Hardware operators (Providers): Contributors buying or lending their hardware to the given network Token: A financial incentive paid out to hardware operators based on data provided by the middleware Users: DePINs need users who are willing to use and pay for the service Hardware (PRNs & DRNs): a physical component connecting networks to the real world Hardware (PRNs & DRNs): Hardware operators (Providers): Contributors buying or lending their hardware to the given network Hardware operators (Providers): Token: A financial incentive paid out to hardware operators based on data provided by the middleware Token: Users: DePINs need users who are willing to use and pay for the service Users: The Current DePIN Landscape The Current DePIN Landscape DePIN projects operate in six core business niches: compute marketplaces, wireless coverage, wholesale data, services marketplaces, energy services, and vertical ad networks. At present, there are several existing projects emerging in all six of these business models, including Filecoin , Helium , Hivemapper , Braintrust , Entheos and Sweatcoin . Filecoin Filecoin Helium Helium Hivemapper Hivemapper Braintrust Braintrust Entheos Entheos Sweatcoin Sweatcoin Out of these six sectors, compute marketplaces are where the most potential is seen, making up the majority of the market capitalization of DePIN crypto projects. Unpacking a DePIN example Unpacking a DePIN example As we can see from the current DePIN landscape, there are many sectors in which DePINs currently operate. One real-world example that makes sense, at its core, is a decentralized energy grid. The basis for this is that traditional energy grids are often centralized, owned, and operated by utility companies, which can lead to inefficiencies and a lack of flexibility in distribution. Contrastingly, a decentralized energy grid built on blockchain technology could enable peer-to-peer energy trading between consumers and producers. Imagine a scenario where homeowners could sell excess energy to neighbors from their solar panels. This would facilitate more efficient use of renewable energy resources and incentivize individuals and communities to invest in sustainable energy production. By leveraging blockchain and smart contracts, this DePIN could ensure transparent and secure transactions while empowering users to have more control over their energy usage and production. The Flywheel Effect The Flywheel Effect The concept of the flywheel effect is crucial to understanding DePINs potential for network growth and scalability. Unlike traditional models that require massive upfront capital investments, DePINs rely on grassroots efforts and community-driven initiatives to scale. Tokens play their part in these ecosystems by serving as an incentive for the community to contribute to the maintenance of the network. The Flywheel (above) visualizes the different steps involved in this maintenance and also helps to explain how DePIN projects can utilize the flywheel effect to catalyze their network growth. There are several different ways projects can increase the value of their token. For example, a stake-weighted random selection algorithm can be utilized to increase the value of a token, as providers must stake the project's token to get user deal flow. This adds an added incentive for contributors to continue building out the network. Therefore, the native token will increase in price as the network grows, resulting in more rewards for providers and a higher attraction for investors to invest. Fundamentally, this flywheel creates infrastructure networks that get stronger as they get bigger. As explained above, the flywheel effect of DePINs offers an alternative approach to traditional business models that fundamentally makes sense. However, we must consider the obstacles DePINs face in their journey to realizing their potential. The Future of DePINs The Future of DePINs By leveraging blockchain technology and tokenomics (The Flywheel Effect), DePINs are expected to disrupt existing IoT business models and enable on-chain communities to build innovative decentralized networks and applications. However, some limitations are currently holding DePINs back. There are several architectural considerations for scaling DePIN applications on-chain that need to be addressed if DePINs are going to be the bridge between decentralized technology and the real world. The most significant challenges to overcome are scalability, interoperability, security, and usability issues. The on-chain infrastructure needs to be able to handle a high volume of transactions and data throughput effectively to support the requirements of decentralized physical networks. To then communicate and exchange this data effectively, seamless interoperability with other blockchain networks and traditional systems is required. Robust security mechanisms, including encryption and authentication, are vital to safeguarding sensitive information and ensuring the integrity of DePIN networks. On top of this, DePINs must have systems in place, ensuring the security of external data feeds (oracles) used to verify real-world information and the prevention of Sybil attacks, where malicious actors create fake identities to gain undue influence within the network. A final consideration is that specialized technical knowledge is currently required to participate in a DePIN ecosystem. A more usable interface and intuitive design will be required for further adoption. The future of DePINs relies heavily on collaboration among stakeholders and ongoing technological innovation to address these challenges and unlock their full potential.

Demystifying DePINs and More: Bridging Real-World Infrastructure

Real-Time Event Monitoring with Redpanda, OpenTelemetry, and Grafana

Scaling Bitcoin On-Chain with Omnity

Omnity সহ বিটকয়েন অন-চেইন স্কেলিং

Bitcoin On-Chain skalieren mit Omnity

Escalando Bitcoin On-Chain con Omnity

Faire évoluer Bitcoin en chaîne avec Omnity

ओम्निटी के साथ बिटकॉइन को ऑन-चेन स्केल करना

Omnity によるオンチェーンでのビットコインのスケーリング

Omnity로 비트코인 온체인 확장

Escalando Bitcoin On-Chain com Omnity

Масштабирование биткойнов в цепочке с помощью Omnity

Omnity ile Bitcoin'i Zincir Üzerinde Ölçeklendirmek

Mở rộng quy mô Bitcoin trên chuỗi với Omnity

使用 Omnity 在链上扩展比特币

In this blog, I will demonstrate how to get the coverage data for each incoming request on a Python web server built using any web framework. What is Code Coverage? Code coverage is a metric used in software testing to measure the extent to which the source code of a program has been executed during testing. It indicates the percentage of code that has been covered by the test cases. Code coverage analysis helps developers understand how thoroughly their tests exercise the codebase. Code coverage tools are used to collect data on code execution during testing and generate reports showing the coverage metrics. These reports help developers identify areas of the code that are not adequately covered by tests, allowing them to write additional tests to improve coverage and increase confidence in the software's correctness and reliability. What does it mean to get coverage data for each request? Obtaining coverage data for each request coming to a web server offers several benefits: Granular Insights: By capturing coverage data for each request, developers gain detailed insights into which parts of the codebase are executed in response to different types of requests. This level of granularity allows for a deeper understanding of the application's behavior under various conditions.


Identifying Untested Code Paths: Coverage data helps identify areas of the code that are not adequately covered by tests. By analyzing coverage reports, developers can pinpoint specific code paths that need additional testing, ensuring comprehensive test coverage across the entire codebase.


Building deduplication feature: coverage data for each e2e test case can be analyzed to identify duplicate tests and remove them. Obtaining coverage data To obtain the coverage data, we would be using the coverage.py library. coverage.py is mostly used through CLI. But it provides API to use it programmatically. We will define a middleware through which every incoming request would pass. In our "coverage" middleware before passing control to other parts of our application, we will call start function from coverage library. Coverage measurement is only collected in functions called after start() function is invoked, so if this middleware is scheduled to run first then coverage of other middleware would also be captured along with main application code. Once the application returns then we would stop collecting coverage data. We can then fetch the data and further process it. Below is a code snippet for the coverage middleware which can be used in servers built using Flask web framework: import coverage

class CoverageMiddleware:
    def __init__(self, app):
        self.app = app

    def __call__(self, environ, start_response):
        cov = coverage.Coverage(cover_pylib=False)
        cov.start()
        response = self.app(environ, start_response)
        cov.stop()
        result = cov.get_data()
        Write(result)
        return response Here,Writefunction writes the coverage data to a file, say dedupData.yaml, which can then be used to identify duplicate testcases in e2e scenario. Here is the modified sample Python application with middleware and writing logic in place: https://github.com/AkashKumar7902/samples-python/tree/v1.0.0/flask-mongo The repository includes test cases generated by Keploy, which can be replayed using the command keploy test -c "pythonapp.py". Upon successful execution of this command, a dedupdata.yaml file will be generated. This file will contain details of the executed files, including the lines covered, for each test case. Here is a sample dedupdata.yaml: - id: test-1
  executedLinesByFile:
    /home/akash/Desktop/githubrepo/samples-python/flask-mongo/app.py:
    - 33
    - 34
    - 35
- id: test-2
  executedLinesByFile:
    /home/akash/Desktop/githubrepo/samples-python/flask-mongo/app.py:
    - 24
    - 23 Using Coverage data to identify duplicate tests Earlier written dedupData.yaml which contains coverage data for each test case, can be used to identify and flag duplicate test cases by analyzing similar code paths. There are also multiple deduplication features for test cases based on coverage data for Keploy Cloud. Conclusion This is how with very little code change you can collect coverage data for each incoming request and prioritize increasing coverage for the most frequent requests. It can also be used to build a deduplication feature. Reference:**https://coverage.readthedocs.io/en/7.4.1/api.html FAQ's How can coverage data for each request benefit developers? Obtaining coverage data for each request provides granular insights into the codebase's execution under various conditions, helps identify untested code paths, and can be used to build deduplication features for test cases. How can coverage data be obtained in a Python web server? Coverage data can be obtained using the coverage.py library, which provides both CLI and API for collecting coverage metrics programmatically. In a web server, coverage data can be captured using a middleware that wraps around the application logic and collects coverage information for each incoming request. What are some deduplication features for test cases based on coverage data? Deduplication features for test cases based on coverage data may include identifying and flagging duplicate tests by analyzing similar code paths, removing redundant tests, and optimizing test suites for better coverage and efficiency. In this blog, I will demonstrate how to get the coverage data for each incoming request on a Python web server built using any web framework. Python What is Code Coverage? Code coverage is a metric used in software testing to measure the extent to which the source code of a program has been executed during testing. It indicates the percentage of code that has been covered by the test cases. Code coverage analysis helps developers understand how thoroughly their tests exercise the codebase. Code coverage tools are used to collect data on code execution during testing and generate reports showing the coverage metrics. These reports help developers identify areas of the code that are not adequately covered by tests, allowing them to write additional tests to improve coverage and increase confidence in the software's correctness and reliability. What does it mean to get coverage data for each request? Obtaining coverage data for each request coming to a web server offers several benefits: Obtaining coverage data for each request coming to a web server offers several benefits: Granular Insights: By capturing coverage data for each request, developers gain detailed insights into which parts of the codebase are executed in response to different types of requests. This level of granularity allows for a deeper understanding of the application's behavior under various conditions. Identifying Untested Code Paths: Coverage data helps identify areas of the code that are not adequately covered by tests. By analyzing coverage reports, developers can pinpoint specific code paths that need additional testing, ensuring comprehensive test coverage across the entire codebase. Building deduplication feature: coverage data for each e2e test case can be analyzed to identify duplicate tests and remove them. Granular Insights: By capturing coverage data for each request, developers gain detailed insights into which parts of the codebase are executed in response to different types of requests. This level of granularity allows for a deeper understanding of the application's behavior under various conditions. Granular Insights : By capturing coverage data for each request, developers gain detailed insights into which parts of the codebase are executed in response to different types of requests. This level of granularity allows for a deeper understanding of the application's behavior under various conditions. Granular Insights Identifying Untested Code Paths: Coverage data helps identify areas of the code that are not adequately covered by tests. By analyzing coverage reports, developers can pinpoint specific code paths that need additional testing, ensuring comprehensive test coverage across the entire codebase. Identifying Untested Code Paths : Coverage data helps identify areas of the code that are not adequately covered by tests. By analyzing coverage reports, developers can pinpoint specific code paths that need additional testing, ensuring comprehensive test coverage across the entire codebase. Identifying Untested Code Paths Building deduplication feature: coverage data for each e2e test case can be analyzed to identify duplicate tests and remove them. Building deduplication feature: coverage data for each e2e test case can be analyzed to identify duplicate tests and remove them. Building deduplication feature: Obtaining coverage data To obtain the coverage data, we would be using the coverage.py library. coverage.py is mostly used through CLI. But it provides API to use it programmatically. We will define a middleware through which every incoming request would pass. In our "coverage" middleware before passing control to other parts of our application, we will call start function from coverage library. Coverage measurement is only collected in functions called after start() function is invoked, so if this middleware is scheduled to run first then coverage of other middleware would also be captured along with main application code. start start() Once the application returns then we would stop collecting coverage data. We can then fetch the data and further process it. Below is a code snippet for the coverage middleware which can be used in servers built using Flask web framework: Below is a code snippet for the coverage middleware which can be used in servers built using Flask web framework: import coverage

class CoverageMiddleware:
    def __init__(self, app):
        self.app = app

    def __call__(self, environ, start_response):
        cov = coverage.Coverage(cover_pylib=False)
        cov.start()
        response = self.app(environ, start_response)
        cov.stop()
        result = cov.get_data()
        Write(result)
        return response import coverage

class CoverageMiddleware:
    def __init__(self, app):
        self.app = app

    def __call__(self, environ, start_response):
        cov = coverage.Coverage(cover_pylib=False)
        cov.start()
        response = self.app(environ, start_response)
        cov.stop()
        result = cov.get_data()
        Write(result)
        return response Here,Writefunction writes the coverage data to a file, say dedupData.yaml, which can then be used to identify duplicate testcases in e2e scenario. Here, Write function writes the coverage data to a file, say dedupData.yaml, which can then be used to identify duplicate testcases in e2e scenario. Here, Write function writes the coverage data to a file, say dedupData.yaml, which can then be used to identify duplicate testcases in e2e scenario. Here is the modified sample Python application with middleware and writing logic in place: https://github.com/AkashKumar7902/samples-python/tree/v1.0.0/flask-mongo https://github.com/AkashKumar7902/samples-python/tree/v1.0.0/flask-mongo The repository includes test cases generated by Keploy, which can be replayed using the command keploy test -c "pythonapp.py" . Upon successful execution of this command, a dedupdata.yaml file will be generated. This file will contain details of the executed files, including the lines covered, for each test case. keploy test -c "pythonapp.py" dedupdata.yaml Here is a sample dedupdata.yaml: Here is a sample dedupdata.yaml: - id: test-1
  executedLinesByFile:
    /home/akash/Desktop/githubrepo/samples-python/flask-mongo/app.py:
    - 33
    - 34
    - 35
- id: test-2
  executedLinesByFile:
    /home/akash/Desktop/githubrepo/samples-python/flask-mongo/app.py:
    - 24
    - 23 - id: test-1
  executedLinesByFile:
    /home/akash/Desktop/githubrepo/samples-python/flask-mongo/app.py:
    - 33
    - 34
    - 35
- id: test-2
  executedLinesByFile:
    /home/akash/Desktop/githubrepo/samples-python/flask-mongo/app.py:
    - 24
    - 23 Using Coverage data to identify duplicate tests Earlier written dedupData.yaml which contains coverage data for each test case, can be used to identify and flag duplicate test cases by analyzing similar code paths. dedupData.yaml There are also multiple deduplication features for test cases based on coverage data for Keploy Cloud. Conclusion Conclusion This is how with very little code change you can collect coverage data for each incoming request and prioritize increasing coverage for the most frequent requests. It can also be used to build a deduplication feature. Reference:**https://coverage.readthedocs.io/en/7.4.1/api.html Reference: ** https://coverage.readthedocs.io/en/7.4.1/api.html Reference : Reference https://coverage.readthedocs.io/en/7.4.1/api.html FAQ's How can coverage data for each request benefit developers? Obtaining coverage data for each request provides granular insights into the codebase's execution under various conditions, helps identify untested code paths, and can be used to build deduplication features for test cases. How can coverage data be obtained in a Python web server? Coverage data can be obtained using the coverage.py library, which provides both CLI and API for collecting coverage metrics programmatically. In a web server, coverage data can be captured using a middleware that wraps around the application logic and collects coverage information for each incoming request. coverage.py What are some deduplication features for test cases based on coverage data? Deduplication features for test cases based on coverage data may include identifying and flagging duplicate tests by analyzing similar code paths, removing redundant tests, and optimizing test suites for better coverage and efficiency.

Stories, News & Mentions about REULAY

Reulay’s Stories on HackerNoon