so this is intended to be kind of what we did during the last year it's because the last on the last one conference we already presented some a lot of things

on Lillithina and we were willing kind of do what's the status of Lillithina nowadays what we've been doing what our our plans and a bit of history also on top of Lillithina so first me I am founder of two companies

right now foundation member a musician and I'm Catalan using my t-shirt and we decided to to include images of the actual situation on our presentation so next one so no I'm Nathan van game co-founder of guillotina and I'm

American I just followed Ramon's like sort of slide that's why that's a some other protest it's not Catalan the Apple Foundation member and work at

Ona doing guillotina thanks so my name is Eric Greg oh I also work at Ona I'm a front-end developer there I manage the front-end team and I'm a contributor I'm also part of the from our team and those are French

protesters you know okay so let's go first why we created ona later we will go with the history kind of details then a bit more interesting but just to highlight some of the the goals of what we are pursuing we are

pursuing something that it's built on a sink I oh and we will talk a lot about the sink I also I'm not going to to go deeper into that we want something that has batteries included what means is that can be delivered with elastic

search cache system distribution that you can really create workflows content types everything that you need kind of a bit the idea of blown but at the same time you can deliver something that it's really small just this framework selling hello wall on an endpoint so we want to keep it simple and with

but that you're able to include batteries on the out of the box it's built to scale we will talk a lot about that so I'm not going to go deeper into that and inspired by the best in Python so we when Nathan and me started to work a lot on creating the Latina we were kind of we don't want to

reinvent the wheel we don't want to start something from a scratch again like it's normal so we decided okay let's copy the best from all the frameworks that we know no so we went to pyramid and we say okay we love these decorators so we are going to copy on to be Athena and in the

spirit of clone which means of course we've been in the plum community I don't know a lot of years too many and and we decided to to copy also the things from clone that we love for example GCA and no GCL no component architecture

and interfaces the schema and the traversal point of view and pickling objects we will talk about that so and mostly the community we you know we are really happy that we are inside the plum foundation and because means that our code our project is protected forever in the foundation so that's

that's great we we want to keep in the plume spirit and we hope that we can have a lot of histories together and we finally and at least we don't want only to be back-end Eric asked do you have any screenshot for the

keynote how about you Tina and we say okay it's a REST API I don't know what the screenshot maybe we can try I don't know to screenshot adjacent wherever but you know once also to be a an history forefront and people who

wants to build application and we will talk a bit about that so we want to be building so building things with you Tina on the front-end side it's easy so now Nathan sorry that we're gonna keep swapping back and forth yeah I just I

want to go over some of the in case you don't know that much about guillotine I just give you an introduction to some of the things that we we're we provide as features for the framework yeah I guess the biggest thing because we're a REST API we're trying to provide a fast very well-defined REST

API and that means everything is defined by JSON schema and open API 3 and with that then we also have a swagger out of the box so everything is defined by a spec that is and all those JSON schema and open API 3 definitions validate the payloads coming in and so like it's it's well defined

and validated against the open API 3 spec and it's part of how you define your endpoints too so it's it's built into the framework itself itself as far as how you provide open API definitions and we're still like a hierarchy

content model just like clone and have this similar security model and we have like enough off framework out of the box with JWT and JWK as well and I mean we can have like really safe transactions with Postgres and web

sockets and cores out of the box it's all the things you need to build the JavaScript applications and lots of really cool features with asyncio for doing tasks asynchronously things like you need to do after a request is finished a different type maybe indexing or whatever but there's a built-in

utilities for doing these things working with the asyncio and cloud file streaming and yeah I don't know redis cache support with pub sub and so lots of fun stuff that allows you to provide a lot of features for your

applications and yeah so over the summer we had a sprint and a couple of sprints that we kind of worked on finishing up the features that we wanted to complete for guillotine f5 and we released towards the end of the summer I think around August and some of the things that we wanted to

improve with guillotine f5 were was the outer out-of-box experience because like before guillotine f5 out-of-the-box you couldn't get indexing and search you had to install like an add-on an elastic search add-on and so like now

that we implemented a generic query parsing framework so now you can pass the same queries and if you're using the Postgres SQL search indexing or the elastic search add-on they both should parse the same queries and had some

