1618518420
In this video I’m gonna show you three Javascript features that you might not know now these features will help you to write better code and will give you a lot of benefits when writing JavaScript code.
#javascript
1653475560
msgpack.php
A pure PHP implementation of the MessagePack serialization format.
The recommended way to install the library is through Composer:
composer require rybakit/msgpack
To pack values you can either use an instance of a Packer
:
$packer = new Packer();
$packed = $packer->pack($value);
or call a static method on the MessagePack
class:
$packed = MessagePack::pack($value);
In the examples above, the method pack
automatically packs a value depending on its type. However, not all PHP types can be uniquely translated to MessagePack types. For example, the MessagePack format defines map
and array
types, which are represented by a single array
type in PHP. By default, the packer will pack a PHP array as a MessagePack array if it has sequential numeric keys, starting from 0
and as a MessagePack map otherwise:
$mpArr1 = $packer->pack([1, 2]); // MP array [1, 2]
$mpArr2 = $packer->pack([0 => 1, 1 => 2]); // MP array [1, 2]
$mpMap1 = $packer->pack([0 => 1, 2 => 3]); // MP map {0: 1, 2: 3}
$mpMap2 = $packer->pack([1 => 2, 2 => 3]); // MP map {1: 2, 2: 3}
$mpMap3 = $packer->pack(['a' => 1, 'b' => 2]); // MP map {a: 1, b: 2}
However, sometimes you need to pack a sequential array as a MessagePack map. To do this, use the packMap
method:
$mpMap = $packer->packMap([1, 2]); // {0: 1, 1: 2}
Here is a list of type-specific packing methods:
$packer->packNil(); // MP nil
$packer->packBool(true); // MP bool
$packer->packInt(42); // MP int
$packer->packFloat(M_PI); // MP float (32 or 64)
$packer->packFloat32(M_PI); // MP float 32
$packer->packFloat64(M_PI); // MP float 64
$packer->packStr('foo'); // MP str
$packer->packBin("\x80"); // MP bin
$packer->packArray([1, 2]); // MP array
$packer->packMap(['a' => 1]); // MP map
$packer->packExt(1, "\xaa"); // MP ext
Check the "Custom types" section below on how to pack custom types.
The Packer
object supports a number of bitmask-based options for fine-tuning the packing process (defaults are in bold):
Name | Description |
---|---|
FORCE_STR | Forces PHP strings to be packed as MessagePack UTF-8 strings |
FORCE_BIN | Forces PHP strings to be packed as MessagePack binary data |
DETECT_STR_BIN | Detects MessagePack str/bin type automatically |
FORCE_ARR | Forces PHP arrays to be packed as MessagePack arrays |
FORCE_MAP | Forces PHP arrays to be packed as MessagePack maps |
DETECT_ARR_MAP | Detects MessagePack array/map type automatically |
FORCE_FLOAT32 | Forces PHP floats to be packed as 32-bits MessagePack floats |
FORCE_FLOAT64 | Forces PHP floats to be packed as 64-bits MessagePack floats |
The type detection mode (
DETECT_STR_BIN
/DETECT_ARR_MAP
) adds some overhead which can be noticed when you pack large (16- and 32-bit) arrays or strings. However, if you know the value type in advance (for example, you only work with UTF-8 strings or/and associative arrays), you can eliminate this overhead by forcing the packer to use the appropriate type, which will save it from running the auto-detection routine. Another option is to explicitly specify the value type. The library provides 2 auxiliary classes for this,Map
andBin
. Check the "Custom types" section below for details.
Examples:
// detect str/bin type and pack PHP 64-bit floats (doubles) to MP 32-bit floats
$packer = new Packer(PackOptions::DETECT_STR_BIN | PackOptions::FORCE_FLOAT32);
// these will throw MessagePack\Exception\InvalidOptionException
$packer = new Packer(PackOptions::FORCE_STR | PackOptions::FORCE_BIN);
$packer = new Packer(PackOptions::FORCE_FLOAT32 | PackOptions::FORCE_FLOAT64);
To unpack data you can either use an instance of a BufferUnpacker
:
$unpacker = new BufferUnpacker();
$unpacker->reset($packed);
$value = $unpacker->unpack();
or call a static method on the MessagePack
class:
$value = MessagePack::unpack($packed);
If the packed data is received in chunks (e.g. when reading from a stream), use the tryUnpack
method, which attempts to unpack data and returns an array of unpacked messages (if any) instead of throwing an InsufficientDataException
:
while ($chunk = ...) {
$unpacker->append($chunk);
if ($messages = $unpacker->tryUnpack()) {
return $messages;
}
}
If you want to unpack from a specific position in a buffer, use seek
:
$unpacker->seek(42); // set position equal to 42 bytes
$unpacker->seek(-8); // set position to 8 bytes before the end of the buffer
To skip bytes from the current position, use skip
:
$unpacker->skip(10); // set position to 10 bytes ahead of the current position
To get the number of remaining (unread) bytes in the buffer:
$unreadBytesCount = $unpacker->getRemainingCount();
To check whether the buffer has unread data:
$hasUnreadBytes = $unpacker->hasRemaining();
If needed, you can remove already read data from the buffer by calling:
$releasedBytesCount = $unpacker->release();
With the read
method you can read raw (packed) data:
$packedData = $unpacker->read(2); // read 2 bytes
Besides the above methods BufferUnpacker
provides type-specific unpacking methods, namely:
$unpacker->unpackNil(); // PHP null
$unpacker->unpackBool(); // PHP bool
$unpacker->unpackInt(); // PHP int
$unpacker->unpackFloat(); // PHP float
$unpacker->unpackStr(); // PHP UTF-8 string
$unpacker->unpackBin(); // PHP binary string
$unpacker->unpackArray(); // PHP sequential array
$unpacker->unpackMap(); // PHP associative array
$unpacker->unpackExt(); // PHP MessagePack\Type\Ext object
The BufferUnpacker
object supports a number of bitmask-based options for fine-tuning the unpacking process (defaults are in bold):
Name | Description |
---|---|
BIGINT_AS_STR | Converts overflowed integers to strings [1] |
BIGINT_AS_GMP | Converts overflowed integers to GMP objects [2] |
BIGINT_AS_DEC | Converts overflowed integers to Decimal\Decimal objects [3] |
1. The binary MessagePack format has unsigned 64-bit as its largest integer data type, but PHP does not support such integers, which means that an overflow can occur during unpacking.
2. Make sure the GMP extension is enabled.
3. Make sure the Decimal extension is enabled.
Examples:
$packedUint64 = "\xcf"."\xff\xff\xff\xff"."\xff\xff\xff\xff";
$unpacker = new BufferUnpacker($packedUint64);
var_dump($unpacker->unpack()); // string(20) "18446744073709551615"
$unpacker = new BufferUnpacker($packedUint64, UnpackOptions::BIGINT_AS_GMP);
var_dump($unpacker->unpack()); // object(GMP) {...}
$unpacker = new BufferUnpacker($packedUint64, UnpackOptions::BIGINT_AS_DEC);
var_dump($unpacker->unpack()); // object(Decimal\Decimal) {...}
In addition to the basic types, the library provides functionality to serialize and deserialize arbitrary types. This can be done in several ways, depending on your use case. Let's take a look at them.
If you need to serialize an instance of one of your classes into one of the basic MessagePack types, the best way to do this is to implement the CanBePacked interface in the class. A good example of such a class is the Map
type class that comes with the library. This type is useful when you want to explicitly specify that a given PHP array should be packed as a MessagePack map without triggering an automatic type detection routine:
$packer = new Packer();
$packedMap = $packer->pack(new Map([1, 2, 3]));
$packedArray = $packer->pack([1, 2, 3]);
More type examples can be found in the src/Type directory.
As with type objects, type transformers are only responsible for serializing values. They should be used when you need to serialize a value that does not implement the CanBePacked interface. Examples of such values could be instances of built-in or third-party classes that you don't own, or non-objects such as resources.
A transformer class must implement the CanPack interface. To use a transformer, it must first be registered in the packer. Here is an example of how to serialize PHP streams into the MessagePack bin
format type using one of the supplied transformers, StreamTransformer
:
$packer = new Packer(null, [new StreamTransformer()]);
$packedBin = $packer->pack(fopen('/path/to/file', 'r+'));
More type transformer examples can be found in the src/TypeTransformer directory.
In contrast to the cases described above, extensions are intended to handle extension types and are responsible for both serialization and deserialization of values (types).
An extension class must implement the Extension interface. To use an extension, it must first be registered in the packer and the unpacker.
The MessagePack specification divides extension types into two groups: predefined and application-specific. Currently, there is only one predefined type in the specification, Timestamp.
Timestamp
The Timestamp extension type is a predefined type. Support for this type in the library is done through the TimestampExtension
class. This class is responsible for handling Timestamp
objects, which represent the number of seconds and optional adjustment in nanoseconds:
$timestampExtension = new TimestampExtension();
$packer = new Packer();
$packer = $packer->extendWith($timestampExtension);
$unpacker = new BufferUnpacker();
$unpacker = $unpacker->extendWith($timestampExtension);
$packedTimestamp = $packer->pack(Timestamp::now());
$timestamp = $unpacker->reset($packedTimestamp)->unpack();
$seconds = $timestamp->getSeconds();
$nanoseconds = $timestamp->getNanoseconds();
When using the MessagePack
class, the Timestamp extension is already registered:
$packedTimestamp = MessagePack::pack(Timestamp::now());
$timestamp = MessagePack::unpack($packedTimestamp);
Application-specific extensions
In addition, the format can be extended with your own types. For example, to make the built-in PHP DateTime
objects first-class citizens in your code, you can create a corresponding extension, as shown in the example. Please note, that custom extensions have to be registered with a unique extension ID (an integer from 0
to 127
).
More extension examples can be found in the examples/MessagePack directory.
To learn more about how extension types can be useful, check out this article.
If an error occurs during packing/unpacking, a PackingFailedException
or an UnpackingFailedException
will be thrown, respectively. In addition, an InsufficientDataException
can be thrown during unpacking.
An InvalidOptionException
will be thrown in case an invalid option (or a combination of mutually exclusive options) is used.
Run tests as follows:
vendor/bin/phpunit
Also, if you already have Docker installed, you can run the tests in a docker container. First, create a container:
./dockerfile.sh | docker build -t msgpack -
The command above will create a container named msgpack
with PHP 8.1 runtime. You may change the default runtime by defining the PHP_IMAGE
environment variable:
PHP_IMAGE='php:8.0-cli' ./dockerfile.sh | docker build -t msgpack -
See a list of various images here.
Then run the unit tests:
docker run --rm -v $PWD:/msgpack -w /msgpack msgpack
To ensure that the unpacking works correctly with malformed/semi-malformed data, you can use a testing technique called Fuzzing. The library ships with a help file (target) for PHP-Fuzzer and can be used as follows:
php-fuzzer fuzz tests/fuzz_buffer_unpacker.php
To check performance, run:
php -n -dzend_extension=opcache.so \
-dpcre.jit=1 -dopcache.enable=1 -dopcache.enable_cli=1 \
tests/bench.php
Example output
Filter: MessagePack\Tests\Perf\Filter\ListFilter
Rounds: 3
Iterations: 100000
=============================================
Test/Target Packer BufferUnpacker
---------------------------------------------
nil .................. 0.0030 ........ 0.0139
false ................ 0.0037 ........ 0.0144
true ................. 0.0040 ........ 0.0137
7-bit uint #1 ........ 0.0052 ........ 0.0120
7-bit uint #2 ........ 0.0059 ........ 0.0114
7-bit uint #3 ........ 0.0061 ........ 0.0119
5-bit sint #1 ........ 0.0067 ........ 0.0126
5-bit sint #2 ........ 0.0064 ........ 0.0132
5-bit sint #3 ........ 0.0066 ........ 0.0135
8-bit uint #1 ........ 0.0078 ........ 0.0200
8-bit uint #2 ........ 0.0077 ........ 0.0212
8-bit uint #3 ........ 0.0086 ........ 0.0203
16-bit uint #1 ....... 0.0111 ........ 0.0271
16-bit uint #2 ....... 0.0115 ........ 0.0260
16-bit uint #3 ....... 0.0103 ........ 0.0273
32-bit uint #1 ....... 0.0116 ........ 0.0326
32-bit uint #2 ....... 0.0118 ........ 0.0332
32-bit uint #3 ....... 0.0127 ........ 0.0325
64-bit uint #1 ....... 0.0140 ........ 0.0277
64-bit uint #2 ....... 0.0134 ........ 0.0294
64-bit uint #3 ....... 0.0134 ........ 0.0281
8-bit int #1 ......... 0.0086 ........ 0.0241
8-bit int #2 ......... 0.0089 ........ 0.0225
8-bit int #3 ......... 0.0085 ........ 0.0229
16-bit int #1 ........ 0.0118 ........ 0.0280
16-bit int #2 ........ 0.0121 ........ 0.0270
16-bit int #3 ........ 0.0109 ........ 0.0274
32-bit int #1 ........ 0.0128 ........ 0.0346
32-bit int #2 ........ 0.0118 ........ 0.0339
32-bit int #3 ........ 0.0135 ........ 0.0368
64-bit int #1 ........ 0.0138 ........ 0.0276
64-bit int #2 ........ 0.0132 ........ 0.0286
64-bit int #3 ........ 0.0137 ........ 0.0274
64-bit int #4 ........ 0.0180 ........ 0.0285
64-bit float #1 ...... 0.0134 ........ 0.0284
64-bit float #2 ...... 0.0125 ........ 0.0275
64-bit float #3 ...... 0.0126 ........ 0.0283
fix string #1 ........ 0.0035 ........ 0.0133
fix string #2 ........ 0.0094 ........ 0.0216
fix string #3 ........ 0.0094 ........ 0.0222
fix string #4 ........ 0.0091 ........ 0.0241
8-bit string #1 ...... 0.0122 ........ 0.0301
8-bit string #2 ...... 0.0118 ........ 0.0304
8-bit string #3 ...... 0.0119 ........ 0.0315
16-bit string #1 ..... 0.0150 ........ 0.0388
16-bit string #2 ..... 0.1545 ........ 0.1665
32-bit string ........ 0.1570 ........ 0.1756
wide char string #1 .. 0.0091 ........ 0.0236
wide char string #2 .. 0.0122 ........ 0.0313
8-bit binary #1 ...... 0.0100 ........ 0.0302
8-bit binary #2 ...... 0.0123 ........ 0.0324
8-bit binary #3 ...... 0.0126 ........ 0.0327
16-bit binary ........ 0.0168 ........ 0.0372
32-bit binary ........ 0.1588 ........ 0.1754
fix array #1 ......... 0.0042 ........ 0.0131
fix array #2 ......... 0.0294 ........ 0.0367
fix array #3 ......... 0.0412 ........ 0.0472
16-bit array #1 ...... 0.1378 ........ 0.1596
16-bit array #2 ........... S ............. S
32-bit array .............. S ............. S
complex array ........ 0.1865 ........ 0.2283
fix map #1 ........... 0.0725 ........ 0.1048
fix map #2 ........... 0.0319 ........ 0.0405
fix map #3 ........... 0.0356 ........ 0.0665
fix map #4 ........... 0.0465 ........ 0.0497
16-bit map #1 ........ 0.2540 ........ 0.3028
16-bit map #2 ............. S ............. S
32-bit map ................ S ............. S
complex map .......... 0.2372 ........ 0.2710
fixext 1 ............. 0.0283 ........ 0.0358
fixext 2 ............. 0.0291 ........ 0.0371
fixext 4 ............. 0.0302 ........ 0.0355
fixext 8 ............. 0.0288 ........ 0.0384
fixext 16 ............ 0.0293 ........ 0.0359
8-bit ext ............ 0.0302 ........ 0.0439
16-bit ext ........... 0.0334 ........ 0.0499
32-bit ext ........... 0.1845 ........ 0.1888
32-bit timestamp #1 .. 0.0337 ........ 0.0547
32-bit timestamp #2 .. 0.0335 ........ 0.0560
64-bit timestamp #1 .. 0.0371 ........ 0.0575
64-bit timestamp #2 .. 0.0374 ........ 0.0542
64-bit timestamp #3 .. 0.0356 ........ 0.0533
96-bit timestamp #1 .. 0.0362 ........ 0.0699
96-bit timestamp #2 .. 0.0381 ........ 0.0701
96-bit timestamp #3 .. 0.0367 ........ 0.0687
=============================================
Total 2.7618 4.0820
Skipped 4 4
Failed 0 0
Ignored 0 0
With JIT:
php -n -dzend_extension=opcache.so \
-dpcre.jit=1 -dopcache.jit_buffer_size=64M -dopcache.jit=tracing -dopcache.enable=1 -dopcache.enable_cli=1 \
tests/bench.php
Example output
Filter: MessagePack\Tests\Perf\Filter\ListFilter
Rounds: 3
Iterations: 100000
=============================================
Test/Target Packer BufferUnpacker
---------------------------------------------
nil .................. 0.0005 ........ 0.0054
false ................ 0.0004 ........ 0.0059
true ................. 0.0004 ........ 0.0059
7-bit uint #1 ........ 0.0010 ........ 0.0047
7-bit uint #2 ........ 0.0010 ........ 0.0046
7-bit uint #3 ........ 0.0010 ........ 0.0046
5-bit sint #1 ........ 0.0025 ........ 0.0046
5-bit sint #2 ........ 0.0023 ........ 0.0046
5-bit sint #3 ........ 0.0024 ........ 0.0045
8-bit uint #1 ........ 0.0043 ........ 0.0081
8-bit uint #2 ........ 0.0043 ........ 0.0079
8-bit uint #3 ........ 0.0041 ........ 0.0080
16-bit uint #1 ....... 0.0064 ........ 0.0095
16-bit uint #2 ....... 0.0064 ........ 0.0091
16-bit uint #3 ....... 0.0064 ........ 0.0094
32-bit uint #1 ....... 0.0085 ........ 0.0114
32-bit uint #2 ....... 0.0077 ........ 0.0122
32-bit uint #3 ....... 0.0077 ........ 0.0120
64-bit uint #1 ....... 0.0085 ........ 0.0159
64-bit uint #2 ....... 0.0086 ........ 0.0157
64-bit uint #3 ....... 0.0086 ........ 0.0158
8-bit int #1 ......... 0.0042 ........ 0.0080
8-bit int #2 ......... 0.0042 ........ 0.0080
8-bit int #3 ......... 0.0042 ........ 0.0081
16-bit int #1 ........ 0.0065 ........ 0.0095
16-bit int #2 ........ 0.0065 ........ 0.0090
16-bit int #3 ........ 0.0056 ........ 0.0085
32-bit int #1 ........ 0.0067 ........ 0.0107
32-bit int #2 ........ 0.0066 ........ 0.0106
32-bit int #3 ........ 0.0063 ........ 0.0104
64-bit int #1 ........ 0.0072 ........ 0.0162
64-bit int #2 ........ 0.0073 ........ 0.0174
64-bit int #3 ........ 0.0072 ........ 0.0164
64-bit int #4 ........ 0.0077 ........ 0.0161
64-bit float #1 ...... 0.0053 ........ 0.0135
64-bit float #2 ...... 0.0053 ........ 0.0135
64-bit float #3 ...... 0.0052 ........ 0.0135
fix string #1 ....... -0.0002 ........ 0.0044
fix string #2 ........ 0.0035 ........ 0.0067
fix string #3 ........ 0.0035 ........ 0.0077
fix string #4 ........ 0.0033 ........ 0.0078
8-bit string #1 ...... 0.0059 ........ 0.0110
8-bit string #2 ...... 0.0063 ........ 0.0121
8-bit string #3 ...... 0.0064 ........ 0.0124
16-bit string #1 ..... 0.0099 ........ 0.0146
16-bit string #2 ..... 0.1522 ........ 0.1474
32-bit string ........ 0.1511 ........ 0.1483
wide char string #1 .. 0.0039 ........ 0.0084
wide char string #2 .. 0.0073 ........ 0.0123
8-bit binary #1 ...... 0.0040 ........ 0.0112
8-bit binary #2 ...... 0.0075 ........ 0.0123
8-bit binary #3 ...... 0.0077 ........ 0.0129
16-bit binary ........ 0.0096 ........ 0.0145
32-bit binary ........ 0.1535 ........ 0.1479
fix array #1 ......... 0.0008 ........ 0.0061
fix array #2 ......... 0.0121 ........ 0.0165
fix array #3 ......... 0.0193 ........ 0.0222
16-bit array #1 ...... 0.0607 ........ 0.0479
16-bit array #2 ........... S ............. S
32-bit array .............. S ............. S
complex array ........ 0.0749 ........ 0.0824
fix map #1 ........... 0.0329 ........ 0.0431
fix map #2 ........... 0.0161 ........ 0.0189
fix map #3 ........... 0.0205 ........ 0.0262
fix map #4 ........... 0.0252 ........ 0.0205
16-bit map #1 ........ 0.1016 ........ 0.0927
16-bit map #2 ............. S ............. S
32-bit map ................ S ............. S
complex map .......... 0.1096 ........ 0.1030
fixext 1 ............. 0.0157 ........ 0.0161
fixext 2 ............. 0.0175 ........ 0.0183
fixext 4 ............. 0.0156 ........ 0.0185
fixext 8 ............. 0.0163 ........ 0.0184
fixext 16 ............ 0.0164 ........ 0.0182
8-bit ext ............ 0.0158 ........ 0.0207
16-bit ext ........... 0.0203 ........ 0.0219
32-bit ext ........... 0.1614 ........ 0.1539
32-bit timestamp #1 .. 0.0195 ........ 0.0249
32-bit timestamp #2 .. 0.0188 ........ 0.0260
64-bit timestamp #1 .. 0.0207 ........ 0.0281
64-bit timestamp #2 .. 0.0212 ........ 0.0291
64-bit timestamp #3 .. 0.0207 ........ 0.0295
96-bit timestamp #1 .. 0.0222 ........ 0.0358
96-bit timestamp #2 .. 0.0228 ........ 0.0353
96-bit timestamp #3 .. 0.0210 ........ 0.0319
=============================================
Total 1.6432 1.9674
Skipped 4 4
Failed 0 0
Ignored 0 0
You may change default benchmark settings by defining the following environment variables:
Name | Default |
---|---|
MP_BENCH_TARGETS | pure_p,pure_u , see a list of available targets |
MP_BENCH_ITERATIONS | 100_000 |
MP_BENCH_DURATION | not set |
MP_BENCH_ROUNDS | 3 |
MP_BENCH_TESTS | -@slow , see a list of available tests |
For example:
export MP_BENCH_TARGETS=pure_p
export MP_BENCH_ITERATIONS=1000000
export MP_BENCH_ROUNDS=5
# a comma separated list of test names
export MP_BENCH_TESTS='complex array, complex map'
# or a group name
# export MP_BENCH_TESTS='-@slow' // @pecl_comp
# or a regexp
# export MP_BENCH_TESTS='/complex (array|map)/'
Another example, benchmarking both the library and the PECL extension:
MP_BENCH_TARGETS=pure_p,pure_u,pecl_p,pecl_u \
php -n -dextension=msgpack.so -dzend_extension=opcache.so \
-dpcre.jit=1 -dopcache.enable=1 -dopcache.enable_cli=1 \
tests/bench.php
Example output
Filter: MessagePack\Tests\Perf\Filter\ListFilter
Rounds: 3
Iterations: 100000
===========================================================================
Test/Target Packer BufferUnpacker msgpack_pack msgpack_unpack
---------------------------------------------------------------------------
nil .................. 0.0031 ........ 0.0141 ...... 0.0055 ........ 0.0064
false ................ 0.0039 ........ 0.0154 ...... 0.0056 ........ 0.0053
true ................. 0.0038 ........ 0.0139 ...... 0.0056 ........ 0.0044
7-bit uint #1 ........ 0.0061 ........ 0.0110 ...... 0.0059 ........ 0.0046
7-bit uint #2 ........ 0.0065 ........ 0.0119 ...... 0.0042 ........ 0.0029
7-bit uint #3 ........ 0.0054 ........ 0.0117 ...... 0.0045 ........ 0.0025
5-bit sint #1 ........ 0.0047 ........ 0.0103 ...... 0.0038 ........ 0.0022
5-bit sint #2 ........ 0.0048 ........ 0.0117 ...... 0.0038 ........ 0.0022
5-bit sint #3 ........ 0.0046 ........ 0.0102 ...... 0.0038 ........ 0.0023
8-bit uint #1 ........ 0.0063 ........ 0.0174 ...... 0.0039 ........ 0.0031
8-bit uint #2 ........ 0.0063 ........ 0.0167 ...... 0.0040 ........ 0.0029
8-bit uint #3 ........ 0.0063 ........ 0.0168 ...... 0.0039 ........ 0.0030
16-bit uint #1 ....... 0.0092 ........ 0.0222 ...... 0.0049 ........ 0.0030
16-bit uint #2 ....... 0.0096 ........ 0.0227 ...... 0.0042 ........ 0.0046
16-bit uint #3 ....... 0.0123 ........ 0.0274 ...... 0.0059 ........ 0.0051
32-bit uint #1 ....... 0.0136 ........ 0.0331 ...... 0.0060 ........ 0.0048
32-bit uint #2 ....... 0.0130 ........ 0.0336 ...... 0.0070 ........ 0.0048
32-bit uint #3 ....... 0.0127 ........ 0.0329 ...... 0.0051 ........ 0.0048
64-bit uint #1 ....... 0.0126 ........ 0.0268 ...... 0.0055 ........ 0.0049
64-bit uint #2 ....... 0.0135 ........ 0.0281 ...... 0.0052 ........ 0.0046
64-bit uint #3 ....... 0.0131 ........ 0.0274 ...... 0.0069 ........ 0.0044
8-bit int #1 ......... 0.0077 ........ 0.0236 ...... 0.0058 ........ 0.0044
8-bit int #2 ......... 0.0087 ........ 0.0244 ...... 0.0058 ........ 0.0048
8-bit int #3 ......... 0.0084 ........ 0.0241 ...... 0.0055 ........ 0.0049
16-bit int #1 ........ 0.0112 ........ 0.0271 ...... 0.0048 ........ 0.0045
16-bit int #2 ........ 0.0124 ........ 0.0292 ...... 0.0057 ........ 0.0049
16-bit int #3 ........ 0.0118 ........ 0.0270 ...... 0.0058 ........ 0.0050
32-bit int #1 ........ 0.0137 ........ 0.0366 ...... 0.0058 ........ 0.0051
32-bit int #2 ........ 0.0133 ........ 0.0366 ...... 0.0056 ........ 0.0049
32-bit int #3 ........ 0.0129 ........ 0.0350 ...... 0.0052 ........ 0.0048
64-bit int #1 ........ 0.0145 ........ 0.0254 ...... 0.0034 ........ 0.0025
64-bit int #2 ........ 0.0097 ........ 0.0214 ...... 0.0034 ........ 0.0025
64-bit int #3 ........ 0.0096 ........ 0.0287 ...... 0.0059 ........ 0.0050
64-bit int #4 ........ 0.0143 ........ 0.0277 ...... 0.0059 ........ 0.0046
64-bit float #1 ...... 0.0134 ........ 0.0281 ...... 0.0057 ........ 0.0052
64-bit float #2 ...... 0.0141 ........ 0.0281 ...... 0.0057 ........ 0.0050
64-bit float #3 ...... 0.0144 ........ 0.0282 ...... 0.0057 ........ 0.0050
fix string #1 ........ 0.0036 ........ 0.0143 ...... 0.0066 ........ 0.0053
fix string #2 ........ 0.0107 ........ 0.0222 ...... 0.0065 ........ 0.0068
fix string #3 ........ 0.0116 ........ 0.0245 ...... 0.0063 ........ 0.0069
fix string #4 ........ 0.0105 ........ 0.0253 ...... 0.0083 ........ 0.0077
8-bit string #1 ...... 0.0126 ........ 0.0318 ...... 0.0075 ........ 0.0088
8-bit string #2 ...... 0.0121 ........ 0.0295 ...... 0.0076 ........ 0.0086
8-bit string #3 ...... 0.0125 ........ 0.0293 ...... 0.0130 ........ 0.0093
16-bit string #1 ..... 0.0159 ........ 0.0368 ...... 0.0117 ........ 0.0086
16-bit string #2 ..... 0.1547 ........ 0.1686 ...... 0.1516 ........ 0.1373
32-bit string ........ 0.1558 ........ 0.1729 ...... 0.1511 ........ 0.1396
wide char string #1 .. 0.0098 ........ 0.0237 ...... 0.0066 ........ 0.0065
wide char string #2 .. 0.0128 ........ 0.0291 ...... 0.0061 ........ 0.0082
8-bit binary #1 ........... I ............. I ........... F ............. I
8-bit binary #2 ........... I ............. I ........... F ............. I
8-bit binary #3 ........... I ............. I ........... F ............. I
16-bit binary ............. I ............. I ........... F ............. I
32-bit binary ............. I ............. I ........... F ............. I
fix array #1 ......... 0.0040 ........ 0.0129 ...... 0.0120 ........ 0.0058
fix array #2 ......... 0.0279 ........ 0.0390 ...... 0.0143 ........ 0.0165
fix array #3 ......... 0.0415 ........ 0.0463 ...... 0.0162 ........ 0.0187
16-bit array #1 ...... 0.1349 ........ 0.1628 ...... 0.0334 ........ 0.0341
16-bit array #2 ........... S ............. S ........... S ............. S
32-bit array .............. S ............. S ........... S ............. S
complex array ............. I ............. I ........... F ............. F
fix map #1 ................ I ............. I ........... F ............. I
fix map #2 ........... 0.0345 ........ 0.0391 ...... 0.0143 ........ 0.0168
fix map #3 ................ I ............. I ........... F ............. I
fix map #4 ........... 0.0459 ........ 0.0473 ...... 0.0151 ........ 0.0163
16-bit map #1 ........ 0.2518 ........ 0.2962 ...... 0.0400 ........ 0.0490
16-bit map #2 ............. S ............. S ........... S ............. S
32-bit map ................ S ............. S ........... S ............. S
complex map .......... 0.2380 ........ 0.2682 ...... 0.0545 ........ 0.0579
fixext 1 .................. I ............. I ........... F ............. F
fixext 2 .................. I ............. I ........... F ............. F
fixext 4 .................. I ............. I ........... F ............. F
fixext 8 .................. I ............. I ........... F ............. F
fixext 16 ................. I ............. I ........... F ............. F
8-bit ext ................. I ............. I ........... F ............. F
16-bit ext ................ I ............. I ........... F ............. F
32-bit ext ................ I ............. I ........... F ............. F
32-bit timestamp #1 ....... I ............. I ........... F ............. F
32-bit timestamp #2 ....... I ............. I ........... F ............. F
64-bit timestamp #1 ....... I ............. I ........... F ............. F
64-bit timestamp #2 ....... I ............. I ........... F ............. F
64-bit timestamp #3 ....... I ............. I ........... F ............. F
96-bit timestamp #1 ....... I ............. I ........... F ............. F
96-bit timestamp #2 ....... I ............. I ........... F ............. F
96-bit timestamp #3 ....... I ............. I ........... F ............. F
===========================================================================
Total 1.5625 2.3866 0.7735 0.7243
Skipped 4 4 4 4
Failed 0 0 24 17
Ignored 24 24 0 7
With JIT:
MP_BENCH_TARGETS=pure_p,pure_u,pecl_p,pecl_u \
php -n -dextension=msgpack.so -dzend_extension=opcache.so \
-dpcre.jit=1 -dopcache.jit_buffer_size=64M -dopcache.jit=tracing -dopcache.enable=1 -dopcache.enable_cli=1 \
tests/bench.php
Example output
Filter: MessagePack\Tests\Perf\Filter\ListFilter
Rounds: 3
Iterations: 100000
===========================================================================
Test/Target Packer BufferUnpacker msgpack_pack msgpack_unpack
---------------------------------------------------------------------------
nil .................. 0.0001 ........ 0.0052 ...... 0.0053 ........ 0.0042
false ................ 0.0007 ........ 0.0060 ...... 0.0057 ........ 0.0043
true ................. 0.0008 ........ 0.0060 ...... 0.0056 ........ 0.0041
7-bit uint #1 ........ 0.0031 ........ 0.0046 ...... 0.0062 ........ 0.0041
7-bit uint #2 ........ 0.0021 ........ 0.0043 ...... 0.0062 ........ 0.0041
7-bit uint #3 ........ 0.0022 ........ 0.0044 ...... 0.0061 ........ 0.0040
5-bit sint #1 ........ 0.0030 ........ 0.0048 ...... 0.0062 ........ 0.0040
5-bit sint #2 ........ 0.0032 ........ 0.0046 ...... 0.0062 ........ 0.0040
5-bit sint #3 ........ 0.0031 ........ 0.0046 ...... 0.0062 ........ 0.0040
8-bit uint #1 ........ 0.0054 ........ 0.0079 ...... 0.0062 ........ 0.0050
8-bit uint #2 ........ 0.0051 ........ 0.0079 ...... 0.0064 ........ 0.0044
8-bit uint #3 ........ 0.0051 ........ 0.0082 ...... 0.0062 ........ 0.0044
16-bit uint #1 ....... 0.0077 ........ 0.0094 ...... 0.0065 ........ 0.0045
16-bit uint #2 ....... 0.0077 ........ 0.0094 ...... 0.0063 ........ 0.0045
16-bit uint #3 ....... 0.0077 ........ 0.0095 ...... 0.0064 ........ 0.0047
32-bit uint #1 ....... 0.0088 ........ 0.0119 ...... 0.0063 ........ 0.0043
32-bit uint #2 ....... 0.0089 ........ 0.0117 ...... 0.0062 ........ 0.0039
32-bit uint #3 ....... 0.0089 ........ 0.0118 ...... 0.0063 ........ 0.0044
64-bit uint #1 ....... 0.0097 ........ 0.0155 ...... 0.0063 ........ 0.0045
64-bit uint #2 ....... 0.0095 ........ 0.0153 ...... 0.0061 ........ 0.0045
64-bit uint #3 ....... 0.0096 ........ 0.0156 ...... 0.0063 ........ 0.0047
8-bit int #1 ......... 0.0053 ........ 0.0083 ...... 0.0062 ........ 0.0044
8-bit int #2 ......... 0.0052 ........ 0.0080 ...... 0.0062 ........ 0.0044
8-bit int #3 ......... 0.0052 ........ 0.0080 ...... 0.0062 ........ 0.0043
16-bit int #1 ........ 0.0089 ........ 0.0097 ...... 0.0069 ........ 0.0046
16-bit int #2 ........ 0.0075 ........ 0.0093 ...... 0.0063 ........ 0.0043
16-bit int #3 ........ 0.0075 ........ 0.0094 ...... 0.0062 ........ 0.0046
32-bit int #1 ........ 0.0086 ........ 0.0122 ...... 0.0063 ........ 0.0044
32-bit int #2 ........ 0.0087 ........ 0.0120 ...... 0.0066 ........ 0.0046
32-bit int #3 ........ 0.0086 ........ 0.0121 ...... 0.0060 ........ 0.0044
64-bit int #1 ........ 0.0096 ........ 0.0149 ...... 0.0060 ........ 0.0045
64-bit int #2 ........ 0.0096 ........ 0.0157 ...... 0.0062 ........ 0.0044
64-bit int #3 ........ 0.0096 ........ 0.0160 ...... 0.0063 ........ 0.0046
64-bit int #4 ........ 0.0097 ........ 0.0157 ...... 0.0061 ........ 0.0044
64-bit float #1 ...... 0.0079 ........ 0.0153 ...... 0.0056 ........ 0.0044
64-bit float #2 ...... 0.0079 ........ 0.0152 ...... 0.0057 ........ 0.0045
64-bit float #3 ...... 0.0079 ........ 0.0155 ...... 0.0057 ........ 0.0044
fix string #1 ........ 0.0010 ........ 0.0045 ...... 0.0071 ........ 0.0044
fix string #2 ........ 0.0048 ........ 0.0075 ...... 0.0070 ........ 0.0060
fix string #3 ........ 0.0048 ........ 0.0086 ...... 0.0068 ........ 0.0060
fix string #4 ........ 0.0050 ........ 0.0088 ...... 0.0070 ........ 0.0059
8-bit string #1 ...... 0.0081 ........ 0.0129 ...... 0.0069 ........ 0.0062
8-bit string #2 ...... 0.0086 ........ 0.0128 ...... 0.0069 ........ 0.0065
8-bit string #3 ...... 0.0086 ........ 0.0126 ...... 0.0115 ........ 0.0065
16-bit string #1 ..... 0.0105 ........ 0.0137 ...... 0.0128 ........ 0.0068
16-bit string #2 ..... 0.1510 ........ 0.1486 ...... 0.1526 ........ 0.1391
32-bit string ........ 0.1517 ........ 0.1475 ...... 0.1504 ........ 0.1370
wide char string #1 .. 0.0044 ........ 0.0085 ...... 0.0067 ........ 0.0057
wide char string #2 .. 0.0081 ........ 0.0125 ...... 0.0069 ........ 0.0063
8-bit binary #1 ........... I ............. I ........... F ............. I
8-bit binary #2 ........... I ............. I ........... F ............. I
8-bit binary #3 ........... I ............. I ........... F ............. I
16-bit binary ............. I ............. I ........... F ............. I
32-bit binary ............. I ............. I ........... F ............. I
fix array #1 ......... 0.0014 ........ 0.0059 ...... 0.0132 ........ 0.0055
fix array #2 ......... 0.0146 ........ 0.0156 ...... 0.0155 ........ 0.0148
fix array #3 ......... 0.0211 ........ 0.0229 ...... 0.0179 ........ 0.0180
16-bit array #1 ...... 0.0673 ........ 0.0498 ...... 0.0343 ........ 0.0388
16-bit array #2 ........... S ............. S ........... S ............. S
32-bit array .............. S ............. S ........... S ............. S
complex array ............. I ............. I ........... F ............. F
fix map #1 ................ I ............. I ........... F ............. I
fix map #2 ........... 0.0148 ........ 0.0180 ...... 0.0156 ........ 0.0179
fix map #3 ................ I ............. I ........... F ............. I
fix map #4 ........... 0.0252 ........ 0.0201 ...... 0.0214 ........ 0.0167
16-bit map #1 ........ 0.1027 ........ 0.0836 ...... 0.0388 ........ 0.0510
16-bit map #2 ............. S ............. S ........... S ............. S
32-bit map ................ S ............. S ........... S ............. S
complex map .......... 0.1104 ........ 0.1010 ...... 0.0556 ........ 0.0602
fixext 1 .................. I ............. I ........... F ............. F
fixext 2 .................. I ............. I ........... F ............. F
fixext 4 .................. I ............. I ........... F ............. F
fixext 8 .................. I ............. I ........... F ............. F
fixext 16 ................. I ............. I ........... F ............. F
8-bit ext ................. I ............. I ........... F ............. F
16-bit ext ................ I ............. I ........... F ............. F
32-bit ext ................ I ............. I ........... F ............. F
32-bit timestamp #1 ....... I ............. I ........... F ............. F
32-bit timestamp #2 ....... I ............. I ........... F ............. F
64-bit timestamp #1 ....... I ............. I ........... F ............. F
64-bit timestamp #2 ....... I ............. I ........... F ............. F
64-bit timestamp #3 ....... I ............. I ........... F ............. F
96-bit timestamp #1 ....... I ............. I ........... F ............. F
96-bit timestamp #2 ....... I ............. I ........... F ............. F
96-bit timestamp #3 ....... I ............. I ........... F ............. F
===========================================================================
Total 0.9642 1.0909 0.8224 0.7213
Skipped 4 4 4 4
Failed 0 0 24 17
Ignored 24 24 0 7
Note that the msgpack extension (v2.1.2) doesn't support ext, bin and UTF-8 str types.
The library is released under the MIT License. See the bundled LICENSE file for details.
Author: rybakit
Source Code: https://github.com/rybakit/msgpack.php
License: MIT License
1669952228
In this tutorial, you'll learn: What is Dijkstra's Algorithm and how Dijkstra's algorithm works with the help of visual guides.
You can use algorithms in programming to solve specific problems through a set of precise instructions or procedures.
Dijkstra's algorithm is one of many graph algorithms you'll come across. It is used to find the shortest path from a fixed node to all other nodes in a graph.
There are different representations of Dijkstra's algorithm. You can either find the shortest path between two nodes, or the shortest path from a fixed node to the rest of the nodes in a graph.
In this article, you'll learn how Dijkstra's algorithm works with the help of visual guides.
Before we dive into more detailed visual examples, you need to understand how Dijkstra's algorithm works.
Although the theoretical explanation may seem a bit abstract, it'll help you understand the practical aspect better.
In a given graph containing different nodes, we are required to get the shortest path from a given node to the rest of the nodes.
These nodes can represent any object like the names of cities, letters, and so on.
Between each node is a number denoting the distance between two nodes, as you can see in the image below:
We usually work with two arrays – one for visited nodes, and another for unvisited nodes. You'll learn more about the arrays in the next section.
When a node is visited, the algorithm calculates how long it took to get to the node and stores the distance. If a shorter path to a node is found, the initial value assigned for the distance is updated.
Note that a node cannot be visited twice.
The algorithm runs recursively until all the nodes have been visited.
In this section, we'll take a look at a practical example that shows how Dijkstra's algorithm works.
Here's the graph we'll be working with:
We'll use the table below to put down the visited nodes and their distance from the fixed node:
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | ∞ |
B | ∞ |
C | ∞ |
D | ∞ |
E | ∞ |
Visited nodes = []
Unvisited nodes = [A,B,C,D,E]
Above, we have a table showing each node and the shortest distance from the that node to the fixed node. We are yet to choose the fixed node.
Note that the distance for each node in the table is currently denoted as infinity (∞). This is because we don't know the shortest distance yet.
We also have two arrays – visited and unvisited. Whenever a node is visited, it is added to the visited nodes array.
Let's get started!
To simplify things, I'll break the process down into iterations. You'll see what happens in each step with the aid of diagrams.
The first iteration might seem confusing, but that's totally fine. Once we start repeating the process in each iteration, you'll have a clearer picture of how the algorithm works.
Step #1 - Pick an unvisited node
We'll choose A as the fixed node. So we'll find the shortest distance from A to every other node in the graph.
We're going to give A a distance of 0 because it is the initial node. So the table would look like this:
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | 0 |
B | ∞ |
C | ∞ |
D | ∞ |
E | ∞ |
Step #2 - Find the distance from current node
The next thing to do after choosing a node is to find the distance from it to the unvisited nodes around it.
The two unvisited nodes directly linked to A are B and C.
To get the distance from A to B:
0 + 4 = 4
0 being the value of the current node (A), and 4 being the distance between A and B in the graph.
To get the distance from A to C:
0 + 2 = 2
Step #3 - Update table with known distances
In the last step, we got 4 and 2 as the values of B and C respectively. So we'll update the table with those values:
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | 0 |
B | 4 |
C | 2 |
D | ∞ |
E | ∞ |
Step #4 - Update arrays
At this point, the first iteration is complete. We'll move node A to the visited nodes array:
Visited nodes = [A]
Unvisited nodes = [B,C,D,E]
Before we proceed to the next iteration, you should know the following:
Step #1 - Pick an unvisited node
We have four unvisited nodes — [B,C,D,E]. So how do you know which node to pick for the next iteration?
Well, we pick the node with the smallest known distance recorded in the table. Here's the table:
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | 0 |
B | 4 |
C | 2 |
D | ∞ |
E | ∞ |
So we're going with node C.
Step #2 - Find the distance from current node
To find the distance from the current node to the fixed node, we have to consider the nodes linked to the current node.
The nodes linked to the current node are A and B.
But A has been visited in the previous iteration so it will not be linked to the current node. That is:
From the diagram above,
To find the distance from C to B:
2 + 1 = 3
2 above is recorded distance for node C while 1 is the distance between C and B in the graph.
Step #3 - Update table with known distances
In the last step, we got the value of B to be 3. In the first iteration, it was 4.
We're going to update the distance in the table to 3.
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | 0 |
B | 3 |
C | 2 |
D | ∞ |
E | ∞ |
So, A --> B = 4 (First iteration).
A --> C --> B = 3 (Second iteration).
The algorithm has helped us find the shortest path to B from A.
Step #4 - Update arrays
We're done with the last visited node. Let's add it to the visited nodes array:
Visited nodes = [A,C]
Unvisited nodes = [B,D,E]
Step #1 - Pick an unvisited node
We're down to three unvisited nodes — [B,D,E]. From the array, B has the shortest known distance.
To restate what is going on in the diagram above:
Step #2 - Find the distance from current node
The nodes linked to the current node are D and E.
B (the current node) has a value of 3. Therefore,
For node D, 3 + 3 = 6.
For node E, 3 + 2 = 5.
Step #3 - Update table with known distances
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | 0 |
B | 3 |
C | 2 |
D | 6 |
E | 5 |
Step #4 - Update arrays
Visited nodes = [A,C,B]
Unvisited nodes = [D,E]
Step #1 - Pick an unvisited node
Like other iterations, we'll go with the unvisited node with the shortest known distance. That is E.
Step #2 - Find the distance from current node
According to our table, E has a value of 5.
For D in the current iteration,
5 + 5 = 10.
The value gotten for D here is 10, which is greater than the recorded value of 6 in the previous iteration. For this reason, we'll not update the table.
Step #3 - Update table with known distances
Our table remains the same:
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | 0 |
B | 3 |
C | 2 |
D | 6 |
E | 5 |
Step #4 - Update arrays
Visited nodes = [A,C,B,E]
Unvisited nodes = [D]
Step #1 - Pick an unvisited node
We're currently left with one node in the unvisited array — D.
Step #2 - Find the distance from current node
The algorithm has gotten to the last iteration. This is because all nodes linked to the current node have been visited already so we can't link to them.
Step #3 - Update table with known distances
Our table remains the same:
NODE | SHORTEST DISTANCE FROM FIXED NODE |
---|---|
A | 0 |
B | 3 |
C | 2 |
D | 6 |
E | 5 |
At this point, we have updated the table with the shortest distance from the fixed node to every other node in the graph.
Step #4 - Update arrays
Visited nodes = [A,C,B,E,D]
Unvisited nodes = []
As can be seen above, we have no nodes left to visit. Using Dijkstra's algorithm, we've found the shortest distance from the fixed node to others nodes in the graph.
The pseudocode example in this section was gotten from Wikipedia. Here it is:
1 function Dijkstra(Graph, source):
2
3 for each vertex v in Graph.Vertices:
4 dist[v] ← INFINITY
5 prev[v] ← UNDEFINED
6 add v to Q
7 dist[source] ← 0
8
9 while Q is not empty:
10 u ← vertex in Q with min dist[u]
11 remove u from Q
12
13 for each neighbor v of u still in Q:
14 alt ← dist[u] + Graph.Edges(u, v)
15 if alt < dist[v]:
16 dist[v] ← alt
17 prev[v] ← u
18
19 return dist[], prev[]
Here are some of the common applications of Dijkstra's algorithm:
In this article, we talked about Dijkstra's algorithm. It is used to find the shortest distance from a fixed node to all other nodes in a graph.
We started by giving a brief summary of how the algorithm works.
We then had a look at an example that further explained Dijkstra's algorithm in steps using visual guides.
We concluded with a pseudocode example and some of the applications of Dijkstra's algorithm.
Happy coding!
Original article source at https://www.freecodecamp.org
#algorithm #datastructures
1630743562
FHIR_DB
This is really just a wrapper around Sembast_SQFLite - so all of the heavy lifting was done by Alex Tekartik. I highly recommend that if you have any questions about working with this package that you take a look at Sembast. He's also just a super nice guy, and even answered a question for me when I was deciding which sembast version to use. As usual, ResoCoder also has a good tutorial.
I have an interest in low-resource settings and thus a specific reason to be able to store data offline. To encourage this use, there are a number of other packages I have created based around the data format FHIR. FHIR® is the registered trademark of HL7 and is used with the permission of HL7. Use of the FHIR trademark does not constitute endorsement of this product by HL7.
So, while not absolutely necessary, I highly recommend that you use some sort of interface class. This adds the benefit of more easily handling errors, plus if you change to a different database in the future, you don't have to change the rest of your app, just the interface.
I've used something like this in my projects:
class IFhirDb {
IFhirDb();
final ResourceDao resourceDao = ResourceDao();
Future<Either<DbFailure, Resource>> save(Resource resource) async {
Resource resultResource;
try {
resultResource = await resourceDao.save(resource);
} catch (error) {
return left(DbFailure.unableToSave(error: error.toString()));
}
return right(resultResource);
}
Future<Either<DbFailure, List<Resource>>> returnListOfSingleResourceType(
String resourceType) async {
List<Resource> resultList;
try {
resultList =
await resourceDao.getAllSortedById(resourceType: resourceType);
} catch (error) {
return left(DbFailure.unableToObtainList(error: error.toString()));
}
return right(resultList);
}
Future<Either<DbFailure, List<Resource>>> searchFunction(
String resourceType, String searchString, String reference) async {
List<Resource> resultList;
try {
resultList =
await resourceDao.searchFor(resourceType, searchString, reference);
} catch (error) {
return left(DbFailure.unableToObtainList(error: error.toString()));
}
return right(resultList);
}
}
I like this because in case there's an i/o error or something, it won't crash your app. Then, you can call this interface in your app like the following:
final patient = Patient(
resourceType: 'Patient',
name: [HumanName(text: 'New Patient Name')],
birthDate: Date(DateTime.now()),
);
final saveResult = await IFhirDb().save(patient);
This will save your newly created patient to the locally embedded database.
IMPORTANT: this database will expect that all previously created resources have an id. When you save a resource, it will check to see if that resource type has already been stored. (Each resource type is saved in it's own store in the database). It will then check if there is an ID. If there's no ID, it will create a new one for that resource (along with metadata on version number and creation time). It will save it, and return the resource. If it already has an ID, it will copy the the old version of the resource into a _history store. It will then update the metadata of the new resource and save that version into the appropriate store for that resource. If, for instance, we have a previously created patient:
{
"resourceType": "Patient",
"id": "fhirfli-294057507-6811107",
"meta": {
"versionId": "1",
"lastUpdated": "2020-10-16T19:41:28.054369Z"
},
"name": [
{
"given": ["New"],
"family": "Patient"
}
],
"birthDate": "2020-10-16"
}
And we update the last name to 'Provider'. The above version of the patient will be kept in _history, while in the 'Patient' store in the db, we will have the updated version:
{
"resourceType": "Patient",
"id": "fhirfli-294057507-6811107",
"meta": {
"versionId": "2",
"lastUpdated": "2020-10-16T19:45:07.316698Z"
},
"name": [
{
"given": ["New"],
"family": "Provider"
}
],
"birthDate": "2020-10-16"
}
This way we can keep track of all previous version of all resources (which is obviously important in medicine).
For most of the interactions (saving, deleting, etc), they work the way you'd expect. The only difference is search. Because Sembast is NoSQL, we can search on any of the fields in a resource. If in our interface class, we have the following function:
Future<Either<DbFailure, List<Resource>>> searchFunction(
String resourceType, String searchString, String reference) async {
List<Resource> resultList;
try {
resultList =
await resourceDao.searchFor(resourceType, searchString, reference);
} catch (error) {
return left(DbFailure.unableToObtainList(error: error.toString()));
}
return right(resultList);
}
You can search for all immunizations of a certain patient:
searchFunction(
'Immunization', 'patient.reference', 'Patient/$patientId');
This function will search through all entries in the 'Immunization' store. It will look at all 'patient.reference' fields, and return any that match 'Patient/$patientId'.
The last thing I'll mention is that this is a password protected db, using AES-256 encryption (although it can also use Salsa20). Anytime you use the db, you have the option of using a password for encryption/decryption. Remember, if you setup the database using encryption, you will only be able to access it using that same password. When you're ready to change the password, you will need to call the update password function. If we again assume we created a change password method in our interface, it might look something like this:
class IFhirDb {
IFhirDb();
final ResourceDao resourceDao = ResourceDao();
...
Future<Either<DbFailure, Unit>> updatePassword(String oldPassword, String newPassword) async {
try {
await resourceDao.updatePw(oldPassword, newPassword);
} catch (error) {
return left(DbFailure.unableToUpdatePassword(error: error.toString()));
}
return right(Unit);
}
You don't have to use a password, and in that case, it will save the db file as plain text. If you want to add a password later, it will encrypt it at that time.
After using this for a while in an app, I've realized that it needs to be able to store data apart from just FHIR resources, at least on occasion. For this, I've added a second class for all versions of the database called GeneralDao. This is similar to the ResourceDao, but fewer options. So, in order to save something, it would look like this:
await GeneralDao().save('password', {'new':'map'});
await GeneralDao().save('password', {'new':'map'}, 'key');
The difference between these two options is that the first one will generate a key for the map being stored, while the second will store the map using the key provided. Both will return the key after successfully storing the map.
Other functions available include:
// deletes everything in the general store
await GeneralDao().deleteAllGeneral('password');
// delete specific entry
await GeneralDao().delete('password','key');
// returns map with that key
await GeneralDao().find('password', 'key');
FHIR® is a registered trademark of Health Level Seven International (HL7) and its use does not constitute an endorsement of products by HL7®
Run this command:
With Flutter:
$ flutter pub add fhir_db
This will add a line like this to your package's pubspec.yaml (and run an implicit flutter pub get):
dependencies:
fhir_db: ^0.4.3
Alternatively, your editor might support or flutter pub get. Check the docs for your editor to learn more.
Now in your Dart code, you can use:
import 'package:fhir_db/dstu2.dart';
import 'package:fhir_db/dstu2/fhir_db.dart';
import 'package:fhir_db/dstu2/general_dao.dart';
import 'package:fhir_db/dstu2/resource_dao.dart';
import 'package:fhir_db/encrypt/aes.dart';
import 'package:fhir_db/encrypt/salsa.dart';
import 'package:fhir_db/r4.dart';
import 'package:fhir_db/r4/fhir_db.dart';
import 'package:fhir_db/r4/general_dao.dart';
import 'package:fhir_db/r4/resource_dao.dart';
import 'package:fhir_db/r5.dart';
import 'package:fhir_db/r5/fhir_db.dart';
import 'package:fhir_db/r5/general_dao.dart';
import 'package:fhir_db/r5/resource_dao.dart';
import 'package:fhir_db/stu3.dart';
import 'package:fhir_db/stu3/fhir_db.dart';
import 'package:fhir_db/stu3/general_dao.dart';
import 'package:fhir_db/stu3/resource_dao.dart';
import 'package:fhir/r4.dart';
import 'package:fhir_db/r4.dart';
import 'package:flutter/material.dart';
import 'package:test/test.dart';
Future<void> main() async {
WidgetsFlutterBinding.ensureInitialized();
final resourceDao = ResourceDao();
// await resourceDao.updatePw('newPw', null);
await resourceDao.deleteAllResources(null);
group('Playing with passwords', () {
test('Playing with Passwords', () async {
final patient = Patient(id: Id('1'));
final saved = await resourceDao.save(null, patient);
await resourceDao.updatePw(null, 'newPw');
final search1 = await resourceDao.find('newPw',
resourceType: R4ResourceType.Patient, id: Id('1'));
expect(saved, search1[0]);
await resourceDao.updatePw('newPw', 'newerPw');
final search2 = await resourceDao.find('newerPw',
resourceType: R4ResourceType.Patient, id: Id('1'));
expect(saved, search2[0]);
await resourceDao.updatePw('newerPw', null);
final search3 = await resourceDao.find(null,
resourceType: R4ResourceType.Patient, id: Id('1'));
expect(saved, search3[0]);
await resourceDao.deleteAllResources(null);
});
});
final id = Id('12345');
group('Saving Things:', () {
test('Save Patient', () async {
final humanName = HumanName(family: 'Atreides', given: ['Duke']);
final patient = Patient(id: id, name: [humanName]);
final saved = await resourceDao.save(null, patient);
expect(saved.id, id);
expect((saved as Patient).name?[0], humanName);
});
test('Save Organization', () async {
final organization = Organization(id: id, name: 'FhirFli');
final saved = await resourceDao.save(null, organization);
expect(saved.id, id);
expect((saved as Organization).name, 'FhirFli');
});
test('Save Observation1', () async {
final observation1 = Observation(
id: Id('obs1'),
code: CodeableConcept(text: 'Observation #1'),
effectiveDateTime: FhirDateTime(DateTime(1981, 09, 18)),
);
final saved = await resourceDao.save(null, observation1);
expect(saved.id, Id('obs1'));
expect((saved as Observation).code.text, 'Observation #1');
});
test('Save Observation1 Again', () async {
final observation1 = Observation(
id: Id('obs1'),
code: CodeableConcept(text: 'Observation #1 - Updated'));
final saved = await resourceDao.save(null, observation1);
expect(saved.id, Id('obs1'));
expect((saved as Observation).code.text, 'Observation #1 - Updated');
expect(saved.meta?.versionId, Id('2'));
});
test('Save Observation2', () async {
final observation2 = Observation(
id: Id('obs2'),
code: CodeableConcept(text: 'Observation #2'),
effectiveDateTime: FhirDateTime(DateTime(1981, 09, 18)),
);
final saved = await resourceDao.save(null, observation2);
expect(saved.id, Id('obs2'));
expect((saved as Observation).code.text, 'Observation #2');
});
test('Save Observation3', () async {
final observation3 = Observation(
id: Id('obs3'),
code: CodeableConcept(text: 'Observation #3'),
effectiveDateTime: FhirDateTime(DateTime(1981, 09, 18)),
);
final saved = await resourceDao.save(null, observation3);
expect(saved.id, Id('obs3'));
expect((saved as Observation).code.text, 'Observation #3');
});
});
group('Finding Things:', () {
test('Find 1st Patient', () async {
final search = await resourceDao.find(null,
resourceType: R4ResourceType.Patient, id: id);
final humanName = HumanName(family: 'Atreides', given: ['Duke']);
expect(search.length, 1);
expect((search[0] as Patient).name?[0], humanName);
});
test('Find 3rd Observation', () async {
final search = await resourceDao.find(null,
resourceType: R4ResourceType.Observation, id: Id('obs3'));
expect(search.length, 1);
expect(search[0].id, Id('obs3'));
expect((search[0] as Observation).code.text, 'Observation #3');
});
test('Find All Observations', () async {
final search = await resourceDao.getResourceType(
null,
resourceTypes: [R4ResourceType.Observation],
);
expect(search.length, 3);
final idList = [];
for (final obs in search) {
idList.add(obs.id.toString());
}
expect(idList.contains('obs1'), true);
expect(idList.contains('obs2'), true);
expect(idList.contains('obs3'), true);
});
test('Find All (non-historical) Resources', () async {
final search = await resourceDao.getAll(null);
expect(search.length, 5);
final patList = search.toList();
final orgList = search.toList();
final obsList = search.toList();
patList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Patient);
orgList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Organization);
obsList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Observation);
expect(patList.length, 1);
expect(orgList.length, 1);
expect(obsList.length, 3);
});
});
group('Deleting Things:', () {
test('Delete 2nd Observation', () async {
await resourceDao.delete(
null, null, R4ResourceType.Observation, Id('obs2'), null, null);
final search = await resourceDao.getResourceType(
null,
resourceTypes: [R4ResourceType.Observation],
);
expect(search.length, 2);
final idList = [];
for (final obs in search) {
idList.add(obs.id.toString());
}
expect(idList.contains('obs1'), true);
expect(idList.contains('obs2'), false);
expect(idList.contains('obs3'), true);
});
test('Delete All Observations', () async {
await resourceDao.deleteSingleType(null,
resourceType: R4ResourceType.Observation);
final search = await resourceDao.getAll(null);
expect(search.length, 2);
final patList = search.toList();
final orgList = search.toList();
patList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Patient);
orgList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Organization);
expect(patList.length, 1);
expect(patList.length, 1);
});
test('Delete All Resources', () async {
await resourceDao.deleteAllResources(null);
final search = await resourceDao.getAll(null);
expect(search.length, 0);
});
});
group('Password - Saving Things:', () {
test('Save Patient', () async {
await resourceDao.updatePw(null, 'newPw');
final humanName = HumanName(family: 'Atreides', given: ['Duke']);
final patient = Patient(id: id, name: [humanName]);
final saved = await resourceDao.save('newPw', patient);
expect(saved.id, id);
expect((saved as Patient).name?[0], humanName);
});
test('Save Organization', () async {
final organization = Organization(id: id, name: 'FhirFli');
final saved = await resourceDao.save('newPw', organization);
expect(saved.id, id);
expect((saved as Organization).name, 'FhirFli');
});
test('Save Observation1', () async {
final observation1 = Observation(
id: Id('obs1'),
code: CodeableConcept(text: 'Observation #1'),
effectiveDateTime: FhirDateTime(DateTime(1981, 09, 18)),
);
final saved = await resourceDao.save('newPw', observation1);
expect(saved.id, Id('obs1'));
expect((saved as Observation).code.text, 'Observation #1');
});
test('Save Observation1 Again', () async {
final observation1 = Observation(
id: Id('obs1'),
code: CodeableConcept(text: 'Observation #1 - Updated'));
final saved = await resourceDao.save('newPw', observation1);
expect(saved.id, Id('obs1'));
expect((saved as Observation).code.text, 'Observation #1 - Updated');
expect(saved.meta?.versionId, Id('2'));
});
test('Save Observation2', () async {
final observation2 = Observation(
id: Id('obs2'),
code: CodeableConcept(text: 'Observation #2'),
effectiveDateTime: FhirDateTime(DateTime(1981, 09, 18)),
);
final saved = await resourceDao.save('newPw', observation2);
expect(saved.id, Id('obs2'));
expect((saved as Observation).code.text, 'Observation #2');
});
test('Save Observation3', () async {
final observation3 = Observation(
id: Id('obs3'),
code: CodeableConcept(text: 'Observation #3'),
effectiveDateTime: FhirDateTime(DateTime(1981, 09, 18)),
);
final saved = await resourceDao.save('newPw', observation3);
expect(saved.id, Id('obs3'));
expect((saved as Observation).code.text, 'Observation #3');
});
});
group('Password - Finding Things:', () {
test('Find 1st Patient', () async {
final search = await resourceDao.find('newPw',
resourceType: R4ResourceType.Patient, id: id);
final humanName = HumanName(family: 'Atreides', given: ['Duke']);
expect(search.length, 1);
expect((search[0] as Patient).name?[0], humanName);
});
test('Find 3rd Observation', () async {
final search = await resourceDao.find('newPw',
resourceType: R4ResourceType.Observation, id: Id('obs3'));
expect(search.length, 1);
expect(search[0].id, Id('obs3'));
expect((search[0] as Observation).code.text, 'Observation #3');
});
test('Find All Observations', () async {
final search = await resourceDao.getResourceType(
'newPw',
resourceTypes: [R4ResourceType.Observation],
);
expect(search.length, 3);
final idList = [];
for (final obs in search) {
idList.add(obs.id.toString());
}
expect(idList.contains('obs1'), true);
expect(idList.contains('obs2'), true);
expect(idList.contains('obs3'), true);
});
test('Find All (non-historical) Resources', () async {
final search = await resourceDao.getAll('newPw');
expect(search.length, 5);
final patList = search.toList();
final orgList = search.toList();
final obsList = search.toList();
patList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Patient);
orgList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Organization);
obsList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Observation);
expect(patList.length, 1);
expect(orgList.length, 1);
expect(obsList.length, 3);
});
});
group('Password - Deleting Things:', () {
test('Delete 2nd Observation', () async {
await resourceDao.delete(
'newPw', null, R4ResourceType.Observation, Id('obs2'), null, null);
final search = await resourceDao.getResourceType(
'newPw',
resourceTypes: [R4ResourceType.Observation],
);
expect(search.length, 2);
final idList = [];
for (final obs in search) {
idList.add(obs.id.toString());
}
expect(idList.contains('obs1'), true);
expect(idList.contains('obs2'), false);
expect(idList.contains('obs3'), true);
});
test('Delete All Observations', () async {
await resourceDao.deleteSingleType('newPw',
resourceType: R4ResourceType.Observation);
final search = await resourceDao.getAll('newPw');
expect(search.length, 2);
final patList = search.toList();
final orgList = search.toList();
patList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Patient);
orgList.retainWhere(
(resource) => resource.resourceType == R4ResourceType.Organization);
expect(patList.length, 1);
expect(patList.length, 1);
});
test('Delete All Resources', () async {
await resourceDao.deleteAllResources('newPw');
final search = await resourceDao.getAll('newPw');
expect(search.length, 0);
await resourceDao.updatePw('newPw', null);
});
});
}
Download Details:
Author: MayJuun
Source Code: https://github.com/MayJuun/fhir/tree/main/fhir_db
1677907260
Node.js client for the official ChatGPT API.
This package is a Node.js wrapper around ChatGPT by OpenAI. TS batteries included. ✨
March 1, 2023
The official OpenAI chat completions API has been released, and it is now the default for this package! 🔥
Method | Free? | Robust? | Quality? |
---|---|---|---|
ChatGPTAPI | ❌ No | ✅ Yes | ✅️ Real ChatGPT models |
ChatGPTUnofficialProxyAPI | ✅ Yes | ☑️ Maybe | ✅ Real ChatGPT |
Note: We strongly recommend using ChatGPTAPI
since it uses the officially supported API from OpenAI. We may remove support for ChatGPTUnofficialProxyAPI
in a future release.
ChatGPTAPI
- Uses the gpt-3.5-turbo-0301
model with the official OpenAI chat completions API (official, robust approach, but it's not free)ChatGPTUnofficialProxyAPI
- Uses an unofficial proxy server to access ChatGPT's backend API in a way that circumvents Cloudflare (uses the real ChatGPT and is pretty lightweight, but relies on a third-party server and is rate-limited)To run the CLI, you'll need an OpenAI API key:
export OPENAI_API_KEY="sk-TODO"
npx chatgpt "your prompt here"
By default, the response is streamed to stdout, the results are stored in a local config file, and every invocation starts a new conversation. You can use -c
to continue the previous conversation and --no-stream
to disable streaming.
Under the hood, the CLI uses ChatGPTAPI
with text-davinci-003
to mimic ChatGPT.
Usage:
$ chatgpt <prompt>
Commands:
<prompt> Ask ChatGPT a question
rm-cache Clears the local message cache
ls-cache Prints the local message cache path
For more info, run any command with the `--help` flag:
$ chatgpt --help
$ chatgpt rm-cache --help
$ chatgpt ls-cache --help
Options:
-c, --continue Continue last conversation (default: false)
-d, --debug Enables debug logging (default: false)
-s, --stream Streams the response (default: true)
-s, --store Enables the local message cache (default: true)
-t, --timeout Timeout in milliseconds
-k, --apiKey OpenAI API key
-n, --conversationName Unique name for the conversation
-h, --help Display this message
-v, --version Display version number
npm install chatgpt
Make sure you're using node >= 18
so fetch
is available (or node >= 14
if you install a fetch polyfill).
To use this module from Node.js, you need to pick between two methods:
Method | Free? | Robust? | Quality? |
---|---|---|---|
ChatGPTAPI | ❌ No | ✅ Yes | ✅️ Real ChatGPT models |
ChatGPTUnofficialProxyAPI | ✅ Yes | ☑️ Maybe | ✅ Real ChatGPT |
ChatGPTAPI
- Uses the gpt-3.5-turbo-0301
model with the official OpenAI chat completions API (official, robust approach, but it's not free). You can override the model, completion params, and system message to fully customize your assistant.
ChatGPTUnofficialProxyAPI
- Uses an unofficial proxy server to access ChatGPT's backend API in a way that circumvents Cloudflare (uses the real ChatGPT and is pretty lightweight, but relies on a third-party server and is rate-limited)
Both approaches have very similar APIs, so it should be simple to swap between them.
Note: We strongly recommend using ChatGPTAPI
since it uses the officially supported API from OpenAI. We may remove support for ChatGPTUnofficialProxyAPI
in a future release.
Sign up for an OpenAI API key and store it in your environment.
import { ChatGPTAPI } from 'chatgpt'
async function example() {
const api = new ChatGPTAPI({
apiKey: process.env.OPENAI_API_KEY
})
const res = await api.sendMessage('Hello World!')
console.log(res.text)
}
You can override the default model
(gpt-3.5-turbo-0301
) and any OpenAI chat completion params using completionParams
:
const api = new ChatGPTAPI({
apiKey: process.env.OPENAI_API_KEY,
completionParams: {
temperature: 0.5,
top_p: 0.8
}
})
If you want to track the conversation, you'll need to pass the parentMessageId
like this:
const api = new ChatGPTAPI({ apiKey: process.env.OPENAI_API_KEY })
// send a message and wait for the response
let res = await api.sendMessage('What is OpenAI?')
console.log(res.text)
// send a follow-up
res = await api.sendMessage('Can you expand on that?', {
parentMessageId: res.id
})
console.log(res.text)
// send another follow-up
res = await api.sendMessage('What were we talking about?', {
parentMessageId: res.id
})
console.log(res.text)
You can add streaming via the onProgress
handler:
const res = await api.sendMessage('Write a 500 word essay on frogs.', {
// print the partial response as the AI is "typing"
onProgress: (partialResponse) => console.log(partialResponse.text)
})
// print the full text at the end
console.log(res.text)
You can add a timeout using the timeoutMs
option:
// timeout after 2 minutes (which will also abort the underlying HTTP request)
const response = await api.sendMessage(
'write me a really really long essay on frogs',
{
timeoutMs: 2 * 60 * 1000
}
)
If you want to see more info about what's actually being sent to OpenAI's chat completions API, set the debug: true
option in the ChatGPTAPI
constructor:
const api = new ChatGPTAPI({
apiKey: process.env.OPENAI_API_KEY,
debug: true
})
We default to a basic systemMessage
. You can override this in either the ChatGPTAPI
constructor or sendMessage
:
const res = await api.sendMessage('what is the answer to the universe?', {
systemMessage: `You are ChatGPT, a large language model trained by OpenAI. You answer as concisely as possible for each responseIf you are generating a list, do not have too many items.
Current date: ${new Date().toISOString()}\n\n`
})
Note that we automatically handle appending the previous messages to the prompt and attempt to optimize for the available tokens (which defaults to 4096
).
Usage in CommonJS (Dynamic import)
async function example() {
// To use ESM in CommonJS, you can use a dynamic import
const { ChatGPTAPI } = await import('chatgpt')
const api = new ChatGPTAPI({ apiKey: process.env.OPENAI_API_KEY })
const res = await api.sendMessage('Hello World!')
console.log(res.text)
}
The API for ChatGPTUnofficialProxyAPI
is almost exactly the same. You just need to provide a ChatGPT accessToken
instead of an OpenAI API key.
import { ChatGPTUnofficialProxyAPI } from 'chatgpt'
async function example() {
const api = new ChatGPTUnofficialProxyAPI({
accessToken: process.env.OPENAI_ACCESS_TOKEN
})
const res = await api.sendMessage('Hello World!')
console.log(res.text)
}
See demos/demo-reverse-proxy for a full example:
npx tsx demos/demo-reverse-proxy.ts
ChatGPTUnofficialProxyAPI
messages also contain a conversationid
in addition to parentMessageId
, since the ChatGPT webapp can't reference messages across
You can override the reverse proxy by passing apiReverseProxyUrl
:
const api = new ChatGPTUnofficialProxyAPI({
accessToken: process.env.OPENAI_ACCESS_TOKEN,
apiReverseProxyUrl: 'https://your-example-server.com/api/conversation'
})
Known reverse proxies run by community members include:
Reverse Proxy URL | Author | Rate Limits | Last Checked |
---|---|---|---|
https://chat.duti.tech/api/conversation | @acheong08 | 120 req/min by IP | 2/19/2023 |
https://gpt.pawan.krd/backend-api/conversation | @PawanOsman | ? | 2/19/2023 |
Note: info on how the reverse proxies work is not being published at this time in order to prevent OpenAI from disabling access.
To use ChatGPTUnofficialProxyAPI
, you'll need an OpenAI access token from the ChatGPT webapp. To do this, you can use any of the following methods which take an email
and password
and return an access token:
These libraries work with email + password accounts (e.g., they do not support accounts where you auth via Microsoft / Google).
Alternatively, you can manually get an accessToken
by logging in to the ChatGPT webapp and then opening https://chat.openai.com/api/auth/session
, which will return a JSON object containing your accessToken
string.
Access tokens last for days.
Note: using a reverse proxy will expose your access token to a third-party. There shouldn't be any adverse effects possible from this, but please consider the risks before using this method.
See the auto-generated docs for more info on methods and parameters.
Most of the demos use ChatGPTAPI
. It should be pretty easy to convert them to use ChatGPTUnofficialProxyAPI
if you'd rather use that approach. The only thing that needs to change is how you initialize the api with an accessToken
instead of an apiKey
.
To run the included demos:
OPENAI_API_KEY
in .envA basic demo is included for testing purposes:
npx tsx demos/demo.ts
A demo showing on progress handler:
npx tsx demos/demo-on-progress.ts
The on progress demo uses the optional onProgress
parameter to sendMessage
to receive intermediary results as ChatGPT is "typing".
npx tsx demos/demo-conversation.ts
A persistence demo shows how to store messages in Redis for persistence:
npx tsx demos/demo-persistence.ts
Any keyv adaptor is supported for persistence, and there are overrides if you'd like to use a different way of storing / retrieving messages.
Note that persisting message is required for remembering the context of previous conversations beyond the scope of the current Node.js process, since by default, we only store messages in memory. Here's an external demo of using a completely custom database solution to persist messages.
Note: Persistence is handled automatically when using ChatGPTUnofficialProxyAPI
because it is connecting indirectly to ChatGPT.
All of these awesome projects are built using the chatgpt
package. 🤯
If you create a cool integration, feel free to open a PR and add it to the list.
node >= 14
.fetch
is installed.chatgpt
, we recommend using it only from your backend APIPrevious Updates
Feb 19, 2023
We now provide three ways of accessing the unofficial ChatGPT API, all of which have tradeoffs:
Method | Free? | Robust? | Quality? |
---|---|---|---|
ChatGPTAPI | ❌ No | ✅ Yes | ☑️ Mimics ChatGPT |
ChatGPTUnofficialProxyAPI | ✅ Yes | ☑️ Maybe | ✅ Real ChatGPT |
ChatGPTAPIBrowser (v3) | ✅ Yes | ❌ No | ✅ Real ChatGPT |
Note: I recommend that you use either ChatGPTAPI
or ChatGPTUnofficialProxyAPI
.
ChatGPTAPI
- Uses text-davinci-003
to mimic ChatGPT via the official OpenAI completions API (most robust approach, but it's not free and doesn't use a model fine-tuned for chat)ChatGPTUnofficialProxyAPI
- Uses an unofficial proxy server to access ChatGPT's backend API in a way that circumvents Cloudflare (uses the real ChatGPT and is pretty lightweight, but relies on a third-party server and is rate-limited)ChatGPTAPIBrowser
- (deprecated; v3.5.1 of this package) Uses Puppeteer to access the official ChatGPT webapp (uses the real ChatGPT, but very flaky, heavyweight, and error prone)Feb 5, 2023
OpenAI has disabled the leaked chat model we were previously using, so we're now defaulting to text-davinci-003
, which is not free.
We've found several other hidden, fine-tuned chat models, but OpenAI keeps disabling them, so we're searching for alternative workarounds.
Feb 1, 2023
This package no longer requires any browser hacks – it is now using the official OpenAI completions API with a leaked model that ChatGPT uses under the hood. 🔥
import { ChatGPTAPI } from 'chatgpt'
const api = new ChatGPTAPI({
apiKey: process.env.OPENAI_API_KEY
})
const res = await api.sendMessage('Hello World!')
console.log(res.text)
Please upgrade to chatgpt@latest
(at least v4.0.0). The updated version is significantly more lightweight and robust compared with previous versions. You also don't have to worry about IP issues or rate limiting.
Huge shoutout to @waylaidwanderer for discovering the leaked chat model!
If you run into any issues, we do have a pretty active Discord with a bunch of ChatGPT hackers from the Node.js & Python communities.
Lastly, please consider starring this repo and following me on twitter to help support the project.
Thanks && cheers, Travis
Author: Transitive-bullshit
Source Code: https://github.com/transitive-bullshit/chatgpt-api
License: MIT license
1675513260
When building JavaScript applications, you may encounter scenarios where you need to build objects in a certain, predefined fashion, or reuse a common class by modifying or adapting it to multiple use cases.
It is, of course, not convenient to solve these problems again and again.
This is where JavaScript design patterns come to your rescue.
JavaScript design patterns provide you with a structured, repeatable way to tackle commonly occurring problems in JavaScript development.
In this guide, we will take a look at what JavaScript design patterns are and how to use them in your JavaScript apps.
JavaScript design patterns are repeatable template solutions for frequently occurring problems in JavaScript app development.
The idea is simple: Programmers all around the world, since the dawn of development, have faced sets of recurring issues when developing apps. Over time, some developers chose to document tried and tested ways to tackle these issues so others could refer back to the solutions with ease.
As more and more developers chose to use these solutions and recognized their efficiency in solving their problems, they became accepted as a standard way of problem-solving and were given the name “design patterns.”
As the importance of design patterns became better understood, these were further developed and standardized. Most modern design patterns have a defined structure now, are organized under multiple categories, and are taught in computer science-related degrees as independent topics.
Here are some of the most popular classifications of JavaScript design patterns.
Creational design patterns are those that help solve problems around creating and managing new object instances in JavaScript. It can be as simple as limiting a class to having just one object or as complex as defining an intricate method of handpicking and adding each feature in a JavaScript object.
Some examples of creational design patterns include Singleton, Factory, Abstract Factory, and Builder, among others.
Structural design patterns are those that help solve problems around managing the structure (or schema) of JavaScript objects. These problems could include creating a relationship between two unlike objects or abstracting some features of an object away forspecific users.
A few examples of structural design patterns include Adapter, Bridge, Composite, and Facade.
Behavioral design patterns are those that help solve problems around how control (and responsibility) is passed between various objects. These problems could involve controlling access to a linked list or establishing a single entity that can control access to multiple types of objects.
Some examples of behavioral design patterns include Command, Iterator, Memento, and Observer.
Concurrency design patterns are those that help solve problems around multi-threading and multitasking. These problems could entail maintaining an active object among multiple available objects or handling multiple events supplied to a system by demultiplexing incoming input and handling it piece by piece.
A few examples of concurrency design patterns include active object, nuclear react, and scheduler.
Architectural design patterns are those that help solve problems around software design in a broad sense. These generally are related to how to design your system and ensure high availability, mitigate risks, and avoid performance bottlenecks.
Two examples of architectural design patterns are MVC and MVVM.
Almost all design patterns can be broken down into a set of four important components. They are:
If you’re looking to learn more about design patterns and their inception, MSU has some succinct study material that you can refer to.
There are multiple reasons why you would want to use design patterns:
Now that you understand what a design pattern is made of and why you need them, let’s take a deeper dive into how some of the most commonly used JavaScript design patterns can be implemented in a JavaScript app.
Let’s start the discussion with some fundamental, easy-to-learn creational design patterns.
The Singleton pattern is one of the most commonly used design patterns across the software development industry. The problem that it aims to solve is to maintain only a single instance of a class. This can come in handy when instantiating objects that are resource-intensive, such as database handlers.
Here’s how you can implement it in JavaScript:
function SingletonFoo() {
let fooInstance = null;
// For our reference, let's create a counter that will track the number of active instances
let count = 0;
function printCount() {
console.log("Number of instances: " + count);
}
function init() {
// For our reference, we'll increase the count by one whenever init() is called
count++;
// Do the initialization of the resource-intensive object here and return it
return {}
}
function createInstance() {
if (fooInstance == null) {
fooInstance = init();
}
return fooInstance;
}
function closeInstance() {
count--;
fooInstance = null;
}
return {
initialize: createInstance,
close: closeInstance,
printCount: printCount
}
}
let foo = SingletonFoo();
foo.printCount() // Prints 0
foo.initialize()
foo.printCount() // Prints 1
foo.initialize()
foo.printCount() // Still prints 1
foo.initialize()
foo.printCount() // Still 1
foo.close()
foo.printCount() // Prints 0
While it serves the purpose well, the Singleton pattern is known to make debugging difficult since it masks dependencies and controls the access to initializing or destroying a class’s instances.
The Factory method is also one of the most popular design patterns. The problem that the Factory method aims to solve is creating objects without using the conventional constructor. Instead, it takes in the configuration (or description) of the object that you want and returns the newly created object.
Here’s how you can implement it in JavaScript:
function Factory() {
this.createDog = function (breed) {
let dog;
if (breed === "labrador") {
dog = new Labrador();
} else if (breed === "bulldog") {
dog = new Bulldog();
} else if (breed === "golden retriever") {
dog = new GoldenRetriever();
} else if (breed === "german shepherd") {
dog = new GermanShepherd();
}
dog.breed = breed;
dog.printInfo = function () {
console.log("\n\nBreed: " + dog.breed + "\nShedding Level (out of 5): " + dog.sheddingLevel + "\nCoat Length: " + dog.coatLength + "\nCoat Type: " + dog.coatType)
}
return dog;
}
}
function Labrador() {
this.sheddingLevel = 4
this.coatLength = "short"
this.coatType = "double"
}
function Bulldog() {
this.sheddingLevel = 3
this.coatLength = "short"
this.coatType = "smooth"
}
function GoldenRetriever() {
this.sheddingLevel = 4
this.coatLength = "medium"
this.coatType = "double"
}
function GermanShepherd() {
this.sheddingLevel = 4
this.coatLength = "medium"
this.coatType = "double"
}
function run() {
let dogs = [];
let factory = new Factory();
dogs.push(factory.createDog("labrador"));
dogs.push(factory.createDog("bulldog"));
dogs.push(factory.createDog("golden retriever"));
dogs.push(factory.createDog("german shepherd"));
for (var i = 0, len = dogs.length; i < len; i++) {
dogs[i].printInfo();
}
}
run()
/**
Output:
Breed: labrador
Shedding Level (out of 5): 4
Coat Length: short
Coat Type: double
Breed: bulldog
Shedding Level (out of 5): 3
Coat Length: short
Coat Type: smooth
Breed: golden retriever
Shedding Level (out of 5): 4
Coat Length: medium
Coat Type: double
Breed: german shepherd
Shedding Level (out of 5): 4
Coat Length: medium
Coat Type: double
*/
The Factory design pattern controls how the objects will be created and provides you with a quick way of creating new objects, as well as a uniform interface that defines the properties that your objects will have. You can add as many dog breeds as you want, but as long as the methods and properties exposed by the breed types remain the same, they will work flawlessly.
However, note that the Factory pattern can often lead to a large number of classes that can be difficult to manage.
The Abstract Factory method takes the Factory method up a level by making factories abstract and thus replaceable without the calling environment knowing the exact factory used or its internal workings. The calling environment only knows that all the factories have a set of common methods that it can call to perform the instantiation action.
This is how it can be implemented using the previous example:
// A factory to create dogs
function DogFactory() {
// Notice that the create function is now createPet instead of createDog, since we need
// it to be uniform across the other factories that will be used with this
this.createPet = function (breed) {
let dog;
if (breed === "labrador") {
dog = new Labrador();
} else if (breed === "pug") {
dog = new Pug();
}
dog.breed = breed;
dog.printInfo = function () {
console.log("\n\nType: " + dog.type + "\nBreed: " + dog.breed + "\nSize: " + dog.size)
}
return dog;
}
}
// A factory to create cats
function CatFactory() {
this.createPet = function (breed) {
let cat;
if (breed === "ragdoll") {
cat = new Ragdoll();
} else if (breed === "singapura") {
cat = new Singapura();
}
cat.breed = breed;
cat.printInfo = function () {
console.log("\n\nType: " + cat.type + "\nBreed: " + cat.breed + "\nSize: " + cat.size)
}
return cat;
}
}
// Dog and cat breed definitions
function Labrador() {
this.type = "dog"
this.size = "large"
}
function Pug() {
this.type = "dog"
this.size = "small"
}
function Ragdoll() {
this.type = "cat"
this.size = "large"
}
function Singapura() {
this.type = "cat"
this.size = "small"
}
function run() {
let pets = [];
// Initialize the two factories
let catFactory = new CatFactory();
let dogFactory = new DogFactory();
// Create a common petFactory that can produce both cats and dogs
// Set it to produce dogs first
let petFactory = dogFactory;
pets.push(petFactory.createPet("labrador"));
pets.push(petFactory.createPet("pug"));
// Set the petFactory to produce cats
petFactory = catFactory;
pets.push(petFactory.createPet("ragdoll"));
pets.push(petFactory.createPet("singapura"));
for (var i = 0, len = pets.length; i < len; i++) {
pets[i].printInfo();
}
}
run()
/**
Output:
Type: dog
Breed: labrador
Size: large
Type: dog
Breed: pug
Size: small
Type: cat
Breed: ragdoll
Size: large
Type: cat
Breed: singapura
Size: small
*/
The Abstract Factory pattern makes it easy for you to exchange concrete factories easily, and it helps promote uniformity between factories and the products created. However, it can become difficult to introduce new kinds of products since you’d have to make changes in multiple classes to accommodate new methods/properties.
The Builder pattern is one of the most complex yet flexible creational JavaScript design patterns. It allows you to build each feature into your product one by one, providing you full control over how your object is built while still abstracting away the internal details.
In the intricate example below, you’ll see the Builder design pattern in action along with Director to help make Pizzas!
// Here's the PizzaBuilder (you can also call it the chef)
function PizzaBuilder() {
let base
let sauce
let cheese
let toppings = []
// The definition of pizza is hidden from the customers
function Pizza(base, sauce, cheese, toppings) {
this.base = base
this.sauce = sauce
this.cheese = cheese
this.toppings = toppings
this.printInfo = function() {
console.log("This pizza has " + this.base + " base with " + this.sauce + " sauce "
+ (this.cheese !== undefined ? "with cheese. " : "without cheese. ")
+ (this.toppings.length !== 0 ? "It has the following toppings: " + toppings.toString() : ""))
}
}
// You can request the PizzaBuilder (/chef) to perform any of the following actions on your pizza
return {
addFlatbreadBase: function() {
base = "flatbread"
return this;
},
addTomatoSauce: function() {
sauce = "tomato"
return this;
},
addAlfredoSauce: function() {
sauce = "alfredo"
return this;
},
addCheese: function() {
cheese = "parmesan"
return this;
},
addOlives: function() {
toppings.push("olives")
return this
},
addJalapeno: function() {
toppings.push("jalapeno")
return this
},
cook: function() {
if (base === null){
console.log("Can't make a pizza without a base")
return
}
return new Pizza(base, sauce, cheese, toppings)
}
}
}
// This is the Director for the PizzaBuilder, aka the PizzaShop.
// It contains a list of preset steps that can be used to prepare common pizzas (aka recipes!)
function PizzaShop() {
return {
makePizzaMargherita: function() {
pizzaBuilder = new PizzaBuilder()
pizzaMargherita = pizzaBuilder.addFlatbreadBase().addTomatoSauce().addCheese().addOlives().cook()
return pizzaMargherita
},
makePizzaAlfredo: function() {
pizzaBuilder = new PizzaBuilder()
pizzaAlfredo = pizzaBuilder.addFlatbreadBase().addAlfredoSauce().addCheese().addJalapeno().cook()
return pizzaAlfredo
},
makePizzaMarinara: function() {
pizzaBuilder = new PizzaBuilder()
pizzaMarinara = pizzaBuilder.addFlatbreadBase().addTomatoSauce().addOlives().cook()
return pizzaMarinara
}
}
}
// Here's where the customer can request pizzas from
function run() {
let pizzaShop = new PizzaShop()
// You can ask for one of the popular pizza recipes...
let pizzaMargherita = pizzaShop.makePizzaMargherita()
pizzaMargherita.printInfo()
// Output: This pizza has flatbread base with tomato sauce with cheese. It has the following toppings: olives
let pizzaAlfredo = pizzaShop.makePizzaAlfredo()
pizzaAlfredo.printInfo()
// Output: This pizza has flatbread base with alfredo sauce with cheese. It has the following toppings: jalapeno
let pizzaMarinara = pizzaShop.makePizzaMarinara()
pizzaMarinara.printInfo()
// Output: This pizza has flatbread base with tomato sauce without cheese. It has the following toppings: olives
// Or send your custom request directly to the chef!
let chef = PizzaBuilder()
let customPizza = chef.addFlatbreadBase().addTomatoSauce().addCheese().addOlives().addJalapeno().cook()
customPizza.printInfo()
// Output: This pizza has flatbread base with tomato sauce with cheese. It has the following toppings: olives,jalapeno
}
run()
You can pair up the Builder with a Director, as shown by the PizzaShop
class in the example above, to predefine a set of steps to follow every time to build a standard variant of your product, i.e., a specific recipe for your pizzas.
The only issue with this design pattern is that it is quite complex to set up and maintain. Adding new features this way is simpler than the Factory method, though.
The Prototype design pattern is a quick and simple way of creating new objects from existing objects by cloning them.
A prototype object is first created, which can be cloned multiple times to create new objects. It comes in handy when directly instantiating an object is a more resource-intensive operation compared to creating a copy of an existing one.
In the example below, you’ll see how you can use the Prototype pattern to create new documents based on a set template document:
// Defining how a document would look like
function Document() {
this.header = "Acme Co"
this.footer = "For internal use only"
this.pages = 2
this.text = ""
this.addText = function(text) {
this.text += text
}
// Method to help you see the contents of the object
this.printInfo = function() {
console.log("\n\nHeader: " + this.header + "\nFooter: " + this.footer + "\nPages: " + this.pages + "\nText: " + this.text)
}
}
// A protype (or template) for creating new blank documents with boilerplate information
function DocumentPrototype(baseDocument) {
this.baseDocument = baseDocument
// This is where the magic happens. A new document object is created and is assigned the values of the current object
this.clone = function() {
let document = new Document();
document.header = this.baseDocument.header
document.footer = this.baseDocument.footer
document.pages = this.baseDocument.pages
document.text = this.baseDocument.text
return document
}
}
function run() {
// Create a document to use as the base for the prototype
let baseDocument = new Document()
// Make some changes to the prototype
baseDocument.addText("This text was added before cloning and will be common in both documents. ")
let prototype = new DocumentPrototype(baseDocument)
// Create two documents from the prototype
let doc1 = prototype.clone()
let doc2 = prototype.clone()
// Make some changes to both objects
doc1.pages = 3
doc1.addText("This is document 1")
doc2.addText("This is document 2")
// Print their values
doc1.printInfo()
/* Output:
Header: Acme Co
Footer: For internal use only
Pages: 3
Text: This text was added before cloning and will be common in both documents. This is document 1
*/
doc2.printInfo()
/** Output:
Header: Acme Co
Footer: For internal use only
Pages: 2
Text: This text was added before cloning and will be common in both documents. This is document 2
*/
}
run()
The Prototype method works great for cases where a large part of your objects share the same values, or when creating a new object altogether is quite costly. However, it feels like overkill in cases where you don’t need more than a few instances of the class.
Structural design patterns help you organize your business logic by providing tried and tested ways of structuring your classes. There are a variety of structural design patterns that each cater to unique use cases.
A common problem when building apps is allowing collaboration between incompatible classes.
A good example to understand this is while maintaining backward compatibility. If you write a new version of a class, you’d naturally want it to be easily usable in all places where the old version worked. However, if you make breaking changes like removing or updating methods that were crucial to the functioning of the old version, you might end up with a class that needs all of its clients to be updated in order to be run.
In such cases, the Adapter design pattern can help.
The Adapter design pattern provides you with an abstraction that bridges the gap between the new class’s methods and properties and the old class’s methods and properties. It has the same interface as the old class, but it contains logic to map old methods to the new methods to execute similar operations. This is similar to how a power plug socket acts as an adapter between a US-style plug and a European-style plug.
Here’s an example:
// Old bot
function Robot() {
this.walk = function(numberOfSteps) {
// code to make the robot walk
console.log("walked " + numberOfSteps + " steps")
}
this.sit = function() {
// code to make the robot sit
console.log("sit")
}
}
// New bot that does not have the walk function anymore
// but instead has functions to control each step independently
function AdvancedRobot(botName) {
// the new bot has a name as well
this.name = botName
this.sit = function() {
// code to make the robot sit
console.log("sit")
}
this.rightStepForward = function() {
// code to take 1 step from right leg forward
console.log("right step forward")
}
this.leftStepForward = function () {
// code to take 1 step from left leg forward
console.log("left step forward")
}
}
function RobotAdapter(botName) {
// No references to the old interfact since that is usually
// phased out of development
const robot = new AdvancedRobot(botName)
// The adapter defines the walk function by using the
// two step controls. You now have room to choose which leg to begin/end with,
// and do something at each step.
this.walk = function(numberOfSteps) {
for (let i=0; i<numberOfSteps; i++) {
if (i % 2 === 0) {
robot.rightStepForward()
} else {
robot.leftStepForward()
}
}
}
this.sit = robot.sit
}
function run() {
let robot = new Robot()
robot.sit()
// Output: sit
robot.walk(5)
// Output: walked 5 steps
robot = new RobotAdapter("my bot")
robot.sit()
// Output: sit
robot.walk(5)
// Output:
// right step forward
// left step forward
// right step forward
// left step forward
// right step forward
}
run()
The main issue with this design pattern is that it adds complexity to your source code. You already needed to maintain two different classes, and now you have another class — the Adapter — to maintain.
Expanding upon the Adapter pattern, the Bridge design pattern provides both the class and the client with separate interfaces so that they may both work even in cases of incompatible native interfaces.
It helps in developing a very loosely coupled interface between the two types of objects. This also helps in enhancing the extensibility of the interfaces and their implementations for maximum flexibility.
Here’s how you can use it:
// The TV and speaker share the same interface
function TV() {
this.increaseVolume = function() {
// logic to increase TV volume
}
this.decreaseVolume = function() {
// logic to decrease TV volume
}
this.mute = function() {
// logic to mute TV audio
}
}
function Speaker() {
this.increaseVolume = function() {
// logic to increase speaker volume
}
this.decreaseVolume = function() {
// logic to decrease speaker volume
}
this.mute() = function() {
// logic to mute speaker audio
}
}
// The two remotes make use of the same common interface
// that supports volume up and volume down features
function SimpleRemote(device) {
this.pressVolumeDownKey = function() {
device.decreaseVolume()
}
this.pressVolumeUpKey = function() {
device.increaseVolume()
}
}
function AdvancedRemote(device) {
this.pressVolumeDownKey = function() {
device.decreaseVolume()
}
this.pressVolumeUpKey = function() {
device.increaseVolume()
}
this.pressMuteKey = function() {
device.mute()
}
}
function run() {
let tv = new TV()
let speaker = new Speaker()
let tvSimpleRemote = new SimpleRemote(tv)
let tvAdvancedRemote = new AdvancedRemote(tv)
let speakerSimpleRemote = new SimpleRemote(speaker)
let speakerAdvancedRemote = new AdvancedRemote(speaker)
// The methods listed in pair below will have the same effect
// on their target devices
tvSimpleRemote.pressVolumeDownKey()
tvAdvancedRemote.pressVolumeDownKey()
tvSimpleRemote.pressVolumeUpKey()
tvAdvancedRemote.pressVolumeUpKey()
// The advanced remote has additional functionality
tvAdvancedRemote.pressMuteKey()
speakerSimpleRemote.pressVolumeDownKey()
speakerAdvancedRemote.pressVolumeDownKey()
speakerSimpleRemote.pressVolumeUpKey()
speakerAdvancedRemote.pressVolumeUpKey()
speakerAdvancedRemote.pressMuteKey()
}
As you might have already guessed, the Bridge pattern greatly increases the complexity of the codebase. Also, most interfaces usually end up with only one implementation in real-world use cases, so you don’t really benefit from the code reusability much.
The Composite design pattern helps you structure and manage similar objects and entities easily. The basic idea behind the Composite pattern is that the objects and their logical containers can be represented using a single abstract class (that can store data/methods related to the object and references to itself for the container).
It makes the most sense to use the Composite pattern when your data model resembles a tree structure. However, you shouldn’t try to turn a non-tree data model into a tree-like data model just for the sake of using the Composite pattern, as doing so can often take away a lot of flexibility.
In the example below, you’ll see how you can use the Composite design pattern to construct a packaging system for ecommerce products that can also calculate the total order value per package:
// A product class, that acts as a Leaf node
function Product(name, price) {
this.name = name
this.price = price
this.getTotalPrice = function() {
return this.price
}
}
// A box class, that acts as a parent/child node
function Box(name) {
this.contents = []
this.name = name
// Helper function to add an item to the box
this.add = function(content){
this.contents.push(content)
}
// Helper function to remove an item from the box
this.remove = function() {
var length = this.contents.length;
for (var i = 0; i < length; i++) {
if (this.contents[i] === child) {
this.contents.splice(i, 1);
return;
}
}
}
// Helper function to get one item from the box
this.getContent = function(position) {
return this.contents[position]
}
// Helper function to get the total count of the items in the box
this.getTotalCount = function() {
return this.contents.length
}
// Helper function to calculate the total price of all items in the box
this.getTotalPrice = function() {
let totalPrice = 0;
for (let i=0; i < this.getTotalCount(); i++){
totalPrice += this.getContent(i).getTotalPrice()
}
return totalPrice
}
}
function run() {
// Let's create some electronics
const mobilePhone = new Product("mobile phone," 1000)
const phoneCase = new Product("phone case," 30)
const screenProtector = new Product("screen protector," 20)
// and some stationery products
const pen = new Product("pen," 2)
const pencil = new Product("pencil," 0.5)
const eraser = new Product("eraser," 0.5)
const stickyNotes = new Product("sticky notes," 10)
// and put them in separate boxes
const electronicsBox = new Box("electronics")
electronicsBox.add(mobilePhone)
electronicsBox.add(phoneCase)
electronicsBox.add(screenProtector)
const stationeryBox = new Box("stationery")
stationeryBox.add(pen)
stationeryBox.add(pencil)
stationeryBox.add(eraser)
stationeryBox.add(stickyNotes)
// and finally, put them into one big box for convenient shipping
const package = new Box('package')
package.add(electronicsBox)
package.add(stationeryBox)
// Here's an easy way to calculate the total order value
console.log("Total order price: USD " + package.getTotalPrice())
// Output: USD 1063
}
run()
The biggest downside to using the Composite pattern is that changes to the component interfaces can be very challenging in the future. Designing the interfaces takes time and effort, and the tree-like nature of the data model can make it very tough to make changes as you wish.
The Decorator pattern helps you add new features to existing objects by simply wrapping them up inside a new object. It’s similar to how you can wrap an already-wrapped gift box with new wrapping paper as many times as you want: Each wrap allows you to add as many features as you’d like, so it’s great on the flexibility front.
From a technical perspective, no inheritance is involved, so there’sgreater freedom when designing business logic.
In the example below, you’ll see how the Decorator pattern helps to add more features to a standard Customer
class:
function Customer(name, age) {
this.name = name
this.age = age
this.printInfo = function() {
console.log("Customer:\nName : " + this.name + " | Age: " + this.age)
}
}
function DecoratedCustomer(customer, location) {
this.customer = customer
this.name = customer.name
this.age = customer.age
this.location = location
this.printInfo = function() {
console.log("Decorated Customer:\nName: " + this.name + " | Age: " + this.age + " | Location: " + this.location)
}
}
function run() {
let customer = new Customer("John," 25)
customer.printInfo()
// Output:
// Customer:
// Name : John | Age: 25
let decoratedCustomer = new DecoratedCustomer(customer, "FL")
decoratedCustomer.printInfo()
// Output:
// Customer:
// Name : John | Age: 25 | Location: FL
}
run()
The downsides of this pattern include high code complexity since there is no standard pattern defined for adding new features using decorators. You might end up with a lot of non-uniform and/or similar decorators at the end of your software development lifecycle.
If you’re not careful while designing the decorators, you might end up designing some decorators to be logically dependent on others. If this is not resolved, removing or restructuring decorators later down the line can wreak havoc on your application’s stability.
When building most real-world applications, the business logic usually turns out to be quite complex by the time you are done. You might end up with multiple objects and methods being involved in executing core operations in your app. Maintaining track of their initializations, dependencies, the correct order of method execution, etc., can be quite tricky and error-prone if not done correctly.
The Facade design pattern helps you create an abstraction between the environment that invokes the above-mentioned operations and the objects and methods involved in completing those operations. This abstraction houses the logic for initializing the objects, tracking their dependencies, and other important activities. The calling environment has no information on how an operation is executed. You can freely update the logic without making any breaking changes to the calling client.
Here’s how you can use it in an application:
/**
* Let's say you're trying to build an online store. It will have multiple components and
* complex business logic. In the example below, you will find a tiny segment of an online
* store composed together using the Facade design pattern. The various manager and helper
* classes are defined first of all.
*/
function CartManager() {
this.getItems = function() {
// logic to return items
return []
}
this.clearCart = function() {
// logic to clear cart
}
}
function InvoiceManager() {
this.createInvoice = function(items) {
// logic to create invoice
return {}
}
this.notifyCustomerOfFailure = function(invoice) {
// logic to notify customer
}
this.updateInvoicePaymentDetails = function(paymentResult) {
// logic to update invoice after payment attempt
}
}
function PaymentProcessor() {
this.processPayment = function(invoice) {
// logic to initiate and process payment
return {}
}
}
function WarehouseManager() {
this.prepareForShipping = function(items, invoice) {
// logic to prepare the items to be shipped
}
}
// This is where facade comes in. You create an additional interface on top of your
// existing interfaces to define the business logic clearly. This interface exposes
// very simple, high-level methods for the calling environment.
function OnlineStore() {
this.name = "Online Store"
this.placeOrder = function() {
let cartManager = new CartManager()
let items = cartManager.getItems()
let invoiceManager = new InvoiceManager()
let invoice = invoiceManager.createInvoice(items)
let paymentResult = new PaymentProcessor().processPayment(invoice)
invoiceManager.updateInvoicePaymentDetails(paymentResult)
if (paymentResult.status === 'success') {
new WarehouseManager().prepareForShipping(items, invoice)
cartManager.clearCart()
} else {
invoiceManager.notifyCustomerOfFailure(invoice)
}
}
}
// The calling environment is unaware of what goes on when somebody clicks a button to
// place the order. You can easily change the underlying business logic without breaking
// your calling environment.
function run() {
let onlineStore = new OnlineStore()
onlineStore.placeOrder()
}
A downside to using the Facade pattern is that it adds an additional layer of abstraction between your business logic and client, thereby requiring additional maintenance. More often than not, this increases the overall complexity of the codebase.
On top of that, the Facade
class becomes a mandatory dependency on your app’s functioning — meaning any errors in the Facade
class directly impact the functioning of your app.
The Flyweight pattern helps you solve problems that involve objects with repeating components in memory-efficient ways by helping you reuse the common components of your object pool. This helps reduce the load on the memory and results in faster execution times as well.
In the example below, a large sentence is stored in the memory using the Flyweight design pattern. Instead of storing each character as it occurs, the program identifies the set of distinct characters that have been used to write the paragraph and their types (number or alphabet) and builds reusable flyweights for each character that contains details of which character and type are stored.
Then the main array just stores a list of references to these flyweights in the order that they occur in the sentence instead of storing an instance of the character object whenever it occurs.
This reduces the memory taken by the sentence by half. Bear in mind that this is a very basic explanation of how text processors store text.
// A simple Character class that stores the value, type, and position of a character
function Character(value, type, position) {
this.value = value
this.type = type
this.position = position
}
// A Flyweight class that stores character value and type combinations
function CharacterFlyweight(value, type) {
this.value = value
this.type = type
}
// A factory to automatically create the flyweights that are not present in the list,
// and also generate a count of the total flyweights in the list
const CharacterFlyweightFactory = (function () {
const flyweights = {}
return {
get: function (value, type) {
if (flyweights[value + type] === undefined)
flyweights[value + type] = new CharacterFlyweight(value, type)
return flyweights[value + type]
},
count: function () {
let count = 0;
for (var f in flyweights) count++;
return count;
}
}
})()
// An enhanced Character class that uses flyweights to store references
// to recurring value and type combinations
function CharacterWithFlyweight(value, type, position) {
this.flyweight = CharacterFlyweightFactory.get(value, type)
this.position = position
}
// A helper function to define the type of a character
// It identifies numbers as N and everything as A (for alphabets)
function getCharacterType(char) {
switch (char) {
case "0":
case "1":
case "2":
case "3":
case "4":
case "5":
case "6":
case "7":
case "8":
case "9": return "N"
default:
return "A"
}
}
// A list class to create an array of Characters from a given string
function CharactersList(str) {
chars = []
for (let i = 0; i < str.length; i++) {
const char = str[i]
chars.push(new Character(char, getCharacterType(char), i))
}
return chars
}
// A list class to create an array of CharacterWithFlyweights from a given string
function CharactersWithFlyweightsList(str) {
chars = []
for (let i = 0; i " + charactersList.length)
// Output: Character count -> 656
// The number of flyweights created is only 31, since only 31 characters are used to write the
// entire paragraph. This means that to store 656 characters, a total of
// (31 * 2 + 656 * 1 = 718) memory blocks are used instead of (656 * 3 = 1968) which would have
// used by the standard array.
// (We have assumed each variable to take up one memory block for simplicity. This
// may vary in real-life scenarios)
console.log("Flyweights created -> " + CharacterFlyweightFactory.count())
// Output: Flyweights created -> 31
}
run()
As you may have already noticed, the Flyweight pattern adds to the complexity of your software design by not being particularly intuitive. So, if saving memory isn’t a pressing concern for your app, Flyweight’s added complexity can do more bad than good.
Moreover, flyweights trade memory for processing efficiency, so if you’re short on CPU cycles, Flyweight isn’t a good solution for you.
The Proxy pattern helps you substitute an object for another object. In other terms, proxy objects can take the place of actual objects (that they’re a proxy of) and control access to the object. These proxy objects can be used to perform some actions before or after an invocation request is passed on to the actual object.
In the example below, you’ll see how access to a database instance is controlled via a proxy that performs some basic validation checks on the requests before allowing them through:
function DatabaseHandler() {
const data = {}
this.set = function (key, val) {
data[key] = val;
}
this.get = function (key, val) {
return data[key]
}
this.remove = function (key) {
data[key] = null;
}
}
function DatabaseProxy(databaseInstance) {
this.set = function (key, val) {
if (key === "") {
console.log("Invalid input")
return
}
if (val === undefined) {
console.log("Setting value to undefined not allowed!")
return
}
databaseInstance.set(key, val)
}
this.get = function (key) {
if (databaseInstance.get(key) === null) {
console.log("Element deleted")
}
if (databaseInstance.get(key) === undefined) {
console.log("Element not created")
}
return databaseInstance.get(key)
}
this.remove = function (key) {
if (databaseInstance.get(key) === undefined) {
console.log("Element not added")
return
}
if (databaseInstance.get(key) === null) {
console.log("Element removed already")
return
}
return databaseInstance.remove(key)
}
}
function run() {
let databaseInstance = new DatabaseHandler()
databaseInstance.set("foo," "bar")
databaseInstance.set("foo," undefined)
console.log("#1: " + databaseInstance.get("foo"))
// #1: undefined
console.log("#2: " + databaseInstance.get("baz"))
// #2: undefined
databaseInstance.set("," "something")
databaseInstance.remove("foo")
console.log("#3: " + databaseInstance.get("foo"))
// #3: null
databaseInstance.remove("foo")
databaseInstance.remove("baz")
// Create a fresh database instance to try the same operations
// using the proxy
databaseInstance = new DatabaseHandler()
let proxy = new DatabaseProxy(databaseInstance)
proxy.set("foo," "bar")
proxy.set("foo," undefined)
// Proxy jumps in:
// Output: Setting value to undefined not allowed!
console.log("#1: " + proxy.get("foo"))
// Original value is retained:
// Output: #1: bar
console.log("#2: " + proxy.get("baz"))
// Proxy jumps in again
// Output:
// Element not created
// #2: undefined
proxy.set("," "something")
// Proxy jumps in again
// Output: Invalid input
proxy.remove("foo")
console.log("#3: " + proxy.get("foo"))
// Proxy jumps in again
// Output:
// Element deleted
// #3: null
proxy.remove("foo")
// Proxy output: Element removed already
proxy.remove("baz")
// Proxy output: Element not added
}
run()
This design pattern is commonly used across the industry and helps to implement pre- and post-execution operations easily. However, just like any other design pattern, it also adds complexity to your codebase, so try not to use it if you don’t really need it.
You’ll also want to keep in mind that since an additional object is involved when making calls to your actual object, there might be some latency due to the added processing operations. Optimizing your main object’s performance now also involves optimizing your proxy’s methods for performance.
Behavioral design patterns help you solve problems around how objects interact with one another. This can involve sharing or passing responsibility/control between objects to complete set operations. It can also involve passing/sharing data across multiple objects in the most efficient way possible.
The Chain of Responsibility pattern is one of the simplest behavioral design patterns. It comes in handy when you are designing logic for operations that can be handled by multiple handlers.
Similar to how issue escalation works in support teams, the control is passed through a chain of handlers, and the handler responsible for taking action completes the operation. This design pattern is often used in UI design, where multiple layers of components can handle a user input event, such as a touch or a swipe.
Below you will see an example of a complaint escalation using the Chain of Responsibility pattern. The complaint will be handled by the handlers on the basis of its severity:
// Complaint class that stores title and severity of a complaint
// Higher value of severity indicates a more severe complaint
function Complaint (title, severity) {
this.title = title
this.severity = severity
}
// Base level handler that receives all complaints
function Representative () {
// If this handler can not handle the complaint, it will be forwarded to the next level
this.nextLevel = new Management()
this.handleComplaint = function (complaint) {
if (complaint.severity === 0)
console.log("Representative resolved the following complaint: " + complaint.title)
else
this.nextLevel.handleComplaint(complaint)
}
}
// Second level handler to handle complaints of severity 1
function Management() {
// If this handler can not handle the complaint, it will be forwarded to the next level
this.nextLevel = new Leadership()
this.handleComplaint = function (complaint) {
if (complaint.severity === 1)
console.log("Management resolved the following complaint: " + complaint.title)
else
this.nextLevel.handleComplaint(complaint)
}
}
// Highest level handler that handles all complaints unhandled so far
function Leadership() {
this.handleComplaint = function (complaint) {
console.log("Leadership resolved the following complaint: " + complaint.title)
}
}
function run() {
// Create an instance of the base level handler
let customerSupport = new Representative()
// Create multiple complaints of varying severity and pass them to the base handler
let complaint1 = new Complaint("Submit button doesn't work," 0)
customerSupport.handleComplaint(complaint1)
// Output: Representative resolved the following complaint: Submit button doesn't work
let complaint2 = new Complaint("Payment failed," 1)
customerSupport.handleComplaint(complaint2)
// Output: Management resolved the following complaint: Payment failed
let complaint3 = new Complaint("Employee misdemeanour," 2)
customerSupport.handleComplaint(complaint3)
// Output: Leadership resolved the following complaint: Employee misdemeanour
}
run()
The obvious issue with this design is that it’s linear, so there can be some latency in handling an operation when a large number of handlers are chained to one another.
Keeping track of all handlers can be another pain point, as it can get quite messy after a certain number of handlers. Debugging is yet another nightmare as each request can end on a different handler, making it difficult for you to standardize the logging and debugging process.
The Iterator pattern is quite simple and is very commonly used in almost all modern object-oriented languages. If you find yourself faced with the task of going through a list of objects that aren’t all the same type, then normal iteration methods, such as for loops, can get quite messy — especially if you’re also writing business logic inside them.
The Iterator pattern can help you isolate the iteration and processing logic for your lists from the main business logic.
Here’s how you can use it on a rather basic list with multiple types of elements:
// Iterator for a complex list with custom methods
function Iterator(list) {
this.list = list
this.index = 0
// Fetch the current element
this.current = function() {
return this.list[this.index]
}
// Fetch the next element in the list
this.next = function() {
return this.list[this.index++]
}
// Check if there is another element in the list
this.hasNext = function() {
return this.index < this.list.length
}
// Reset the index to point to the initial element
this.resetIndex = function() {
this.index = 0
}
// Run a forEach loop over the list
this.forEach = function(callback) {
for (let element = this.next(); this.index <= this.list.length; element = this.next()) {
callback(element)
}
}
}
function run() {
// A complex list with elements of multiple data types
let list = ["Lorem ipsum," 9, ["lorem ipsum dolor," true], false]
// Create an instance of the iterator and pass it the list
let iterator = new Iterator(list)
// Log the first element
console.log(iterator.current())
// Output: Lorem ipsum
// Print all elements of the list using the iterator's methods
while (iterator.hasNext()) {
console.log(iterator.next())
/**
* Output:
* Lorem ipsum
* 9
* [ 'lorem ipsum dolor', true ]
* false
*/
}
// Reset the iterator's index to the first element
iterator.resetIndex()
// Use the custom iterator to pass an effect that will run for each element of the list
iterator.forEach(function (element) {
console.log(element)
})
/**
* Output:
* Lorem ipsum
* 9
* [ 'lorem ipsum dolor', true ]
* false
*/
}
run()
Needless to say, this pattern can be unnecessarily complex for lists without multiple types of elements. Also, if there are too many types of elements in a list, it can become difficult to manage too.
The key is to identify if you really need an iterator based on your list and its future change possibilities. What’s more, the Iterator pattern is only useful in lists, and lists can sometimes limit you to their linear mode of access. Other data structures can sometimes give you greater performance benefits.
Your application design may sometimes require you to play around with a large number of distinct objects that house various kinds of business logic and often depend on one another. Handling the dependencies can sometimes get tricky as you need to keep track of how these objects exchange data and control between them.
Struggling with downtime and WordPress problems? Kinsta is the hosting solution designed to save you time! Check out our features
The Mediator design pattern is aimed at helping you solve this problem by isolating the interaction logic for these objects into a separate object by itself.
This separate object is known as the mediator, and it is responsible for getting the work done by your lower-level classes. Your client or the calling environment will also interact with the mediator instead of the lower-level classes.
Here’s an example of the mediator design pattern in action:
// Writer class that receives an assignment, writes it in 2 seconds, and marks it as finished
function Writer(name, manager) {
// Reference to the manager, writer's name, and a busy flag that the manager uses while assigning the article
this.manager = manager
this.name = name
this.busy = false
this.startWriting = function (assignment) {
console.log(this.name + " started writing \"" + assignment + "\"")
this.assignment = assignment
this.busy = true
// 2 s timer to replicate manual action
setTimeout(() => { this.finishWriting() }, 2000)
}
this.finishWriting = function () {
if (this.busy === true) {
console.log(this.name + " finished writing \"" + this.assignment + "\"")
this.busy = false
return this.manager.notifyWritingComplete(this.assignment)
} else {
console.log(this.name + " is not writing any article")
}
}
}
// Editor class that receives an assignment, edits it in 3 seconds, and marks it as finished
function Editor(name, manager) {
// Reference to the manager, writer's name, and a busy flag that the manager uses while assigning the article
this.manager = manager
this.name = name
this.busy = false
this.startEditing = function (assignment) {
console.log(this.name + " started editing \"" + assignment + "\"")
this.assignment = assignment
this.busy = true
// 3 s timer to replicate manual action
setTimeout(() => { this.finishEditing() }, 3000)
}
this.finishEditing = function () {
if (this.busy === true) {
console.log(this.name + " finished editing \"" + this.assignment + "\"")
this.manager.notifyEditingComplete(this.assignment)
this.busy = false
} else {
console.log(this.name + " is not editing any article")
}
}
}
// The mediator class
function Manager() {
// Store arrays of workers
this.editors = []
this.writers = []
this.setEditors = function (editors) {
this.editors = editors
}
this.setWriters = function (writers) {
this.writers = writers
}
// Manager receives new assignments via this method
this.notifyNewAssignment = function (assignment) {
let availableWriter = this.writers.find(function (writer) {
return writer.busy === false
})
availableWriter.startWriting(assignment)
return availableWriter
}
// Writers call this method to notify they're done writing
this.notifyWritingComplete = function (assignment) {
let availableEditor = this.editors.find(function (editor) {
return editor.busy === false
})
availableEditor.startEditing(assignment)
return availableEditor
}
// Editors call this method to notify they're done editing
this.notifyEditingComplete = function (assignment) {
console.log("\"" + assignment + "\" is ready to publish")
}
}
function run() {
// Create a manager
let manager = new Manager()
// Create workers
let editors = [
new Editor("Ed," manager),
new Editor("Phil," manager),
]
let writers = [
new Writer("Michael," manager),
new Writer("Rick," manager),
]
// Attach workers to manager
manager.setEditors(editors)
manager.setWriters(writers)
// Send two assignments to manager
manager.notifyNewAssignment("var vs let in JavaScript")
manager.notifyNewAssignment("JS promises")
/**
* Output:
* Michael started writing "var vs let in JavaScript"
* Rick started writing "JS promises"
*
* After 2s, output:
* Michael finished writing "var vs let in JavaScript"
* Ed started editing "var vs let in JavaScript"
* Rick finished writing "JS promises"
* Phil started editing "JS promises"
*
* After 3s, output:
* Ed finished editing "var vs let in JavaScript"
* "var vs let in JavaScript" is ready to publish
* Phil finished editing "JS promises"
* "JS promises" is ready to publish
*/
}
run()
While the mediator provides your app design with decoupling and a great deal of flexibility, at the end of the day, it’s another class that you need to maintain. You must assess whether your design can really benefit from a mediator before writing one so you don’t end up adding unnecessary complexity to your codebase.
It’s also important to keep in mind that even though the mediator class doesn’t hold any direct business logic, it still contains a lot of code that is crucial to the functioning of your app and can therefore quickly get pretty complex.
Versioning objects is another common problem that you’ll face when developing apps. There are a lot of use cases where you need to maintain the history of an object, support easy rollbacks, and sometimes even support reverting those rollbacks. Writing the logic for such apps can be tough.
The Memento design pattern is meant to solve this problem easily.
A memento is considered to be a snapshot of an object at a certain point in time. The Memento design pattern makes use of these mementos to preserve snapshots of the object as it is changed over time. When you need to roll back to an old version, you can simply pull up the memento for it.
Here’s how you can implement it in a text processing app:
// The memento class that can hold one snapshot of the Originator class - document
function Text(contents) {
// Contents of the document
this.contents = contents
// Accessor function for contents
this.getContents = function () {
return this.contents
}
// Helper function to calculate word count for the current document
this.getWordCount = function () {
return this.contents.length
}
}
// The originator class that holds the latest version of the document
function Document(contents) {
// Holder for the memento, i.e., the text of the document
this.text = new Text(contents)
// Function to save new contents as a memento
this.save = function (contents) {
this.text = new Text(contents)
return this.text
}
// Function to revert to an older version of the text using a memento
this.restore = function (text) {
this.text = new Text(text.getContents())
}
// Helper function to get the current memento
this.getText = function () {
return this.text
}
// Helper function to get the word count of the current document
this.getWordCount = function () {
return this.text.getWordCount()
}
}
// The caretaker class that providers helper functions to modify the document
function DocumentManager(document) {
// Holder for the originator, i.e., the document
this.document = document
// Array to maintain a list of mementos
this.history = []
// Add the initial state of the document as the first version of the document
this.history.push(document.getText())
// Helper function to get the current contents of the documents
this.getContents = function () {
return this.document.getText().getContents()
}
// Helper function to get the total number of versions available for the document
this.getVersionCount = function () {
return this.history.length
}
// Helper function to get the complete history of the document
this.getHistory = function () {
return this.history.map(function (element) {
return element.getContents()
})
}
// Function to overwrite the contents of the document
this.overwrite = function (contents) {
let newVersion = this.document.save(contents)
this.history.push(newVersion)
}
// Function to append new content to the existing contents of the document
this.append = function (contents) {
let currentVersion = this.history[this.history.length - 1]
let newVersion
if (currentVersion === undefined)
newVersion = this.document.save(contents)
else
newVersion = this.document.save(currentVersion.getContents() + contents)
this.history.push(newVersion)
}
// Function to delete all the contents of the document
this.delete = function () {
this.history.push(this.document.save(""))
}
// Function to get a particular version of the document
this.getVersion = function (versionNumber) {
return this.history[versionNumber - 1]
}
// Function to undo the last change
this.undo = function () {
let previousVersion = this.history[this.history.length - 2]
this.document.restore(previousVersion)
this.history.push(previousVersion)
}
// Function to revert the document to a previous version
this.revertToVersion = function (version) {
let previousVersion = this.history[version - 1]
this.document.restore(previousVersion)
this.history.push(previousVersion)
}
// Helper function to get the total word count of the document
this.getWordCount = function () {
return this.document.getWordCount()
}
}
function run() {
// Create a document
let blogPost = new Document("")
// Create a caretaker for the document
let blogPostManager = new DocumentManager(blogPost)
// Change #1: Add some text
blogPostManager.append("Hello World!")
console.log(blogPostManager.getContents())
// Output: Hello World!
// Change #2: Add some more text
blogPostManager.append(" This is the second entry in the document")
console.log(blogPostManager.getContents())
// Output: Hello World! This is the second entry in the document
// Change #3: Overwrite the document with some new text
blogPostManager.overwrite("This entry overwrites everything in the document")
console.log(blogPostManager.getContents())
// Output: This entry overwrites everything in the document
// Change #4: Delete the contents of the document
blogPostManager.delete()
console.log(blogPostManager.getContents())
// Empty output
// Get an old version of the document
console.log(blogPostManager.getVersion(2).getContents())
// Output: Hello World!
// Change #5: Go back to an old version of the document
blogPostManager.revertToVersion(3)
console.log(blogPostManager.getContents())
// Output: Hello World! This is the second entry in the document
// Get the word count of the current document
console.log(blogPostManager.getWordCount())
// Output: 53
// Change #6: Undo the last change
blogPostManager.undo()
console.log(blogPostManager.getContents())
// Empty output
// Get the total number of versions for the document
console.log(blogPostManager.getVersionCount())
// Output: 7
// Get the complete history of the document
console.log(blogPostManager.getHistory())
/**
* Output:
* [
* '',
* 'Hello World!',
* 'Hello World! This is the second entry in the document',
* 'This entry overwrites everything in the document',
* '',
* 'Hello World! This is the second entry in the document',
* ''
* ]
*/
}
run()
While the Memento design pattern is a great solution for managing the history of an object, it can get very resource-intensive. Since each memento is almost a copy of the object, it can bloat your app’s memory very quickly if not used in moderation.
With a large number of objects, their lifecycle management can also be quite a tedious task. On top of all this, the Originator
and the Caretaker
classes are usually very tightly coupled, adding to the complexity of your codebase.
The Observer pattern provides an alternate solution to the multi-object-interaction problem (seen before in the Mediator pattern).
Instead of allowing each object to communicate with one another through a designated mediator, the Observer pattern allows them to observe each other. Objects are designed to emit events when they are trying to send out data or control, and other objects that are “listening” to these events can then receive them and interact based on their contents.
Here’s a simple demonstration of sending out newsletters to multiple people through the Observer pattern:
// The newsletter class that can send out posts to its subscribers
function Newsletter() {
// Maintain a list of subscribers
this.subscribers = []
// Subscribe a reader by adding them to the subscribers' list
this.subscribe = function(subscriber) {
this.subscribers.push(subscriber)
}
// Unsubscribe a reader by removing them from the subscribers' list
this.unsubscribe = function(subscriber) {
this.subscribers = this.subscribers.filter(
function (element) {
if (element !== subscriber) return element
}
)
}
// Publish a post by calling the receive function of all subscribers
this.publish = function(post) {
this.subscribers.forEach(function(element) {
element.receiveNewsletter(post)
})
}
}
// The reader class that can subscribe to and receive updates from newsletters
function Reader(name) {
this.name = name
this.receiveNewsletter = function(post) {
console.log("Newsletter received by " + name + "!: " + post)
}
}
function run() {
// Create two readers
let rick = new Reader("ed")
let morty = new Reader("morty")
// Create your newsletter
let newsletter = new Newsletter()
// Subscribe a reader to the newsletter
newsletter.subscribe(rick)
// Publish the first post
newsletter.publish("This is the first of the many posts in this newsletter")
/**
* Output:
* Newsletter received by ed!: This is the first of the many posts in this newsletter
*/
// Subscribe another reader to the newsletter
newsletter.subscribe(morty)
// Publish the second post
newsletter.publish("This is the second of the many posts in this newsletter")
/**
* Output:
* Newsletter received by ed!: This is the second of the many posts in this newsletter
* Newsletter received by morty!: This is the second of the many posts in this newsletter
*/
// Unsubscribe the first reader
newsletter.unsubscribe(rick)
// Publish the third post
newsletter.publish("This is the third of the many posts in this newsletter")
/**
* Output:
* Newsletter received by morty!: This is the third of the many posts in this newsletter
*/
}
run()
While the Observer pattern is a slick way of passing around control and data, it is better suited to situations where there are a large number of senders and receivers interacting with each other via a limited number of connections. If the objects were to all make one-to-one connections, you would lose the edge you get by publishing and subscribing to events since there will always be only one subscriber for each publisher (when it would have been better handled by a direct line of communication between them).
Additionally, the Observer design pattern can lead to performance problems if the subscription events are not handled properly. If an object continues to subscribe to another object even when it doesn’t need to, it will not be eligible for garbage collection and will add to the memory consumption of the app.
The State design pattern is one of the most used design patterns across the software development industry. Popular JavaScript frameworks like React and Angular heavily rely on the State pattern to manage data and app behavior based on that data.
Put simply, the State design pattern is helpful in situations where you can define definitive states of an entity (which could be a component, a page, an app, or a machine), and the entity has a predefined reaction to the state change.
Let’s say you’re trying to build a loan application process. Each step in the application process can be defined as a state.
While the customer usually sees a small list of simplified states of their application (pending, in review, accepted, and rejected), there can be other steps involved internally. At each of these steps, the application will be assigned to a distinct person and can have unique requirements.
The system is designed in such a way that at the end of processing in a state, the state is updated to the next one in line, and the next relevant set of steps is started.
Here’s how you can build a task management system using the State design pattern:
// Create titles for all states of a task
const STATE_TODO = "TODO"
const STATE_IN_PROGRESS = "IN_PROGRESS"
const STATE_READY_FOR_REVIEW = "READY_FOR_REVIEW"
const STATE_DONE = "DONE"
// Create the task class with a title, assignee, and duration of the task
function Task(title, assignee) {
this.title = title
this.assignee = assignee
// Helper function to update the assignee of the task
this.setAssignee = function (assignee) {
this.assignee = assignee
}
// Function to update the state of the task
this.updateState = function (state) {
switch (state) {
case STATE_TODO:
this.state = new TODO(this)
break
case STATE_IN_PROGRESS:
this.state = new IN_PROGRESS(this)
break
case STATE_READY_FOR_REVIEW:
this.state = new READY_FOR_REVIEW(this)
break
case STATE_DONE:
this.state = new DONE(this)
break
default:
return
}
// Invoke the callback function for the new state after it is set
this.state.onStateSet()
}
// Set the initial state of the task as TODO
this.updateState(STATE_TODO)
}
// TODO state
function TODO(task) {
this.onStateSet = function () {
console.log(task.assignee + " notified about new task \"" + task.title + "\"")
}
}
// IN_PROGRESS state
function IN_PROGRESS(task) {
this.onStateSet = function () {
console.log(task.assignee + " started working on the task \"" + task.title + "\"")
}
}
// READY_FOR_REVIEW state that updates the assignee of the task to be the manager of the developer
// for the review
function READY_FOR_REVIEW(task) {
this.getAssignee = function () {
return "Manager 1"
}
this.onStateSet = function () {
task.setAssignee(this.getAssignee())
console.log(task.assignee + " notified about completed task \"" + task.title + "\"")
}
}
// DONE state that removes the assignee of the task since it is now completed
function DONE(task) {
this.getAssignee = function () {
return ""
}
this.onStateSet = function () {
task.setAssignee(this.getAssignee())
console.log("Task \"" + task.title + "\" completed")
}
}
function run() {
// Create a task
let task1 = new Task("Create a login page," "Developer 1")
// Output: Developer 1 notified about new task "Create a login page"
// Set it to IN_PROGRESS
task1.updateState(STATE_IN_PROGRESS)
// Output: Developer 1 started working on the task "Create a login page"
// Create another task
let task2 = new Task("Create an auth server," "Developer 2")
// Output: Developer 2 notified about new task "Create an auth server"
// Set it to IN_PROGRESS as well
task2.updateState(STATE_IN_PROGRESS)
// Output: Developer 2 started working on the task "Create an auth server"
// Update the states of the tasks until they are done
task2.updateState(STATE_READY_FOR_REVIEW)
// Output: Manager 1 notified about completed task "Create an auth server"
task1.updateState(STATE_READY_FOR_REVIEW)
// Output: Manager 1 notified about completed task "Create a login page"
task1.updateState(STATE_DONE)
// Output: Task "Create a login page" completed
task2.updateState(STATE_DONE)
// Output: Task "Create an auth server" completed
}
run()
While the State pattern does a great job of segregating steps in a process, it can become extremely difficult to maintain in large applications that have multiple states.
On top of that, if your process design allows more than just linearly moving through all the states, you’re in for writing and maintaining more code, since each state transition needs to be handled separately.
Also known as the Policy pattern, the Strategy pattern aims to help you encapsulate and freely interchange classes using a common interface. This helps maintain a loose coupling between the client and the classes and allows you to add as many implementations as you’d like.
The Strategy pattern is known to help immensely in situations where the same operation is needed using different methods/algorithms, or where massive switch blocks need to be replaced with more human-friendly code.
Here’s an example of the Strategy pattern:
// The strategy class that can encapsulate all hosting providers
function HostingProvider() {
// store the provider
this.provider = ""
// set the provider
this.setProvider = function(provider) {
this.provider = provider
}
// set the website configuration for which each hosting provider would calculate costs
this.setConfiguration = function(configuration) {
this.configuration = configuration
}
// the generic estimate method that calls the provider's unique methods to calculate the costs
this.estimateMonthlyCost = function() {
return this.provider.estimateMonthlyCost(this.configuration)
}
}
// Foo Hosting charges for each second and KB of hosting usage
function FooHosting (){
this.name = "FooHosting"
this.rate = 0.0000027
this.estimateMonthlyCost = function(configuration){
return configuration.duration * configuration.workloadSize * this.rate
}
}
// Bar Hosting charges per minute instead of seconds
function BarHosting (){
this.name = "BarHosting"
this.rate = 0.00018
this.estimateMonthlyCost = function(configuration){
return configuration.duration / 60 * configuration.workloadSize * this.rate
}
}
// Baz Hosting assumes the average workload to be of 10 MB in size
function BazHosting (){
this.name = "BazHosting"
this.rate = 0.032
this.estimateMonthlyCost = function(configuration){
return configuration.duration * this.rate
}
}
function run() {
// Create a website configuration for a website that is up for 24 hours and takes 10 MB of hosting space
let workloadConfiguration = {
duration: 84700,
workloadSize: 10240
}
// Create the hosting provider instances
let fooHosting = new FooHosting()
let barHosting = new BarHosting()
let bazHosting = new BazHosting()
// Create the instance of the strategy class
let hostingProvider = new HostingProvider()
// Set the configuration against which the rates have to be calculated
hostingProvider.setConfiguration(workloadConfiguration)
// Set each provider one by one and print the rates
hostingProvider.setProvider(fooHosting)
console.log("FooHosting cost: " + hostingProvider.estimateMonthlyCost())
// Output: FooHosting cost: 2341.7856
hostingProvider.setProvider(barHosting)
console.log("BarHosting cost: " + hostingProvider.estimateMonthlyCost())
// Output: BarHosting cost: 2601.9840
hostingProvider.setProvider(bazHosting)
console.log("BarHosting cost: " + hostingProvider.estimateMonthlyCost())
// Output: BarHosting cost: 2710.4000
}
run()
The Strategy pattern is great when it comes to introducing new variations of an entity without changing the clients much. However, it can seem like overkill if you only have a handful of variations to implement.
Also, the encapsulation takes away finer details about each variant’s internal logic, so your client is unaware of how a variant is going to behave.
The Visitor pattern aims to help you make your code extensible.
The idea is to provide a method in the class that allows objects of other classes to make changes to objects of the current class easily. The other objects visit the current object (also called the place object), or the current class accepts the visitor objects, and the place object handles the visit of each external object appropriately.
Here’s how you can use it:
// Visitor class that defines the methods to be called when visiting each place
function Reader(name, cash) {
this.name = name
this.cash = cash
// The visit methods can access the place object and invoke available functions
this.visitBookstore = function(bookstore) {
console.log(this.name + " visited the bookstore and bought a book")
bookstore.purchaseBook(this)
}
this.visitLibrary = function() {
console.log(this.name + " visited the library and read a book")
}
// Helper function to demonstrate a transaction
this.pay = function(amount) {
this.cash -= amount
}
}
// Place class for a library
function Library () {
this.accept = function(reader) {
reader.visitLibrary()
}
}
// Place class for a bookstore that allows purchasing book
function Bookstore () {
this.accept = function(reader) {
reader.visitBookstore(this)
}
this.purchaseBook = function (visitor) {
console.log(visitor.name + " bought a book")
visitor.pay(8)
}
}
function run() {
// Create a reader (the visitor)
let reader = new Reader("Rick," 30)
// Create the places
let booksInc = new Bookstore()
let publicLibrary = new Library()
// The reader visits the library
publicLibrary.accept(reader)
// Output: Rick visited the library and read a book
console.log(reader.name + " has $" + reader.cash)
// Output: Rick has $30
// The reader visits the bookstore
booksInc.accept(reader)
// Output: Rick visited the bookstore and bought a book
console.log(reader.name + " has $" + reader.cash)
// Output: Rick has $22
}
run()
The only flaw in this design is that each visitor class needs to be updated whenever a new place is added or modified. In cases where multiple visitors and place objects exist together, this can be difficult to maintain.
Other than that, the method works great for enhancing the functionality of classes dynamically.
Now that you’ve seen the most common design patterns across JavaScript, here are some tips that you should keep in mind when implementing them.
This tip is to be applied before you implement a design pattern into your source code. While it may look like a design pattern is the end of all of your worries, take a moment to critically analyze if that is true.
There are many patterns that solve the same problem but take different approaches and have different consequences. So your criteria for selecting a design pattern shouldn’t just be whether it solves your problem or not — it should also be how well it solves your problem and whether there is any other pattern that can present a more efficient solution.
While design patterns seem to be the best solution for all engineering problems, you shouldn’t jump into implementing them in your source code right away.
While judging the consequences of implementing a solution, you also need to take into consideration your own situation. Do you have a large team of software developers that are well adept at understanding and maintaining design patterns? Or are you an early-stage founder with a minimal development team looking to release a quick MVP of your product? If you answer yes to the last question, design patterns might not be the most optimal way of development for you.
Design patterns do not lead to heavy code reuse unless they are planned in a very early stage of app design. Randomly using design patterns at various stages can lead to an unnecessarily complex app architecture that you’d have to spend weeks simplifying.
The effectiveness of a design pattern cannot be judged by any form of testing. It’s your team’s experience and introspection that will let you know if they work. If you have the time and resources to allocate to these aspects, only then will design patterns truly solve your problems.
Another rule of thumb to keep in mind is to refrain from trying to turn every little problem-solution pair into a design pattern and using it wherever you see room for it.
While it’s good to identify standard solutions and keep them in mind when you encounter similar problems, there’s a good chance the new problem you encountered will not fit the exact same description as an older problem. In such a case, you might end up implementing a suboptimal solution and wasting resources.
Design patterns are established today as leading examples of problem-solution pairs because they’ve been tested by hundreds and thousands of programmers over time and have been generalized as much as possible. If you try to replicate that effort by just looking at a bunch of problems and solutions and calling them similar, you might end up doing a lot more damage to your code than you’d ever expected.
To sum up, here are a few cues that you should look out for to use design patterns. Not all of them apply to every app’s development, but they should give you a good idea of what to look out for when thinking of using design patterns:
If a design pattern solves your problem and helps you write code that’s simple, reusable, modular, loosely coupled, and free of “code smell,” it might be the right way to go.
Another good tip to keep in mind is to avoid making everything about design patterns. Design patterns are meant to help you solve problems. They are not laws to abide by or rules to strictly follow. The ultimate rules and laws are still the same: Keep your code clean, simple, readable, and scalable. If a design pattern helps you do that while solving your problem, you should be good to go with it.
JavaScript design patterns are a wonderful way of approaching problems that multiple programmers have faced over the course of time. They present tried-and-tested solutions that strive to keep your codebase clean and loosely coupled.
Today, there are hundreds of design patterns available that will solve almost any problem that you encounter while building apps. However, not every design pattern will really solve your problem every time.
Just like any other programming convention, design patterns are meant to be taken as suggestions for solving problems. They are not laws to be followed all the time, and if you treat them like laws, you might end up doing a lot of damage to your apps.
Once your app is finished, you’ll need a place to host it — and Kinsta’s Application Hosting solutions are chief among the fastest, most reliable, and most secure. You just need to sign in to your MyKinsta account (Kinsta’s custom administrative dashboard), connect to your GitHub repository, and launch! Plus, you’re only charged for the resources your app uses.
What are the design patterns that you regularly use in your software programming job? Or is there a pattern that we missed in the list? Let us know in the comments below!
Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:
Test it yourself with $20 off your first month of Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.
Original article source at: https://kinsta.com/