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

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.

REULAY

reulay.com

-- employees

Since n.d.

COMPANY RANKING

REULAY

EVERGREEN INDEX #8344

Representing this company? Click here to claim and customize this page!

Reulay WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

REULAY

reulay.com

-- employees

Since n.d.

COMPANY RANKING

REULAY

EVERGREEN INDEX #8344

RELATED COMPANIESRANK

STORIES ABOUT REULAY

Representing this company? Click here to claim and customize this page!

Reulay WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!