improvements with the object cache and pub sub and we moved swagger into core as well and I guess the other big thing was moving to Python 3.7 Python 3.7 has a really nice context vars API and that context vars API translates

really nicely over to async IO and allowed us to clean up a lot of our API's internally when we started with guillotine a sync IO was new and some of the patterns of how to accomplish things wasn't well defined yet so in 3.7 it's kind of like a really important threshold for us that

we are able to clean up a lot of internal API's and and async IO library is is nicer in 3.7 and as I was saying before everything in guillotine has core rest API now is open API 3 defined with JSON schema and it's

validated and we're using the latest swagger and yeah I kind of already went through some of that some other things more my pi support so if you extend guillotine now you can get just more support for type checking and we

improve the right cash hit and right performance of guillotine and and again related to the context vars better transactional API to make things a little bit nicer developer experience for people using async IO and and then

the search query API as well just just to mention my pie it's really important I know Nate did a nice talk about that well it's he said but it's really important that that we have my pie because it helps a lot the

development experience I really love it okay so the what we were planning to do now it's to go through the use cases I think it's one of the most frequently questions I've been asked so are you using guillotina it's ready for production which use cases are you using guillotina so we try to yeah we

are using the Tina we are using in production we are using a lot in production and we are trying to just summarize some of the use cases without names in some of the cases but just to explain where we are using it no so

first CMS I suppose that everybody understands what's the use case of CMS this is as far as we know right now being used at the escrow for example that we are using for building any kind of CMS's small pitches some small

internets some bigger internets and we built our own front-end on top of this API the clone rest API and we have workflows we have content types we have subscribers everything that you have more or less in clone the back-end

supports it but we are building our specific front ends why we are building our specific front ends is that our double uppers and our use cases are maybe so specific and they need a really specific front end with some angular application or whatever and then for us it's easy we are still not

using Volto but for us it fix the problem to have an API where we can connect safe content and publish content and being able to have security and folders and etc etc the second use case is is a bit complex to

explain but I will try to explain with an example so there is an electricity company in Spain that they collect data of consumptions of all the consumers imagine I don't know which is the one in Italy but in Spain and

this factor Energia there are a lot of a lot of them so we collect this information we process we do kind of numbers of how much kilobytes you use today at what time blah blah blah and then you also want to generate reports and these reports needs to be managed with content management so there is

somebody who is choosing I want the graphic I want this graphic I want these options I want to translate these labels whatever so for us it was a great opportunity to test Wilutina and the result was really great because Wilutina supports two kind of databases in this case are this is

really useful one is the Postgres database where we are storing the data from all the different reports the layout we are using react page for for doing the layouts and then another database that we are using cockroach that is being able to scale a lot originally to store the data which

allows us to scale with hundreds of thousands of different uses and data that we are getting every day that use case I don't know if with Plone will be possible maybe having an external storage of course but for us was really

great the developers just needed to learn one API the same API to access the data from the consumption is the same API that they use to access the layouts to publish to edit to do whatever they want it's also really great that besides having Postgres and cockroach as databases to scale a lot to hundreds of millions of objects there is also the option to use elastic

search so if you have time series information or you have a lot of information that you need to index out of the box you have PG catalog that it's the standard one that you can index hundreds of thousands of

objects but if you want to use a massive amount of information that you need to index an elastic search you can use elastic search out of the box without needing to worry about synchronization and indexation yeah another use case that we are using it's machine learning processing so I

don't know if you know some data scientists but they are really difficult to deal with because they want to have the data in a CSV file no so they they come to you and say I want a CSV file because I'm going to build my model that it's the best thing in the world okay but you know how

much time it takes to explore something to create a CSV file it's a lot of data hundreds of thousands of registries and you need to do that a lot of times because they need to update the models back over so one of the good things is that thank you to the transactional API that Nathan mentioned before that

we have in guillotina 5 we have Jupyter notebooks that are connected directly to guillotina and we are able to run batch operations that are doing models whatever kind of data scientist wall they want to do but they are able to

get information directly from the database directly from guillotina with an iterator that you can send a search give me all the documents that has I don't know attack call hello and then you get all the objects and then you can do any kind of work that you want to do a batch work for processing

