So you want to write a sync system for a web app with offline and realtime support? Good luck. You might find the following resources useful.
Database in a browser, a spec (Stepan Parunashvili)
What problem are we trying to solve with a sync system?
The web of tomorrow (Nikita Prokopov)
| <?php | |
| // This script creates a valid push package. | |
| // This script assumes that the website.json file and iconset already exist. | |
| // This script creates a manifest and signature, zips the folder, and returns the push package. | |
| // Use this script as an example to generate a push package dynamically. | |
| $package_version = 2; // Change this to the desired push package version. |
| /* | |
| * MIT License | |
| * | |
| * Copyright (c) 2023-2024 Fabio Lima | |
| * | |
| * Permission is hereby granted, free of charge, to any person obtaining a copy | |
| * of this software and associated documentation files (the "Software"), to deal | |
| * in the Software without restriction, including without limitation the rights | |
| * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell | |
| * copies of the Software, and to permit persons to whom the Software is |
| # N.B. The only tool missing here that is mentioned in the document is `zenmap` | |
| # purely because this image is intended to be run via a CLI and `zenmap` is a GUI | |
| # to `nmap` i.e. one can play around with the tools by running: | |
| # | |
| # $ docker build --name bite_size_networking:latest . | |
| # $ docker run --rm -d --name bsn_test bite_size_networking:latest | |
| # $ docker exec -it bsn_test bash | |
| # | |
| # Alternatively, one can change the `ENTRYPOINT` to `["bash"]` and run: | |
| # |
| CREATE EXTENSION IF NOT EXISTS pgcrypto; | |
| -- Based roughly on: https://github.com/oklog/ulid | |
| CREATE FUNCTION generate_ulid() | |
| RETURNS TEXT | |
| AS $$ | |
| DECLARE | |
| -- Crockford's Base32 | |
| encoding BYTEA = '0123456789ABCDEFGHJKMNPQRSTVWXYZ'; | |
| timestamp BYTEA = E'\\000\\000\\000\\000\\000\\000'; |
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
| version: 2 | |
| jobs: | |
| test: | |
| docker: | |
| - image: circleci/node:10 | |
| working_directory: ~/repo | |
| steps: | |
| - checkout | |
| - restore_cache: | |
| keys: |
