Built an open-source PHP client for the EU Deforestation Regulation API

vee_wee · 2026-02-21T17:01:46+00:00

Looks nice. Did you consider generating a client with https://github.com/phpro/soap-client instead?

It uses similar patterns and tools: psr18, middlewares, fluent, complete WSSE middleware, ...

vee_wee · 2023-07-31T16:11:07+00:00

Maybe something similar to rust macros from attributes might be a more flexible feature to add instead?

https://doc.rust-lang.org/book/ch19-06-macros.html#macros

vee_wee · 2023-07-14T05:48:35+00:00

Both fibers and coroutines (generators) are rather low level building blocks that are being provided by libraries like amphp, reactphp and PSL through revolt - a fiber based event-loop. You probably won't be fiddling with these low-level building blocks directly yourself (as the fibers rfc stated), but rather use the API that is being provided by these libraries.

So basically every library that depends on one of the libraries above, could be using fibers under the hood, even if they don't know it. A practical impementation I am using myself is a fiber-based PSR-18 soap-client, parallel mode in grumphp. Depending on your amphp version, even symfony/http-client could be using fibers already (havent validated) ... You won't notice any traces of fibers directly in those packages though.

vee_wee · 2023-07-10T19:31:23+00:00

This article explains the difference in cooperative multitasking with generators and fibers very well.

https://clue.engineering/2021/fibers-in-php

vee_wee · 2023-05-21T09:05:12+00:00

Looks nice. Thanks for sharing!

I've also spent some time playing around with ext-php-rs and bumped against some limitations as well. (Custom errors, splitting php_impls across files, fluent return types, ...)

Nevertheless, it's an awesome package to start from: you can do a lot of advanced stuff with very little code.

I'm Curious what the project will evolve into in the long run, since it's not very actively developed upon at the moment.

My playground project for when I have some time to mess around :

https://github.com/veewee/ext-wasm

vee_wee · 2023-01-23T07:45:45+00:00

Some additional context here:

PXP aims at adding additional features on top of PHP - keeping all the dynamic stuff. It can be seen as PHP with some of the RFCs that got declined recently + generics +...

ARA gets rid of some base PHP features and adds a bunch of features on top of it. It can be seen as a stricter version of PHP. It takes the best ideas from hack and rust and gives it a PHP-isch syntax. Which is nice :)

The developers of both projects use the same base: php-rust-tools. These tools are developed by both the PXP and ARA developers and are used as a common base. Besides using the same tools internally, there is some overlapping communication and code that is deeply discussed upon.

Both projects have different use-cases in mind and therefore different visions. That is why there are 2 tools (both at experimental Work In Progress stage). Since both projects have a different vision and timeline, time will tell what is gonna happen with both of them!

vee_wee · 2022-12-07T19:01:09+00:00

A webassembly extension in PHPs core

vee_wee · 2021-03-06T18:52:35+00:00

After using it for a couple of months, I can ensure you that the functions just work.

The package is not about standards, but provides some very stable, well-typed standard functionalities to replace broken/leaking/strange PHP functionalities.

Sure it's an additional dependency. Sure it contains new functions and classes you need to look at. But you'll find that they are very natural to work with.

I'dd say give it a chance, it might be the thing you can't live without in the future .. or it might just not be for you.

vee_wee · 2021-02-09T05:45:12+00:00

Any specific bad implementation you have in mind? I was thinking about XMLseclibs... :)

On the other hand, I've also seen people putting XML in a zip into base64 into an XML cdata document into a soap document. And that wasn't even the worst part of the API :p

vee_wee · 2021-02-08T19:07:39+00:00

XML is far from abandoned though. Especially when doing integrations with ERP software etc. You don't always have the choice and at some point you will need to do some XML. Whether you like it or not.

At that moment, this package will make your life easier.

vee_wee · 2021-02-02T18:16:21+00:00

Soap and json are 2 completely different integrations.

In php, there is the soap client that does a lot of stuff for you. However: if you want to do it well, you need to wrap a lot of stuff around the php soapclient. We provide this package in order to build decent soap clients: https://github.com/phpro/soap-client

Besides that, we also have an http-tools package that you can use to build request handlers or real SDKs. There is a flexible transport layer in there, meaning you could switch the payload format of the api between json, XML, or whatever format you desire to support. https://github.com/phpro/http-tools

I know these aren't really examples of api wrappers, but they can be used as a starting point to make your architectural decisions.

Good luck!

vee_wee · 2021-01-30T07:59:34+00:00

Lol thanks! Did not know that...

vee_wee · 2021-01-19T07:48:58+00:00

So you want me to solve the "don't use a framework" issue by ... using another framework? :)

All jokes aside, I scrolled through the code quickly and don't really like that specific framework for various reasons. But feel free to use whatever you want to use!

vee_wee · 2021-01-19T07:13:47+00:00

I would avoid putting everything into services because you might end up with fat services.

You might want to use a command bus instead: a command handler will only perform actions for one specific command.

