J'ai décidé de construire ce qui est parfois appelé orthodontal,
ce concept d'un programme durable.
Tout le programme de membre est juste un database SQLI.
Tout le programme est un autre file.
Tout ce programme n'est pas dans ce database.
D'accord, le tout épisode est disponible pour nos membres Patreon.
Bonjour, bienvenue à la podcast de DevTools FM.
C'est un podcast sur les tools de développeurs et les gens qui les font.
Je suis Andrew et je suis ma co-host, Justin.
Bonjour tout le monde, notre guest aujourd'hui est Juan Capa.
Juan est le créateur de Membrane.io,
un plateforme de développement pour simplifier l'animation API
et l'interne de la tooling.
Je suis vraiment excité de parler de Membrane.
Mais avant de nous en parler, Juan,
qu'est-ce que vous voulez nous parler de vous?
Hey, les gars, oui.
Je suis Juan.
Je suis originaire de Venezuela.
Je suis un backbone en développement de jeu.
Je me suis donné un peu plus de 10 ans
de travailler en développement de jeu.
Je suis travaillé sur tout ce qui est de consoles, de mobile.
Je suis en train de faire des jeux de jeu, des jeux de web.
Et puis à un moment, je décidais de construire Membrane.
Et puis je suis allé dans San Francisco
de travailler sur ça 100%.
C'était un peu d'année plus tard.
Je construis quelque chose que je pensais que c'était ok
et puis je réalise que c'était juste pas bon.
Et on peut parler de ça un peu plus tard.
Et puis j'ai rencontré un tweet par Guillermo Rouch.
Il est le CEO de Versel.
Il cherchait quelqu'un pour travailler sur leur terminal, hyper.
Je me suis dit que je pouvais peut-être commencer par travailler avec Versel.
Je me suis répliqué sur le tweet et j'ai commencé à hacker hyper.
Et puis il a aimé et m'a acheté pour travailler sur Versel.
J'ai spenté deux années là-bas en tant que lead dans le team CDN.
Et puis à un moment, je voulais aller en fonction de Membrane.
Je suis allé sur Versel.
Je suis allé en fonction de mon travail prévu
pour un peu de développement de jeu.
Versel était très intense.
En ce moment, c'était une petite compagnie,
on était 20-something.
Et j'étais part de l'infra-team.
Donc j'ai payé mon défi.
C'était constant.
Je me suis dit que je pouvais aller en fonction de mon travail prévu
avec Zynga.
Et c'est un travail super chill.
Je vais travailler sur les choses que je savais,
les choses que j'ai construites.
Je suis allé en fonction de mon travail prévu.
Et puis, je pense que la dernière chose que j'ai faite
était de rejoindre Mighty.
Et aussi, sur Twitter.
Je l'aime, je trouve toujours des choses là.
J'ai posté quelque chose sur les hires,
ce qu'ils s'appellent,
les Builders in residence programme,
où vous pouvez travailler sur votre start-up,
mais aussi travailler 3 jours pour eux,
en aidant leur produit.
Donc j'ai accepté pour ce programme
et je travaille 3 jours en week-end,
sur Mighty, et puis, le reste de week-end,
je travaille sur les mémories de Buildings.
Et je ne sais pas si vous l'avez entendu,
mais ça a juste terminé quelques weeks auparavant.
Ils ont décidé que ça ne fonctionnait pas.
Donc, oui, je suis maintenant un membre de 100%.
J'espère que je peux aller au monde
et remborder des utilisateurs en week-end.
C'est super, c'est cool que vous avez commencé
à faire des développements de jeux
dans des idées traditionnelles,
des worlds sassiques.
Vous pouvez parler un peu de membre
et de producteur.
Vous avez des postes médiums.
En plus d'un jour, il y avait 4 développeurs,
des jeux de jeu,
il y avait des réunions d'un certain nombre.
Qu'est-ce que vous avez accompli à membre?
C'est un peu ce qui est un peu
où l'inspiration est venu.
Je pense que j'ai vécu avec l'idée de membre
et puis, en regardant le boulot,
c'est pourquoi j'ai l'intuition
que membre serait cool.
C'est parce que dans le développement de jeux,
vous avez un enjeu, un univers
et cet univers est complètement programmable.
Tout est programmable,
même les gens, les NPCs dans le jeu,
vous pouvez les faire,
vous pouvez contrôler le vent, les roues, les carres,
les portes, les speeds,
et tout ça.
J'ai l'intuition que les choses
sont plus programmables.
Tout est un objet dans le jeu
et vous pouvez contrôler
ou lire les valeurs que l'objecte représente.
J'ai voulu ça pour le monde réel.
Et bien sûr, c'est maintenant possible
parce que tout a un API
et le monde est plus connecté.
Même les choses physiques ont un API.
C'est là où l'idée est formée.
C'est un endroit
pour faire des programmes,
pour construire une automation personnelle.
C'est un enjeu JavaScript
qui est optimisé pour les programmes
personnels.
Ou plus généralement,
les applications de l'application.
C'est vraiment un truc très petit.
Nous avons des tools excellents
pour construire des choses scaleables.
Mais nous n'avons pas les meilleures
tools pour construire les choses
pour un utilisateur.
Je veux construire un programme
pour un utilisateur.
Qu'est-ce qui est le meilleur?
J'espère que le membre est ça.
Je peux l'élaborer
sur les features.
Mais...
basically,
je voulais
faire ça vraiment facile
pour quelqu'un pour automater
quelque chose.
Et pour faire ça,
je voulais le processus de la formation.
Vous n'avez pas besoin d'un nouveau plate-forme
et de la façon dont ça fonctionne.
Parce que c'est comme si vous avez besoin...
Si vous venez d'automater quelque chose
qui est relativement simple,
l'invité de automater
ça doit être petit enough
pour automater le produit.
Ainsi, vous avez plus de temps.
Oui.
Je pense que c'est tout.
Et...
Comment je fais ça?
Le premier est de construire
les tools que nous avons réutilisés.
Le tool qui est la plus utilisée
est le code visual studio.
Et la plus utilisée est
le JavaScript.
Je voulais le lever.
Tout le monde sait ça.
On va le construire en haut.
Pour que vous puissiez utiliser ce que vous savez.
Et aussi,
lever les ressources de la formation
qui sont déjà disponibles.
Et...
C'est l'une des choses.
La chose est construite
dans le code studio visual.
Vous installez cette extension.
Vous créez un bouton
pour créer un programme.
Et ça vous donne un JavaScript empty.
En fait, un JavaScript type,
c'est un peu mieux.
Vous avez un file type empty
qui ne fait rien.
Et ça ne peut pas faire rien.
Parce que ça n'a pas d'accès.
Et ça ne peut pas faire rien.
C'est l'autre feature
qui est le plus important
de ce concept.
Ceci est le principal
qui est la plus importante
que les programmes utilisent
pour manipuler le monde
et pour rééter les APIs
et pour contrôler les choses.
Donc...
Vous avez un programme
qui ne fait rien.
Et vous vous installez
dans votre graph.
Vous vous apprêtez à quoi quelles ingrédients
ou outils que vous voulez.
Vous vous vous apprêtez
et vous vous vous vous vous vous vous vous.
Et maintenant, ce programme a d'accès
à ce que vous puissiez faire.
Et ces choses peuvent être
très bas de niveau
comme un request
d'HTP
que ce programme veut performer.
Ou un objet
de l'API.
Par exemple,
je veux faire un programme
avec un issue GitHub.
Un issue specific
d'un réputé.
Je trouve un issue dans le graph
et je vais le faire
dans le programme.
Et ça a d'accès à ce sujet
et à seulement ce sujet.
Vous pouvez faire
une sorte de code que vous voulez.
Vous voulez observer le sujet
pour des nouvelles commentaires.
Vous pouvez évaluer
trois lines de code
dans Membrane.
Donc,
c'est
le
des features
de la course.
Il y a
beaucoup plus.
Le fait que
les programmes sont durables.
Donc,
quand vous vous récoltez en Membrane,
si vous voulez
récolter un état,
vous pouvez
faire un programme
pour faire un poll
dans
votre compagnie.
Vous voulez récolter
les réponses de ce programme.
Normalement, vous devez
récolter ça en quelque part.
Parce que votre programme est en train
et va mourir.
Vous devez mettre un file
ou vous devez mettre un database
ou quelque part.
Avec Membrane,
l'entire état de
le programme est persisté
constantement.
Il est constantement persisté et
efficacement persisté aussi.
Vous
vous mettez les résultats
de l'appel en avance.
C'est là.
Ce programme
va toujours avoir accès à ce programme.
Paul, même si quelqu'un
décide de répondre 3 mois de maintenant,
ce programme
va toujours
prendre
l'aise
de tout ce qu'il faut.
C'est l'un des choses
que je voulais parler.
C'est magique.
Si vous pensez
à un programme,
un projet d'automation,
ou quelque chose d'automation,
c'est une chose très importante.
Peut-être que vous pouvez atteindre le light s'il vous plaît,
ou savoir comment interfacer le light s'il vous plaît,
ou mettre un ORM
et tout ça.
Mais
juste de persister au programme
ou de faire un variable,
ça va toujours être magique.
Comment ça
fonctionne ?
Comment vous allez faire pour faire quelque chose comme ça ?
Oui.
Le premier
version de membre,
ou je ne sais pas si je le disais le premier,
mais l'une des versions
n'a pas
ça.
C'est la première chose que je le vois.
Oh, la plupart de ma code est en fait
en déclenchant le truc,
et en en prenant le truc,
selon le programme
il se trouve très compliqué.
Surtout si vous vous rendez
avec des gens.
Si je vous donne un message en texte,
et le programme est en train de
répondre,
je vais être en train de dormir.
Je vais répondre le prochain jour,
ou peut-être jamais.
Donc je dois le détruire.
Si il y a un temps,
il va être tué le programme,
et je dois
réhydrer le state.
Ça a pris beaucoup
de complexité incidentale
que nous avons parlé
de ça.
C'est juste...
C'est pas bon.
J'ai décidé de faire la version
et de faire un programme
qui est parfois appelé
orthogonal,
ce concept de
programme durable.
Et le moyen de le faire
c'est...
Vous avez mentionné l'esquilite,
ou l'esquilite, et ça
est
ce qui est
derrière
un programme de membre.
Donc tout programme de membre
est juste un database
de s'écouler.
Chaque programme est un autre file,
et tout le programme
n'est pas dans ce database.
Donc
chaque message que ça a
récise, il y a
un database, et puis
il y a un processus.
Il a de l'abord un database.
Et puis chaque message que ce programme
veut s'écouler au monde,
même si c'est un request de l'HDP,
il y a un database
et puis quelqu'un
qui regarde le database, il y a
un nouveau message
dans le box de ce programme.
Je vais le envoyer,
et puis la réponse
est récise.
C'est comme un sourcil
à la granularité
d'un processus.
Et
il y a
une table dans ce database
qui s'appelle
pages.
Et c'est le membre
pages
de
le processus JavaScript.
Je utilise QuickJS
pour le tourner de votre code.
J'aime QuickJS car
la membre de la footprint est très soud.
C'est un excellent
JavaScript.
Et
il y a
un concept
dans le kernel Linux
qui s'appelle
pages de la pêche du soft.
C'est un
bâtiment que chaque
choc de la membre
a, que vous pouvez le clarifier.
Et si quelqu'un le réglage,
le kernel Linux va le replier
et dire, hey,
cette pêche
a été élevé.
Je peux
faire un programme
et se séariser
les pages qui changent.
C'est très efficace
de cette façon.
Et je vais
élevé le bâtiment,
et le mettre
dans le database.
C'est vraiment
un bon concept.
Vous êtes
juste hydréant le contexte
de l'exécution de la JavaScript
et de
ce qui est cool.
C'est plus
efficace.
Je vais aussi utiliser WebAssembly,
car
la membre est facile
de le faire.
On a le modèle de membre
de la membre.
Je n'ai pas de
d'un array de
data
qui doit être séarisé.
Je commence
avec un programme blanc.
Je ne sais pas
que la version séarisée.
Et puis,
quand je mets le code,
le programme se démarre
et les messages et tout,
il change la membre.
Je ne savais pas
que les pages de WebAssembly
aient été séparées.
Je
savais plus de data
que ça.
Il y a plus de optimisations
que je peux faire.
C'est intéressant.
Parce que
vous êtes
en train de faire des applications
spécifiques.
Vous êtes en train de faire des cases
de single user
pour réduire
la complexité d'implementation
de l'ensemble.
Si
vous avez des
1000 users,
vous ne pourrez pas
se séariser
comme ça.
Mais,
en cas de pas
que de nombreux users,
vous n'avez pas de délicieux.
Et, en fait,
vous n'avez pas de délicieux.


