12 ms·

REST and GraphQL framework to build API-driven projects

230 points by yagodragon 7y ago

smt88 7y ago
It's not immediately obvious from the summary at the top, but this is a PHP library.
- moveax 7y ago
  In detail a collection of symfony Framework components
kwesidev 7y ago
php is dead
- sk0g 7y ago
  And yet there's a modern (looking) library that seems to make using state of the art technology painless. Mind sharing your definition of "dead"? It's not a part of the tech stack I work with currently, but that's not what we mean by dead, right? :)
- sebcat 7y ago
  PHP-FIG brought PHP back to life from my point of view.
  - gulperxcx 7y ago
    and also the Laravel framework
    - thinkindie 7y ago
      Laravel is a layer of singletons on top of Symfony components, I think it should not be credited for PHP renaissance.
      - tpetry 7y ago
        Larsvel may be built on the shoulders of symfony but it achieved to build a great ecosystem dragging in new people. So he is right.
        thinkindie 7y ago
        it managed to attract a lot of people that used to use wordpress or some spaghetti code, helping giving the idea PHP is not a good fit for enterprise-grade software.
- JMTQp8lwXL 7y ago
  Genuine question: Is anybody picking up PHP off the shelf for starting applications today, or its relevance mostly in existing applications like Facebook (which I've read is powered by PHP).
  - jefozabuss 7y ago
    Started using it (Laravel) for a new project recently, looks pretty handy so far (lots of forms and validation).
    - JMTQp8lwXL 7y ago
      My favorite forms solution (for SPAs) is https://github.com/final-form/final-form https://github.com/final-form/final-form (there are adapters for React and Vue). The author has also written a previous form management tool called Redux Forms. Between the two versions (both are very good), you could tell the API evolution that the author had deep knowledge of the space, and the solution is pretty elegant.
  - bebna 7y ago
    Just look at the awesome selfhosted list and you will see that php still dominates. In my city, php is still in the top 3, too.
  - moksly 7y ago
    I have an old friend who’s been working with PHP for almost two decades. We’ve teased him a lot over the years “because PHP”, but the truth is that in 2019 PHP is actually rather relevant. Everything is becoming a web-app, even major enterprise solutions are turning into some sort of web-api and a MVVM JavaScript front, and PHP is actually rather suited for this. It’s fast, relatively safe and reliable and you won’t have trouble hiring for it. I think one of the reasons you don’t hear too much about it is the same reason you don’t see a lot of JAVA or C# articles on HN, it’s old. If I look at my local jobmarket for development though, those three languages make up around 90% of the current open positions.
    - 7y ago
dopeboy 7y ago
(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 7y ago
  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.
  - dmix 7y ago
    You won’t go back because of the gains but would you have done it again from the start? Or is it more of the supporting libraries being the problem. Even outside of python many people seem to be on the fence when talking about actually implementing it.
    - _AzMoo 7y ago
      It's the supporting libraries. GraphQL itself is fantastic and solves so many of the issues that crop up when using REST, especially around excessive requests, extraneous data and poor transaction support. My team's core knowledge is in Python and Django so that's where we're most productive, even hamstrung by the tools, but with a bit more flexibility in timelines I'd probably go the typescript/node/apollo route.
  - creimers 7y ago
    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.
deleted 7y ago
[deleted]
peteforde 7y ago
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.
- thinkindie 7y ago
  this comment is so 2005 and it is suggesting you haven't worked with the latest versions of PHP and the ecosystem around it. From a language perspective, PHP is not any worse than Ruby, Python or Javascript. Composer, Symfony and other libraries have improved PHP projects by a lot.
  - skrebbel 7y ago
    PHP is still super quirky and inconsistent though. You can't fix that without breaking backward compatibility.
    - kartan 7y ago
      JavaScript is still super quirky and inconsistent though. You can't fix that without breaking backward compatibility.
      - deleted 7y ago
        [deleted]
      - dmix 7y ago
        Are you saying PHP has improved the way JavaScript has over the last decade? The improvements in both the language/community plus how people are using JS since The Good Parts was quite a significant improvement. But people largely went through that whole process because of the ubiquity of browsers not because JS was a good idea. There are so many better alternatives on the server side for web, I don’t see the point in PHP going through that whole renovation unless it’s to hire more and cheaper developers.
tannhaeuser 7y ago
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 7y ago
  I have never used SOAP/WSDL. What was particularly good or bad about them? Only heard coworkers rant about the XML stuff...
  - true_religion 7y ago
    He thing about soap was that it was not simple. You had a full object model which was separate from your language and used different semantics. Operating it require a library which wasn’t often nice to work with. It’s the same argument against ORMs. If the library is bad, the ORM becomes a worst common demonominator interface.
  - tannhaeuser 7y ago
    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.
    - 7y ago
softwarelimits 7y ago
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-symfony-4-c958e9c6a410 https://medium.com/@ordermind/better-authorization-for-symfo... 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.
cutler 7y ago
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 7y ago
  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 7y ago
    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.
yodon 7y ago
Or use NestJS to do this in the node ecosystem instead of the PHP ecosystem.
- esistgut 7y ago
  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.
- iosonofuturista 7y ago
  I'm using Nestjs / typeorm for a mobile app backend, and I must say I am enjoying it a lot. Previously I would use symfony / doctrine, or some other PHP / ORM combo, but the TypeScript environment is much more to my liking. This will not convince anyone who dislikes node.js, but if anyone here is considering a node.js backend, give Nestjs a try. I did some tests and found it preferable than pure Express, Sails, or Ember. Edit: I agree with softwarelimits comments. I absolutely hate synfony/doctrine comment annotations. TypeScript decorators are a better solution.
- resurge 7y ago
  This doesn't seem to do as much as API Platform though? In API Platform you can just define an entity and it will automatically expose CRUD endpoints for that entity [1]. While in NestJS it seems you still need to define each action manually [2]. It's too bad cause I'm really looking for something like API Platform in Typescript. [1] https://api-platform.com/docs/distribution/#bringing-your-own-model https://api-platform.com/docs/distribution/#bringing-your-ow... [2] https://docs.nestjs.com/controllers https://docs.nestjs.com/controllers
conradfr 7y ago
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.
- mLuby 7y ago
  Interesting. What would you say the argument or feature was that won people over?
  - conradfr 7y ago
    Quick bootstrapping for auth, routes, serialization etc I guess.
- overcast 7y ago
  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 7y ago
    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
joking 7y ago
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 7y ago
  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 7y ago
    How does one do migrations and that sort of thing when using these?
    - RussianCow 7y ago
deleted 7y ago
[deleted]
bmn__ 7y ago
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-22ef67f738ff https://demo.api-platform.com/books/526eea89-f98c-4dfc-80bb-... Accept:application/hal+json
- kdunglas 7y ago
  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.

230 points by yagodragon 7y ago

smt88 7y ago

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

moveax 7y ago
In detail a collection of symfony Framework components

kwesidev 7y ago

php is dead

sk0g 7y ago
And yet there's a modern (looking) library that seems to make using state of the art technology painless. Mind sharing your definition of "dead"? It's not a part of the tech stack I work with currently, but that's not what we mean by dead, right? :)
sebcat 7y ago
PHP-FIG brought PHP back to life from my point of view.
- gulperxcx 7y ago
  and also the Laravel framework
  - thinkindie 7y ago
    Laravel is a layer of singletons on top of Symfony components, I think it should not be credited for PHP renaissance.
    - tpetry 7y ago
      Larsvel may be built on the shoulders of symfony but it achieved to build a great ecosystem dragging in new people. So he is right.
      - thinkindie 7y ago
        it managed to attract a lot of people that used to use wordpress or some spaghetti code, helping giving the idea PHP is not a good fit for enterprise-grade software.
JMTQp8lwXL 7y ago
Genuine question: Is anybody picking up PHP off the shelf for starting applications today, or its relevance mostly in existing applications like Facebook (which I've read is powered by PHP).
- jefozabuss 7y ago
  Started using it (Laravel) for a new project recently, looks pretty handy so far (lots of forms and validation).
  - JMTQp8lwXL 7y ago
    My favorite forms solution (for SPAs) is https://github.com/final-form/final-form https://github.com/final-form/final-form (there are adapters for React and Vue). The author has also written a previous form management tool called Redux Forms. Between the two versions (both are very good), you could tell the API evolution that the author had deep knowledge of the space, and the solution is pretty elegant.
- bebna 7y ago
  Just look at the awesome selfhosted list and you will see that php still dominates. In my city, php is still in the top 3, too.
- moksly 7y ago
  I have an old friend who’s been working with PHP for almost two decades. We’ve teased him a lot over the years “because PHP”, but the truth is that in 2019 PHP is actually rather relevant. Everything is becoming a web-app, even major enterprise solutions are turning into some sort of web-api and a MVVM JavaScript front, and PHP is actually rather suited for this. It’s fast, relatively safe and reliable and you won’t have trouble hiring for it. I think one of the reasons you don’t hear too much about it is the same reason you don’t see a lot of JAVA or C# articles on HN, it’s old. If I look at my local jobmarket for development though, those three languages make up around 90% of the current open positions.
  - 7y ago

dopeboy 7y ago

(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 7y ago
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.
- dmix 7y ago
  You won’t go back because of the gains but would you have done it again from the start? Or is it more of the supporting libraries being the problem. Even outside of python many people seem to be on the fence when talking about actually implementing it.
  - _AzMoo 7y ago
    It's the supporting libraries. GraphQL itself is fantastic and solves so many of the issues that crop up when using REST, especially around excessive requests, extraneous data and poor transaction support. My team's core knowledge is in Python and Django so that's where we're most productive, even hamstrung by the tools, but with a bit more flexibility in timelines I'd probably go the typescript/node/apollo route.
- creimers 7y ago
  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.

deleted 7y ago

[deleted]

peteforde 7y ago

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.

thinkindie 7y ago
this comment is so 2005 and it is suggesting you haven't worked with the latest versions of PHP and the ecosystem around it. From a language perspective, PHP is not any worse than Ruby, Python or Javascript. Composer, Symfony and other libraries have improved PHP projects by a lot.
- skrebbel 7y ago
  PHP is still super quirky and inconsistent though. You can't fix that without breaking backward compatibility.
  - kartan 7y ago
    JavaScript is still super quirky and inconsistent though. You can't fix that without breaking backward compatibility.
    - deleted 7y ago
      [deleted]
    - dmix 7y ago
      Are you saying PHP has improved the way JavaScript has over the last decade? The improvements in both the language/community plus how people are using JS since The Good Parts was quite a significant improvement. But people largely went through that whole process because of the ubiquity of browsers not because JS was a good idea. There are so many better alternatives on the server side for web, I don’t see the point in PHP going through that whole renovation unless it’s to hire more and cheaper developers.

tannhaeuser 7y ago

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 7y ago
I have never used SOAP/WSDL. What was particularly good or bad about them? Only heard coworkers rant about the XML stuff...
- true_religion 7y ago
  He thing about soap was that it was not simple. You had a full object model which was separate from your language and used different semantics. Operating it require a library which wasn’t often nice to work with. It’s the same argument against ORMs. If the library is bad, the ORM becomes a worst common demonominator interface.
- tannhaeuser 7y ago
  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.
  - 7y ago

softwarelimits 7y ago

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-symfony-4-c958e9c6a410 https://medium.com/@ordermind/better-authorization-for-symfo... 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.

cutler 7y ago

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 7y ago
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 7y ago
  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.

yodon 7y ago

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

esistgut 7y ago
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.
iosonofuturista 7y ago
I'm using Nestjs / typeorm for a mobile app backend, and I must say I am enjoying it a lot. Previously I would use symfony / doctrine, or some other PHP / ORM combo, but the TypeScript environment is much more to my liking. This will not convince anyone who dislikes node.js, but if anyone here is considering a node.js backend, give Nestjs a try. I did some tests and found it preferable than pure Express, Sails, or Ember. Edit: I agree with softwarelimits comments. I absolutely hate synfony/doctrine comment annotations. TypeScript decorators are a better solution.
resurge 7y ago
This doesn't seem to do as much as API Platform though? In API Platform you can just define an entity and it will automatically expose CRUD endpoints for that entity [1]. While in NestJS it seems you still need to define each action manually [2]. It's too bad cause I'm really looking for something like API Platform in Typescript. [1] https://api-platform.com/docs/distribution/#bringing-your-own-model https://api-platform.com/docs/distribution/#bringing-your-ow... [2] https://docs.nestjs.com/controllers https://docs.nestjs.com/controllers

conradfr 7y ago

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.

mLuby 7y ago
Interesting. What would you say the argument or feature was that won people over?
- conradfr 7y ago
  Quick bootstrapping for auth, routes, serialization etc I guess.
overcast 7y ago
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 7y ago
  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

joking 7y ago

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 7y ago
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 7y ago
  How does one do migrations and that sort of thing when using these?
  - RussianCow 7y ago

deleted 7y ago

[deleted]

bmn__ 7y ago

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-22ef67f738ff https://demo.api-platform.com/books/526eea89-f98c-4dfc-80bb-... Accept:application/hal+json

kdunglas 7y ago
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.