Expliquer comment les nouvelles technologies, telles que les LLM et ChatGPT, peuvent révolutionner les interfaces de programmation d'applications (API) à l'avenir. Fournir un exemple de la manière dont ces API pourraient fonctionner.
Explain how new technologies, like LLMs and ChatGPT, may revolutionize Application Programming Interfaces (APIs) in the future. Provide an example of how these APIs might work.
As a kid, I loved watching the Jetsons. As I grew older and ended up writing software and creating & implementing architectures for systems, I thought I would never see the day when a Jetsons-like kitchen would be feasible.
GPT (ChatGPT, etc.) has changed my mind.

Contractual Obligations
As an architect, you kind of need to think like a lawyer. You define contracts (APIs) between systems or components. You monitor those APIs for abuse or misuse.

I would use Swagger editor to define those contracts, and I would write the APIs to match interactions implied in mock-ups. I would vet the design with the team, I would walk through scenarios to see if the API would fit the use case and would not introduce performance bottlenecks, and I would simulate and automate as much as I could along the journey.

I was very careful to get it right the first time. It was never perfect the first time, of course. So, I also had to consider how the API could evolve while minimizing costs/impact to the rest of the system. The API, once deployed, would become something I would guard, like an honest politician guards the #usconstitution. The team had to be careful with any change that impacted the API.

