We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Django, Django Rest Framework and Angular2: RAD on SaaS platforms

00:00

Formal Metadata

Title
Django, Django Rest Framework and Angular2: RAD on SaaS platforms
Title of Series
Number of Parts
160
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Django, Django Rest Framework and Angular2: RAD on SaaS platforms [EuroPython 2017 - Talk - 2017-07-10 - Anfiteatro 1] [Rimini, Italy] Rapid Application Development has been a major topic for the desktop development world. Yet, desktop development has proven to be at the end of its timeline and the latest major environment is now the web in its many forms (from browser to Electron and similars). Django offers an amazing infrastructure and Django Rest Framework an amazing middleware to solve most of the problems. The RAD development on Angular2 is then enabled by a set of libraries developed at Modal Nodes for both front and backend that ease the development of the front end tools and front end interactions with both unauthenticated and authenticated systems via JWT and Djoser. Specifically, we will see the changes in the metadata that will enable better interactions and the usage of both the backend elements and the front-end ones in order to ease development
Software frameworkComputing platformSoftware as a serviceComa BerenicesSoftwareIntelModal logicVertex (graph theory)Android (robot)Stack (abstract data type)CodeCoroutineSolomon (pianist)ExpressionSoftware frameworkProcess (computing)PlanningSurvival analysisRight angleSoftware developerMultiplication signMobile appFormal grammarClient (computing)Web page1 (number)Product (business)Interactive televisionCartesian coordinate systemGame theoryWeb 2.0Computing platformElement (mathematics)Latent heatPiMetropolitan area networkStack (abstract data type)Form (programming)DebuggerTemplate (C++)SoftwareCodeComputer animation
Cartesian coordinate systemCodeSoftware
Rule of inferenceStandard deviationExpressionSocial classView (database)Software frameworkGroup actionData structureComputer configurationSlide ruleMultiplication signInterface (computing)Online helpBasis <Mathematik>Goodness of fitView (database)Software frameworkSocial classMeta elementCodeMetadataElement (mathematics)Interactive televisionComputer configurationLevel (video gaming)Graph (mathematics)Descriptive statisticsTransformation (genetics)Computer fileRule of inferenceEndliche ModelltheorieGroup actionComputing platformLibrary (computing)Standard deviationForm (programming)BitCartesian coordinate systemMarkup languageFront and back endsData structureVapor barrierReplication (computing)Real numberPower (physics)FreewareGenderCodeFrame problemWage labourError messageDifferent (Kate Ryan album)
Social classView (database)Software frameworkGroup actionData structureComputer configurationStandard deviationSlide ruleMetadataData managementService (economics)Front and back endsTwitterVertex (graph theory)Software frameworkFront and back endsDatabaseInformationDistanceWater vaporProcess (computing)Point (geometry)Attribute grammarCategory of beingGroup actionLibrary (computing)WhiteboardReading (process)MereologyFrame problemTask (computing)Communications protocolLimit (category theory)Computing platformRight angleBeat (acoustics)Normal (geometry)Projective planeDirection (geometry)Moment (mathematics)Element (mathematics)Computer configurationConnected spaceSoftware developerView (database)Order (biology)Endliche ModelltheorieExpressionSet (mathematics)Electronic mailing listCodeNumberWeb-DesignerData structureMetadataStandard ModelData managementSound effectData modelMathematicsDrop (liquid)Web pageDescriptive statisticsService (economics)Latent heatInteractive televisionResultantStandard deviationTouchscreenException handlingWeb browserExterior algebraOnline helpMultiplication signVertex (graph theory)NewsletterExtension (kinesiology)Game controllerStatement (computer science)Electric generatorRadiusInternet forumConnectivity (graph theory)WebsiteDifferent (Kate Ryan album)Visualization (computer graphics)Representation (politics)CASE <Informatik>Computer fileReal numberScripting languagePhysicalismJava appletInterface (computing)Revision controlBitSummierbarkeitSpacetimeInfinityGraph coloringGenderDecision theoryPattern languageLoginTemplate (C++)Hidden Markov modelGeneric programmingDemo (music)American Physical SocietyDebuggerClassical physicsSystem callBridging (networking)Mobile appObject-relational mappingExpert systemSerial portStability theoryMeta elementLevel (video gaming)Goodness of fitTransformation (genetics)TwitterLecture/ConferenceComputer animationDiagram
Transcript: English(auto-generated)
Hello everyone We're going to talk about As the title said Django Django s framework and something else that is more Java or Java esque There's a catch because the title you have on the on the on the plan is not exactly the one that
Will be following because we'll find you'll find out. I don't want to spoil our everything There's enough of that about Game of Thrones already. So Let's start with a fast. Who am I? I'm a software developer. I'm a Python
Developer, I love tasty pie love Django rest framework I'm more GIS developer and I work with the team in Bologna with who does basically full stack in many different stacks even the ones with the wrong P I think this is very important because it's one of the of the elements that
Brings me here today and it's the interaction with the customer and the designers and the end product that we Are required to develop in fact being for for design for developers and one designer means that
the designer is the one that interacts with the customer usually and interacts with the client that wants that specific Shade of red or that specific form for that specific element on the platform on the front end on the front page on the
mobile application and It's important because as coders we want to write new stuff we hate the routine and As coders we would love to have The designers changing their graphical stuff and be happy with that and have the clients and the customers be happy with that without us
Being bothered to change the CSS because that's not our work honestly, and it's not being so chauvinistic its we hate that honestly and usually what we find ourselves doing is this and it's
good because We usually find ourselves writing a Django application and we can put the templates into the Django application and we're Kind of happy with that and it's good, but the real issue with that is that
We are unable to really Use this flexibility that Django offers us. So with the issue we had as A Spanish poet says a wise man's question contains half the answer
What does the issue we want to say We we've seen before we don't want to repeat ourselves. We don't want to Do the same work all over again every time how does that impact the The world we want to define and we want to express
Well, we don't want to Explain the API as we write we I mean the customer already has exactly Understood what we are going to describe this world We know We would love these
Apis to be self-documenting and what is more self-documenting than a beautiful piece of code Except it is not and we know that very well, but it's difficult to make that understand and it's difficult to Really have it
Explained to To a designer and to a software enter the the end customer of the application so What we found out as a team is that we need simple standard rules then standard rules means standard API is that's
the basis of restfulness And that's good because standard API has been standard libraries and standard libraries mean more time and more possibilities to create the famous tool for the our designer to basically design and draw his own interfaces without our knee without our help and that is
An enormous win because that creates a lot of time to be used for this And it's all a matter of how we want to describe the world In a talk in the previous session about the status of rest frameworks. I
Think one of the aspect that was not really dealt with what is the meta level description that these Tools That these libraries that Python has Can can offer in fact?
With considering that we're using Django we could use many different ways to design our API or describe the world we want to define as API's In fact, there are endless ways We could use Django class-based views and
personalize them to do the the hard work of responding to our options call to our get posts And all the interactions that we consider useful. We could describe a swagger file and Sadly, it's not that easy to do that in an automated manner
with Django and with For example rest Django rest framework So what could we so we would need to describe our API in a completely different? JSON file and then expose that JSON file through some
Way that has to be kept aligned with the real code of our application We could use whistle the whistle to Good we could use Rammell you could we could use any kind of standard and we could any kind of standard based on a markup language
any kind of standard based on JSON variant we could use UML with our with graphs and designs and Any kind of descriptive element or we could use any kind of
Transformation and as always this is the rule Once we have 15 standards and somebody thinks up a way to standardize them all in a universal standard We have we end up with one more standard to mess with Do we really want that?
Honestly, no Because it's already a mess and we don't want entropy to Kill us all sooner than needed There's Donald Trump for that So considering that we're starting with the Django framework as the basis for our
For our platform This the options that Remain are basically two and it's Django class based views or Django rest framework Let's go back to the basics. So what are the two ways that we could use to? to work with we could use
Again class based views are very loose We can really define many kinds of interactions with them and they're cool, but it means defining an adapter for from Django to the outside world that shows us the meta information that our
Our model represents on the other hand. We have Django rest framer, which is quite strict because it implements a real Very precise restful model and it is very descriptive on what kind of
action We can do with the elements But it has a it lacks on this down the description of data structures at least based on Python 2 the code hinting features of Python 3 have not been yet very
Explored by the framework and we're trying to work on that on the through the description of the metadata One more thing that Django requests for the Django rest framework offers is the options method It's an amazing tool. How many of you use it to?
Work on Django rest framework. How many of you use Django rest framework? That's okay Okay, I'm not in the wrong room It's not obvious How many of you use the options the the metadata element of Django rest framework? It's
Possibly the most amazing element that that can be used because it really describes you. I happen to have been working on on form generator based on just that and it's Amazing how much we can achieve with that and Maybe sometimes it's a little bit under a descriptive but with just a few adjustments. It becomes an incredible
It tells you really the story of the back end and how it works how it interacts with stuff and how it Represents things. Whoa, what happened? Where have you gone? Okay
I Said it's an amazing tool
So what we have now we have chosen Django rest framework So we suddenly have a back end based on Django and Django rest framework that keeps us on the database We have all the features of Django all the expert The expressions of the restful
Frame with the rest framework given by Django rest framework We have the API exposed through Django rest framework and we have the metadata exposed to the options element so Cool, but we have added two layers on our app and that's not cool. It's not maintainable it's it's a mess because we have the model we have the serializer we have the view the the view sets and
Sometimes we don't have just one serializer for one model That would be a perfect world and sometimes we have two three four serializer for one specific model because we have one for creation one for details one for
listings one for Other specific views or nested views or whatever So it becomes It risks the risk is making it becoming really messy Unless we have we get something cool from that
Unless we can find a nice tool or library that helps us doing Cool things on the front end and here comes the famous catch Because I'm going to could be a nice tool and angular for Considering it changes number every six months
Angular, whatever the number that had the highest bidder wins Could be a nice tool, but it has an amazing side effect It's a really cool element and has a really amazing Ability to describe and to
Enable really the structuring of meta level Descriptions of the world it does not work. Well with automated designers drag-and-drop designers, we have a library where we have developed a library to enable us to really ease the work with angular and
It's a nice library. It helps a lot it shortens Development time a lot, but it doesn't help us help our designer So what's the alternative?
The alternative is to go for something pure JavaScript driven How many of you have happened to know Grapes JS? Good Grapes JS is an amazing tool. It's extensible flexible and really a beautiful
drag-and-drop webpage designer, it's it was built for a Newsletter the designing in a very wordpressy fashion in order to help Designers recreate their
Newsletter in a fashion in a simple way to keep all the elements under control but it's a really amazing tool as a platform because it's Easy to use for the designer fun fun to work with for the developers the only side effect is that it's pure JavaScript and there is no way to integrate JavaScript into
the Grapes JS element so That means that we have to create something magic ish to Connect the world
What if we could take the DRF metadata and generate Grapes es components from the standardized Metadata, what do you mean by that? suppose you have the
elements Suppose we have the elements we can work with described as As exactly as the Django rest framework does we have the all the methods we we know Of we know that we can have the get on the list. We have know that we can Have the get on the detail the post the put and the options
And the delete and as such we can easily define how these elements have to be connected to each other and From that we can easily generate new components for the Grapes JS
platform as such It becomes quite easy to define a simple way for The designer to take our metadata describing the API we have Transporting it to that everything into Grapes JS
Looking at the sidebar where the components live dropping them into the into the interface and saving the resulting elements as pure JavaScript and
HTML JavaScript and CSS basically a zip file can be generated directly from Grapes JS It's not easily versionable. I know I and I totally agree, but it requires just to learn a bit of get and the designer can do that and His code is perfectly versioned and it can be tracked
And the the result in this is That the developers can live in their own space defining their own data structures and their own data models
These data models are then made visible through the metadata to the designer who doesn't need to Read documents or analyze Papers and and results of discussions. He just looks at the code and
starts designing the interface Just looks at the components and starts designing their their their details and starts defining what color the specific element has what Pattern it has to Take from whatever other source and
From whatever decision the customer the the the the customer makes on what kind of elements he wants to see It's not a pure angular way, but it's it goes away. It goes very far as As a data structure, so what are the
Contributions what are the elements? we are we have published and we will publish in the next in the next few days because these are the elements that really
That we're really trying to publish and transform into Let's say betterments for the community The Jen Django rest framework metadata transformer a tool that enables us to transform the Jenga rest framework metadata into a JavaScript that can be used on grapes.js in fact on
different situations one of them is grapes.js On the other hand, we have the grapes.js data attribute animator, which is not strictly bound to grapes.js But it basically helps us
to transform the data from The data attributes in grapes.js from VOG concepts saying that this data set should go and take data from that specific backend and
Use this or that Login data login information to Get the information from the backend and should expose that through this or that Template and should wrap all these informations into one
simple action that goes directly to the backend pulls the data shows them on the front end and Solves everything with a simple as a simple task as a simple repetitive task on the other hand as said
We're trying to standardize the work on angular2 as well angular whatever as well We didn't discuss this but it's a that it was the main reason for this talk in fact because we were hoping a certain amount of
changes and in the angular2 infrastructure Would happen by now it didn't happen Hmm but it's it's an amazing framework anyway, and all the the work we have done is right now Will be published in the next few days as the model notes back and management service
Which is a generic? backend management Platform for angular2 services enabling interaction with any kind of Flavored back ends or specific back ends if you write your own your own flavor
All in all This is the result Finally we can stay in our corner and hide behind our screens and be happy
That we don't have to interact with customers except for the beginning where we have to easily Discuss this but we are discussing the possibility to have the designer doing also the data modeling if possible and The designer talks to the customer and is happy and rich
Ricardo keeps Interacting with his friends the customers and we are all and everybody is happy basically That was our main goal and we think that with this structure We're able to go for that I think we don't have the time for a full demo. So I'll say with the next
Okay. Well anyway, I would say it's better to maybe ask Get some questions and have some hands give you some answers. Anyway, these are the mediums Twitter GitHub
for me and the team Thanks Questions
Thank you for your talk. So what happens when the thing you're doing on the back ends? goes away from the standard model view sets and standard generic APS because this is for me this is for Getting people hyped about the restaurant model view sets are great, but not really useful in real projects because there are requirements
That's movie away from there So what happens then you have just an API view There are two aspects on the answer the first one is that
If there is an aspect that good that moves away from a Jenga from from the classic model view set then we try to understand why it moves away from the model view set and At least in the last two three projects that we worked on It was just a matter of describing the world that for example
if you put a like on if you like something then it's I Like this post and it's put as a verb On the other hand if you think of it as a physical action You want to have an interaction with your database and you want to put something on the database. We you need to track something
Then you need to physically represent it as something different then it's a more a matter of defining the interactions the actions on the the data as Real physical things that become at a certain point models. There are I agree some aspects that cannot be
Redirected to this for example If you suppose you have different kinds of Visualizations of the same element where we have we might have different detail
representation of the same model in that case It's part of the Extended metadata that we've been working on extending the metadata generator To expose these kinds of information as well because it's the only way to go into that direction
again Personally, I think I feel more comfortable keeping the rest structure rigid and strict Because it keeps the I mean standardizing helps Not getting the call from the designer
Let's let's speak cynically we don't want to be called by the designer. What how do I get to that information? We would love the designer to be able to do that by himself and saying okay, this is a data structure that I need Where do I get that? Let's see the the metadata or maybe let's see
From the components if there is a component that keeps that gives me that information if that's missing then that's a good thing That's the kind of the kind of work we love because that's me that means that we need to explore a new way to expose information, but
So hi and thanks for the crates off I've been working with view chairs, which is basically the best pitch from angler and react If I understood correctly
The crepe chairs is looks pretty nice How how far is it the the bridge thing or is it? Is there a way or is it like something like If you will ORM for JavaScript for example for Django
to get a JavaScript and kind of a thing just Like a library thingy for JavaScript and that would work like a ORM In the back end. Are we like is this Moving forward seat or is this implementing this kind of a thing?
Your Question is if there is something like an ORM for the JavaScript part like like the crepe chairs is obviously one step higher, but yeah, if if Is the is the medium bit you talked about is it? Is it something like a
ORM for the JavaScript or is there a project like that Grapes ES is just a front-end designer and that's exactly the limit of the project We've been experimenting with
With realm for both For basically any platform right now Because they enabled realm on web development on web pages as well, so there is this Possibility and it's quite interesting because it's a very interesting world to explore
Right now it's quite difficult to integrate the various parts because It's JavaScript and it's as the people from typescript said hey
stable is the new alpha and So you don't get really to a standpoint where you say, okay, this is stable stuff Let's put that together and see what happens there is this beautiful lake where every ship is slightly moving and you don't exactly know in which direction and
We're working on on trying to interact to to have these elements interacting as I said The the most interesting project in that direction at the moment is possibly real to work with an ORM But there are also smaller projects that try to just rely on SQLite on the browser side to have
Almost a deep connection with the database Anyway can be interesting anyway can be explored again. The most advanced project on that is real so thank you once again for the great talk and
Remember to write the talks. Yeah. Thank you. Thank you very much