mix_install_examples VS fetch

Ya, it's fair, it's a common complaint! Though the size of the generated files is nothing compared to Rails :D

You're right that phx_new does count too. It's a bit misunderstood that Phoenix is actually closer to a micro-framework like Flask than it is a full-fledged solution like Django or Rails. What takes it up to their level is `mix phx.new`, so your argument is more on point than I initially thought. The LiveView issue tracker even provides a single-file version of a Phoenix app to re-create your issue in [0]. As you can see, it's not as simple as something like Flask, but not as complex as the generator does.

Again, great article and happy to have you aboard ;)

Also, if you want an auth solution without code generation, there is Pow [1]

[0] https://github.com/wojtekmach/mix_install_examples/blob/main...

- learning how to compute the checksum of the internal content of a zip file https://github.com/etalab/transport-site/blob/master/scripts...

As mentioned in the article, I can definitely recommend to check out https://github.com/wojtekmach/mix_install_examples which has a long list of examples.

Streaming ChatGPT via SSE in Elixir: https://github.com/wojtekmach/mix_install_examples/pull/22#i...

love elixir. hate Mix.

it's like using Maven or npm all over again. but even worse because it generates a lot of code.

it creates disposable projects by design. No way to keep track of what to change when mix create outputs something different next year.

and now things like https://github.com/wojtekmach/mix_install_examples/blob/main... where is ecto even installed? download from where? so annoying this trend.

Like others have told you, Phoenix doesn't really add much complexity / fat / weight. In terms of complexity, if you don't want to use phx_new to boostrap the project here's a sample of using Phoenix LiveView in a single script file: https://github.com/wojtekmach/mix_install_examples/blob/main/phoenix_live_view.exs

If you want to play around with Ecto in isolation, you can (thanks to `Mix.install/2`) work in single-files, all containing the migrations, the schemas and configuration.

Check-out this repository for an example (and other single-file examples):

https://github.com/wojtekmach/mix_install_examples/blob/main...

mTLS has warts when used cross-origin. Fetch spec says that pre-flight requests mustn't include client certificates[1], so as a consequence servers behind mTLS authenticated proxy won't get a chance to reply to those pre-flight. Yet for non-preflighted requests it's fine to include client certificates..

[1] https://fetch.spec.whatwg.org/#cors-protocol-and-credentials

I've been testing full duplex streaming from and to the browser using fetch() in a Native Messaging host. (No browser currently support full duplex streaming even though HTTP/2 does, see Fetch body streams are not full duplex #1254).

Most js libraries use XMLHttpRequest and so provide HTTP_X_REQUESTED_WITH: XMLHttpRequest, but neither Chrome's implementation nor Github's polyfill of the new fetch uses a similar header. So how can one detect that the request is AJAX?

Any resource of significance should be given a URI. https://www.w3.org/DesignIssues/Axioms.html#uri

Or alternatively,

> Cool URLs don't change (implicitly, cool things have URLs, see above). https://www.w3.org/Provider/Style/URI

The advantage would be so high. It'd become a standard way to assert a resource, to make known a fact, that would be viable across systems. Instead of pushing to a chat app an anonymous chat message in a room, the server could assert a /room/42/msg/c0f3 resource, could identify universally what it is it's sending.

We have come glancingly close to getting such a thing so many times. The HyBi mailing list that begat websockets had a number of alternate more resourceful ideas floating around such as a BEEP protocol that allowed patterns beyond request/response of resources. The browser actually implements an internal protocol that uses HTTP2/push to send resourceful messages... Even though http2/push was de-implemented for webserving in general, and even though ability to hear push events was never implemented (oft requested).

The best we have today is to stream json-ls events, which have an @id property identifying them. But developers would have to snoop these events, and store them in a service worker, to make them actually accessible as http resources.

I continue to hold hope eventually we'll get better at using urls to send data, to assert new things happening... But it's been nearly 30 years of me hoping, and with some fleeting exceptions the browser teams have seemed disinterested in making urls cool, in spite of a number of requests. https://github.com/whatwg/fetch/issues/65 was an old request. https://github.com/whatwg/fetch/issues/607 had some steam in making it happen.

Fetch

Proposal: fetch with multiple AbortSignals - I got the idea of merging multiple signals from here.

Port 10080 is blocked on most browsers[0] per the WhatWG "bad ports" list[1]. That particular port was added to the list due to the Slipstream attack[2] that made the news a few years ago[3].

You don't have to switch to a browser that ignores standard security mitigations. Just pick a different port for your service.

[0] I just tested Chrome, Firefox, and Safari.

[1] https://fetch.spec.whatwg.org/#bad-port

[2] https://samy.pl/slipstream/

[3] https://news.ycombinator.com/item?id=24955891

Note that caching resources across sites isn't really a thing anymore. See https://github.com/whatwg/fetch/issues/904