Thank you so much Andy and welcome everybody. So we are coming to start and we're going to start. Okay, this is my town hall in Manresa. So I just want to welcome everybody to my city.

And it's a really nice city with a good code these days and it's really great to be able to be in this conference to all the organizers, their board and everybody involved on being able to go to this conference in these situations. I really want to say thanks to everybody.

And this talk, okay, it's the Pilatina talk. We are going to go across all the changes that we did this year. It's not kind of one of the best years in Pilatina life because we've been busy with other situations. And we have a lot of things to say, and also the roadmap.

And mostly we are going to focus on use cases. So because one of the feedbacks I feel receiving that I think that are very interesting is people doesn't understand what exactly is Pilatina. What is it for, no, mostly? I even heard that because it's based on WordPress,

it's an SQL engine that you can use tables and columns and it's not like that. So we'll go through all these situations. So let me share my presentation.

So first, who we are, I'm Ramon Navarro, co-founder and CTO of Flabs and Iskra,

long foundation member and video team and framework team member. And I'm invited also. Hello, I'm Jové Güell, I'm a Pilatina video team member and I'm also Kunti Mudor, I'm someone of the team member.

Cool, thank you, you're welcome. So first we're going to start with what's Pilatina. This is going to be a pretty basic kind of headlines about what is it that we're using. So first, long is a long REST API compliant.

It means that where most of the things that you can do with long REST API, you can do with Pilatina. So most of the projects that you can build on top of that will be able to be used with Pilatina as an API. Second, it's a tree traversal, hierarchical security like Plone, Zoo, architecture.

So you store objects in a tree and you set security in a tree and it's inherited and de-inherited, that's easy. That's the same as we are used to know, it's the same Plone, Zoo, basic lines that we have. So what's not? So we have reduced all the layers from Zoo,

CMF, Plone in just one package. One package that has a schema, has the, you know, to configure the adapters, subscribers, all the rest of the additional database, the transaction, how we are serializing the database, all in one package.

So it's easy to follow up and to understand without more than just one layer. There is no server-side rendering. It means that we are not rendering templates. Well, we have to enjoin with Ginger to render some templates if you want, but our focus is to be an API. So we are a really fast API.

It's YAML-based global configuration, which means that we are not storing things on a local registry of components on a tree, on the container. We have the registry of configuration, the same as Plone, but we don't have templates stored on database.

We have content that is stored on the database. Everything is propagated through a global configuration. So all the containers in the same process has the same configuration. It's, we are losing some functionality from Plone, the option to customize each of the containers.

At the same time, we are winning a way of being much productive in order to be deterministic about what's the configuration of that environment. Well, it's our underlying layer. It's an SQL and cloud services that we can store files on a file system.

We can store files on S3. We can store files on Google Cloud Storage. We can have both of those as a database, as a co-croach, as a database. And so all the tools that already exist around these underlying layers help us to keep the backup, the replication, scaling the application,

wherever you need it. Oh yeah, and one of the most important things is that we are saying to ourselves, don't reinvent the wheel. There is a lot of things that are ready. For example, we implemented workflows. And we're saying, we don't need to reinvent the wheel. We just take the basic concepts from workflows in Plone and just we implement them with our interfaces.

For the web server, right now we are using unicorn and we thought, okay, we can change our request object to use the started one because we don't need to maintain our own request object. So we decided to, that on building a seven, I'm going to talk more about that later.

It's going to be a start with this. So basically, this is cool. It's our main focus, trying to do less things, to do more things and to be more productive in order to develop our APS.

So 2020, what we did this year, we released a Minutina 6, as Eric still already said on the keynote. It was a great effort from Jordan Massif, Jordan Poulet, Nathan, a lot of other contributors to push for an ASCII interface.

So we can plug to unicorn and nip a cord easily. So we don't need to keep the HDP dependency that we were keeping in order to provide the HTTP serving. We added workflows, a really basic implementation, but just enough to do most of the use cases that we are facing. We have ginted emblading in case that somebody wants to render.

There is somebody who wants to implement also with Chameleon, but we will see if it's used implementation soon. We have a full open API validation system where we can push all the information from the API into Swabber. We have a flow to provide user registration,

resetting the password with the mail validation, integrated bookable arrays, a really nice feature called GMI that Jordan is going to explain to you later. We did some performance improvements and a lot of book fixing in order to provide more stability and more reliability on the software.

