
REST and GraphQL framework to build API-driven projects - yagodragon
https://api-platform.com
======
peteforde
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.

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.

~~~
xDest
Same question: Who would take Ruby or Django for a new project when the
language is not even existing in public discussion?

But honestly, the main reason is that you can find PHP developers everywhere
and they are cheap. Given that you want to build a project that grows and
advances, that is maintainable, for which you require a vast ecosystem to
kick-start your ideas and a lot of very good tooling and free sources of
knowledge, you won't find a better platform than PHP.

Ok, Perl might be an alternatively hugely developed language but it is really
complicated to find new developers for it. In contrast, you will find a lot of
developers, testers, sysops that have the knowledge for working and
administering the PHP tech stack. Yes, you could use the coolest language but
how would you be able to pay super expensive Go/Kotlin/Node developers once
your company has left start-up mode and is there really any gain from that?
The risk to be betting on a dying horse might be too high or, less dramatic,
everyone is just cooking with water.

If you want to earn money from your company and not just sell your expensive
personell at some point it makes sense to start easy and advance the people
you have. If you are building API based systems you are not locking yourself
in a technology anyways. Given how flexible and fast-moving technology is
today one could probably also find a good argument that you absolutely should
always base your projects on PHP.

~~~
CuriouslyC
My experience with PHP programmers is that while there are a lot more of them,
there aren't a lot of good ones. I suppose if you're just making a fairly
simple, server rendered CRUD app, that shouldn't be a problem...

~~~
4ndrewl
My experience with programmers is that while there are a lot of them, there
aren't a lot of good ones

------
joking
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.

You have several headless cms for almost any language, so you can start with
your language and database of choice and move from there.

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.

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

~~~
michelpp
Postgraphile is fantastic, as is PostgREST and I support them both on Patreon
because they have changed my life for the good immensely.

They both delegate the application entirely to Postgres, which can do
everything all other GraphQL/REST frameworks can do, with no ORMs, data
copying, restarting worker processes, poorly generated SQL, or worse. Both
systems can have a dozen workers per gigabyte of RAM, vs a dozen gigabytes of
RAM per worker for something like Django.

Postgres can do per-row security, can run functions in Python or Javascript or
many other languages, can integrate with FDWs to many external services (like
redis or mongo or what have you). Numerous extensions exist to trigger event
streams (like to rabbit) work with advanced text analysis and searching,
horizontal sharding of many different flavors, the list goes on.

If you have to write an API that's pure logic and no model, then pick your
favorite language; I'd probably use either Flask or node. But when does that
ever happen? Maybe a small sidecar API on what is generally a large CRUD
application with analytics. Everything SQL is perfectly designed to serve.
Stitch them together with GraphQL or route the REST off different path
prefixes from the frontend ala microservices.

~~~
mixmastamyk
How does one do migrations and that sort of thing when using these?

~~~
joking
migrations are needed to sync the database with the model, if your model comes
from the database, you don't need to do any migration.

~~~
mixmastamyk
Ok, so you're basically using straight SQL for development.

------
smt88
It's not immediately obvious from the summary at the top, but this is a PHP
library.

~~~
moveax
In detail a collection of symfony Framework components

------
dopeboy
(I realize this library is about PHP - read on for a slight tangent in the
Django world)

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?

I'm giving a talk at this year's PyBay and am looking to solicit some stories
/ experiences.

~~~
_AzMoo
Yes. The transition has been frustrating. We won't go back because of the
benefits inherent in GraphQL's design, but graphene-django has so much
boilerplate that a more complex application becomes very convoluted. In my
opinion there's a lot of work to be done to get it to a point where it's not a
frustrating experience to implement.

~~~
creimers
Similar experience. While the django rest framework is a joy to use, I’m
almost inclined to call graphene a headache. Poor docs, lots of spread our
third party extensions that really should be in the core... I have even found
myself wondering if the stark discrepancy between drf and graphene reflects or
hints at a decline of django as a framework.

~~~
cutler
I don't know about decline but in the UK there are currently 65% more Django
roles than Rails on Indeed.co.uk if you search by title:Django or Django
title:Python.

------
tannhaeuser
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.

~~~
erdii
I have never used SOAP/WSDL. What was particularly good or bad about them?

Only heard coworkers rant about the XML stuff...

~~~
tannhaeuser
What I said: it looks at the whole story, rather than piecemeally stitching
together a stack. The downside is that it's maybe overwhelming, especially
with multiple competing protocol specs and stacks doing the same thing.