pour utiliser SQLite.
C'est cool
parce que vous avez
réduit les services
que vous avez besoin de maintenir.
C'est cool.
C'est un point
d'amélioration.
J'ai listé
les goals de membre
et la performance
était
à la fin.
Juste faire ça
très bien
et faire ça très observable.
Vous pouvez voir
tout ce qui
a
été arrivé.
Si ce n'est pas dans les logs,
ce n'est pas possible.
C'est la seule façon
que ça peut se passer.
Si c'est écrit dans les logs,
c'est la première.
C'est pas mal
parce que les disques hard
sont très slow
mais
ça vous donne le meilleur
expérience de développeur possible
en termes de observabilité.
Je le n'ai pas dit
de perfection de observabilité
parce que
il n'y a rien à l'écrire.
Il y a
un autre fonctionner
parce que tout est dans les logs.
Vous pouvez aller en temps
et vous dire
que ce qui s'est passé
est de retourner
et de rerunir le code.
Vous pouvez le faire
au niveau de la granularité
où les choses sont en place.
Ce n'est pas
chaque ligne de code qui est élevé
mais chaque message.
Je peux aller en temps où le message est reçu
et puis faire le code
qui était disponible
en temps de réunir.
C'est
complètement
déterminant.
Je vais vous demander
cette question exacte.
Vous pouvez aller en temps
au niveau de la construction
et tout le temps
de la programmation.
C'est super cool.
Il y a
une complication
avec ça
où
je peux
en théorie
déterminer toutes les versions de la heap
qui n'ont jamais existé.
Mais je ne fais pas
ceci
pour le faire un peu plus vite.
C'est
quelque chose qu'on ne peut pas faire aujourd'hui
mais c'est quelque chose qui est possible.
Et la version,
je pense que la première version
que je vais avoir
de ce type de travel
va être avec
un snapshot qui est en train
d'avoir une heure
pour que vous puissiez
faire un point de réunition
mais vous pouvez aller en temps
et réunir de là-bas.
Ça vous donnera
quelque chose
qui est
assez close.
C'est assez cool.
Ça me rend compte
que les gens qui réplayent
sont en train de faire
des magies.
Mais je me suis dit
que c'est le même truc.
Ça me rend compte
que l'épisode que nous avons
récouru
avec le founder
de Unison Lang.
Une des principales principes
de la campagne de Unison Lang
est d'avoir un database
avec des magies de contenu.
C'est intéressant que vous
utilisez un database SQLite
pour faire un programme
mais en faisant des choses
de differentes choses.
Oh oui,
j'ai vu unison.
Ça me rend très intéressant.
C'est quelque chose
que je vais avoir de plus en plus.
C'est incroyable.
Il y a quelque chose qui est cool
et qui est complètement serialisé.
C'est le même type de infrastructure
mais vous voulez avoir
une latence plus basée.
Vous avez un exemple local
dans votre service de maison
ou votre laptop.
Vous pouvez juste bouger
un programme de service
pour le dernier
sans le faire.
Et maintenant vous avez une réaction
qui est juste là-bas.
C'est vraiment cool.
Vous avez un membre
qui va être un truc ?
Je pense que oui.
Maintenant
la code n'est pas open source
mais
je pense
que je veux faire un open source.
C'est probablement
la seule façon de faire ces jours.
Et aussi,
je suis sûr qu'il y a des utilisateurs
avec des concerns privés
et des trucs comme ça
que je ne veux pas.
Vous devez me donner
tout votre data.
Vous devez pouvoir
faire des choses à la maison
et des choses à la membre.
C'est un système fédéré
où pas tous les programmes
sont en train de faire les mêmes.
Vous pouvez les faire, si vous voulez.
Il y a beaucoup de travail
à faire sur ce sujet.
Des cryptographiques pour
faire surement que c'est secure.
Mais c'est
sur le roadmap.
C'est vraiment cool.
Il y a un peu d'autres graphes.
Vous avez des données
et vous pouvez mettre des données
dans votre programme
pour faire quelque chose.
Qu'est-ce que ce graphe ?
Comment ça va ?
Comment les données se réagissent ?
Si vous voulez ajouter un nouveau
API de GitHub,
vous pouvez mettre des données
dans le graphe.
Comment ça va ?
C'est une bonne question.
Vous,
comme utilisateur,
avez un graph.
Il commence à être élevé.
Quand vous créez un programme,
vous êtes
monté sur le graphe.
Donc,
votre graphe est la combination
de tous les programmes.
Et
certains programmes
sont les drivers
qui sont les programmes
qui parlent des APIs.
Ils prennent
l'API
dans votre graph.
Le programme de GitHub
ou le driver de GitHub
a un schéma.
Le graphe est type safe.
Le schéma
est le schéma qui est basé
sur le graphe de
l'API de GitHub.
Ce schéma est
un schéma qui est