or doing whatever and we can do that with Jupyter notebooks itself or with your own scripts on top of that oh yeah and as we are using pickles and now pickle supports numpy array in 3.8 we are able also to store numpy models onto onto the database like a standard guillotina objects well the use

case of weapon mobile applications that's that simple no you have a mobile application you need to store your data you could use firebase lots of people are using fibers nowadays but you need to send that to the cloud

you need to pay to Google well guillotina is of that kind of an API that it's similar you have web sockets you have real-time communication you have storage of data you have transaction ability you have security you could use us that to store the information from your data from your mobile phone a mobile application wherever you want and now we have a use case

that it's really big knowledge management well knowledge management is so big that we decided just to focus on the use cases that we work daily so now Eric is going

to explain that on a use case yeah so at oh now we are basically providing a platform to index all the information managed by a company and all customers are big big company big Americans company like Facebook or EA or Fitbit this kind of big company so they have thousand millions of emails of slack

conversation of Jira project g-drive stuff Dropbox file anywhere everywhere in the company's that's huge as you can understand and the thing is with Ona platform you can index all of that wherever it is you can make sure it's always in sync and you can search across these big amount of information

in order to retrieve knowledge basically so that's that's demanding I mean is that that's that's involving very very big volumes of data very big ability to scale and that's where guillotine is a perfect match right if

you can if you try to implement that with something different which is not the sink are you based for instance or which is not providing this ability to index fast etc you will fail at some point and you will not be able to adapt to all the situation where you are you try to get this big amount of information and where on is really good at compared to other solution to

do similar things is we are able to integrate many many different type of information because our platform is flexible is super easy actually to connect to a new third-party application like I don't know yeah Dropbox for instance and just use a their API to get information push

everything into the guillotine a backend and then it connects to the rest and it will work like any other kind of information so that's this flexibility and this scalability scalability is are the key factors is a key factor of success for for guillotine I mean using you tonight

here yeah we thought it would be good to talk about how guillotine is different maybe than some of the other more popular frameworks or some of frameworks that people here might be familiar with just so you know how to like classify it if you're going to think about using it well before I'll

start I'm gonna I'm gonna say this a few times during the conference a sync I oh one like there for a little while there was like you know there was a lot of resistance but I mean if you even look at the latest Django improvement proposal they're gonna adopt async I oh and so like resistance is

futile or something you know I'm like we're moving to an async I oh web framework world so like that I guess I'm just gonna say that async I oh one and all and like if there's any sort of like innovation left in the web

framework world in Python it's only an async I oh right now that's where the only movement is and so like Django is obviously really popular and it's like really full feature it out of the box experience for the most part and it's got like the admin the back end to manage content and lots of tooling lots

of answers on stack overflow and but the rest API isn't that great they have that add-on but it's not really that nice of a rest API but people use it a lot and it's not fully async I oh it will be maybe someday but it's

like it comes from a world of templating it comes from the days that when we were rendering HTML templates in Python and pyramid is a really nice framework it's unopinionated and it comes out of like sort of the Plone zoo heritage and it has a lot of similar concepts to guillotine as far as

like how it's built but it's not a sync I oh as well and there's no batteries included and then Plone I hope you guys are familiar with Plone so I don't know if I want to speak too much on that Ramon would like to tell a

little story of like why we have guillotina though and talk about how that relates to Plone well we're not going to do the compression there is the panel on Friday so we don't we're not going to fulfill this slide I just want to explain and I know I've explained a lot of times but just I'd like to explain these stories two years three three

years ago already I was starting the owner or starting the to design everything we needed to know how much information needed to be held there and it was a really ambitious project so I tried Plone I knew Plone I wasn't

willing to use Plone so I was starting to use Plone and it was going deeper into Plone trying to load a lot of data after two months I switched to real storage because ZODB the memory was blowing up the index of memory of

the ZODB was not enough the speed was really bad not because of the ZODB because all the cons that we have on on the stack in the middle between zoo and Plone there is a lot of decisions that are really great for CMS but not really great for building an application that needed to scale so we

