nmeri17

/**
 * Steps to run
 * 1) turn off images, to save data
 * 2) paste https://code.jquery.com/jquery-3.7.1.min.js
 * 3) wait for the first frame of following to appear before running below code
*/

var processedRows = 0, batchToProcess = 12/*00*/,

followingIndicator = ".r-z2wwpe.r-6koalj.r-1q142lx", // .css-175oi2r.r-1awozwy

nmeri17

message based interfaces are implemented by GuzzleHttp\Psr7 that we already depend on. but the return types and the way

the values are derived are different

CacheManager: https://www.php-fig.org/psr/psr-16/

container: https://www.php-fig.org/psr/psr-11/

request stuff: https://www.php-fig.org/psr/psr-7/ (will be impossible if they're all one object)

nmeri17

Home

Let's not forget: this is still Suphle's first official release. The idea is that when it's augmented by a community no longer burdened by the issues it currently puts to rest, it'll serve as springboard for the next level of engineering web and CLI based software.

Module

Descriptor definition

This class allows us expose desired functionality to its module's consumers. In addition, it serves as both a platform for declaring module-wide dependencies, as well as the port through which other modules are inserted into ours.

nmeri17

• Decoupled development
• Documentation
• Seamless integration

If you don't have the luxury of developing at your pace, you will greatly benefit from design first tools like API blueprint. It's important to not work under pressure of delivering endpoints to kick off API consumption. Aside from this, APIs should be rapidly prototyped. And the first step in doing so would be setting up the routes and returning dummy responses. That's the bare minimum promise of what is to come

If you don't care much about using an API design tool, it is assumed you have an alternative or intuitive means of arriving at a decent design your consumers will consent to. Should this be the case, after implementation, suphle solves the documentation problem by generating openAPI schemas from your routes and their associated responses

nmeri17

Request lifecycle

Though not compulsory, it's strongly recommended to compartmentalize your app into modules. Modules exist independently, which means they tend to contain their own routes and exist in a state where they can be deployed without knowledge of their sibling modules' internal details.

For every request received by your app, it's apportioned to its appropriate handler before being passed onto a module where applicable.

Suphle has 3 different kinds of request, which are in turn, subdivided into their subcategories:

• Login requests
• Flow requests
• Regular requests

nmeri17

<?php
	namespace Suphle\Exception;

	use ErrorException;

	class NativeErrorHandlers {

		/**
		 * After the failable operation that required this call, unset this catcher so it doesn't affect everyone else, using restore_error_handler
		*/

nmeri17

<?php
	namespace Suphle\Adapters\Queues;

	use Suphle\Contracts\IO\EnvAccessor;

	use Qutee\{Task, Queue, Worker, Persistor\Redis};

	use Throwable;

	class QuTee extends BaseQueueAdapter {

nmeri17

		private function payloadStringifier (array $payload, array $headers):string {

			if (
				array_key_exists($this->CONTENT_TYPE_KEY, $headers) &&

				$headers[$this->CONTENT_TYPE_KEY] == $this->JSON_HEADER_VALUE
			)

nmeri17

<?php
	namespace Tilwa\Adapters\Queues;

	use Tilwa\Contracts\IO\EnvAccessor;

	use Resque as ResqueLib;

	class Resque extends BaseQueueAdapter {

		private $envAccessor;

nmeri17

Htmx
Custom js language (in code), called hyperscript
You'd have to handle your own styling for transitions and effects
Duplicate implementation (on front and back end) for things like validation
Lots of examples for commonly encountered tasks

Unpoly
Has a place for writing js called compilers that is more or less like using jQuery, but with up.element instead of $()
Has examples in form of a demo site. You check which functionality suits what you're looking for and peek under the hood
No websocket support