Deploying a Phoenix app to Fly.io is a breeze...is what everyone kept telling me. In fairness, I imagine the process would have been breezier had I just used postgres, but all the sqlite and litestream talk has been far too intriguing to ignore. "Wait", you say. "It is just a flat file. How much harder can it be?"
It is easy to make something harder than it should be. It is hard to take something complex and make it truly simple. flyctl launch does an amazing job at providing a simple interface to the utterly complex task of generating deployment resources, especially now that we are living in a containerd (erm, firecracker) world.
This gist is for anyone who, like me, thinks they know better than to read all of the documentation and therefore necessari
Tutorial: https://www.youtube.com/watch?v=hIqMrPTeGTc
Paste the below code in your browser console (F12 > Console):
(()=>{
markAllVideosAsNotBeingInteresting({
iterations: 1
});
})();
| // We support the GET, POST, HEAD, and OPTIONS methods from any origin, | |
| // and allow any header on requests. These headers must be present | |
| // on all responses to all CORS preflight requests. In practice, this means | |
| // all responses to OPTIONS requests. | |
| const corsHeaders = { | |
| "Access-Control-Allow-Origin": "*", | |
| "Access-Control-Allow-Methods": "GET,HEAD,POST,OPTIONS", | |
| "Access-Control-Max-Age": "86400", | |
| } |
I have created a library based on the below snippets: https://github.com/arkadiyk/surface_rich_components
defmodule Components.TextEditor do
use Surface.Component
| import * as Y from 'yjs' | |
| import * as mutex from 'lib0/mutex.js' | |
| import { Observable } from 'lib0/observable.js' | |
| import PouchDB from 'pouchdb'; | |
| // This is the name of the top level Y.Map that is used to construct the main pouchDB | |
| // JSON document. | |
| const topDataYMapName = 'data'; |
| import { useEffect, useState } from "react" | |
| import { createBrowserHistory } from "history" | |
| const history = createBrowserHistory() | |
| const toLocation = path => new URL(path, window.location.href) | |
| // without this react won't re-render as location is the same object | |
| // @see https://reactjs.org/docs/hooks-reference.html#bailing-out-of-a-state-update | |
| const cloneLocation = () => Object.assign({}, window.location) |
| /* Was looking for a way to delegate global keyboard shortcuts in an app to small | |
| * Preact components in a way that didn't require any of: | |
| * • Binding and unbinding events on ancestor nodes by a component's render function | |
| * • Calling a function from a render function to try to manage/track that event-binding state for me | |
| * • Require me to adopt class-ey components for only this feature (binding and unbinding an out-of-scope event using lifecycle hooks) | |
| */ | |
| const FORWARDING_RULES = [ | |
| {node: document, event: 'keydown', test: e => e.keyCode === 13, delegate: '.handle-enter'} | |
| ] |
It's relatively easy to scale out stateless web applications. You often only need a reverse proxy. But for those stateful web applications, especially those applications that embeds websocket services in them, it's always a pain to distribute them in a cluster. The traditional way is introducing some external services like Redis to handle pubsub, however, in such way, you often need to change your code. Can Erlang/Elixir, the "concurrency oriented programming languages", best other languages in this use case? Has Phoenix framework already integrated the solution of horizontally scaling websocket? I'll do an experiment to prove (or disprove) that.