There is also, you didn't imagine, not only the Python package, it's also an ecosystem of different frameworks or softwares, softwares branch is one of them. It's built by Martin, by Erbihaup, or by Erbihaup, and it's an Angular toolkit in order

to develop applications. It's not a UI that you can use it by itself, but it provides most of the new things, you know, that you build your own applications on top of Kubernetes. And the good thing is that it's also compatible with Poom, so you can do applications that work with both environments. It has ingestion schema forms generated automatically,

pastanaga UI widgets, traversal render with Angular, and all the crude supporting for editing and getting all the options. There is also an effort to use Voto onto Vigotina. You can ping Victor later to ask, which is the status.

He said that it's nearly 80% of the functionality working. Of course, you cannot create content types for the web with Vigotina because we want to enforce that a configuration is done through the YAML configuration file. We added some add-ons. For example, now we support a lab, whoo!

So, because we needed to support some old clone sites that we were, like on the line, we needed to develop a driver for that. It's, it's, it's on. We have also NATs to have a streaming support, NumPy to support fields with NumPy values,

and Postgres PgFields to store a field of an object into a table. Okay, now, in order to explain about what's Vigotina React and Vigotina GMA, Gerald.

Okay, Vigotina React is the project I started as to, because when I started a job, I found the job management thing, something pretty cool. And I say, okay, we need something like this for Vigotina, and I start people doing something.

And then I feel like perhaps it should be more a toolkit that I can extend, and we can extend, and we can maintain, and that's how it work. Right now, it's a natural, and it's cheaper than Vigotina,

but also, it's a library that you can plug on your own React project. And there are some decisions around to be able to use it like this, like there is no routing, because you can plug on whatever router you use on React, there is, but, and also, there are some job ideas in it.

There is a traversal, there is a registry to resist abuse, to write components, to be able to customize everything on the context. And also, it's working around the context. Let's see how they move.

Okay, let's log in. Over here, we are looking at the DB, and then we can create containers to use more or less alongside.

It's in a container, we have the basic request tool to manage tabs, you can customize the tabs, you can have ones, you can have managed permissions, materials, install norms,

but now we can install a new folder that runs provided by Vigotina, as you can see by our cards. And we can check on the side that we have a user, a user folder where we can start creating users. Let's connect one.

For example, this model, it's something you want to write for every content that you have. It's a registry, you can just register a form, and in this form, you will be able to go.

Also, you can add materials, like the job, around the context, and there is enforcement around the context. Only the types you have, you can get it in that context. Every content type, it has its own properties,

and you can add behaviors in Amazon. For example, this content type doesn't have any external behavior, we are just adding a new attachment, and then we can just define the product.

It's still a bit simple, but we are using all of the CMS. We are expanding bit by bit, so that we can associate some of the components of the product we are using. That's the reason, perhaps it's still a smile, and we're just putting it out.

For example, here we are adding permissions to the tree, like in the one plant, it's a bit different, and it's not showing in the models with the permissions, but we are just making this item a public access environment.

You can even have a hit from the window. It is also shared in plants, using the catalog. You can also, as a catalog, go to the plant, so it's like having them throw in portions, or also plastic, you can choose.

And there is a bunch of tools for the people you can use. For example, we can make a new folder, we can move it to a touching folder,

and you can delay, you can move everything. Later, I will show you more of how we have extended it and we will do it as a folder, so I'll give you more of that. Thank you so much for having me. And yeah, as I said, the T-NEX is not only a CMS,

it's a framework, it's more of a community of people, also inside the Bloom community, that we are really important in this large community. And we decided to organize it with ourself,

kind of defining it with, which is the communication channel and how we're going to organize, decide where we are going, and we'll go back to the future that we're going to implement and who's going to be able to process. So we have our GitHub channel, from the slides at the end of the slide, and there is also, once a month,

there is a framework team meeting, that is Marjorie, Nathan, me, Jodie, and Jodie, Jodie, Jodie, Jodie, and Steve. And then there is also co-owners on the GitHub repo, so any pull requests from any of us needs to be validated by somebody from one of these three people,

Jodie, me, Marjorie. So we decided to organize ourself to be a proper team inside of Bloom. So this is a big, the state of what we've been doing this year, as you see, there's not a lot, but we are so happy about it because we've been able to use it on projects

and production with really great vessels, and that's what we are going to show you now, which are the use cases that we've been doing that are closer to the Bloom kind of environment and a less scale than maybe the ones that we've been showing at the moment.

