kdunglas

Server Push has a use case for web APIs. I just published a benchmark showing that under certain conditions APIs using Server Push (such as APIs implementing the https://vulcain.rocks specification) can be 4x times faster than APIs generating compound documents (GraphQL-like): https://github.com/dunglas/api-parallelism-benchmark

They key point for performance is to send relations in parallel in separate HTTP streams. Even without Server Push Vulcain-like APIs are still faster than APIs relying on compound documents thanks to Preload links and to HTTP/2 / HTTP/3 multiplexing.

Using Preload links also fixes the over-pushing problem (pushing a relation already in a server-side or client-side cache), some limitations regarding authorization (by default most servers don't propagate the Authorization HTTP header nor cookies in the push request), and and is easier to implement.

(By the way Preload links were supported from day 1 by the Vulcain Gateway Server.)

However, using Preload links introduce a bit more latency than using Server Push. Does the theoretical performance gain is worth the added complexity? To be honest I don't know. I guess it doesn't.

Using Preload links combined with Early Hints (the 103 status code - RFC 8297) may totally remove the need for Server Push. And Early Hints are way easier than Server Push to implement (it's even possible in PHP!).

Unfortunately browsers don't support Early Hints yet.

- Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=671310

- Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1407355

For the API use case, it would be nice that Blink adds support of Early Hints before killing Server Push!

Thanks then :)

> They are using AGPL as a fake open license

Actually, AGPL is the only license respecting copyleft's spirit for network applications such as the Vulcain Gateway Server (https://www.gnu.org/licenses/why-affero-gpl.en.html).

If big companies don't want to play the game for whatever legal reasons, that's on them. And... so there is the commercial license (even if I'm pretty sure I'll never sell a single one for Vulcain). If they really want to use it, they can pay (they pay for AWS, Windows, Sales Force... and a lot of other proprietary software after all).

> knowing no one will actually use it

MongoDB (among other big projects) is very popular, and has been licensed for a while with AGPL (and it wasn't even restrictive enough to prevent Amazon to predate them, but that's another topic). Also Ghostscript, ownCloud, nextCloud, SugarCRM...

In the case of Vulcain, the protocol is what has most value (IMHO), and it is not licensed under AGPL.

It's pretty easy to implement directly the protocol in an app server (if it is written in a programming language able to deal with HTTP/2 directly such as Go, Rust, C or Node).

> so this is really just a paid commercial venture trying to make itself look open sourcey

My goal when publishing free software isn't to help big companies making proprietary services to make even more money without giving anything back (MongoDB, Redis, ... stories).

Thanks to AGPL, users not able to modify the software (lack of financial resources, time or skills) can still benefit from changes made by big companies. That's the goal of copyleft.

If they don't want to play according to the copyleft rules, then ok, they can pay as for any other proprietary software. It looks like a fair deal to me.

> The work you're doing is too important to needlessly kill it like this.

I really appreciate, and I'll maybe consider switching to another license at some points if it's a real blocker. Mercure.rocks (another of my projects) use the same strategy (permissive spec, that anybody can implement, and AGPL implem) and so far it got both adoption (and PRs, even if, as for Vulcain, the main value is in the spec, the server is a tiny piece of software that doesn't require too much maintenance).

For lower level stuffs (such as my PHP libraries), I use MIT because they are designed to build something bigger, not to be used as-is such as the Vulcain Gateway Server or Mercure.

All my projects are free software (including their docs). You are free to improve them, or to not use them, or as you stated to hire me or anyone else to do it for you.

Anyway, I'm interested in hearing more about the corner cases and incomplete docs you stumbled upon, to fix/improve what can be done.

Thanks for the feedback! I just added a section in the README to clarify things about the license: https://github.com/dunglas/vulcain#license-and-copyright

* proprietary software can implement the Vulcain specification * proprietary software can be used behind the Vulcain Gateway Server without having to share their sources * modifications made to the Vulcain Gateway Server must be shared * alternatively, a commercial license is available for the Vulcain Gateway Server

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-persisters/ You can also customize / replace / adapt the query generated by the ORM: https://api-platform.com/docs/core/extensions/#extensions

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