derrière les scènes
qui sont les programmes de GitHub.
Donc,
c'est
comme un adaptateur
pour les APIs externes.
Mais, vous pouvez faire vos propres programmes
qui permettent de mettre des choses dans votre graphe.
Et
ce type de choses peut combiner
des notes de d'autres programmes
ou de
des sources externes.
C'est
tout uniforme,
dans le sens que tout est un note,
qui, vous pouvez penser,
est un objet.
Ou un scaler,
un numéro de la ligne
de la ligne de la ligne de la ligne de la ligne de la ligne.
Donc, vous pouvez
courir ce graphe avec GraphQL.

oui, c'est le
main-le-deau
de les réveiller
en membre.
Donc, c'est le seul moyen de vous mettre le stuff dans ce graphe
currently, le Chrome extension?
Non,
donc, maintenant, vous devez installer
un programme. Donc, pour exemple,
ce demo que vous avez vu
où je vais
sur le GitHub et clique sur le Chrome extension
et il me montre
toutes ces choses, comme il reconnaît
tout dans le GitHub
et il connecte
à
les choses.
Ça fonctionne
parce que dans mon compte membre
j'ai installé
le DriveGitHub.
Donc,
c'est comme, ok,
quand je clique sur le bouton,
ce que ça fait,
c'est que
on demande
que les programmes
qui se sont réveillés
reconnaissent tout sur ce page.
Ça ne sent pas le page,
ça
donne toutes les expressions
qui sont les reconnaissances.
Les choses qui reconnaissent le stuff
sur le page. Et ça les rend.
Et c'est comme, hey,
DriveGitHub,
regardez, j'ai trouvé
ce piece de texte
dans
ce site que vous vous reconnaissez.
Donc, dis-moi ce que c'est.
Et les DriveGitHub sont comme, oh,
ça ressemble à un repo.
Donc, ça envoie
une référence au note dans le grapho
pour ce repo, pour que vous puissiez explorer
ça et puis prendre ça et donner ça
à un programme et utiliser ça.
Ok, donc
c'est comme comment les credentials
travaillent. C'est comme, vous allez sur le membrane, vous vous setez
l'adapter, vous vous setez vos credentials
et puis vous avez, et puis la extension
de Chrome vous montre
ce qui se passe en currently sur le page.
Oui,
oui, bien,
c'est la version de Chrome.
Ce que j'ai voulu,
eventually, est
que je ne dois pas avoir installé
le DriveGitHub, parce que je ne vais pas
envoyer quelque chose à tout point.
Je suis juste, littéralement, la extension
se tourne localement,
pour 90% de l'heure,
d'exception de tout le monde.
Donc, ce que je peux faire
c'est dire, hey,
vous n'avez pas cette DriveGitHub
mais il y a un DriveGitHub
là-bas. Et
il définit ces
reconnaissances.
Et donc, je vais les envoyer,
c'est pas going
to send anything anywhere, just like
running it on the page
and
offer you the option to now install
that driver with a click from the Chrome
extensions. OK, this is available
right now.
So that way, you don't have to
like have installed
stuff before you want to use
membrane. You're like, OK, I want to
automate something with GitHub.
You don't have to previously
have thought that you're going to do
that at some point and have installed
the driver instead. You just like, oh,
I want to automate this thing on
Twitter. Let me click the button. Oh,
all these things are available for me to use
in my automation. Let me grab
some of those things. Oh, I need to install
the Twitter driver. OK,
click the button.
And that's it.
That's like the ideal.
So in that idealized world
is it also handling like
setting up API tokens and all of that
because that could be like the hardest part
of interacting with an API, especially like the
Twitter one. Yeah,
that's a really good question.
And that's something that
I
haven't completely figured out yet.
Currently, you
have to bring your own keys.
So as opposed to like things
like Zapierre,
or Zapierre,
where
they have their API keys
and you just authenticate via OAuth
too.
Currently,
the current version of Membrane,
you have to
go and get an API key
from the service
and then install it and then
do OAuth with your own
driver.
So it's a little more complicated
than it should be.
Some
APIs offer a personal access token
which is the ideal
way of interfacing with
stuff.
So for example, you know, GitHub has a personal API token
that you can generate and then you just
copy and paste that and that's it.
But some APIs
do require OAuth
which means you need
a client ID, a client secret
and then to do the whole flow.
But it's not that bad.
I have it for the Google
Dogs
driver and the Google Calendar driver
and
it requires you to go
and get an API key and all that.
But the driver itself implements
the OAuth.
So, you know,
once you've gotten those two values, you just
click and log in.
So it sounds like the drivers are definitely
like where most of the low level code
for interacting with a lot of APIs
and stuff is stored. So you can
expect those to be a little bit more complicated.
But when you're actually getting into your
sort of dedicated apps where you're
just doing your automation, those are like
pretty terse and like, you know, kind
of doing the only things that you need to do.
Yeah,
that's exactly right. Yeah,
drivers have to have a certain
patterns in the way they
expose data.
So, if you
want to write a driver, you do have
to read a little bit of how
to design
a driver correctly.
Because, you know, something that
the graph abstracts away is pagination,
for example. So,
pagination,
which is something like, to me, is
crazy that we still
have to, for each individual
API, you have to figure out how pagination
works.
They use like an offset or some of them
use some sort of like
opaque token.
And some of them
send the pagination in a header
or like it's just
all over the place.
With Membrane,
you have this object that's
one page.
And a page has a reference
to the next page. So, all you do
is like follow this linked list
and this reference encodes
the pagination logic
that's that specific API.
But, from the point of view
of view, the user
is just a link
from one
node graph to another node
graph.
And so on.
Yeah, that makes sense.
That's awesome. Yeah, pagination
is deceptive. Like, it can be hard.
Yeah, it can be.
Yeah,
that's definitely
something that shouldn't be.
It should be
simpler.
And, well,
I mean, there are some trade
tradeoffs between different
modes of pagination
where
some pagination system is like
hey, give me the page after
this element.
Which ensures that you're not going to be
seeing the same element
again.
And some pagination systems are like
hey, give me the elements
after this offset.
There's a tradeoff between the two systems.
But, in membrane
it's just a subtractive way.
It's just hey, from one node to the next
and to the next and to the next and so on.
So, you have a demo
that I thought was really cool
where you sort of show
how
you visualize timers
and the time they're taking.
So, membrane has
a crime-like functionality.
Can you talk
a little bit more about
that functionality and sort of the
visualizations that you built?
Yeah, the
SQLite database
I mentioned before
has a table called timers.
And that table
you can
from the code, you can
create timers in that table
basically.
And
you know, each
program, you know, that's just a row
in the database and then
the execution engine
looks at the database
of all programs and all the timers
and it just fires them
when they need to fire
writing something in the database
hey, you know, this happened
this timer just fired.
And
but then from the client side
you can
get those timers
that the program has set
and then look at their specs
and say, okay, this timer
is supposed to fire at this specific time in the future.
So, that's what
the client is showing you is this
bar of how long
it's how long
until we hit that point in the future
or if the timer is
like a
repetitive timer
like a crone job type of
thing, then it can show you
all of the times in the future
that it's going to execute it because
you know, it's like
it's predictable, I guess.
So, if
you're from visual studio code
you can just hover on each timer
that the program has set
and then see how long
it's going to take until it fires
and then you can also see what code is going to run
when that timer fires.
Like, you can compare this
to something that people use today
which is like set interval, set time out
or even crone jobs.
Like, the experience
is hidden.
If you use a crone job
it's like, ok, I trust
that that's going to run
and then if it runs
you know
it's going to run some script or something
with membrane you can
jump directly into the code
that's going to run
and you can see it visually, like oh, yeah
this bar is about to hit
zero, let me just, you know, keep an eye on this
because it's about to run.
Yeah.
And you can also run
the thing, run the action manually.
Like, if you're
set a crone job and then you're like
ok, I just changed something, let me
make sure that it actually works.
You can just like, click on the action
and then invoke
and that's going to run the code
for you to try it out, test it, whatever.
Cool.
What happens if it fails?
Like, so you have a crone schedule
and then like crone fails, like do you do anything special
in that case?
Not really.
I mean, other than showing you the error
I don't really do anything special.
I mean, showing you that you're probably
plenty sufficient.
That's something that always happens
is like you set up a crone somewhere
and it's like just off chugging
and then like, at some point in the future
it just starts breaking for inexplicable reasons
and then takes you forever to figure out
oh, this service, this thing,
this task isn't working anymore.
Right.
Yeah, the key to me
is observability.
Like, if you know everything
that is happening, then you can take action.
And action can be
as simple as
because, you know, everything is
referensible, even the code
that is going to run when the timer expires
I can, oh, okay, this time it failed.
Let me click on the action
that was going to run.
This action can have parameters,
like it's a whole like
function call, you can think of it.
Assemble, ready to be
invoked.
And so you can click on it
and maybe the parameters were wrong.
So you can just edit the parameters and then invoke.
And it's like, okay, I caught up
with the crone that
just failed by manually running it.
But then it took two clicks
and, you know, just one modification.
Or you can just like change the code
quickly and then
invoke it again.
You can do that as well.
That's pretty cool.
That's pretty cool.
So you said that like
the roots of membrane
kind of come from games.
And so I read
an article where you basically show that
in games you can like click
on an object and see all of its properties.
I assume in that, in those cases,
like they haven't really set
that up. That's just like how it works.
Like you just see into them.
Am I wrong with that?
Yeah.
Game engines
are extremely advanced
pieces of software.

