henrieri

What I've been trying out recently is just function calls with arguments from frontend to backend.

It's only for side projects, but I personally prefer this type of approach over both REST and GraphQL.

You just have to think of it as another function.

In addition I define contract using TypeScript code something like this:

defineOperation('getPosts', { input: { filters: dataTypes.array(...) }, output: dataTypes.array(dataTypes.object({ id: dataTypes.uuid(), title: dataTypes.string()}) })

And this generates typed backend function handler and a frontend client function. Backend is TypeScript also, but it could generate for any language in theory.

I also generate database entities like that, and auto create migrations, etc. You could in theory add documentation into that defineOperation as well.

Very simple, and very smooth in my view. Also debuggable since it's text based (using POST method) with json { "operationName": "getPosts", { "filters": ... }}

In frontend I will have a generated, typed function I can use client.getPosts

and in the backend I just have to define export const getPosts: GetPosts = (requestManager) => ... where GetPosts type is generated.

It's because I think REST methods don't make much sense and the endpoints are arbitrary, in the end it's just easier to reason of everything as a function.

I also don't particularly like how GraphQL forces you into this certain mindset, that feels like in many cases it holds you back rather than makes you productive.

The point is that a person who otherwise works and provides value, but does cannabis is better for the society as a working person rather than someone in prison where people will pay with taxes for his living. If you skip on taxes you are living off of society so this should be illegal ofcourse.

The case is about who would be getting the blame. If manufacturer's mechanics mess up it would be definetly manufacturer's fault.

If both sides were to use Duplex, it would already know to just send 1010 instead of verbal communications.

Also if it was unknown whether the opposing person was a bot, a bot could firstly send a common test according to some protocol to ask if the other one was bot by some kind of sound representing that. In which case both would start sending machine readable information to each-other.

Coming from a long line of miner families from my father's side (my hundreds of times great great parents used to be dwarven miners some time before the defeat of the Sauron) I must say the concept of Bitcoin and gold mining are not that different. It is just the tools which have changed.

Human composition of chemicals has evolved over a long period of evolution. Choices stem from this composition. The composition however is not perfect. It has evolved by random mutations with best mutations surviving the environment. Composition is made to learn which decisions and choices come to a good outcome however it is not perfect (falling pray to drugs) or it does not always adaot to fast evolving environment (being addicted to social media).

But the decision and choice itself comes from chemicals of course. It is like asking which was first, the bits in the computer or the calculation it produced.

A combination of username, steamID and display name completely understandable in my opinion. User shouldn't be forced to login using a randomly generated ID, but something he can remember and has the option of being private by being able to use the display name.

UrlID can be beneficial for the user so the user can choose a easily spellable identifier for the URL in case he needs to share the link often using voice.

Seems like an optimal system except that the UrlID probably is only a use case not that often. But it still won't really hurt anyone. If it wasn't the URL ID it would be steamID, which does nothing to help to remember the URLs. So why is it poorly thought out if it gives benefits to some usecases without making anyone else worse off?