Serious question: why voluntarily choose PHP for a greenfield project in 2019? Less terrible is not a huge selling feature when most of the good stuff in Laravel is lifted directly from Rails but with none of the developer happiness.<p>The only argument I can think of is that you already have a team of PHP experts and they don't want to transition to Ruby, Node or Django.
I would call this YAHCMS (Yet Another Headless CMS). This has a client app however, where in most of the headless cms they give you a client library at most and you can use the framework that you like.<p>You have several headless cms for almost any language, so you can start with your language and database of choice and move from there.<p>I particularly settled with this arquitecture:
- Postgraphile as an api layer over the postgresql storage
- prect client, as I work with old embedded systems and need something very small.<p>It doesn't have an automated admin as I don't need it, but if needed you could throw an admin built with react-admin or something similar
(I realize this library is about PHP - read on for a slight tangent in the Django world)<p>For the Djangonauts in the crowd, has anyone moved from REST to GraphQL in their teams? How's the transition been and what kind of tools did you use?<p>I'm giving a talk at this year's PyBay and am looking to solicit some stories / experiences.
Maybe SOAP isn't so bad after all. Like GraphQL, it can aggregate multiple "API" calls (actually service/protocol invocations) into a single, typed payload to the client, also exposes a typed state model (WSDL ports/interfaces), has uniform error messages, takes care of security contexts and transaction boundaries, models asynchronous/message-queue-based invocations in the same modelling universe rather than binding directly to HTTP, etc.
So my company (a Symfony shop) is currently migrating its API to this, despite my recommendation, and the lack of maturity of the project really shows sometimes.<p>So far it has slowed us down more than speed us up, except maybe right at the beginning, which in my experience is usually the case with these kind of tools.<p>From what I hear there was problems due excessive db queries for serializing entities and stuff. I do not work on that project though so I don't have more details and take all that with a grain of salt.
I'm quite disappointed in the HAL representation, it lacks standard compliant link relations. OPTIONS is not supported. PATCH with application/merge-patch+json is not supported. Range on items is not supported. JSON home document is not supported. Deprecation is either not supported or undocumented. HTTP authentication schemes are either not supported or undocumented. It looks like the authors of this software don't know what they're doing; I could build much richer HAL documents than them. Try with httpie to see what I mean:<p>http -v <a href="https://demo.api-platform.com/books/526eea89-f98c-4dfc-80bb-22ef67f738ff" rel="nofollow">https://demo.api-platform.com/books/526eea89-f98c-4dfc-80bb-...</a> Accept:application/hal+json
Took a look at this some time ago, a few things you might like to know before diving deeper:<p>OpenAPI support<p>Developers seemed to oversee that there is an important spec-first trend with building apis. Currently there is no way to generate code / models from OpenAPI spec, only generates documentation - so the statement about "OpenAPI integration" is only partially true.<p>Instead you have to fall back to legacy technique of manually coding models - this is bad for teams that adapted OpenAPI as their single source of truth. With this project you will have to maintain php code on api updates and it breaks any established spec-first OpenAPI roundtrip workflow.<p>Security<p>Very weak support for expected security out of the box - you need to implement Symfony based security ideas - if you have already done this and know that dark planet, go for it, if you have never seen that before be prepared for lots of awkwardness:<p><pre><code> /**
* Secured resource.
*
* @ApiResource(
* attributes={"access_control"="is_granted('ROLE_USER')"},
* collectionOperations={
* "get",
* "post"={"access_control"="is_granted('ROLE_ADMIN')"}
* },
* itemOperations={
* "get"={"access_control"="is_granted('ROLE_USER') and object.owner == user"},
* "put"={"access_control"="is_granted('ROLE_USER') and previous_object.owner == user"},
* }
* )
* @ORM\Entity
*/
</code></pre>
Yes, that is a PHP comment - Symfony uses comments for simulation of the non-existing language feature of annotations. Anybody who needs to make money in the Symfony universe follows that awkward and evil cult. Privately you will always hate it, but if all your team says "cool" you just shut up and accept it (and start looking for the next better job).<p>The whole security story with Symfony seems to be a horrible mess and after-thought, feels incredible tacked-on and will slowly grow into a maintenance nightmare. Badly maintained external libraries. Every software that uses it implements it in a different way.<p>But: because of large adaption in companies you will still find a solution for everything - be prepared for a long journey. You will end up with your very own solution and never be sure, if it is really secure - why did you want to use open source in the first place - was it for security reasons?<p>Interesting alternative security implementation:
<a href="https://medium.com/@ordermind/better-authorization-for-symfony-4-c958e9c6a410" rel="nofollow">https://medium.com/@ordermind/better-authorization-for-symfo...</a><p>Integration<p>This is just Symfony, so luckily you will find libraries for everything. However, it seems to be somehow detached from the current API product market, so there are some overlapping and not so obvious integration points with tools that help with API management. Note: this is not a complete api platform like the name suggests - many basic features for API management are missing. Developers should stop simulation of "no other software exists" and instead offer nice integration with some of the advanced api management tools.<p>Nice: GraphQL output only needs import of one library, no additional coding needed.<p>Support: Better learn french if you are using this to build your company on.
PHP is responsible for the commoditisation of developers. PHP salaries and contract rates are 20% less than for Ruby, Python and Node.js here in the UK. The demands of the job are just the same, ie. Laravel = Rails = Django, but companies assume they can get good developers 20% cheaper just because they use PHP. That's gotta be the main reason to stop using and promoting PHP.