This does not replace the ADR section at all. As we have a lot of repositories and this will be a channel to summarize the news that are shared across the packages. This will also be the way to get informed about new packages as we follow our flexible package structure.
]]>Have a deep dive into two hours of HEPTAconnect knowledge and its creators:
]]>Coming soon: We are currently setting up an integration guide that holds up our integration knowledge and explains our decisions that you should consider as well. Stay tuned to let your next project experience the full data transfer expertise.
]]>The major update at Shopware from 6.3 to 6.4 has been rolled out onto the HEPTAconnect packages.
To experience Shopware 6.4 with HEPTAconnect you can now easily grab yourself a fresh copy of the playground and dive in.
To allow the playground be used with your familiar ecommerce framework in a more complete manner you will now find an integrated shopware/administration.
This way you can use the playground to fiddle with HEPTAconnect within Shopware and in addition also with Shopware itself after importing your favorite data.
How to get your favorite data in, you might ask? Just use the bundled shopware platform portal. On creating the shopware instance in the playground you will get a portal node for the shopware instance as well as for the artificial portal for bottles. Require other portals you can already find online on GitHub under the tag heptaconnect-portal into the shopware composer.json. They are automatically discovered for you to draw your first routes between the portal nodes.
What is that /repos/ folder at root level? We had a look at the contribution and experimenting flow we currently provide and chose to rework that. The new folder contains every HEPTAconnect package as a clone from GitHub. They are linked into the vendor folder. Having the different packages on this directory level makes it much easier to discover and change HEPTAconnect. As they are clones from GitHub it also allows a direct way to share your work on HEPTAconnect in a bleeding edge manner.
How can you know all of this? The documentation got a truck load of new content about:
Some of these new pages are also linked within this article so have a look around.
]]>In detail, we've been using the message broker to completely keep the data in question for each transfer. Read our ADR about jobs and their payloads to follow our thoughts but here are the basic pros:
We were testing the storage sizes on a default Shopware 6 setup. It uses php serialization to store messages on the database. After our change we only store a job reference in the message and store the payload on the database. Our referenced payload takes up from 40% to 95% less memory on the same database driver than in the message table. The following tasks benefit from the size difference:
Above mentioned the architecture also draws a big benefit from that change: As we now have the job payloads separated from their execution scheduling, it is easier to add reference between these jobs. This is especially useful for SAT algorithms that will make their way into HEPTAconnect one day.
]]>Write less.
Achieve more in less time.
Look at your results faster.
Read more about Dependency injection and the new default utilities.
One of our main goals for HEPTAconnect is the ability to replace lots of different implementations to gain a frictionless integrability. When we were looking for the service container feature, we had an issue to solve: As service container builders have not been addressed in the PSR-11, we had to implement service container and builder. The custom implementation holds a 47 lines-of-code container implementation, a 36 lines-of-code container builder and a single entry point for portal developers in their code.
We were able to get yet another PSR compatibility and its benefits: build and share reusable components. By now our implementation of a service container is about half a year old, and we are missing features. We didn't expect our small implementation to have it all right away, but it is a bit impractical in daily usage.
It served the purpose, but it wasn't quite right.
Basically we were looking for what we were missing:
We were accustomed to the Symfony and Laravel worlds having all these features.
Laravel didn't make the cut for us as it is difficult to pull Illuminate components out of their ecosystem.
Symfony gave us similar expectations back when we noticed Bundles are part of the HttpKernel and also quite baked into the Symfony framework /rant.
On our search for a good implementation for service containers with dependency injection we stumbled upon a benchmark. The Symfony implementation was most of the time in second place but had all we ever wanted. So we revisited that package and were happy to see that it had barely any dependencies which is good for an almost frictionless package. Having the service definition files based on xml and yml also allows portal developers to define services without knowing the exact Symfony version behind the scenes.
We gave the implementation a try and got hooked right back into it. Enabling all the nice things and sprinkling some more educated guesses into the container builder gave us the shiny new developer experience for portal developers we always wanted to provide:
When you already had a deeper look into our documentation, you can notice the reduction of boilerplate code in almost every portal developer code sample. We added a new chapter to the documentation under portal development containing everything you need to know to use dependency injection with the new service container. This way we also took the chance to provide a complete list of utility service we provide out of the box.
]]>Write less.
Achieve more in less time.
Look at your results faster.
Read more about short notation for flow components.
No, the TL;DR is not a copy mistake from the previous feed entry about dependency injection. We once more achieved to improve the developer experience by adding more tools to reduce your boilerplate code. Summarizing our ADR you can now stop writing sections of code and start to write lines of code. Previously you had to write:
<?php
declare(strict_types=1);
namespace FooBar\Emitter;
use FooBar\Packer\BottlePacker;
use FooBar\Service\ApiClient;
use Heptacom\HeptaConnect\Dataset\Base\Contract\DatasetEntityContract;
use Heptacom\HeptaConnect\Portal\Base\Emission\Contract\EmitContextInterface;
use Heptacom\HeptaConnect\Portal\Base\Emission\Contract\EmitterContract;
class BottleEmitter extends EmitterContract
{
private ApiClient $client;
private BottlePacker $packer;
public function __construct(ApiClient $client, BottlePacker $packer)
{
$this->client = $client;
$this->packer = $packer;
}
public function run(string $externalId, EmitContextInterface $context) : ?DatasetEntityContract
{
return $this->packer->pack($this->client->getBottleData($externalId));
}
}
Sieve out the boilerplate lines and you have:
<?php
declare(strict_types=1);
use FooBar\Packer\BottlePacker;
use FooBar\Service\ApiClient;
use Heptacom\HeptaConnect\Portal\Base\Builder\FlowComponent;
FlowComponent::emitter(Bottle::class)->run(
fn (ApiClient $client, BottlePacker $packer, string $id) => $packer->pack($client->getBottleData($id))
);
When this reminds you of Laravel routes and commands, you are right. This is heavily inspired by Laravel's nature of quickly scribbling down some lines to get something big running. To get an overview of the short notation and how to use it visit the documentation page.
]]>Train in step-by-step.
Run in batches.
Read more about the way how to batch in short notation for flow components and flow components like emitter and receiver.
Every emitting or receiving flow component can improve on performance when data is processed in batches. In general HEPTAconnect groups data into batches to allow the flow components to be able to act in reasonable batch sizes. The documentation in the past only explained how to make a single step-by-step API interactions. Running through a data transfer in such a sequential manner is due to its complexity better to outline its inner statements. The flow component loops that unrolled the batches into single steps are now accessible for child classes to override. Compare the following real life examples how to receive manufacturer data to its successor within Shopware 6:
<?php
use Heptacom\HeptaConnect\Dataset\Ecommerce\Product\Manufacturer;
use Heptacom\HeptaConnect\Portal\Base\Builder\FlowComponent;
use Heptacom\HeptaConnect\Portal\LocalShopwarePlatform\Support\DalAccess;
use Heptacom\HeptaConnect\Portal\LocalShopwarePlatform\Unpacker;
FlowComponent::receiver(Manufacturer::class)->run(static fn (
DalAccess $dal,
Manufacturer $manufacturer,
Unpacker\ManufacturerUnpacker $unpacker
) => $dal->createSyncer()->upsert('product_manufacturer', [$unpacker->unpack($manufacturer)])->flush());
<?php
use Heptacom\HeptaConnect\Dataset\Base\TypedDatasetEntityCollection;
use Heptacom\HeptaConnect\Dataset\Ecommerce\Product\Manufacturer;
use Heptacom\HeptaConnect\Portal\Base\Builder\FlowComponent;
use Heptacom\HeptaConnect\Portal\LocalShopwarePlatform\Support\DalAccess;
use Heptacom\HeptaConnect\Portal\LocalShopwarePlatform\Unpacker;
FlowComponent::receiver(Manufacturer::class)->batch(static fn (
DalAccess $dal,
TypedDatasetEntityCollection $manufacturers,
Unpacker\ManufacturerUnpacker $unpacker
) => $dal->createSyncer()->upsert('product_manufacturer', $manufacturers->map([$unpacker, 'unpack']))->flush());
There is basically no difference. Your project can make use of this today when you are in the lucky position to have a batch-ready API, and you've been following architectural patterns to use packer and unpacker services.
]]>Maybe you already noticed it: We have a beautiful new documentation website, and we think you will love it. Our new website is based on the material theme for MkDocs with some customizations and it's rocking a bunch of new and improved features.
The HEPTAconnect documentation is now available under a new domain: heptaconnect.io. We have moved from a subdomain under heptacom.de to a dedicated domain and we are also using the .io domain ending.
Perhaps the most notable change are the stunning visuals. The main landing page shows the HEPTAconnect logo and prominently advertises the four most important sections of the documentation. Have you noticed the glowing backdrop behind the cards when you hover over them?
Speaking of sections: We have restructured our content into different sections. Most of our existing content went into Portal Developer and Reference. The sections Integrator and Administrator are completely new and bring different perspectives into the documentation. Truth be told, they are not finished yet. But we have big plans to extend the documentation with new content for them, so stay tuned.
And when we are already on the topic of staying tuned: We noticed that most RSS readers don't update as frequently as we would like them to. So starting from today we will additionally publish our blog entries on Twitter. So if your RSS reader is giving you trouble, feel free to follow us there.
Let's get back to the star of today's show: The new documentation website has an amazing new search function. A big problem we had with the search on the old website was the small space where the search results would get crammed into. Search results were nearly indistinguishable from one another rendering them downright useless. The new search bar makes use of all the space it can get to give results that are actually helpful.
If you are hyped to try it out, a good first search term would be "Basic flow". The first result will take you to a brand-new page with our new sequence diagrams to visualize how data flows through HEPTAconnect. Those diagrams show both the perspective of a portal and the perspective of HEPTAconnect core components during an exploration, an emission and a reception in a basic flow. Let us know if they could help you to better grasp the big picture.
And there is still more. MkDocs has another trick up its sleeve. The entire documentation is available for download as a PDF file with a cover page and a linked table of contents. So when your client demands a copy of the documentation, it's just one click away. Take a look on the left side of the footer.
Last but not least, the switch from docsify to MkDocs means that our documentation is finally visible for Google and other search engines. So hopefully you can soon find your answers even faster from your favourite search engine.
]]>In the last news the new documentation structure and engine have been celebrated. Now we can suggest once again to read into the new pages about our new flow component: HTTP handler. This new component already has some configuration which can be managed as administrator that can be read upon in the HTTP APIs page of the administrator section.
We rely fully on PSR-7 and PSR-17.
Unfortunately PSR-15 does not fit into our just released HTTP handler structure.
It behaves similar to other flow components in terms of stacked processing, extensibility by portal extensions and integrations, ability to write definition in a short-notation and an object-oriented manner.
In the past you had to be an integration to host an HTTP controller to create an event driven flow over HTTP messages. With HTTP handlers at hand you can now use incoming web requests and transfer them into publications or already a direct emission. We already use it in the Business Central portal to build an OAuth 2 authentication flow. The following example shows how to convert an incoming request into a publication of external ids about new data that is ready to pick up.
use Heptacom\HeptaConnect\Playground\Dataset\Bottle;
use Heptacom\HeptaConnect\Portal\Base\Builder\FlowComponent;
use Heptacom\HeptaConnect\Portal\Base\Mapping\MappingComponentCollection;
use Heptacom\HeptaConnect\Portal\Base\Mapping\MappingComponentStruct;
use Heptacom\HeptaConnect\Portal\Base\StorageKey\Contract\PortalNodeKeyInterface;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
FlowComponent::httpHandler('bottle')->post(static function (
ServerRequestInterface $request,
ResponseInterface $response,
PortalNodeKeyInterface $portalNodeKey
): ResponseInterface {
$bottleIds = \json_decode($request->getQueryParams()['bottle-ids']);
$bottleMappings = \array_map(static fn (string $bottleId) => new MappingComponentStruct(
$portalNodeKey,
Bottle::class,
$bottleId
), $bottleIds);
$this->publisher->publishBatch(new MappingComponentCollection($bottleMappings));
return $response->withStatus(201);
});
Direct emission based flows can be created quickly when you already use packers to pack API data into HEPTAconnect entities. With packers at hand you can use the request body, pass it into the packer and use the packed entity directly into the DirectEmissionFlow.
]]>With the release of version 0.7 we started to add changelogs. These are important news and therefore reside in our news section. There you can find a human-readable and easy to browse version of the changelogs. So with each upcoming release of HEPTAconnect you should check out the documentation about the new changes and get excited.
Updating to the most recent version of HEPTAconnect is always a combination of:
So you can check your version of HEPTAconnect using $ composer show heptacom/heptaconnect-\*, understand the news and compare.
That is super easy as we write them in a non code-exclusive focussed view to explain the changes of the public API.
We are focussing on feature based logs so the generic changes of a git diff turns into a human understandable view on the change.
The keep a changelog project thinks alike, therefore we follow its guidelines for a good changelog.
To summarize: Every version has a clear title with a semantic version and the release date.
Each version has a section filled changes grouped by their classification of additions, changes, deprecations, removals, fixes and security fixes.
Looking at the changelog lines you will see they always reveal quite technical information. We add them to the messages to visualize a clear connection of features to code components. It makes it easy to research for unique code components and understand why they have been changed. When we do package internal changes you won't see them as they probably won't bother you. Don't worry though, when we change e.g. database interactions this is often considered an internal change but still resides under the changes classification for e.g. resources usage reasons.
You have to take every log and look up whether it affects your code changes as every log should contain enough technical reference. When you have a match you can understand the connected feature and apply the knowledge.
The process sounds correct but tedious, right? We thought so as well, so we decided to snoop around one step ahead again and had a look on how to automate this, so we all have less to do again.
So we like our code a bit magical but still reasonable. As we do it ourselves, we are aware how people can turn PHP into anything. Therefore, we can't provide an automatic upgrade yet, but we are working on a tool which either supports or fixes code automatically for you. We prepared guides to do upgrades for portal developers and integrators as well for contributors which we will both upgrade regularly.
]]>With the release of 0.9 we started to document every interface and contract. This way we ensure clear communication how to use the interface as an API consumer and as an API provider.
Adding documentation on source code is a delicate discussion topic in most developer conversations.
We evaluated our experience with other documentations and were (and still are) really happy with the approach of the PSR composer packages.
When looking at e.g. the \Psr\Log\LoggerInterface, there is a common description at the interface and a short hint on every method.
In everyday usage it was nice to use a logger instance, navigate to the interface symbol or one of the methods and see right away how the intended use is.
A similar pattern can be seen in the documentation stubs PHPStorm ships for native PHP functions.
This kept the developer in the IDE without losing their focus.
We see the possibility that these comments may go out of date. To prevent this from happening too often, we decided to only write expected usage and possible implementation hints. With this rule of thumb we are not fixed to a certain implementation that may change over time. Instead, we use the intended use case as comment when the component was introduced so everyone shares the same expectation.
]]>Two weeks ago we released the first 0.9 version. To be more specific it is 0.9.0.0 and so the first version following the new version scheme described in this ADR. Updated changelogs for your updating strategy can be found in the release news section. Let's get more detailed and hydrate the TL;DR above.
The file references are a new way to transfer files with the focus on availability via HTTP and reduction of I/O operations in the HEPTAconnect installation. The datasets and portals have been updated accordingly to use the new performant transport. See a sample usage here.
Flow components are now loaded deferred and only grouped when used. This allows portal extensions to provide as much flexibility as portals in terms of flow components. New flexibilities are also given to portal extension developers and administrators as portal extension can now be deactivated on a stack and declared as optional.
We restructured the internal management storage handling to ensure the stability and performance it deserves. This includes a new package full of test scenarios against the storage base interfaces to allow also pre-built tests for any future storage provider. Read more here.
New utilities for integrators are now available to build automatically assigned portal node configurations by patterns. This enables various configurations sources like JSON files from hosting services or environment variables. Read more here.
We provide a new service for portals to make HTTP API usage a step easier.
The PSR-18 compatible HttpClientContract is preconfigured to throw exceptions for 4XX and 5XX status codes, add missing headers, follow redirects and retry in case of an error or rate limit.
When a flow component is put into the log context it will be swapped out with its code origin. This supports navigation to the source of an error, that is not identified by an exception.
All our storage implementations start to add some form of unique identifier to the request, so it can be found more easily in the source code when found in logs.
Even more log messages we write and exceptions we throw have unique identifiers for quick search in the code and in the online changelog.
Jobs have a state history that can be inspected for processing and performance analysis.
The dependency version range is changed to keep everything up to date.
This affects doctrine/dbal, shopware/core, ramsey/uuid and dragonmantank/cron-expression as library usage has been updated to match known deprecations and raised or removed.
Read more about its details in the changelogs.
As HEPTAconnect is looking to achieve a state-of-the-art experience on using our API, we improved our API design by ensuring to use final more frequently without removing extensibility.
To ensure code documentation browsing is easy, we add it to a lot of places within the code.
Even small subtleties are taken into account like $this in short notation flow components now refers to the wrapping object-oriented flow component.
Everyone managing an HEPTAconnect instance on setup can now use --bidirectional on heptaconnect:router:add to also create a route in the reverse direction.
More CLI commands are supporting JSON output for easier scripting use.
Spoiler alert: There is a huge change coming to raise the quality bar for administrator tools in the not so distant future.
Follow the news section by subscribing to the RSS feeds:
Or follow us on Twitter to get more insights on the briefly touched topics in here in the future.
]]>Since the version of 0.8 we add unique codes to exceptions and log messages. The full explanation can be read in this ADR.
In short: these unique codes are quickly looked out for. Either online in our documentation or your IDE. They describe a point in the source code and keeps consistent in meaning even after an update.
Although we use the unique codes for log messages and exceptions, you will likely only look them up because you are a first-responder to an issue of your system. So whenever you get a code from your log message's metadata you can just look them up in the search of our documentation. In general, you get a single hit within changelogs when the code has been introduced. There can be more hits, when the code has been moved to a different place or removed. In this scenario you can match by your installed HEPTAconnect version to find your issue. As these codes are part of our public API and are in the changelogs, you will find a technical reference and a human-readable meaning to it.
The real life scenario could now be something like this:
When there is the exception code 123 in your logs, and you find this message in the changelogs:
Add code
123in\Heptacom\HeptaConnect\TechnicalReference::doSomethingwhen JSON configuration file is invalid JSON.
And someone recently edited a JSON file, you can combine these hints and find a solution on your own.
As the changelogs are shipped with the code, you can also find this hint with a grep call in your installation.
When you search the files, you will also find that single piece of code that triggered the exception right away.
This will make first-responders more helpful and independent.
When we talk about codes in log messages, we should point out that these are not correlation identifiers. Correlation identifiers could only be queried in the HEPTAconnect installation as they identify a single situation like a specific web request or a job run.
To keep posted with our news, that will definitely contain information on correlation ids once they are released, subscribe our feeds:
Or follow us on Twitter.
]]>With the release of 0.9 we introduce a new feature for portal developers to vastly improve performances of file transfers. Previously, transferring files always required to write them to an intermediate storage and later read them from this storage again. The new FileReferences will respect the source of a file and choose the optimal transfer method accordingly. A portal developer can choose from three available file sources:
These three strategies already cover many use cases. Here are some example usages for each source type:
use Heptacom\HeptaConnect\Dataset\Ecommerce\Media\Media;
use Heptacom\HeptaConnect\Portal\Base\Builder\FlowComponent;
use Heptacom\HeptaConnect\Portal\Base\File\FileReferenceFactoryContract;
use League\Flysystem\Filesystem;
use Psr\Http\Message\RequestFactoryInterface;
use Psr\Http\Message\StreamFactoryInterface;
FlowComponent::explorer(Media::class, function (
FileReferenceFactoryContract $fileReferenceFactory
): iterable {
$publicUrl = 'https://picsum.photos/seed/php/300/300';
$fileReference = $fileReferenceFactory->fromPublicUrl($publicUrl);
$mediaEntity = new Media();
$mediaEntity->setPrimaryKey('ad9e5b8a46364e019d9b3045b5172623');
$mediaEntity->setFile($fileReference);
yield $mediaEntity;
});
FlowComponent::explorer(Media::class, function (
FileReferenceFactoryContract $fileReferenceFactory,
RequestFactoryInterface $requestFactory,
StreamFactoryInterface $streamFactory
): iterable {
$request = $requestFactory
->createRequest('POST', 'https://private-image-server.test/api/download-image/28664337703749c49af4bf198e94c396')
->withHeader('Authorization', 'Basic aGVwdGFjb25uZWN0OmlzIGNvb2w=')
->withBody($streamFactory->createStream(\json_encode([
'foo' => 'bar'
])));
$fileReference = $fileReferenceFactory->fromRequest($request);
$mediaEntity = new Media();
$mediaEntity->setPrimaryKey('ad9e5b8a46364e019d9b3045b5172623');
$mediaEntity->setFile($fileReference);
yield $mediaEntity;
});
FlowComponent::explorer(Media::class, function (
FileReferenceFactoryContract $fileReferenceFactory,
Filesystem $filesystem
): iterable {
$fileContents = $filesystem->read('data/images/a2ef9e0ef17e4b3585041ea36c4cde13/1.jpg');
$fileReference = $fileReferenceFactory->fromContents($fileContents);
$mediaEntity = new Media();
$mediaEntity->setPrimaryKey('ad9e5b8a46364e019d9b3045b5172623');
$mediaEntity->setFile($fileReference);
yield $mediaEntity;
});
We recommend to avoid using the source type "File contents", because it leads to I/O operations and preventing those will greatly improve performance. In an effort to prevent usages of "File contents" and therefore improve performance, you can utilize HTTP handlers to tunnel file downloads through HEPTAconnect. The idea is to generate a URL to be used as "Public URL" file source. This URL points to an HTTP handler that will perform the file download and return its contents as its response body. Take a look at the new article Send files from an FTP server to learn more about this topic and see our example code.
]]>HEPTAconnect is (at its core) completely framework-agnostic. That means, it can virtually be integrated into any kind of PHP-based application. This approach makes HEPTAconnect highly versatile, but it also requires integrating HEPTAconnect into an application to provide a runtime environment.
We aim to make setting up HEPTAconnect projects as simple as possible, so we created a template repository to kickstart your projects.
This repository is designed to be forked and then adjusted to your requirements.
Here you can check out our HEPTAconnect production template repository on GitHub and fork it yourself.
You can also use composer create-project to start your new project.
composer create-project heptaconnect/production my-project -s dev
At this point you should take a look at the README.md file.
There you will find a quick introduction and useful first steps.
This repository template is our recommendation to create new projects with HEPTAconnect. We will continue to maintain it to stay up to date with the latest HEPTAconnect releases. We also use this repository internally to kickstart our own HEPTAconnect integrations.
Currently, the production template depends on shopware/core for some dev-ops utilities and uses it as runtime environment for HEPTAconnect.
While this is not really a problem, we aim to be fully independent from shopware/core to trim down on our required composer packages.
We have that planned for version 0.10 of HEPTAconnect.
Furthermore, we plan to release more documentation content about the production template.
As of now, the README.md file inside the repository is the only documentation for it.
More detailed documentation that covers more use cases will follow soon™ in the Integrator section on the HEPTAconnect documentation website.
With HTTP handlers we already solved different challenges in the past:
So many use cases, where we could use an abstraction layer to share common code efficiently.
Good news: PSR-15 solves this problem conceptually.
With 0.9.2 we added support for PSR-15 middlewares for HTTP handlers. This means, you can add middlewares to your portal, which are automatically applied to all inbound HTTP requests and responses. Using this very powerful concept allows you to add custom logic like authorization, logging, caching, etc. to your portal.
PSR-15 is unfortunately not made for HTTP clients. The PSR-7 HTTP client can already have shared common code with the use of decorators, which are very similar to PSR-15 middlewares. Using these decorators is a good and known strategy but it is not as easy to use as the automatically applied PSR-15 middlewares. Therefore, we created our own middleware interface for HTTP clients, that is similar to PSR-15 middleware specification.
These two middleware interfaces will support you to build your own helpful tools for your project. Have a look at the documentation pages for the PSR-15 middleware interface and the HTTP client middleware interface to learn more about the interfaces and how to use them.
]]>composer require psysh you can use heptaconnect:repl, which integrates psysh into HEPTAconnectREPL stands for Read-Eval-Print-Loop.
It is a common pattern in programming languages to provide a way to execute code without prior writing and deployment.
You are likely familiar with this pattern from the browser console or the php -a/php --interactive command.
The php -a command is a REPL for PHP, that is shipped with the PHP interpreter itself.
Try it out yourself by simply typing php -a into your terminal and execute a command like var_dump(new DateTime()).
It will print the current date and time.
The execution did not stop though.
You can execute multiple commands in a row now by entering a new command.
This is where the loop comes in.
It will keep executing commands until you exit the REPL by typing exit or pressing Ctrl+D.
The php interactive mode is a very simple REPL, that does not provide any additional features you are used to from IDEs or other development tools.
psysh is a REPL for PHP written in PHP itself and shipped as a standalone package, that can be used as a replacement for php --interactive.
In comparison, it is a very powerful REPL, that provides a lot of features, that you know from your IDE.
You can look up code behind classes, read documentation, autocomplete code and much more.
It is really versatile and that is why we integrated it into HEPTAconnect.
Once you composer require psysh you can use the heptaconnect:repl command, which integrates psysh into HEPTAconnect.
It will automatically load a portal node container of your choice and provide you with a REPL, that is already configured to work with that specific portal node.
As example you can paste the following code into the REPL and execute it:
service(\Psr\Log\LoggerInterface::class)->info('Hello World');
This will log the message Hello World to the portal node specific logger.
You can access any service out of the portal node container and execute any code you want.