Mromsion—di ganoitha, kaстав receivede tu ka tup depending on where you're at and i au z silen hawnta ila ganagamai. I'm basically going to tell you a story, or my story, how did I get to Graf QL. Can you give me in the back, by the way? My speaking loud enough. And then we're going to look at Graf QL in general, and then we'll look at micro-profile the specification, and then I'm going to show you some examples that is going to run against the smaller implementation of this specification. And at any time, please interrupt me if you have a question. Right, so my story, and I'm hoping this will give you enough context, and you can relate, because I think this is feeling similar in any big organisation. So before I joined Red Hat, I worked at a big insurance company in South Africa, and we did everything.  Medical insurance or health insurance, we did life insurance, so pay out when you die. We did some wealth management, helping you save money, employment insurance, and all of these business units was actually small little companies that had their own IT systems, kind of operating on there. And then on the front end or on the engagement to the client side, you can typically engage using a broker, and so you would deal with your broker when you take out new insurance, or you can phone the call centre, or you can use the website, or you can use the mobile app. And all of these are different business units or different teams with their own CIO and their own IT systems. And where I worked was something in the middle of all of this, because insurance companies are typically a fading negative to engagement. If you have to deal with your insurance company, something bad happens.  So our job was to make sure that engagement with the client is positive. And more frequent, because typically you don't deal with your insurance company on a daily basis, and you forget about them and then only when something bad happens you have to talk to them. So I would think this is the problem for client engagement solutions, and our job was to engage the client in a positive manner. So we need to keep the client happy. And the way in which we've done that is we basically carry the profile of this client and then we store this profile. So we will do things like, we will understand how active you are. So we will integrate with this smartwatch and understand how many steps you take, how many catalysts that you burn. We integrate with the gyms in the country to understand where to the gyms, so you are active. All sorts of very private information that we shouldn't really do, but we're doing it, right? So we will understand how you spend your money so that we know that you spend money well. And then we'll use that information to score you, and then because of your score you can get a discount at a shop, a discount on flight tickets, or at a coffee shop, or we have an online shop where you can buy stuff. This is fairly normal inside the dyno. It's a foreign concept here, but if I do this talk inside, everybody knows who's the company we're talking about. The point is that this team that I've worked with did a lot of integration. So we had to talk to all of these third party partners and to integrate with their systems, and we have to talk to all of these to be able to integrate with those systems. And then all of these business units need to talk to us and understand the client there. So the point is we did a lot of integration. Now when I started there, which is now five, six years ago, obviously like any big company, there's a lot of ligas. So a lot of the integration actually happens with FTP, files being dropped on some folder, and we have to pause and pick it up on a daily basis. There were some SOAP services, not really well defined. There's some RMI services, again not very well defined. A big part of the system is even today's school, running on day is 400, and then there was a Java server which was by that time also 3 years ago. So when I got there, we decided right, we're going to be modernising our systems, and we're going to do something which is cloud-first or cloud-friendly, API-based and well-documented. So we came up with REST, and it's awesome, and it's going to solve all our problems. So at that time, the website team was busy redesigning their website using Portlet, so it's a server-side technology to create front-ends, and we said, no problem, we're going to build you the REST endpoint, which will allow you to get the user's profile so that you can display this onto the website. And we will give you information about the user and about the score that we gave. Right, so that means that we need to also hit these systems to understand what they actually do so that we can score you and show all that information.  It's not the real code that I stole when I left the company, it's just something similar. So what we've done, and if you know Jax REST, this will be familiar, but this will be an example of a Jax REST endpoint where we just say, on the get protocol, on this path return the profile of that user. It's fairly simple, and Jax REST under the covers will make sure that the profile is being marshaled to Jax. Right, so a profile then contains basically the information about the person and the scores that we gave this person. A person in this example, the person is actually being fetched from some other system, shared services, so it's not our system. And the score is our system where we scored the person. So we just fetch these two and aggregate them, and then it's a fairly big response that we get back because the person is a fairly big object. I think it was 70 plus fields just in the person object. But it wasn't an issue because the web team would fetch all the pieces that they need to display out of this, Jason, and then render their patch. So it kind of worked. Everybody was happy, right? So the web team was happy, they went live, and we had a REST endpoint. We started to modernise our systems. At that same point, the mobile team actually started up. They didn't exist, and they heard about our awesome REST endpoint, and they said, well, we want to also display this in the app, but we don't have the bandwidth to see that huge Jason that you produced back. Can you give us something lighter? We only want the following fields. So we said, okay, cool, let's read page two of the REST manual and see what do we do in this situation. And we came across this concept of HATios, which it's awesome. It's going to solve all your problems. So what HATios really says is rather than returning the whole Jason, give me URLs to where I can find the parts. So in our case, you can find the person there, and you can find the scores there, which means I need to make another call to that REST endpoint to get the person, which is still too big, and then make a call to the scores endpoint to get the scores. So that didn't really help us because we still have too much information. We're only making three calls now to get too much information. The mobile team weren't impressed. They don't want to make three calls and still have too much information, and the web team were not happy because they don't want to do the same and change what they already have. So what did we end up doing? Oh, wait. First, secondly, we thought, what about BFF? Now, this is not best friends forever. This is a pattern called back-in for front-end. And what that basically says is, so we leave the web team as is. They integrate like they do currently, but the mobile team will have their own little back-end, which they will use to integrate with us, and then they sanitise the data and send it down over the wire to the mobile phone. Obviously, the web team is happy because there's no change for them, but the app team is not happy at all because they don't want to build back-ins, back-ins or at all interested in doing back-in. So we had to scratch that as well. So what we ended up doing is something like this. Right, and now we have a profile light, and it contains all the information that the mobile team wants. Okay, so now both is happy. We battle to sleep at night, but life goes on. At that same time, the third party vendor that's building our online shop wants to display this information on their brand new CMS that they've just built in some JavaScript framework, but they say they want kind of the same information as what the mobile guys want, but can we add status to that? So it's the profile light but the status, which means following the pattern that we've done up until now, we have to do something like this now. Right, so at that point we realise this is not a scalable solution. We can't, for every consumer that wants something specific, build a weird little endpoint like this. Right, so then we started considering should we do something like this where we go back to just return the profile but allowing a user to pass in a query parameter, giving us the exact information that we should include or exclude, which could work. It's very hard to describe this when you document your endpoint because how do we do an object that contains an object that contains a list of some objects and some dot notation to notate what exactly should we include or exclude? And it's at that point that we realised we have this problem. We have the problem of overfetching and underfetching where overfetching means that we are fetching way too much data that we don't need and underfetching is we don't have enough data and I must make subsequent calls to get the data that I want. And the worst is the combination of the two, like that, your example where I underfetch first and then I overfetch on the subsequent calls. And we knew that what's coming in the pipeline is all of these business units is modernising their systems and they all want to use our new brand spanking new rest service and they all have their own little requirements. So our current model is just not scalable, building a rest endpoint for each of these. So back to the drawing board, surely somebody else has got this issue. So we already looked at that, we also already looked at best friends forever and we know those are not solutions that we can use. So what happens if you Google Quarable Rest and that's how we got to Graf Kiwal or how I got to Graf Kiwal. So it's awesome and it's going to solve all of your problems. So a little bit of history about Graf Kiwal, it's been created by Facebook and open sourced by Facebook. It's just a specification and it's published and available. It's been positioned as an alternative to rest even though I believe that you could use the two together if you want to. It's been declarative data fetching and we'll get into more details of that. Facebook specifically started developing this because of the increased mobile usage that they had on their platform. And they had all sorts of supporting all sorts of mobile phones and going forward watches and what else you're going to use. So they have a variety of front-ends that they have to cater for that has exact same problem that I've described. What this allows them also to do is to have much more rapid front-end developer because the front-end developer doesn't have to go to the back-end team to ask for a new rest endpoint because you can just query the endpoint themselves. So they've been doing this since 2012 and it's publicly available since 2015 so it's not new anymore. So some of the benefits of Graf Kiwal is then obviously solving the over fetching and the under fetching problem because I do data fetching and I can only return what you asked for. Rapid product iterations on the front-end so development speed and then Graf Kiwal comes with a schema built-in. So it's got types and it's got a schema where something like REST you have to add that with a subsequent or another API like Swagger or OpenAPI. So if we go back to the example and this is a good URL how to Graf Kiwal with some nice tutorials to get you through understanding what Graf Kiwal is. But if we look at our example what we would have to do is we would make a call to the profile service that will return a URL which will make a call to the person's service that will return the person and then will make a call to the score service to return the scores, aggregate the data, filter what we don't want and display it on the screen. So that's the problem we're trying to solve. In Graf Kiwal what I'll do is I'll just go to the profile server tell it exactly what is it that I want and the server returns the information that I've asked for which means a mobile phone can now use that same endpoint, ask a smaller amount of data that they want and the server will just return that. So this solves the problem that we had. The schema that's been generated is actually fairly readable so you can see this is an example of the schema that we're going to look at or the example that we're going to look at. You can see the type definitions of certain types. You can see there's a method called the lead person where you have to pass an integer of its mandatory. There's a query which returns a list of people so it's fairly readable but apart from the schema Graf Kiwal also has this concept of introspection where you can use Graf Kiwal to ask your server about itself and so you can actually use a Graf Kiwal query to say give me information about the schema and give me only the types and only the names in the description of the kind of that types which is pretty awesome. Okay so I'm going very fast so we might end a bit earlier. Is there any questions so far? Okay so onto the specifications. So by now I'm sure you've all at least at this conference heard about micro profile but just quickly micro profile is an open source specification for specifically for Enterprise Java and for microservices specifically it's a set of APIs so there's an umbrella specification that contains a whole bunch of specifications and specifically targeting a cloud based on microservices by architectures. So we are not in the umbrella yet Graf Kiwal is not in the umbrella yet we are busy on a standalone and I'll explain that a bit later and we are using CDI and JSONB so we depend on those two. Micro profile is also a Duke Choice Award winner 2018 so the process of micro profile works something like this if you want to start a new API inside micro profile you first go to the sandbox where we play and then you'll play a little bit in the sandbox and create a POC or some sort of an application that you then propose to the community and then you get a yes or no and if you get a yes you start with creating a standalone specification which is what we're busy with so in the next I would say months we will release Graf Kiwal specification and then the next step would be to be included in the umbrella and one of the one of the releases What does that mean? What is a a micro profile specification actually entails it's basically the actual spec in words so write out what this is and we use ASCII DOG for that to create then PDF or HTML it's the actual set of APIs which is usually interfaces and annotations it's the test cases that you have to pass to be able to be an implementation of this specification and we use testNG for that and then it's a compatible implementation and in our case what I'm going to show you is small rai we actually have another one and then I'll talk about it a bit later Okay, so now I'm going to show you some examples of Graf Kiwal using the small rai implementation Any questions so far? Otherwise we're going to end very early Okay, so you can you can see these examples yourself at this URL I'm going to actually show you how easy it is to get this running on your own machine to encourage you to go and play with this so I'm going to I'm going to start off by checking it out so I'll just quickly show you you can go find it in my GitHub repository I've tried to document it as well as I can to show you how to install it because Graf Kiwal itself the specification or the API and the implementation is not released yet you have to first build those but it will do it for you so you can can you see there? Yeah so you can clone it locally and then then you can do Maven clean install and give it a profile of install and what this will do is it will go and fetch first of micro profile the specification to build the API locally so that it's available inside your local Maven repo and then it will go and fetch the small rai implementation from master and build it locally so then after this you actually have all the dependencies you need to run this right so while this is happening let's talk about the example so in the example I'm going to use the same example that we spoke about up until now so we have a profile that has a person and scores and we're going to start off with a plain old Jax RS service which again I'm sure you know so this is just getting the profile so these these two annotations from Jax RS and the operation is actually from open API which is another specification inside micro profile that allows you to describe your rest endpoints and which you can then use something like swagger UI to have a nice UI to test it and then it doesn't do much it you give it a person ID via a path and it creates a person and it gets the scores and it creates this profile and returns it and then the grovkill one is is fairly similar right the only difference is the actual annotations so in the grovkill example we'll just say this is a query or this is queryable and this is the description you don't need the description but if you want to add the description and the rest is fairly much the same with a difference that now this guy becomes filterable I can say exactly what fuels on there I want okay so let's see if this so it's now built everything so now I can actually go to the example and then I'll just do a maven I've just run it on thontail and then what we have is a server on localhost 8080 and then I've created some test data just in memory using Faker which is this library that allows you to just create this bunch of test data so there's 100 100 people in my person person database which is really just memory so once you hear you can you can go to the a rest endpoint which is swagger UI and we can test the rest endpoint so let's say we do we find that person by ID so we'll do person one all right so all that we really did was a get on this URL and we hit that endpoint that I've shown you and now we have this really big JSON file where I can now pick the elements that I want yes this course somewhere there's a name and a surname and all the other elements that I might be interested in right I can now compare this to groffql so this is a javascript library called groffiql which is a javascript front-end on top of groffql and this is what this is it's just a way to to do to do this so what I can do is I can now call profile foo and as you can see I have I actually have insight into what can be done because of introspection so this groffiql javascript is actually using the introspection to be able to build this front-end to give you this code insight the difference now is that I can say right I only want the person back and I only want name and surname let's say just that and then I want the score back and let's say name and and value right so now I only get back what I asked for and that's just by adding that ad query annotation on my method right so what we want to make sure it happens is that what if the query doesn't contain the score and maybe your score system is very slow and I don't want to penalise a specific query by going to score if you didn't ask for score right so what what I want to get right is if the query don't contain score don't actually do the score so I want to remove this part here so that this doesn't happen all the time and I can do that so I can stitch things together by doing something like this where I now give it a source and because the source is linked to what I return here scores will be and a field on profile now and it will only be called when scores is one of the parameters that they'll feel that the that the person asked for so what this allows me to do then is so let me show you the log file so yes the log file will clear it a bit and now I'll do a profile again we'll do person person ID let's do two and I want back that person we'll do names again surname and scores names and value right so exactly the same what I've done now just a different person and and I got that back in the log file you can see that both of the methods been called for person two so I got the scores and I got the person if I now change my query to not include the scores I don't want to make the call to the score server right now I only get back the person data and I didn't make the call to scores which could have been an expensive call so now that we know that this is possible why is the system is calling them methods car yeah well so we are not calling this no you're not calling it yeah you're leaving it because of this and and you're going obviously create fairly complex graphs now because you can do something like this which it's a good or a bad thing depending on on how you look at it but as with any of any of these even jacks or s because it's annotation based you never make the call to to even this one right somewhere behind the scenes usually with reflection this this gets called and the only difference is we now know that oh well we also need to call this one and merge the data and and now that we know that we realise so if we actually don't need this object at all because all that this object does is exactly that is just binding two things to get so so we can get the exact same effect by just using these two and there's no field on the Java object here called scores I only add it to the boundary right at the end so now I can do something like this right where I return a person but I can add a score field to two person on the boundary only on graph qr not in Java so a person doesn't know about scores at this point right so if we look at this as an example I can basically do person this is an ID3 and we'll do names again answer name but now score is actually a field on here it's not a field on on profile profile doesn't really exist now okay and scores I have to say what I want back name and value and similarly I can obviously remove this if I if I don't want that call to happen yeah so far so good so obviously one of the other things that you can do is is a collection of something like a list of people or a list of persons and this is for me one of the bigger benefits of using graph qr over rest because if you think that that one person of 70 fields was big try returning a list of 100 people and see how big your response becomes then and all that you want is the name of the person so if we look at something like this I'm not even going to do it in rest because it's just too big but I can do something like this where I can say give me people but only the surname right so now this can be fairly big but I can actually tell it exactly what I want which I think is a huge benefit okay so up until now we've done queries mostly we're just asking for data and filtering exactly what we want what about changing data which has been called mutations in in graph qr so so in crud operations everything but the read part is a mutation create a new person update the person or delete the person again very easy to do in in micro profile graphql annotate with at mutation and you're done but the difference now is that we have a person object coming in and in graphql we we distinguish between a type as an output type and an input type even though it's the same type in Java both this person in graphql there'll be a person input and a person while all a person so to show how we can add a new person I'm going to just copy and paste from here so all of this examples I'm showing is actually on documented on here as well so that you can go do this at home because I know you want to let's close this one close this one right so now I'm going to I'm going to say let's create a person I'm only going to give it a name Philip and then I say I want the ID name surname profile picture and website back so if I do this I will go create it obviously all of those values are null because I didn't set them but I can now update it because I have an ID now that's been generated by the system for me I can do an update which is again just a mutation right and then I can update the data so we can do normal and then delete obviously is is fairly simple I have a specific delete method which you can just pause the ID and you can delete fields by setting them to null on an update and then the field will be deleted in this case I'll just delete the user we just created so I'm returning that same object back but if I do it again it's now been deleted right so full full blown crowd operation okay the other cool thing that that I think is a big distinct that this thing which are between this and and Jax Rs is how eras eras are handling and handled and specifically partial responses so there's two types of eras one is a validation error when you do something like this where you actually do a query that's not valid like there's no such field like this so this shouldn't work at all and we can show that quickly by just doing something like let's just do people and we'll say give me the names and blah which is not a field so it it should fail immediately right and this fails even before it hits your code so before it before our implementation makes the call to your annotated method we fail and say that this is not valid right validation error so that's the first type of error that you can get the second one is is something like this so I have to hard coded in to simulate the failure so what I did is I added another source element and I call it scores 2 and then I just throw a normal Java exception just to simulate this error but this will be the source system is down or there's some error in your code so if we go back to the example so let's do let's do person again and we'll say where person is 1 and return names surname and then score and scores name and value as an example right so this works and now something happens with the score system so now suddenly it's down so to simulate it we do scores 2 right and now I get a partial result back so we give you what we can which is the person and then we say then this is the error for scores and you can even go at line 5 and column 5 which will go straight there where the where the error is at and depending on how complex your graph is you can have multiple errors right but but you can at least recover a little bit so if this is a mobile phone rather than just crashing the whole thing or showing a oops a web page or page you can show some of the data and some not which I think is is fairly handy any questions anybody no okay so obviously you can build fairly complex graphs like I've mentioned so we show now you can tie these two together but obviously you can tie this together or you can tie more things to person and you can build a fairly complex graph depending on your needs whether that's a good idea or a bad idea that's up to you and in your design but as an example to just show how you can do a source of a source if we say that a score has been made up of a bunch of events like you went to the gym and you took 5000 steps and whatever else you did and maybe we want to display how we got to the score as well onto the screen then event can become a source onto score so we can do something like this where we say we have a person we want to add scores to that person and we want to add events to scores right and you can see how you can build fairly complex stuff now so we can now do something like this where we'll say go back to score and then here we want to say well actually add add the events that made up the score give me the action the date and time and the value right so now now I get more back and again if I don't add events that method wouldn't have been called so what we've done in the specification as well is we've we've said we want to support Jason B annotations because people are not used to it and it's been supported in JAXRS so you can do something like this where you format the date as an example right so back in this example I have another field now which I is also a local date time I called it when and then I said format it in this way and so if I rather use when here then the date is nicely formatted right and similarly all the other annotations so I can do number formatting so in this example this is a salary so it will show the the currency sign here based on EMZ so South African Rand and then I can actually use Jason B property to change the name so if I don't want to use salary in the GraphQL schema I want to use monthly salary I can change the name I can ignore something so if if I have a field in Java that I don't want in GraphQL I can do Jason B transient and then depending on where I place this annotation it will apply to either both if I put it on the field it will apply to both output and input object if I put it on the getter only it will only apply to output and if I put it on the setter it will only apply to input and that's our most of the annotations work if you don't want to use Jason B you can use the GraphQL annotation as well so it's it's very similar you have an add name which will which you can rename the field you have a number format that works exactly the same when you have an ignore and a date format the reason why we we wrote our own annotations is the Jason B annotations you can't do something like this which we also want to support where I want to say actually on this list actually support number formatting for the big decimal inside the list so you can do that as well we have a non null then so you can make something mandatory by doing that the schema will actually mark it as mandatory so it will fail and a validation error if it's if it's not there and then you can do something like this which is quite interesting so you can say that the list itself can be null but the elements inside the list cannot be or you can have a not null on on there that will make both of them not null then we have something like default value so if you have a query that says find me all the people with this surname but if you didn't pass a surname just return everybody that surname is crew you can do something like that some other annotations that I'm not going to go into too much detail in is these four which is really describing the types that we have in graph qr type is just the output type and input is the input type and inam is an inam right so gender male female and then you can have interfaces as well you don't need this because when this system start we will look at all your queries and mutations look at the response objects look at the parameters and build it based on that but in case you want to have specific behaviour like as an example I have an interface but in graph qr but if an actual class in Java then you can mark it as at interface you can rename it the type name otherwise we'll just use the class name and then add source that that I've already shown you that's how you can tie things together and then the last demo is to show you introspection which is also very cool so it's a way to use graph qr to look at the graph qr schema so by default the schema will be created based on your annotations so as the system start up we will scan the annotations and build the schema and make the schema available the schema is available under a URL you can go and download it but in this case you can also then use introspection so you'll see here in this in this little front end you can already browse it here and that's because of introspection so I can actually see all the fields that's available I can go into people I can exactly see what a person looks like you know at the rest is there's a list of of online items but just to show you how you can do this here so I can say show me the schema show me all the types only show me the name and the kind right and then I can get it back that's pretty cool okay so at the moment there's two implementations small rise the one that I've shown you now is the example right on that that's the one I'm working on it's nearly spec compliant for the past two months it's nearly spec compliant and then speaker is a library that you can see there and that's a library that existed before we started this process and a lot of the concepts in years is based on what was available in that library and the author of that library is also on the working group of the spec and that's me so if you have any questions please ask now or find me afterwards or online in my example not really because because my data is in memory so depending on on how you fetch your data yes if you make every field a separate source and then your queries can become very expensive and there's some articles online that explain that problem is actually you can build a very complex system that is fetching data all over the place but if I ask for everything then it's going to be slow the slowest thing in your system is the network right and this is what we're trying to optimise yet so what we'll add in in the petition version one by one because we can't get it in one because we have to release and there's a concept of the context so what you'll have is a ability to inject the context of the original query or question mutation anywhere in the code and if you as an example fetch from a relational database you can first inspect the context and then you can write your SQL the way in which you create on that so if it's a complex join or something you might be able to optimise the way you fetch the data from the database and if you want to and that will be in the 2.0 version so one is going to release in the next month I would say and the implementation shortly after and then we'll start it's on our issumers right so let's go there and then yeah can't it be a graph where the some people are allowed to see some appeal as some people so authorisation authorisation is on our 1.1 so all security stuff is on there right security is one of the more difficult things in the rock yield because we only have one input and with the risk you typically secure your inputs and you say are you allowed to get the same point but you're not allowed to get this input there is a rock yield you have one input and you can ask questions so we have to still find a clean way to do authentication with some sort of real possibilities to use the annotations that's available in the security API but a way to tell can you see this data online and then you can either have an exception and then do apportion the sponsors or you can say well you don't have you don't have you can't see this field because you have authentication there but here's the stuff you can't see that's it I'm thinking out of the box how it would work we haven't find you that yet but please security is a difficult thing even though for a bit more difficult than in the register but we'll make it easy for the difference and then you had a question so you were already on because I wanted to ask it's only one endpoint for the servers yeah yeah there's at this point again maybe in the future if there's a requirement to be able to have more than one endpoint then we can build it into the specification or if you want something like you already have a schema and you want to just merge it with the one that we generate or something like that I wouldn't guess a date because I get a date from all the time so we would have released but in December last year obviously we didn't I think the process of micro-profilers kind of prove yourself as a standalone see if there's interest and if there is which I hope there is then it will be included I personally think this is a much better way for microservices to talk to each other a much more metric optimised way to do but we'll see how the community works very well so what we have in the spec so let me just repeat the question so that I'm just make sure I understand what you said that we can we can provide compromising data in the exception methods that we pass to the sponsor if you want to make sure that that doesn't happen so what the spec says is that the hunt line exceptions we will not pass that we will you'll configure the genetic music that says this has happened or a boogaloo has happened and if any of you really want that to go back to the plan you can use a micro-profile for conflict to set a conflict to say yes this is coming and then vice versa for checking exceptions so vice versa for checking exceptions and say well this is a business exception so this is normal we'll allow that but you can you can blacklist so you have a white and a blacklist for runtime that's already in condition one does it also suffer or other so if it's the JSTB that you use under under the underneath users Jackson then yes but the spec itself we don't want to tie ourself from the spec from the view to the micro-profile speaker the the other implementation supports Jackson and Jason but that's really not a bad thing it makes it go through all this to not figure out which one you use and we want to promote growing against the specific action any more questions yeah and then there and there are for it to search for everything yeah include all the fields every field yeah and every sport for example and every yeah and and that's why this is also an API that makes it easier to add a new field as an example or move a field without breaking anything so so versioning in your experience versioning is less important than it is with register I think yes there was another question there first one can you show any of us about this place but you had a just uh which which link this one no no no yeah you have to keep going yeah okay mm more no yep because I wanted to ask you about how two things how you do search like you would say to not get all the people but people to search and like receive yep another thing which is related is how would you do something like that relation for example yes so so both of those will just be at query you will have to still write it so you will say what is searchable fields searchable will be something good or cheap that you can get is I can get the fields and groff the groff here like I doesn't take care of how do you actually search your data for this and how do you process your data that's your problem but you can build the area how to make the search what you do and do it pagination similarly what we will do with paginations again in version 1.1 or maybe in 1.2 pagination but maybe add an annotation like you say this is pageable something like that and then we will do that for you but already you can do it by manually adding pagination I have an example somewhere of people that add pagination any more questions if you do have more questions please find either here or online