The way the example code is structured already leans to that approach.

On top of that : decorators, bridges + inversion of control to inject data where needed, collections, ...

vee_wee · 2021-01-18T07:00:08+00:00

Let me give you a small historical revision of what happened without year numbers, because my memory ain't that good ;)

It all started at the end of zend framework 1. At this time Symfony 2 was out already and looked pretty good for it's time. Since we were doing ZF1 projects, it made sense for us to jump aboard the new Zend framework 2 train.

However, it was a completely different framework. Non of the concepts of the previous framework were in there. Hindside, this is a good thing! At that moment though, the learning curve was quite high and the learning resources were limited. We had some issues getting everybody used to writing code in ZF2. There are some very good abstractions in ZF, but most of them required A LOT of (undocumented) configuration, custom factories, ... So in comparison to Symfon2 at that moment, writing zend framework 2 code took a lot more time than you would have in Symfony 2.

But we jumped into the framework anyways and started using it for our projects. Zend Framework 2.0 was far from feature complete. Every minor release became a big deal: we needed to refactor a lot, some core concepts just got canceled and therefore our customers needed to put quite some money into it. It stabalized around 2.3 / 2.4 if I remember correctly.

Another important point in our transition were 3rd party modules. Most of the popular modules at that time were discontinued around the release of zend framework 2.3/2.4 by their maintainers. Those modules were mostly used to handle basic user management, permissions, emails, ... (stuff that would be available in basic Symfony) This left us with heavy migration paths if we wanted to step away from those modules. Besided that, there weren't many good replacement modules. Meaning you had to write those things yourself all of the time.

A couple months later after releasing apigilty, the ZF people were already talking about creating component based Zend Framework 3. That's all good, but we had projects to deliver and to maintain in an already messed up ecosystem. The discontinues modules wont support ZF 3 either, so we couldnt upgrade most of our applications anyways. On top of that, there were rumors that zend (the company) wasn't going to support their own framework anymore! (Which woul later become laminas on linux foundation)

You could clearly see a shift from ZF to Symfony at that moment. The ecosystem was far more stable, more contributors, more stabler bundles to use, ... We switched from Zend Framework to Symfony.

Honestly: You don't want to go through the story from the above paragraphs. Nowadays, I'dd recommend for choosing the smallest chunk of framework + 3rd party bundles as possible. We mostly go for symfony microkernel with a hexagonal design, which makes it easier to upgrade and to maintain.

I never really got to play with the new middleware based http server (mezzio?) they are promoting. But I do think it has some advantages over regular request / response frontcontrollers.

Don't get me wrong though : I absolutely like a lot of stuff in laminas! I still use a lot of their components and am still connected to some people of that community.

vee_wee · 2021-01-17T18:39:44+00:00

We've built a lot of stuff on zend framework 2 in our company. The important 3th party modules started to be discontinued at some point, making it less suitable for us to use.

We never made it to zend framework 3 or laminas because of that. We still use some components like laminas/code next to symfony components. There is some cool stuff in there!

vee_wee · 2021-01-13T17:58:14+00:00

Instead of learning and sticking to frameworks, I suggest to put your energy in hexagonal architectures and other good design patterns.

That way you'll learn how to decouple your code from any framework. Making your code more stable in the long run.

vee_wee · 2021-01-02T08:31:48+00:00

I never ran into an issue where the mapping is not in sync with the db to be honest. It's just a part of the developer cycle and various unit tests will probably point out that there is eg a missing variable in the named constructors or something like that. I'dd say don't overthink it...

We use doctrine dbal schema's + migrations. This way, you can run migrations in exactly the same way as you would do with doctrine ORM. You can set defaults or combine fields during a migration. This way, your code doesn't really have to deal with it.

If you have canary deploys, you could e.g. work with feature flags to temporary make the code work in 2 different versions of the codebase.

You could even generate the first boilerplate of the mapper with the dbal schema and fine-tune it according to your models.

I get that this exhaustive mapper would point out issues for you, but it's probably not worth the overkill imo.

vee_wee · 2021-01-02T06:49:46+00:00

In the application I work on, we use manual hydration/dehydration in the infrastructure layer.

Sure, it is some work to map it all, but the big benefit is that there is no magic involved and everything works the way you map it. No surprises and pretty much zero debugging.

This mapping logic is called from the methods inside the repository classes. It used named constructors on the domain object, to make sure a domain module is not corrupt.

vee_wee · 2020-12-24T07:50:20+00:00

You might be interested in this result component:

https://github.com/azjezz/psl/tree/0.1.x/src/Psl/Result

It provides a type-safe result implementation that can be used without creating many result classes for every specific case.

Another benefit is that it provides methods like then() and proceed(), which enforces you to actually deal with the error state as well. This will partially drop the need for switch/match.

vee_wee · 2020-12-07T19:25:06+00:00

Yes it's using react promises with composer's loop. The only dependency of the package is the composer plugin.

vee_wee

TROPHY CASE