the cool thing about game engines
is that they are
designed to be general enough
that you can build any game
with them. At least most of them
are, right?
So
they have all these
systems
to
read data and to model
your objects
and
you know trigger stuff
when something happens and event handling
and all of these
tools so that the, what's called
the gameplay programmer
who's the person like actually building the game logic
a
this like expressivity
to create
whatever designers want them to create
right? So it's all
like
very nicely done to give
developers a really good experience
so that
so that they can just build things
you know, as crazy as they want.
Yeah, so with membrane today
that's why there are those like adapters
c'est cause there's like, there's not this like structured
layer in
web development where like
if you just do some things it becomes available
like my dream
for something like membrane would be
if it could go that distance where it's like
I don't have to have an adapter
like my use case
a lot of the times
in my early career I would hack on an
internal API from some service that I use
would that possibly
be possible maybe
in the future of membrane cause like
going back to the twitter example
twitter's public API is quite limited
if you want to build a twitter clone
you're going to actually have to start looking at the network tab
and figuring out like
how their internal API works
so is something like that on the horizon?
Yes, yes, definitely
is there are two
I have two thoughts on that one is
the
the open API specs
it's something that
I could leverage in the future
to automatically generate
drivers at least
at least an initial version of drivers
but then there's also the private
APIs which
you are totally allowed to use them
you know
because it's not
membrane giving you access to those private
APIs is you
dealing with those APIs, right?