were kind of struggling there and trying we were trying really really hard no if we even were calling Jim and we having calls with Jim how we can try to tune this more far away than what we have because we want we need hundreds of millions of objects to be stored and being accessed so fast

and we've reached a really difficult wall on AsyncIO because AsyncIO is it's one of the keys that makes this we will talk also about that later so I'm not going to go there but AsyncIO is one of the keys to make this happen so ZODB is not able to have AsyncIO due to the design by

itself so we were kind of oh my god I've been in the Plone community a lot of years and I still want to be in the Plone community and I still want to have some Plone related stuff but what I want to build I can reduce Plone even the frameworks even the lowest framework that we have on Plone so then it was when we started to we did a sprint in

Barcelona 15 people were there and we decided to start creating Plone server and then Guillotina and that was the history thank you so much for giving me the opportunity oh yeah and it's me sorry

continuing with the use cases one of the other questions I've been hearing a lot is but Guillotina it's only useful if you need massive amount of objects on your datapave it's true you you if you have massive amount of objects it's a really good good option but it's really good for

a small amount of objects yes yeah and we use a lot for a small amount of objects even 100 1000 10,000 doesn't matter why because the memory footprint of Guillotina is so small and deployment

requirements is so easy that it's so fast to deploy a Guillotina and to have it to support multiple kind of instances or multiple kind of Guillotina at the same time with one Postgres for example and the good thing is that you're using Postgres so the Bob's guys love because they

have a lot of tooling around Postgres so it's so easy to maintain it's easy to know to back up to do whatever you want so we wanted to explain some deployment scenarios okay monolithic the numbers are a bit rough sorry because we didn't have time to do all the tests that we wanted to show the

numbers but well a monolithic one that's a really simple one we have one Guillotina and one Postgres and Postgres is the indexing no you can deploy with one CPU two gigabytes of RAM and with all problems one million objects you get to up to 1,000 requests per second on reads and

30,000 requests per second on writes of course depend on the size of the objects if you are pushing there 100 megabytes of objects is not going to go at this speed but we are talking about standard CMS web pages for example it's cheap but if you are turning down the Guillotina instance you

lose the service a bit more a bit bigger so three instances of Guillotina then you need Redis to do the pub-sub synchronization of invalidation of data the Postgres and Elasticsearch if you want to index full-text search or some

kind of specific n-gram technology yeah you see that we need 20 gigabytes of RAM it's mostly due to Elasticsearch so Elasticsearch I think it's 18 and the rest is the Guillotina but if you ever needed to use Elasticsearch you know how much you need to pay but okay we had some instances with that with 10

million objects 10 million objects are 10 million pages for from the plumb point of view it's not only the it's all the objects and the main objects not the annotations and all the different inside objects inside on the on the main object then some medium size here what we added oh yeah in the

other one Elasticsearch was monolithic oh so if you turn down you lose indexing so we were trying to make something really resilience three Guillotina's was already resilient and on the terms of the instance and

then one now we can have an Elasticsearch cluster 64 gigabytes of rhyme 8 CPUs that's 50 millions of object approximately and then finally one of the production environments that we have three Guillotina's one Redis

cluster for cache invalidation and Postgres cluster or cockroach if you want to use cockroach an Elasticsearch cluster and 14 CPUs and 96 gigabytes of RAM this supports nearly everything that you can push to it okay now that we finish with back-end kind of DevOps things it's time of

Eric so front-end so yeah Guillotina aims to be a full stack solution right so obviously is most important part right now is easy is back-end so we've been talking about it but we are also building front-end component on top of Guillotina that are supposed to be reused and could be it could be

used by you on any Guillotina based product so I will first mention existing tools or product running with Guillotina so the executioner is basically the equivalent of Django admin it's built on on angular and it's shipped with Guillotina it's not I mean it's not production ready right

now it's still having some bugs we are not maintaining it very actively but it looks pretty good and it does some stuff so myself I use it too when I whenever I need to create a new container to do my test test or whatever I'm gonna use this tool I prefer to use that for instance a postman and doing my my API call manually like an animal or something

means those guys but yeah so this this is a tool which is shipped with Guillotina right now we will try to maintain it make it better yeah it's an admin panel basically that's what it does we we have to mention volt2 as well so when you use Guillotina CMS you can run volt2 on top of it it's