Now let me talk about the ISO, IEC, IEEE, 4210, 2011 standard. Togath has always used a model from that standard to explain some of the key concepts that we have, such as view, viewpoint, stakeholder concern. Togath 9.1 referred back to a version of this standard published in 2007. That is not only obsolete, you can't even get hold of it anymore, so we had to do something about that. So what we've done is we have aligned with the 2011 standard. Now the key thing that the ISO, IEC standard attempts to do is to define a set of standard terms and provide a conceptual foundation for enterprise architecture. The relationship between the Togath standard and the ISO standard is complex. Where it is appropriate, we have used the definitions from the ISO, IEC, IEEE standard as the basis for defining similar concepts in the Togath standard. We do not fully conform to that standard. Part of the reason for that is that we have hundreds of thousands of people who use Togath, and if we're going to change it, what we need to do is to make sure that the changes we put in don't disrupt their usage of the standard. We have a principle, evolution not revolution. So we have adapted many of the concepts that we don't fully conform and we do not defer to that standard. Differ means that if we're different, we're wrong. We don't. Togath has been around a long time. It's got a lot of people, but it is sensible for us to take advantage of the work that's been done, and we've worked very closely with the technical editor of the ISO, IEC, IEEE standard in this alignment work. So this is the picture. It's slightly different to the version that was in version 9.1, particularly down in the bottom right. I'm not going to look at the top right because the definitions of system of interest, architecture, architecture, description, stakeholder, and concern have not changed dramatically between the two versions of the ISO standard. The major areas of change are in this shaded area down on the bottom right. And the main thing is the introduction of the box labeled model kind. So we've always had viewpoints and views. Viewpoints capture concerns. Viewpoints define templates which allow you to create views which are extracts from the architecture description to address those concerns. So a viewpoint is a template. A view is a populated template. So a view is a representation of the system from the perspective of a related set of concerns, and a typical view will aggregate one or more models. And a model is a representation of a subject of interest. A smaller scale simplified and or abstract representation of the subject matter. And any of you who've ever listened to me talk about this, whether it's in presentations or in training courses, will know that I always stress that a model is created to communicate with a specific stakeholder who operates in a particular context. So a viewpoint is a specification for the conventions for a view. So it governs the view. It's a definition of the concerns. It's a definition of what you have to do to address those concerns. Now a viewpoint may suggest that you create one or more models. So a model kind defines the conventions for a particular type of modeling. So a viewpoint contains multiple model kinds. A view contains multiple models. A model is a populated model kind. Togeth uses the word artifact broadly and continues to use the word artifact. We had a lot of discussion about whether we should drop the word artifact and put in model kind and model. By and large, the feedback we got from the people who use the Togeth standard is that that would create more problems that it would solve. So in relating these two standards together, we need to recognize that in the Togeth standard, anything in that box could be considered to be an architecture or a work product that describes an aspect of the architecture. Architecture viewpoint, architecture view, model kind, or architecture model.