As to XML: IMHO actually XML isn't a good fit for _most_ API payloads. XML
comes from markup languages/SGML which model semistructured data as regular
content models, rather than co-inductive data structures of programming
languages. The thing is, though, that the alternative, JSON, is really too
basic (doesn't have schema-based validation, doesn't have date datatypes or
enumerations, hell doesn't even have decimal numbers, etc.) Part of the story
why JSON is so popular is that it's untyped and you don't have to agree on
schemas, typed payloads, etc. upfront, and can just begin coding - but that
also means you don't have typing, service contracts, etc. as your apps mature.

~~~
chii
The format of the api (and its' payloads) also depends on the purpose of the
api.

If the api is meant to be tightly coupled to an app, and is designed for that
specific purpose, there's no reason to use anything like xml (or even, json) -
it should be compact binary and minimal footprint.

If the api is meant to be general and apply across a range of client
environments (e.g., you're selling this service api, and you dont know how or
what your customer might use it for), it makes sense to make an api that's
using an open format (like json, or xml) and have easily able clients in
multitude of languages.

------
conradfr
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.

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.

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.

~~~
overcast
This is ALWAYS my problem with frameworks. All of the database voodoo in the
background is a hack. If you end up requiring anything outside of simple
operations for a small audience, you'll be inevitably tearing it all out from
the ground up. I despise poor query performance more than anything.

~~~
kdunglas
With API Platform you can write your own SQL / Mongo / whatever queries
directly if you prefer: [https://api-platform.com/docs/core/data-
providers/](https://api-platform.com/docs/core/data-providers/) /
[https://api-platform.com/docs/core/data-persisters/](https://api-
platform.com/docs/core/data-persisters/) You can also customize / replace /
adapt the query generated by the ORM: [https://api-
platform.com/docs/core/extensions/#extensions](https://api-
platform.com/docs/core/extensions/#extensions)

------
bmn__
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:

http -v [https://demo.api-
platform.com/books/526eea89-f98c-4dfc-80bb-...](https://demo.api-
platform.com/books/526eea89-f98c-4dfc-80bb-22ef67f738ff)
Accept:application/hal+json

~~~
kdunglas
Hi!

* HAL-compliant link relations are included * OPTIONS is not part of the HAL Internet-Draft * JSON Merge Patch isn't part of the HAL I-D, however, it will be supported in the next major release * Pagination is supported: [https://demo.api-platform.com/books.jsonhal](https://demo.api-platform.com/books.jsonhal). Range aren't part of the HAL I-D. * HTTP authentication schemes are documented using OpenAPI. The HAL I-D contains nothings about auth schemes.

The default, and first-class citizen in API Platform is JSON-LD (+ Hydra). But
we know what we're doing and the HAL output is compliant with the I-D. Maybe
should you read the spec before posting.

------
softwarelimits
Took a look at this some time ago, a few things you might like to know before
diving deeper:

OpenAPI support

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.

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.

Security

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:

    
    
      /**
       * 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
       */
    

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).

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.

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?

Interesting alternative security implementation:
[https://medium.com/@ordermind/better-authorization-for-
symfo...](https://medium.com/@ordermind/better-authorization-for-
symfony-4-c958e9c6a410)

Integration

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.

Nice: GraphQL output only needs import of one library, no additional coding
needed.

Support: Better learn french if you are using this to build your company on.

~~~
esistgut
> Yes, that is a PHP comment - Symfony uses comments for simulation of the
> non-existing language feature of annotations.

There is an RFC[1] for builtin annotation but no one seems to care.

> Nice: GraphQL output only needs import of one library, no additional coding
> needed.

The GraphQL output is forced to a relay compliant format.

[1]
[https://wiki.php.net/rfc/annotations_v2](https://wiki.php.net/rfc/annotations_v2)

------
yodon
Or use NestJS to do this in the node ecosystem instead of the PHP ecosystem.

~~~
esistgut
Using nestjs/typeorm/type-graphql for my current project. I have to admit it
is quite refreshing after all of the yaml and docblock annotations of the
Symfony/Doctrine/APIPlatform ecosystem.

------
cutler
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.

~~~
joaobeno
Blaming the language for the market is a mistake... If you stop promoting PHP,
more devs will start on other language, and the market will pay lower, since
there is more people to pick from with that particular skill...

~~~
cutler
Hey, I never looked at it this way - seriously. PHP is doing the rest of the
programming world a service by absorbing all the low-end jobs.