compliant we I mean that's obviously not the main use case for for volt2 right now we know volt2 is designed to run with with blown but it is compliant 80 percent let's say so sorry just well because Eric doesn't so doesn't know

what I had here at the bottom of the slide so I'm going just to try to explain if anybody wants to try Guillotina with volt2 and see how all the errors that there are you can easily you know if you know helm helm is a

technology on top of kubernetes and you can deploy something on a cluster of kubernetes even in your local laptop so if you run helm repo add Guillotina and this URL and then helm install Guillotina Guillotina CMS you get out of the box volt2 a Jupyter notebook connected to Guillotina a

Guillotina instance and executor everything for free so yeah so it does work and it's nice so yeah it's definitely something we need to mention here it's implemented in react as you all know obviously now I want to make a focus on on Grange so Grange is a new thing that have been developing

those past months so Grange is a French word it stands for barn so basically a place in in a farm where you put all your tools and stuff and machines and so on so that's Grange but it also stands for Guillotina REST API angular environments so what it is about Grange objective is basically the

use case is to build web application or mobile application from scratch okay so you use Guillotina as a back-end and then you use Grange to assemble your application fast and the objective is to make it easy so you're gonna say yeah front-end easy not a good match yes true front is complex front

and always been very I mean it's getting even more complex now so a lot of frameworks a lot of knowledge and practice to have so it's complex that's true and my objective is grant is to make it easy that means that you're gonna take Grange and you're gonna provide you with a lot of ready to use

component ready to use feature and then you start from there and you you you reach the point where you have a MVP which is really satisfying for your application on over a few days right that's the objective so how does it work first it comes with powerful principles principles we know about in

in Poland for most of them traversing is one of them it was on them so routing is super bad and I have a talk about it I will not make go into much details for for there but yeah it does work with traversing it it also provides view overriding so just like prone is it see a kind of approach so you can

have a basic view which is the one provided by default for by Grange and you can override it for such type for such given kind of object you want the view to be different and you provide your own you declare it and it's done it gonna work state management as well so it comes with Angierics configuration so everything which is traversed any object you

access through the application gonna be put into the state and will act as a cache and it's traversable as well but here are as well I will not go into too much detail it's featureful it's so compared to the first approach I've been implementing which was a prone rest API angular here we are

providing everything prone recipe I angular we're just providing the services to connect to a prone REST API back-end or guillotine a back-end authenticate and manipulate contents create etc but it was not providing a UI library for instance here with Grange you get Pasenaga UI library so the full

thing really good-looking component for forms you have a beautiful elements like toasters message these kind of things everything you could expect from a basic UI library is there right you have dynamic form generation so as you know or maybe you don't know sorry but from you Tina you can get a chosen

schema for any type and using this giant schema Grange gonna instantiate dynamically a form which just correspond to to the schema so you can modify you can view and you can create new content using this form you have standard views so like edit they let login search whatever this kind of

basic view you use or every time in a you know credit scenario and standard components like breadcrumb like what else yes some navigation these kind of things are ready to use as ours are and international well so that's what

you get for free by installing Grange so that's exactly the principle you start installing it into your application so you have an angular application you install range and then immediately with no code right just running this

install just like you would run build out for instance you install it and immediately you get everything working for a basic cross scenario on any existing object of your you Tina back end I think it's any Grange enabled application is able to render any object content so of course it might

not be exactly what you need because that's basic view standard views so it's not super rich if you not happy with the way it looks you can provide your own just by overriding the default view for such type and you get something which gonna be fitting your need and you go you can move and implementing the rest of applications super rapidly so that's the objective

make it simple you install then you create your your default views and you're done your application is there it's all working and it's it's looking beautiful so that's what I gonna try to show you so it's very short demo not super fancy right but just to show you what you get with

zero code right yeah not entirely zero code I made some code to have this beautiful logo and that's pretty much it so for instance you have this view which is a login page this is of you I made no change then I get the ability to view the content of my application so for now I have one folder I can

enter the folder you see there is a toolbar this is also a ready to use component so this toolbar is addressing the basic crud needs like creating modifying deleting so let's add something so automatically I go to the add view which is also for free it provides me everything which is sorry