API Mesh... More like API mess!
APIs rely on APIs which rely on more APIs and libraries. Once a system gets large enough, that complexity becomes a bottleneck. Small changes can have a huge ripple effect. Some approaches (like federated #GraphQL) help manage this complexity nicely. But it still involves an API under which there can exist a lot of fragility. #Agile or not, developing a complicated web of APIs is complex, requires specialized skills, and is full of unforeseen challenges.

The Kitchen Conversation, ChatGPT-style
The Jetsons' kitchen involves a number of systems, each composed of various parts, sensors, hardware, inputs and outputs. Considering the complexity of interactions between independent systems in a kitchen, the fact that the Jetsons' kitchen components would come from various vendors or manufacturers, traditional API design would not be able to fulfill the vision. Not practical, at all.

Now, let's think about APIs and the Jetsons' kitchen, #chatgpt -style.

Let's keep it simple: pizza. You (or your robot) make a pizza from scratch.

The oven asks the refrigerator: "I see we have a pizza. Can you tell me if this is low-moisture mozzarella?"

Refrigerator: "That's not even mozzarella. This pizza must have Muenster cheese as that is all I had in me. And the human removed some of the contents 30 minutes ago, so the probability of Muenster cheese on that pizza is quite high."

A sensor from the kitchen who has eyes across the room chimes in at this point. Sensor: "Beware that the crust of this pizza is made of cauliflower. I agree with the video sensor's assessment regarding the type of cheese. No new cheese entered the kitchen recently."

Oven: "Anything else I should know?"

Sensor: "The temperature of the dough is 47F. This is cooler than the expert chef consensus of using room-temperature dough."

Oven: "Great. I know what to do. Since the dough is cool, I will start cooking with a temperature a little lower than the recipe specifies. Then I will increase the temp of bottom element so as to provide a nice crisp crust. I will keep a close eye on moisture and may use convection to mitigate any undesirable levels of moisture."

Where is the API that contractually binds the independent systems? APIs are not gone. For instance, the brain of the Oven will have myriad APIs (e.g. for interacting with temperature controllers and sensors, etc.). The key here is that the interface between systems is no longer a fixed, rigid API. No method signatures, no paths, no payload specifications. Instead, a conversation relating to senses and capabilities.

What "brain"?
Kence Anderson's book Designing Autonomous AI describes nicely how a complex system can be decomposed into a number of independent "brains." Each brain, in his book, can be independently developed and refined, with human guidance married with #datascience, #machinelearning and #dataengineering.

What's Cookin'?
I am excited for what the future holds. How architects rethink complex system design with regards to APIs is, in my opinion, something that is inevitable. And, as an amateur pizza maker, my taste buds are watering for the day I get some GPT help to make an even better #detroitpizza.
Enfant, j'adorais regarder les Jetsons. En grandissant, j'ai fini par écrire des logiciels et par créer et mettre en œuvre des architectures de systèmes, et j'ai pensé que je ne verrais jamais le jour où une cuisine comme celle des Jetsons serait réalisable.
GPT (ChatGPT, etc.) m'a fait changer d'avis.

Obligations contractuelles
En tant qu'architecte, il faut penser comme un avocat. Il faut définir des contrats (API) entre les systèmes ou les composants. Tu surveilles ces API pour éviter tout abus ou mauvaise utilisation.

J'utilisais l'éditeur Swagger pour définir ces contrats et j'écrivais les API pour qu'elles correspondent aux interactions implicites dans les maquettes. Je vérifiais la conception avec l'équipe, je parcourais les scénarios pour voir si l'API correspondait au cas d'utilisation et n'introduisait pas de goulots d'étranglement au niveau des performances, et je simulais et automatisais autant que je le pouvais tout au long du parcours.

Je faisais très attention à ce que tout se passe bien du premier coup. Ce n'était jamais parfait du premier coup, bien sûr. Je devais donc également réfléchir à la manière dont l'API pouvait évoluer tout en minimisant les coûts et l'impact sur le reste du système. L'API, une fois déployée, deviendrait quelque chose que je garderais, comme un politicien honnête garde la #usconstitution. L'équipe devait faire attention à tout changement ayant un impact sur l'API.

API Mesh... Plutôt le désordre de l'API !
Les API s'appuient sur des API qui s'appuient sur d'autres API et bibliothèques. Lorsqu'un système devient suffisamment important, cette complexité devient un goulot d'étranglement. De petits changements peuvent avoir un effet d'entraînement considérable. Certaines approches (comme le #GraphQL fédéré) aident à gérer cette complexité de manière agréable. Mais cela implique toujours une API sous laquelle il peut y avoir beaucoup de fragilité. #Agile ou pas, le développement d'un réseau complexe d'API est complexe, nécessite des compétences spécialisées et est plein de défis imprévus.

La conversation sur la cuisine, à la manière de ChatGPT
La cuisine des Jetsons implique un certain nombre de systèmes, chacun composé de différentes parties, de capteurs, de matériel, d'entrées et de sorties. Compte tenu de la complexité des interactions entre les systèmes indépendants d'une cuisine et du fait que les composants de la cuisine des Jetsons proviendraient de différents vendeurs ou fabricants, la conception traditionnelle d'API ne serait pas en mesure de concrétiser la vision. Ce n'est pas du tout pratique.

Maintenant, réfléchissons aux API et à la cuisine des Jetsons, à la manière de #chatgpt.

Restons simples : la pizza. Vous (ou votre robot) préparez une pizza à partir de rien.

Le four demande au réfrigérateur : "Je vois que nous avons une pizza. Peux-tu me dire si c'est de la mozzarella à faible teneur en eau ?"

Le réfrigérateur : "Ce n'est même pas de la mozzarella. Cette pizza doit contenir du fromage Muenster, car c'est tout ce que j'avais en moi. Et l'homme a retiré une partie du contenu il y a 30 minutes, donc la probabilité qu'il y ait du fromage de Münster sur cette pizza est assez élevée".

Un capteur de la cuisine, qui a les yeux rivés sur la pièce, intervient à ce moment-là. Capteur : "Attention, la croûte de cette pizza est faite de chou-fleur. Je suis d'accord avec l'évaluation du capteur vidéo concernant le type de fromage. Aucun nouveau fromage n'est entré dans la cuisine récemment."

Four : "Autre chose que je devrais savoir ?"

Le capteur : "La température de la pâte est de 47°F. C'est plus froid que le consensus des chefs experts qui préconisent d'utiliser une pâte à température ambiante."

Four : "Super. Je sais ce qu'il faut faire. Puisque la pâte est froide, je vais commencer la cuisson avec une température un peu plus basse que celle indiquée dans la recette. J'augmenterai ensuite la température de l'élément inférieur afin d'obtenir une belle croûte croustillante. Je surveillerai de près l'humidité et j'utiliserai peut-être la convection pour atténuer tout niveau d'humidité indésirable."

Où est l'API qui lie contractuellement les systèmes indépendants ? Les API n'ont pas disparu. Par exemple, le cerveau du four disposera d'une myriade d'API (par exemple pour interagir avec les contrôleurs de température et les capteurs, etc.) L'essentiel est que l'interface entre les systèmes ne soit plus une API fixe et rigide. Il n'y a pas de signatures de méthodes, pas de chemins, pas de spécifications de charge utile. Il s'agit plutôt d'une conversation portant sur les sens et les capacités.

Quel "cerveau" ?
Le livre de Kence Anderson, Designing Autonomous AI, décrit joliment comment un système complexe peut être décomposé en un certain nombre de "cerveaux" indépendants. Dans son livre, chaque cerveau peut être développé et affiné de manière indépendante, avec des conseils humains associés à la #datascience, à l'#apprentissage machine et à l'#ingénierie des données.

Qu'est-ce qui se prépare ?
Je suis impatient de voir ce que l'avenir nous réserve. La façon dont les architectes repensent la conception de systèmes complexes en ce qui concerne les API est, à mon avis, quelque chose d'inévitable. Et, en tant que pizzaïolo amateur, mes papilles gustatives s'impatientent du jour où je recevrai l'aide de GPT pour préparer une #pizza de Détroit encore meilleure.
creative_writing
fr