So for example, the first one, it's one that I am quite happy with, it's a cultural project, you know? There is a music festival, what I'm happy to attend this professionally, this is just a career for other professionals to come to see shows and choose which of them are hired

or the ones that are contracted the next year. So they have, we've been doing this project for a long time, and we have a lot of arts alongside with all these flows with the artists, where we go send the proposals, we approve goals, and all the process to buy tickets

to comment about the different shows, et cetera, et cetera. But this year was a difficult one because the pandemic didn't allow them to do most of the things physically and on the physical test. So they decided to be more digital and they needed to move more digital.

We needed to build something to provide a platform for professionals to be able to follow up and to be more integrated on this festival besides they were not being able to come to see the show by itself. So they also wanted that between the professional

who was an option to chat, like a group chat or a one-to-one chat, where people were being able to reconnect and ask for more information about different shows, et cetera, et cetera. And they have a purpose, right? So what we decided to do is we decided that it would be nice for building the chats

and the same thing, it's really powerful. We decided to have a share and see what they're doing across all of the Chrome site and the Athena. So we can request from the user, where is the Chrome site and which of the Athena one. Then we implemented a synchronous push notification service

in the Athena to be able to push information into the browser and we created a chat system for that. And that was a really great solution because it allowed more than 1,000 new patients to be professional people, asking for details of show that they've been seeing. We also implemented a way of being able

to organize different streams that were streamed in professional services. So if you do the stream, so it was a way of following up the show. Like, for example, we have in this conference this platform. So what was the end result is that we have the old Chrome side

and we'll decide for a lot of content or more than five years of information there. Then we have a guillotina with an implemented push notification, user preferences, chat with WebSocket and all the single year improvements. And then we have a new guillotina

that we are doing this year. That is the one that it's going to handle all the proposals, workflows. So in the future, we can place all the infrastructure in the guillotina line. Because at the end, on top, we already moved the professional space to a React proxy web app

and we built a management interface in the guillotina React as you saw from the project report. For the webpage, the CMS model used in Chrome, we were waiting to use photo or WordPress

depending on what the client might decide that is good or comfortable. The underlying layer, the users, as you see, it's an app that was one of the first of the worst functions in the web app. So just to see how does it look like,

if this is the privacy web app, you can log in as a professional person. And here you can check all the information from the last edition

or just present information for the new edition. You can see all your messages that you have across all the years with all the different. This is the demo user, so you will see a demo chat. And then you can also see the notifications that the organization decided to send.

These notifications are also in the system. And you can see all the tickets that you bought and your QR code in order to access them. Shows that were physically done. Then you can present for this year and then you can prepare your own proposals, your own activities, your own representative of parties.

There is lots of information that is in professional career. There is a lot of information that is being asked in order to present a proposal here. And there is a lot of validation process. So these flow forms are done with one of the favorite React libraries called Formic.

And for React people likes to create a lot of libraries for doing everything. And that's that one. So this is an example. And just the conditions that we released. We ended up thinking is that it's really important

but we're going to reduce space. You know, we decided you really need something a high level of training. Like maybe time devotional that does a lot of things that have been tested flexible divisionary. Or you need to choose a CSS design framework like materials or semantic or whatever. And you really focus on choosing the good,

the good fit for your project or your use case in order to define exactly how much time or what do you gain from using each one. There is also one library that we discovered one of these frameworks at React libraries is called JSON schema form which automatically renders forms and validates forms through JSON schema

that it's quite useful to validate schemas that are providing the tools. And one of the quotes from one of our developers is that the rest of REST API blown and you know what, are amazing to develop class from the front end but it needs to be well designed.

The folder-ish data items, the way that your next information needs to be well organized to the way that front end people can use it, that helps from the developer's perspective. There is another use case that Jerry is going to discuss.

Okay, that's one of the reasons I'm here. I'm published about four years ago. I started working with Polymer symbols and then I've actually got a follow-up. So I'm signed and they are not available. I started with bb symbols, it's a wine and romance all of them.

We're called by companies, we have around 60,000 rows, more than 70,000 orders. Then what exactly is that?

They have the whole group with extra methods, extra weights, external methods, and honestly, one of it is managing the RPE, the store, the market in style, all in itself, all templates in itself, everything mixed up and everything evolving from 12 years.

And this is one of the reasons they can scale. And they can not scale of items in terms because we have to add like last year, we have to add like 15 machines to cover all the traffic.

And also they are able to scale on features because it's super hard for more something like this. Then we start from splitting the project to be able to add more themes and to start evolving.