everything which is addable to this into this current object into guitina so according what's different the backend this is a Vania Django guitina CMS setup so there is nothing but folder and item but if I declare now a new content like I don't know what news item I gonna get a new

item here right it's dynamics are there is nothing to declare on my application and the whole logic about grand is this we are neutral compared to the to the to the backends a pagan knows about the structure of the sites the tree he knows about the content he knows about the scheme I knows

everything and I don't care about it I just render I just react to what the back end is sending me so he sent me I can have some folder items well let's just display the weight is so yeah I'm gonna create something whatever and save and I get it if I get it I get this form which is dynamically

generated according to the Jison schema from guillotine R and it's all working and and yeah that's it so you see there is a breadcrumb as well yeah it does work basically and everything is cash is optimized everything using the state so redux state which is defining in grand so I don't care about anything

I just go implement my views and it's it's done so basically slowly so that's it okay we have the last the last one yeah so we we are going to

finish this this presentation with the Roma that we have for the next coming years maybe we are going to present some of these in the next long conference guillotine a5 will be LTS you want to explain it yeah well this

that means that you can really rely on that guillotine a5 is going to be keep for a lot of years within defined how many years but it's going to be maintained for for a long time then guillotine a6 it's going to be

merge the pull request that supports as G on guillotina in the coming weeks and that's a big change but we will be able to integrate with other tools that are supporting as G as it looks like it's going to be the standard protocol for a synchronous application and well we are maybe going to include

awesome guillotine a6 as a concept that it's through the configuration content generation no you know that blown has through the web defining new content types so as guillotine all the configuration is on memory we are going

to allow to create content types and workflows on the configuration at bootstrap so it they are registered on memory and yeah we we have some tests and we are playing on to creating a database focus to fix the problems

from guillotina storing indexing searching in rust and we are going to play with storing protobuffer serialization instead of pickles so the database can be inspected and analyzed and by other languages that is

not Python and I think that's all thank you so much questions any question may

I how do you describe traversal in an open API document so everything is

dynamic so every like if you open up swagger it's gonna be telling you all of the endpoints for a particular context so if you want to go to a different objects on the hierarchy you have to select that as the URL and

swagger UI and then it will load all the endpoints that are available at that context so it's like a dynamic swagger any other question okay what is for payload validation open API core or something else I mean

it's mostly just JSON schema right it's all JSON schema actually so we just read the the open API open API spec which includes JSON schema and there's a JSON schema library to validate it question of curiosity okay where do you

use pickles because I thought you you are storing chase and beer and post pickles so we pick all the objects and those are stored on the database JSON B is for the Postgres SQL like indexing so it's almost like we haven't we

have index fields just like say flown and then those are stored separately from the pickle in a JSON B column for Postgres and then we install indexes on those fields to be able to search them in Postgres so I I'm

already able to accept this chase and part with other languages you're able to to connect to the JSON be a standard Postgres and but it's only the indexing information that you define you may have a lot of fields and you just want to index some so these ones are serialized on to JSON B okay the

question this is a question for Eric for someone who doesn't know anything about front-end development how how different is Scrange from the current

state-of-the-art tools and what what's the main improvement there like what okay so the main thing about it is it's not a framework right it's using it's based on a framework which is angular and you better know about it

if you want to use Grange I mean you can start with it because Grange is an easy starting point to learn about angular but yes you will need to learn something anyway it's not just like magical and you don't just use Grange it's not a product that you will kind of configure through a screen or whatever and does everything you need you are still programming stuff so

you install Grange it will enable your application with a lot of predefined behaviors predefined UI predefined logic navigation and so on so that's good to start with but then when you need to use it you when you need to customize something in order to fit your business need that's that's programming and that's classic angular programming the only thing which

is really nice about it is you will not need to to create your own button click method or whatever it's all provided with all the different framework we different libraries we are embedding in Grange so past Anaga UI for instance is ready to use you just grab the component and you're gonna

work you have you have a lot of form generation as well so you don't care about that so it make you it provide you with a high-level toolkit but still you will need to program so it's not making it that easy right let's be clear about it