Adobe Developer App Builder Deep Dive

Transcript

Okay, hi everyone. So thank you for staying up to this section. I guess that we are the second last one today and hope you have a great day so far with the Adobe Developers Conference. So welcome to our section on Project Firefly Technical Deep Dive. Alright, so just a bit of introduction about ourselves. My name is Duy Nguyen and today I’m going to present this talk together with my colleague, Jesse McFadyen. We are both part of the Adobe IO Extensibility team. Just a brief agenda of our talk today. We will first start with a deep dive into Project Firefly technical aspects. And then we will go through a use case for which we use Project Firefly to create a custom editor for content fragments in the EEM as a cloud service. And that’s directly linked to our demo on Project Firefly developer experience, building this application from scratch. Now let’s take a brief into the technical details. Alright just a couple of minutes before, some of you might have attended the Firefly overview section which gave a good introduction into Project Firefly. For those of you who were not there, it is a brief recap. So Project Firefly is a complete design application and runtime framework for building third-party cloud native applications that extend the functionality of Adobe products and run on Adobe infrastructure. To put it in perspective, this is the application architecture of Project Firefly. Essentially when you build a single page application, it splits into two parts where your front-end code and all the static files are pushed to a CDN and then the backend code for all the microservices and orchestration are deployed in form of actions onto Adobe IO runtime. And then those individual actions or microservices, you can then talk to Adobe APIs, third-party APIs and other cloud services that comes out of the box in Project Firefly. And those include the data storage which can be used to store application states in key value pair format. That could also be file storage for transporting larger files. And last but not least, custom events would enable pubsub systems allowing both emitting and receiving events. In the case of headless application, it’s just really the last layer of this layer at the bottom would allow the user to directly hit the microservices using the IO runtime endpoints. This snapshot of all the components in Project Firefly will go from right to left. So at the core is IO runtime, which is a serverless compute framework for running third-party custom code on Adobe’s infrastructure. On top of that, we provide a CLI and SDKs that bring a streamlined way for developers to interact with core Adobe services and automate processes. Project Firefly is built with a cloud native mindset. So we leverage various cloud services for files, data storage, managing application lifecycle and user access control. Also no software pro without being developer friendly. So Project Firefly supports developer tooling such as the UX modeling, IDE plugins and other tools for debugging, testing and deploying custom applications. So at the top left of this diagram, you can see the spectrum UI that is based on React framework and it brings the Adobe look and feel to your applications. The last hexagon at the bottom left of this is custom events that enable applications to publish and consume custom events with the support of webhooks and channeling API. This is more detailed into Adobe IO CLI, which you can install with NPM. When you download the CLI, there are a number of out of the box blockings that are embedded into the CLI. So you have things that control the configuration, authentication, system information. Every developer console and certificate management. Together with them are the Firefly blockings, which work with application and IOR runtime services. Because our CLI is built on top of the Oculus framework, it allows any developer to easily come in and view additional blockings. Among the blockings on the right hand side, a lot are developed by the community as well as by our product team within Adobe. For instance, the AI and repo blockings that allow you to upload one or multiple files into your instances. And then the cloud manager blocking that allow interacting with the AI manager using the comment lines. In addition, project Firefly also comes together with a bunch of SDKs. Also can be installed with NPM. Some of these are details and used in CLI blockings on the SDKs and in the code templates. Anyway, they are just node modules, so anyone can just take and use them. The core functionalities deal with the configuration, error handling, logging, token vending machine which takes care of secret rotation for your app, and also the core networking library. Beside that, the pieces in the middle are the Adobe ION and Firefly functionalities that communicate with the state and the file storage, Adobe IMS, ION events, runtime, developer console as well as app exchange. Other than that, there are also Experience Cloud SDKs. And those grab the Experience Cloud API from the other Adobe services. For example, the Adobe Asset Compute library that would be interested for some content centric applications. So outside of the CLI and the SDK, we also support a debugger called WISDBUG, which is open source and can be used in any Firefly application. It’s part of the Apache OpenWIS community. It is supported out of the box if you create a new application with the AI or CLI so that you don’t need to do anything extra. There’s also GitHub Actions that you can use to create your own CI CD pipeline for building and deploying your app on top of GitHub. And VS Code extensions for working with the CLI. So we welcome you to try all of these things out. All right, so now let’s look at a use case that we use Project Firefly to extend existing capabilities of content fragments editor in AEM. We have a simple content fragment stored in AEM assets, as you can see on the screen, that is written in markdown format. AEM provides an editor out of the box to edit the content of this fragment. It’s a standard text editor. You can see, well, it’s just a standard one. But in our use case, we have all of our content in markdown. We love to have an editor that can show the preview of the content so that it’s easier to author. For this, if we view this use case using Project Firefly, we would need an SBA written in React Spectrum deployed into Adobe Experience Cloud Shell and having its backend connected to AEM via the asset HTTP API to write and to get content fragments. All right, you may wonder why using Firefly is a good fit for this application. First of all, everything is written in the JavaScript language. The backend actions are in Node.js, so it’s really an open entrance for many frontend developers. In addition, you don’t need deep knowledge of AEM to view this application. We just leveraged the AEM asset API to develop this, so it really decouples the extension from the core AEM components. And another big advantage is thanks to serverless computing as well as an ecosystem of developer tools, it’s just a fraction of time to have the app up and running without the hurdle of configuring machines, server configuration, networking, and so on. And with that, let me hand over to Jesse to walk you through the developer experience. Jesse, up. Thank you, Dewey. There was just a question about what plugins and commands are available for the CLI. So here I have the CLI installed, and if I just run AIO, it’ll actually list all of them. And also I can dig into each of them if I want to. I can go AIO app, and it’ll show me all of the commands available for that plugin. So I’m going to back out a little bit so we can actually look at your starting point typically for a Firefly application. So the place that you’re going to start is you’re going to go to the console.adobe.io, and you’re going to create a project from a template. And here you’re going to choose Firefly and give your project a nice name like markdown editor in this case, because that’s what we want to build. And I’ll put that here for title as well. So what this is going to do for me is it’s going to set up my runtime namespaces. It’s going to register any services that I want to add to this project. And I can choose to add a different API if I want to connect to something. For this demo, I’m just going to go straight to a generic action. So I’m not going to do anything else here. I just have a project set up. And now I’m going to switch over to terminal, and I’m going to make a new directory. And I’m just going to AIO app init. Now, behind the scenes, what the CLI is going to do is it’s going to actually reach out to console and ask me what org I want to create my app in. And I’m going to choose dev, because I’m already in dev. And it’s going to get a list of projects. And the most recently created one was markdown editor. So I can just select that. And I choose which workspace I want to work on. Now it’s actually going to grab all of the credentials and everything and ask me what type of project I want to create. So I have some options here of actions, which are runtime actions, which are code that I write, events, I can register to receive and send events, web assets, and then some continuous integration features using GitHub actions. So I’m just going to select actions and web assets for this. And it’s going to ask me what I want to call my action. I’m just going to go with the default of generic. And I can choose what sort of front-end template I want. So I’m going to stick with React Spectrum because it’s nice-looking and it sets you up with a lot of things out of the box. Whereas I could also choose the pure HTML JavaScript if I wanted to do my own thing. But I’ll just go with React and generic. So now we’re doing a typical NPM install of a whole bunch of stuff. So I’m going to switch to a new tab so we can have a look at what’s going on in code. Okay, here’s my project. It’s still actually being installed behind the scenes, but I can show you the bulk of it. So what we’ve got is your typical package JSON. This defines any NPM dependencies that you have. We have a manifest file which defines what actions I have. And you can see I’ve got one action called generic. And then it has the path to that action, which is also in this code base. And then we have an important thing here, which is whether I want to make sure that this is an authenticated call. So what this means is that this action will actually be deployed with another action that’s called before it in sequence to make sure that the user token is valid before actually passing execution to my action. And in here, we have our generic action code. So I have a very basic setup, which actually does checks for required parameters. And as a sample, all it does is it fetches this API endpoint and returns it as a result. So you can see we’re done here. So I can just quickly go… Choose to app run. While that’s starting up, we can also look through the rest of the project. So actions is pretty basic JavaScript node JS. So your response gets delivered back to the caller. And in this web source folder here, we have a pretty typical front-end React with the spectrum UI elements mixed in. And this is designed specifically to run inside experience.adobe.com. So you can see I’m given two URLs here. So I have a local host URL, which I can open. And here is my application running in local host. It’s a very basic application, but it does have this page which actually populates based on my actions that I’ve added to my application. And if I invoke this, it’s actually going to fail because I’m running directly from local host and I’m not authenticated anywhere. So if I go back and go to the other URL, we have this special URL for dev mode, which is still going to load from local host, but we’re going to go through experience.adobe.com. And now in this case, you can see the org that I’m in, you can see that I’m authenticated. And if I go to app actions now, I can still run the same thing. And this time I get a nice long result. Now, this is all still live. So if I switch back over to my code here, and I go to this, and let’s say I want to change something here. That’s hard to see. So I just commented out some code. Behind the scenes, it’s actually redeploying that. And if I switch back here and I re-invoke, I actually left an error in there on purpose, of course. And you can see in my debug output here, it’s telling me error content is not defined. So switching back quickly, I can see, oh, I specified this variable, which is not actually defined. So I can go like… For example, I can throw this in and behind the scenes, it will redeploy. And let’s see if it’s there yet. And there it is. So we have live debugging for our actions and hot reloading of action code. And then as far as the front end is concerned, I mean, you all expect that if you’re running a React app and you do this, you expect the page to refresh and it to update the UI. So that’s all there as well. So all the things that you expect as a developer developing front end are there. So switching to our actual… The point that we were trying to demo is that we were going to make a markdown editor. Fortunately, the work has already been done. And a version of this will be published and we’ll share a link after. So you can get the code and look at it yourself. But this is the fragment editor. And it’s really based on the fact that there’s this NPM module, which actually does markdown editing and it provides a nice preview. So that has been leveraged into this basic Firefly application. And I can… Go right to the repo. Now, when I downloaded the repo, it’s not actually tied to any org or any project. So I have the opportunity now to just go AIO app use, which will present me with almost the same dialogue I had before where I can choose, yes, I want it to be in the IO dev org, I want to markdown editor project and I want the production workspace. And then I just do the same thing again and it will retrieve all of that for me. So now if I open this in code… I’m hiding my secret a little bit here. So I have a… Again, I have a basic Firefly application here. I’m going to actually make the output a little bit more verbose since this is a deep dive. So I will save that and then I can jump over here and I can go AIO app run. Now we’re getting much more colorful output, as you can see. And in a moment, we will have an application… I need to write tests for this. So basic operations here. Thumbnail action, which just returns an image buffer as a string, update, create read. These are all simply leveraging the asset HTTP API. And if I switch back, we should be almost there. Okay. And here we have our URL. I am logged in again. For comparison, we can actually click on this link through to our instance, and we can see experience fragments. Oh, sorry. It’s assets, isn’t it? Assets, files. So the markdown file that I want to edit is in this test folder. It’s right here. So there’s the typical markdown editor that we’re trying to do better than. And here we have, we’ve loaded this asset browser. So this is calling the API. And I have a test folder, which I can navigate into. And I have a markdown note, the same. And now using that component from NPM, I have a Firefly application, which has, on the left side, it has the raw markdown, and I can actually see a preview on the right-hand side. And I can do… What kind of tricks? I can do HR. I can do a link if I don’t know the syntax offhand. I can see I’ve got a link. So this is my website. I can see I’ve got a link. So this is my markdown editor. And I see we are at time. So I will stop there and allow for questions if there are any. So this is just to recap what we covered in this section. If you want to sign up for Project Firefly developer preview, then just follow this link. I think that the slide will be shared or the video will be shared with you after the event. So you can see it or you can copy it now. And then please visit our documentation website. And tomorrow, I think there will be another section for AEM Asset Compute Service with leverage Project Firefly for processing AEM assets. And lastly, please be welcome to our monthly webinar on February 18th. And I think with this, thank you for your attendance. We hope that this provides you kind of an overlook of Project Firefly technical details. And we look forward to welcoming you in our developer preview program. Thank you. Thank you.