Message Pack for PHP 7.2 - Server & Client implementations

Decebal Dobrica — Thu, 15 Mar 2018 09:54:11 +0000

This package tries to leverage the power of Message Pack and msgpack.php

Mainly this uses https://github.com/msgpack-rpc/msgpack-rpc-php while updating the underlying code & upgrading to the above mentioned msgpack.php package.

There are 3 possible use cases for this repository due to it's server & client perspectives

Client (my main use case)

 $client = new Client('localhost', '1985');

 $messages =  $client->call("SyncJob", $job, $payload);

 echo array_pop($messages);

aside from the obvious host and port arguments for the Client class, let's see the arguments for the call function:

first argument is a string naming the function to be called on the server side (see tests/server.php)
the call method is a variadic function, hence the following arguments are concatenated to an array on the server

Server (not thoroughly tested)

  try {
      $server = new Server('1985', new App());
      echo 'Server is listening on port 1985...';
      $server->recv();
  } catch (Exception $e) {
      echo $e->getMessage();
  }

see tests/server.php for full example

Client and Server

this would be a good use case if you use multiple services or you need back and forth communication

*if you need this between the same 2 services maybe best to take into account switching to http/2 where

     $backChannel = new BackChannel();

     $client = new Client('localhost', '1986', $backChannel);    
     $messages =  $client->call("SyncJob", $job, $payload);    
     echo array_pop($messages);

     try {
         $server = new Server('1985', new App(), $backChannel);
         echo 'Server is listening on port 1985...';
         $server->recv();
     } catch (Exception $e) {
         echo $e->getMessage();
     }

in this case, as it was the case for the original package, it makes sense to use the BackChannel’s combined server and client methods.

Other options

The package provides necessary interfaces & Traits in order to have your own Server or Client enhancements without the need to modify the base classes whom one can mainly use as references rather than implementations as it makes only for the most basic use case.

a few words on the impact of switching to MessagePack from Gearman

I expected the time to first byte to be affected, but given that they both communicate at a low level the benchmarks were almost the same to the byte.

There is a huge change in availability as I expected however, which is solving one big problem for my system.

I am curious to hear what was your experience and how you used it or looking to use it for, please comment below.

Originally published at Utopian.io - Rewarding Open Source Contributors.

Domain Driven Design with React Native

Decebal Dobrica — Tue, 21 Nov 2017 10:04:05 +0000

Problem:

how to guide programmers to implement domain driven design and modular architectecture

Relevant technologies used:

apollo client
graphql
react native
nodejs
redux

As a programmer I am always inclined to prioritise technical detail and just making things work.
One of the techniques to prevent building monolithic code bases closed to expansion is constant refactoring.

An architecture trick I picked up from developing Domain Driven Design is to twick the questions. When refactoring, I would usually ask myself "what does this object do ?", which is a question about the domain, instead of "how do I make all these pieces work together", a question about the underlying technologies or infrastructure.

In order to allow for paced development I learned that designing the Domain can be a longer process, as long as everyone agrees with the bigger picture and they work towards that goal.

Given that I decided to work on a goal using the techniques available with the technologies at hand. The architecture I used with PHP for refactoring a monolith looks something within these lines:

application
     controllers[web-specific]
     services
model
     [bounded-contexts]
              entities
              interfaces[or contracts of the domain]
infrastructure
     [bounded-contexts]
          services
persistence

These generic lines can be followed in most languages, implementation and need for some of these parts however can be missed, in particular a react-native app could have little to no persistence needs to start with, but I would expect that to grow more important and ingrained in the domain model if fragments are used with the domain in mind.

As an extra when developing a react-native first code-base my lead question I like to ask when thinking about architecture is: how would a web app use this module ? . That is mainly due to the ability to swap presentation components from react native to react and get a web experience out of the same underlying logic.

While doing some research on the subject Microcosm came the closest in terms of best help in modeling the domain I could find.
Microcosm can come out as a candidate for replacing redux in an application, however microcosm has rules of Domain Driven Design ingrained and can be used just as an architecture example at times.
Their recommendation here might look like replacing redux, when building a relatively small app or just when starting that might be quite a fair assessment, I can see them work together, although redux might influence the architecture slightly as well.

One other big influence over your infrastructure will be How you separate your components , the guys at armory talk about 4 component types, some might discard some a couple types when in a domain that has different boundaries defined, I can see these services (I would still use service components or functions) growing big as well, so at times these 4 categories will make sense.

These tips on working with redux in Large Applications are still relevant. A correct use of the domain tools would keep separation between data objects, but the other tips are brilliant, at least to be aware of.

Given that, I hope I gave you something to think of, chew while developing or refactoring your next react native app.
Don't be shy to comment if you disagree or if you feel some of these views are completely out of wack.

Would appreciate any kind of feedback as this is an ongoing development.

Also published on:

DEV Community: Decebal Dobrica