Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
You can find the framework code itself at github.com/feastframework/framework and the application skeleton at github.com/feastframework/feast. Alternatively, on packagist at packagist.org/packages/feast
FEAST works with composer and supports PSR4 autoloading standard. In addition there is 100% line coverage via PHPUnit and 100% static type analysis (occasionally through docblocks, mostly through strong typing) via vimeo/psalm.
You can find the framework code itself at github.com/feastframework/framework and the application skeleton at github.com/feastframework/feast. Alternatively, on packagist at packagist.org/packages/feast
The point is why would I pull in code in the first place that is not needed? If it is optional, then why is it not a separate package? Same with all of the bloated HTTP requests and response objects that frameworks and other libs usually use. I really like https://github.com/Nyholm/psr7 for that reason, it has a table in it's readme.md that is pretty much enough to know why I like it. If something specific is needed it can be decorated or extended on project level.
https://github.com/envms/fluentpdo is another good example of a small library that gets one thing well done. ORM? Not always needed, depending on your architecture of course. I keep my aggregates almost 3rd party dependency free (ramsey/uuid) and just write them to the DB when done. Reading is mostly done via specialized read models that are using document based DBs.