And we started looking at CNET, CMEs, because from my experience, it's the best way to evolve on features. And then we found Minitina, we did something on the same family as Joe, but wrong, and I said, okay, we have to go with it.

And we started working with Minitina. Right now, all of our content is migrated to Minitina and just started there on the dream. And also all the content side, like the items for the home branch, the initiatives that we are creating, all that, everything related to content,

it's just started on Minitina and we moved it. Then we moved and checked out the application, also extracted from the result plan, but as an API, and we have informed the Minitina project, managed it from another team that needs working. But we still got Joe, and we have to still evolve it

because we have a lot of screens with a lot of functionality. And we just created a new version, which is Minitina traditional using the storage, it's just Minitina as a framework because we need to use both of these for very business storage.

And we use Minitina as a solution for that stuff. We just started there as a piece to do Maya, and it was quite well, and we are building a new API with Minitina.

That's a bit, the same as I did on the last chat, but okay, I thought we can continue and go to the next one. Okay, let's see a small demo. This is the resource, this is the home branch. You can see that there are a lot of logs and models,

and almost everything is going from Minitina. The public website doesn't have to post any information, it just has to post it for all the processing and when I showed you that. You can see we have a complex layer with a lot of components,

there is a lot of notes and it's hard to optimize. That's one of the things I need to combine. Not sure if it's the best, because we have a lot of problems with Minitina as a service appending and stable service,

but right now it's working quite well and we can evolve super fast in Fittos. Super, super well-known and in very fast way.

Probably, this is our CMS that we do that. It's just, we show you that this is, you cannot actually personalize it with some more things inside, for example, it's a management in Fittos,

that it has to start to grow, some areas will grow from there or there, but we just move this way because we have a, the team of the around, so we don't want to, we want to be fast in things and evolve super quickly.

Cool. Okay, so another one that we are kind of really proud of

is a big data project. This is an electricity company, or it's a company that works for electricity, it's called VDATA, and they work about gathering information from consumption of electricity and they need to provide reports to the final, the final consumer about what they've been using,

how they can spend less money on electricity or how they can be more college. The main problem that they have is that they have a lot of data that comes from the group cluster where they are analyzing that data and that they don't know how to show to the users.

Right now, they are, they create video reports and they send that video reports to them. It's quite great that it's in the reasonable direction, they cannot control what the final customer sees. So we decided to create a built-in environment for them

that gets all the data from the aggregation that is on the other cluster. And finally, we have a front-end application built in React that allows us to define the reports and how they want to see the reports and different kinds of reports that they're going to see.

These reports then can be generated to PDF if they want us to contribute, send them through that to the final client, or they can just create web applications that are embedded on the tier B website. So at the end, the final user can see in real time how the data is being educated on their participation.

So this application, it's built with two things, one for storing the report design information that is CSS, what is the different layouts that we are going to see a demo about that.

And then there was a React application that's just connected to this video team app to destroy all this information. Then there is a data, you know, where here it's much more scary because some of these companies has hundreds of thousands of clients and there is a lot of information that stores all the yearly monthly information

for each user and serves this information to the screen that gets rendered on the website. There is a security process in service account that allows us to provide that nobody can see information that it's not its own. And that we do, we can delegate the screen to service.

So here we will see a bit, the demo of it. It's a simple materials front-end React application, quite easy to develop on a wide perspective.

The editor that you're seeing is one is called React page. React page is what was called a long time ago. It's a good editor, quite complex, but allows you to create different blocks and plug and play different things

and create a lot of information. For example, in this case, we're going to drop a new graphic that we want to put just on top of this pattern where we can define which are the keywords that we want to display. Then we can edit existing layer, existing reports,

and define new layers. A bit similar to the way that Voto is doing things, just instead of Voto is React page. And all the data that you are seeing here, it's generated through these variables that you see in the gear.

There are saved, economic percentage, and this is the model in JSON fields that it's saved from the other cluster. Besides defining the records and storing them, we can generate them, we can define the specifics, CSS for each of these elements,

and then you can define which is the one that we want. And finally, you define the service tokens, you are delegating these tokens to that utility so they can embed on their websites, their own clients. Quite simple React application

that allows a lot of forward to the client to define, to allow the final plan to define how they want to see their report reports and define which elements they want to see on their conceptual analysis. One of the conclusions I would like to point out is that editors like React page work really well