so there are these
there are ways to generate
like
the hard files in the browser
you can download and there are actually
people working on
interpreting those hard files
and
turning those into API specs
I think there's a startup call
there's this two startups
Akita is one of them
and
Optic
which
I've talked to those guys a few times
and they're interpreting the
traffic
to generate an API spec
and from that API spec you can generate the driver
Yeah, yeah, from this whole conversation
it feels like membrane's a lot like
wire shark but with like a lot more
structure put on top of it
where you can see what's happening
but you can actually use it too
that's my dream tool
my next question would be like
could we ever see membrane
on a mobile device?
how might that work?
Yeah
yeah, I thought about that as well
so one thing I didn't mention
is that
you know exploring the graph
is not the ideal
interface
or anything, right?
if I want to send an email
I would rather use
gmail.com
than going into the graph
and finding
the right node to invoke the correct
actions to send an email, right?
but
that is
not necessarily the end game
so
each node in the graph
basically you can build UIs
on top of the graph
that are
custom for you
or at least
someone created and you can just grab it
and use it for yourself
so what is a UI?
UI is just something that
behind the scenes is talking to an API
and
but
if you can build a UI
behind the scenes is talking to the membrane graph
that
can be
then you can swap them out
you can be like oh
there's this UI designer
who is awesome
and he created this whole set of UIs
for email and github
and all these things
and because they don't want to deal with specifics
I have APIs they just deal with the membrane graph
and build UIs on top of that
so if that's the case then you can
even run on your phone
and just access things there
and then you can always flip
this is what I imagine
you're interacting with your membrane
graph via this GUI
and then you can always click
a button and then it just flips
and then you see the API version
of what are you doing
so you can flip
back and forth
yeah, it's really interesting
there's so many
there's so many things
bouncing around my head
going back to the API conversations
about generating APIs
and
and hard files and everything
this reminds me a little bit of GraphQL
mesh from the guild
which is a tool to take any
have an open API spec
or sort of any of these things and turn them into
a GraphQL graph
which it sounds like is kind of the thing
that you'd be going for there
get it all meshed up into your graph
that is super awesome
I am
incredibly excited about the future
of membrane
it seems so fascinating
so yeah
thank you guys
well that's it for this week's episode
remember the full episode is only available
to our patreon members thanks for listening