-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
hyper-express
High performance Node.js webserver with a simple-to-use API powered by uWebsockets.js under the hood.
-
-
desktop
Building native-like Elixir apps for Windows, MacOS, Linux, iOS and Android using Phoenix LiveView! (by elixir-desktop)
I'm one of the 3 maintainers of the French open-data transportation access point (at https://transport.data.gouv.fr/?locale=en), which runs on top of Elixir & Phoenix.
I'm not a big fan of surveys and I'm not sure I've responded to this one actually, but: my current feeling around Phoenix is that it will be my go-to framework for anything web related for the years to come, but also Elixir will be, for larger topics (ML, embedded, data-viz, scripting, etc).
There are a number of important points (to my taste) that comes out of my use of Elixir & Phoenix :
- the maintenance story has been quite good (maintenance work is one of my main line of work since year 2k, I have used many stacks, including Java, .Net, RubyOnRails etc). Upgrades and refactoring & moving code around has been quite easy overall, once you get the stuff right (using Mox etc).
- Phoenix, Ecto & Elixir are a good "generalist web framework" for a lot of use
- Compared to some stacks (non-evented Ruby & Python, for instance), having a part of your app work as a proxy for domain-specific uses, is not a problem, and does not even require you to split that part from the main app (example at https://github.com/etalab/transport-site/tree/master/apps/un..., where we proxy/cache GTFS-RT protobuf & SIRI XML feeds behind rules, adding rate-limiting & hiding target server authentication schemes)
- Similarly, anything real-time is at least initially trivial. For instance, creating this real-time view of moving vehicles (https://transport.data.gouv.fr/explore) with 70+ GTFS-RT feeds has been quite easy (PR at https://github.com/etalab/transport-site/pull/2224). The server side is like "EventMachine done right", and the live updates are broadcasted to each client via web socket. No extra server (e.g. AnyCable) or anything is needed.
From a perf/ops POV, the amount of topics you do not even have to think about is quite important, which is very nice.
Overall I can see myself sticking to this stack for the next 15 years or so, without much worries (I've been coding since 1984 as a kid, so I have a good idea to know when to keep a framework around or not :P)
Lots of reasons:
- Code cleanliness: their code almost looks like code golfing. Hard to debug.
- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.
- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...
- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.
- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.
- WebSocket pub/sub: built-in with uWebSockets.js
There are better alternatives like the following:
- https://www.fastify.io/
- https://github.com/uNetworking/uWebSockets.js
- https://github.com/kartikk221/hyper-express
Something like https://redux-saga.js.org/, basically doing complex background workflows, something that feels like event-driven browser JS was not really built to do
Generally speaking, if it can be done in the client, it should be done in the client.
Phoenix.LiveView.JS aims to tackle the obvious cases but it also documents a pattern that I tend to use a lot in my apps: https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...
The pattern above has a benefit that the dispatch still comes from Phoenix, so you are not relying on IDs or query selectors to attach functionality. You can see how we use it in Livebook here: https://github.com/livebook-dev/livebook/blob/main/assets/js.... However, if the callbacks get too complex, then you may indeed want to test them via headless browsers.
In your generated `my_app_web/endpoint.ex` there is a plug that will serve static contents from your `priv/static` directory:
https://github.com/phoenixframework/phoenix/blob/master/inst...
This points to a function in `my_app_web.ex` which specifies which paths it will serve:
https://github.com/phoenixframework/phoenix/blob/master/inst...
So you can either copy your js and image folders to `priv/static/assets` and they will be available as `localhost:port/assets/js/somefile.js` etc. OR you can add `js` to the list of paths to serve in app_name_web.ex and copy your js files to `priv/static/js` and access them at `localhost:port/js/somefile.js`.
Lots of reasons:
- Code cleanliness: their code almost looks like code golfing. Hard to debug.
- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.
- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...
- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.
- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.
- WebSocket pub/sub: built-in with uWebSockets.js
There are better alternatives like the following:
- https://www.fastify.io/
- https://github.com/uNetworking/uWebSockets.js
- https://github.com/kartikk221/hyper-express
Lots of reasons:
- Code cleanliness: their code almost looks like code golfing. Hard to debug.
- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.
- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...
- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.
- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.
- WebSocket pub/sub: built-in with uWebSockets.js
There are better alternatives like the following:
- https://www.fastify.io/
- https://github.com/uNetworking/uWebSockets.js
- https://github.com/kartikk221/hyper-express
Lots of reasons:
- Code cleanliness: their code almost looks like code golfing. Hard to debug.
- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.
- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...
- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.
- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.
- WebSocket pub/sub: built-in with uWebSockets.js
There are better alternatives like the following:
- https://www.fastify.io/
- https://github.com/uNetworking/uWebSockets.js
- https://github.com/kartikk221/hyper-express
Yes! (well I'm assuming you mean Storyboard). There's a new project that accomplishes just that: https://github.com/phenixdigital/phx_live_storybook
I think you may be looking for this neat library: https://github.com/elixir-desktop/desktop
Although to be honest it boggles my that it's possible to accomplish this on iOS.