with the container like any other environment because store JSON at the end, we have a JSON field that you can store wherever you want there, but it's decisions are related, but editors are hard no matter where we're talking about. There is a lot of work and you need to adapt things to your own needs. It has its own cons and its pros.

Also, one of the things on the project is that we need to scale up and that we need to be scared about using code groups because we use a lot of data and we need at the same time to test with postgres and with lots and lots of data, we were able to scale really fast with postgres.

So we decided to end up with just postgres and just getting postgres and different environments and things like that. So another, let's see, time.

So I'm going to go fast because it is on practice as well. This is another project that was a clone side project that we've been having for a long time, complex workflow, more than that respect and a lot of security for industrial work. And in this case, we're gonna use,

we didn't use Givatina, but what we use is Grange, the build application that allows us with Angular to provide a nice UI that it's easy to use for industrial environments with lots of numbers, lots of tables, a lot of columns, a lot of security, a lot of information. So we ended up with a Grange application

on the clone with no kind of problem. Lavi, another project, it's a SAS software created for musicians, so they push their music to Lavi and people can download cards to give the people to download their music after the concert. It's backed up by Givatina,

but the front end is Grange. Cool. So we could use Grange on the clone side and on the Givatina without any problem. Thank you, this is an amazing job. You can see the Lavi project, it's quite simple, musicians can register on the side

and they push their music, they subscribe to the service and they can generate the PDF in the code, unique QR codes, so people can download the menu that they wish to download. Then there is Raps, my new startup

that is an inside engine software service that's focus is to get all the possible inside information from your information. We don't gather all the information, we just select what is the proper information that may be useful and we analyze and get the last lines.

It's Givatina in the center, Givatina manages the core information of all flaps, it has connections with NATs and streaming queue, similar to Traktor, has multiple indexes of file storage, other storage, our system,

we are using Givatina as an operation and training in order to train machine learning models as a domain for the REST API, as a cluster scheduler to schedule tasks to be done on the Kubernetes cluster, even with GraphQL and Adriana integrated properly, they provide a nice GraphQL interface so frontend people can build easily applications

in the top of the line. Our conclusions, JSON is really great at the REST API, but internally we are using Rotobuffer and gRPC because it makes us a faster introspection and faster speed in order to connect multiple servers

with different languages, like for example, we use Rust and we use Python a lot and it works quite well. Streaming and even driven architectures are really powerful and any server that needs to scale should at least be able to use it and Rust is an amazing language that integrates really well with Python.

I think for your site guides, in order to provide kind of a site guide for the REST application that you can actually see here are really, really good. And GraphQL, as most of you may be testing, it's great for a big issuance and to provide a query language that frontends doesn't depend on the rest of the code.

So I have, I think, a few minutes, so I'm going to go really fast in the roadmap. GCM is coming. We are starting already the branch from the seven. We still continue with the idea of less is more. We want it to create properly with a starlet.

We want to pickle, we store instead of pickles, also JSON and Google app or object, having a lock system, a GraphQL experimental add-on or add-on decor and we are going to create also relational system

and talk to you once you integrate servers. So right here, you know, we're going to do the test, we're going to do the test. Okay. The branch is also going to be at a grade limit with Angular 11 and it's going to move the schema from one as an dependency. We're going to do that,

we're going to just go to the free number list and we have to make sure that we have the R and we need to pick some things, more of the communication, more examples, because you see, and perhaps the Google people will probably be in a moto to make out all the work behind the moto

and also add a lot of people, perhaps Google will have to select this or add pages or something like that. But we can just go with the testimony and then we can go. Cool. And that's what we have.

In a moto, there is a bit of a definition that Victor wrote here, some features that they want to add them to moto and provide much more support on the API. There's some differences, we have dynamic behaviors, for example,

or search and buying is a bit different and a bit powerful in some cases that the long one. So we need to adapt and create this layer that provides this interconnection, also the sharing for this particular. And well, all the beauty has seven milestone,

this is the sixth one, it's on GitHub. All these issues are written there and if anybody wants to help with asking this milestone, it's more than welcome. And I really want to say thanks to everyone, thanks to everybody that you've given to Guilatina. It's a really amazing community

and I really appreciate you. And thank you, Jordi, also for helping on the promissory, so that's okay. And I think that's all. Hey, great, thanks Ramona, Jordi. That was a fantastic, informative discussion

on Guilatina and the roadmap and all the things that you guys have been doing. I was really excited to be able to attend and I'm really glad that you guys were able to present to us this time.