Merken

Build Realtime Apps with Ruby & Pakyow

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and you then there the the the the the the the the and so and spreading going so rails come from Split pretty conference of people have enjoyed it and so this morning Riddick got the alternative framework track great talk little bit about how to build real-time maps so with through the impact of I'm brian how I'm 1 of the creators of packing up I play an active role in maintaining it today about the deepest in my time that goes to building features and fixing the problems like have the village of working alongside about a dozen or so other maintainers and we love this project and we let the little slice of the review committee that we've been able to carve offer ourselves of the last year to you can follow me on Twitter Brian if you'd like so so I'm curious you here has heard packing before else again a few people but for
everyone else patios a web framework for Ruby and pack Alison and and framework so it doesn't work on top of rails you would use it instead of rails in your stack and pac now we've designed to be sort of a different take on building applications for the web and it's really different than what you might see us in something like rails or even other ecosystems and there's really nothing quite like it so this being rails cults rails excuse me but I did want take just a minute to say thank you publicly to DHH I'm a couple years ago but he was kind enough to offer offer his like you could call it an endorsement may be of some of the concepts
behind that yes I I this is why we do what we do I think he did it this no so
pac yell it lets you build server-driven applications that automatically stay in sync with the server I'm so what this means is packing hours a server-side framework just like rails on on the initial request packing I will perform the rendering on the server side and build up a full it's still response so that on the browser and that's presented in the browser just like any other age 2 mortgage would now overpack Yale starts to differ from other server-side frameworks is this view in the browser automatically keeps itself in sync with the server so what that means is if you were looking at a list of comments and applications and 1 of you out there adds a new common to the list receipt immediately anyone is looking at that was see that change immediately in a browser but n the framework handles as forests so as the developer were not having to move any of our application to the client it retains this traditional server-driven architecture so let's look at an example of that together
so this is a blog that were building on the this kind a story behind this so we model the blog but we want to be a little bit more than just a place to throw random thoughts up we wanna think of this more as a place to start a conversation right so I wanna make this engaging for the reader and I really do that in a couple ways so you'll you'll see the 2 counters the the blue 1 and is a gray 1 the blue counter indicates the number of active readers how many people are currently right now reading this page and the gray 1 is the total number of readers across the history of this blog post underneath that is a common format underneath that is where the common Sibewius's right now there aren't any and database so we see in the message now this is built this is already built-in packing up and so let's simulate the
usage of this between 2 clients they can see where things stand so so you'll notice as refreshing it shows up in the 1 client of the other 1 same thing with comments in fact it's not until that 2nd client refreshes the screen they receive any state and so let's fix this so let's make this a little bit more engaging you eye so we start by opening up are outs
from this is gonna look very different than something you might see in rails and try to understand everything that's going on here but will reduce the refocus focus on our statistics 1st the 2 counters remake those start to render in real time there were no test that out there we come back in your comments to this two-step take here and refine the bit of code that's responsible for rendering our counters and read out a call to subscribe of considering here so what this is doing is telling pack l that we want to subscribe this rendered view to any future changes in state that might occur that would affect its rendering and so that's the 1st the 2nd step it is were going to write a class I jobs to component on this components can responsible for rendering the state on the client but just kidding but we're not gonna have to do that and we will not be writing any jealous that today I promise you wondered line my abstract so In fact adding the call subscribe and telling pack l that we want this due to keep up with its state is all that we have to do so was go back to browser intestines up preserving everywhere the
pages notice there out of sync then reload 1 client and all of a sudden the counter start counting together we can continue doing this OK you can even see the blue and it goes down to 1 and the call back up to 2 as the connection is lost and re-established without that's like class we didn't have to write any jobs to all we did is told pack yell who we wanted to do in the framework figured out how to make it happen the so our common still aren't really working well so let's fix that next so we go back to our out here's the code responsible for rendering comments article to subscribe just like we did with the statistics and we come back to the browser the
changes and everything works properly research see comments show up and in fact we do so 1 client adds a common any other connected clients can see immediately on the screen you can go the other way too long and again we can write any jobs script to do this this is all happening in a server-driven environment but you might have heard of no JS
so we embrace no yes and I I can like to think that maybe this is what they were going for unlabeled node images to miss the science cold and they said yes and someone interpreted as no Jessica 1 of built that I don't just a theory of and I will be clear and I like jobs script I like writing JavaScript what I don't like is a developer is having to write code that's largely unnecessary and I think a lot of JavaScript that we write today is completely unnecessary for us to do so if we're not running client-side JavaScript how in the world is this working and that's a fair question
they get through this you might think well we're trans compiling are the rendering code that's written reveal a transparent editor JavaScript or sitting that down the client executing and no we're not doing that but I don't think that's a very good idea at the end of the day this approach requires you to build an application in a particular way it doesn't give you full freedom to build a traditional server side application so that you might think that well were were about when the state changes were doing a re render on server were building of the new HTML worsening that down to the plants were just doing a replacement of the Don work you part of Don note that were not doing that here I I think this is probably a better solution than the 1st and because at least the server is always doing what the server knows to do and that is in a server driven world of render of cement down so at least it has that going for it what I dislike and why we avoided that's and packets implementation is inevitably you replace more of the Don then you need to so we were really interested and and performing the fewest number of Don transformations necessary to render the new state so how does this even work and it seems like we've kind of exhausted all of our potential options here but what we haven't their works in a different way and I will explain this but to really offer a good explanation we we need a step back a little bit we develop some context and some context about how happy all started the initial problems it was built to solve etc. so welcome the 2011 so this is when we spur started working on getting out a real release a pack up the door on this but around for a long time so I think the 1st release was August of 2011 and at the time I was working for metabolome which is a consulting agency that I started back in 2007 we hold web-based apps were all sorts of customers we were working on rails mostly at the time in 2011 were still around today but we're still we still this arousal and and for the 4 years or so that we've been in business we had some unique processes which I think they were pretty and then use of the time and we call
this process the 1st development now our priority you 1st development was to get something in front of project stakeholders that they could see and touch in use in a browser as early in the project as we could so we when we started a project we would meet with project stakeholders and we determine what in the world it is that we're building we figure out the features that we prioritize that would start with the top right the highest party features the kinds of applications that we build are mostly mostly involve user interfaces and so that was what we wanted to start with because that is the tangible thing that we can play with together with the project stakeholders and really use that as a way to talk about some of the more abstract conceptual details of the future the way wanted to work as we wanted to create a useful part
effect Brill building just you you have to build a prototype applications we just want to write a views the thing that was present in the browser and start there so we use that we deliver that ended there too we iterate on that with the project stakeholders we could throw it out of sort of wanted to because we had invested much time so once the prototype was nailed down we wanted to build the back and on top so this implies sort of this consistent forward movement we didn't wanna throw out previous work and start over who want to build on top of everything that had happened previously and the 3rd goal of the 1st development and how we wanted to be building applications is he wanted to be able to revert back to the prototype at any point so we don't build things in a waterfall fashion we work prototyping the entire application of it and then integrating into the application and shipping it reduce 1 feature at a time and I always found with technologies such as Rails and rails as the doesn't most server-side frameworks that is we build our prototype in HTML URI templates the discontinuation of have review sprinkled when it came time to integrate the feature interapplication we spring the and that pretty much destroyed operator so we couldn't just see the age to the raw image to al are really sprinkles so we kind industry so that it when we started building the 2nd feature we could see its protect we couldn't see it in context of the original features part and then it kind of difficult work working through that with stakeholders because they don't understand what I couldn't see the same thing that they solve for so we really want to solve that and I ended up being really difficult
so we did the only logical thing that we can think of to do at the time we Bolton framework that to solve this very specific problem the when we set out to
build pack yell we really had this 1 goal of this is a pattern that I and a few others had noticed in every single web technology that we'd ever used since we started building up against the early 2000 s when I started so and that is that the presentation side of web applications combined to things that we thought were really separate should be treated separately and those are the structure and rendering logic so if we look at a near the template on here were just iterating over a set of posts and rendering an article for each post and were putting the value of body in the paragraph that there's 2 things represented here there's the structure of the view which is based in male and there's the logic to render and that's the really sprinkles and this you look at this it has some semantic meaning to the year before but right we can look at this and we can see that our article tag really does represent a blog post or a post object in this case right because we were creating 1 for every post that we have in our dataset and we can also see that the paragraph tag represents the body because that's the value that were sticking into the body to so this year be simple has some amount of semantic meaning to us and that's lost when you when you build because you end up with just HTML so you lose the semantics of so we set out to tried to save this so what you see at the bottom is a pack out you it's the same exact thing as the topic and you'll notice there's no Ruby code in that's but there are however 2 attributes there's a datascope data problem now impact Yale terminology a datascope representing data types so here we're saying that this article represents a post and in our system and the paragraph tag which is nested within the post represents an actuary of it so the pair reps the body of its current scope with post and that's all of you as impacted we can stop there now the logic to render it looks something like this and this is just an example this is that many different ways that you can do the rendering back out but this is a simple 1 and you'll notice that this doesn't really look like word rendering HTML there's no Don transformations that were leading to express instead what we're doing is expressing by rendering logic in context of the semantics represented by the views so we're not saying find the article title view and render that were saying find me the node whatever happens to be that represents the post my presentation and apply this dataset now applies not magical it's actually pretty simple to understand so let's look at a couple of examples so we have a hash just a single post obvious that we want presented we apply that to a template on what applies going to do is 2 steps 1st it makes the new template match the data structure that replying to secure here that's easy there's no change required because r template RT represents a single post were applying a single post so all apply has to do is map the body value right into its place in the in the temple so were left the result on the bottom looking at a little bit more complex example with 2 posts now apply has something to do right art simple it only represents 1 post trying to visit to so it creates a duplicate they can simply just maximizing the and that's all the rendering is impacted but so many wrapped up part about right this allowed us to do exactly what we want we could prototype dates to HTML we can add the back and they we don't have to change our views of users and at any point to just turn the view rendering part off and would be laughter the prototype and so we can effectively solve our goals so we build applications this way for a few months and we quite enjoyed it and I had this idea of sort of nagging feeling in my brain that I can shake but now keep in mind this is right around 2012 ish and jacks were starting to become more popular gain more momentum as were client-side frameworks and I could shake the feeling that maybe we have something to offer of 2 people who wanted something more than just static views present in the browser really 1 of the dynamic you experience that backpacker might have a unique solution to the and its stem from this 1 idea so this is our 1st rendering example and you'll notice that are introduced still has the semantics that the temple and we still know what every node represents in this rendered here OK so we can actually use that previous render as a starting point for the next so if we add another post to our state we don't have to start with the 2 original template we can start with the 1st render and just build on top of that and were left for the exact same result so is this idea that rendering is additive and the code to render the initial view maybe it's enough to also render changes to an existing here now the rendering a happens on the server it's presented in the browser and that means what's presented in the browser still has those semantics we know exactly what it is that it represents the application so we're have that he's a template that we can work from so all we need now is to get the transformations down to the client and theoretically with some magic we can make the client of the itself OK so let's
walk through for example of this to you have a client server and Klein ask the server for the initial view and the server responds with a fully channel response presented in the browser now subsequent updates and they also originate from the server so the server is telling the client how it can update itself this happens with something called UI transformations and the way that we build these transformations is we execute the exact same rendering code that we used for the natural the but instead of rendering HTML we just recorded the transformations that need to occur and so were not were not trends piling that code into JavaScript were discreteness set of instructions and for the rendering issues to reflect the new state now this is data at this point adjutant just a large data structure we can actually serialize that that's what we do we serialize it as adjacent object and we show that our WebSocket and to any client that should be concerned with the state change no there is a client-side library that's part a pattern of covering digest and reading is what receives these transformations and does something with so reading that has the template now has the transformations and all has to do is step to the transformations and make the necessary updates to reflect the the view now this happens through something called a view transformation in the so because we separated our you structure rendering logic were left with this nice uh 0 7 methods or so of how we express a view rendering and Arabic and we implement that on the back end In a class called presented and presenters the thing responsible for doing initial HTML rendering but ring that Js also has a client-side implementation of the same API so when it receives the UI transformations those transformations are expressed in the common API and ring can iterator red color right functions on the client side and negative that's been make the the browser reflect the new state so Packer fall
somewhere between a traditional the client-side firmer right it's server-driven server-side framework just like rails we're getting full H 2 more responses but once rendered really getting this client side behavior but again we don't have to move anything over to the court on not even happier has to move anything to climb all of our code stays Ruby code and it stays so thinking about how we might do this and other server-driven frameworks but inevitably we adopt some sort of hybrid approach so let's just use rails and as an example so if we care about building our real-time blog and rails we might do the initial rendering of a certain rights that instills and avoid too low response that we might use some client-side tool maybe image AS a backbone or maybe you can even use action people for some of us and it that component is responsible for making the client-side state changes as instance so the that dynamic you but what we've
done is we've kind of we have 2 problems now right we have to code bases that are executed in 2 different contexts and both concerned the same thing and that is how to render a state some that's on the server some that the point and this is kind of creates this web of complexity and it leads to more complexity is the further down the rabbit hole you go I think this is largely why people started building single-page apps to begin with so it's conceptually simpler I understand right we start off we're building a server-side application we only dealt with state on the server and now we got this hybrid thing we have to manage to code bases that both the state solar system at all to the client and you there and on the surface that kind of seems maybe you may be a good idea and maybe for some kinds of applications that is a good idea but I really think that single just break the web and this is a pretty bold statement but I really believe that if you look back at the entire history the web it started off as the server-driven thing and it was a series of hyperlinks documents that were provided by some sort and you were guaranteed to receive exactly what you wanted back in response from from your request with a single page model there if I request a blog post on a meaning it back is an empty skeleton of HTML file with a JavaScript include hopefully I can load the JavaScript senones not on something and that it's a java script can be fetched and can be executed then it's gonna make another round trip to the server to get the data your API and then finally we can do the rendering right and this is a complete departure from Poland and building applications for decades this is how the web works every successful technology built on the Web builds on everything else that was there before and it just feels like ashamed throughout the server-side applications that we've been going for so long so in impact we implement
real-time is an enhancement so thinking back to our example application we 1st demo and we 1st saw the browser was just a static view but all at once on just like any other back in driven application like a rails upper PHP at was a static thing didn't change from the right and what we did is we went into the back in care and we just told the framework that we wanted it to be subscribed to state changes so we did In the framework added that into application but it did so as an enhancement it's just a layer on top of the application continues to work even if real-time doesn't work OK so let's say for example someone visit their application without JavaScript well the problem the 1st responses of wage channel page is already rendered can presented OK well that's not very likely right no 1 disables jobs that work well what if ascidians down and we can fetch a JavaScript that happens to us but maybe we were just not get it off but I think that's a common problem and not a problem right same thing we still have a rendered view that we can present the browser I and I think this really reflects the spirit of the web right it really is real time is an enhancement on top of how we been building applications for decades I last year I love Ruby and I don't mind JavaScript but given the 2 you know which 1 I'm going pick I love the language and that's what drew me to rest rate in 2005 at when I 1st started hearing about this thing I was like 0 my goodness would how we can build applications this is also I've been stuck in PHP for so long and I've lost my soul and here's this also when building Paris and rails has a lot to do with that reals is a fantastic tool that allows us to build things in a much simpler way than before with good patterns and processes but at the heart of rails is really and that's what I really want go my applications I think as developers we need options we need options for how we build that I don't like this migration towards the client and even on the server having to write JavaScript to other applications that distinguishes so where's the project
going and so this time stuff has been out for about 6 months but about 2 years of work to figure out how we're gonna make this work but it works but there are production applications some of them we felt similarly have not on that use packing you URI and impact real-time to provide these dynamic these to people the browser so we feel like we've we solve the hard problems now like we've got all that figured out now we just have to make it a better framework because if you're trying to use Packy our documentation Snyder a other API is not exactly perfect and those are the things that we were fixed we really have this vision for you know pack yell makes it possible for people to build applications in a completely different way and to build the server side applications that feel like modern clients that and we would bring that to people but more than that we want this to be the easiest way even easier the client-side and we want someone to get a pick this up to build these applications do more much easier and that's really the focus of 1 so hopefully be out later this year we'll see we're not really putting a date on we love your help and they said there's a small community around us really passionate about this project that you kind of have to be to work on it for 5 years and I love the layout and this way you can read more about Akilia website packet word with God guides and documentation and you can build a real-time chat up and I will say 5 minutes but half an hour so fair so then we walk you through entity that employs a rope you Our run get out it was a star I'll follow along the development there are open issue that packets leftback l i and on that note added wenigen that we started doing this thing with the or issues we label some of them as starter issues so really interested in pulling people from the community and and some of these because PacBio has such a weird approach to things I when when or start and have the confidence to begin so we went on and said OK yes this it's like 2 hours or less of context building we promise you get a complete this word and so if you wanna find a place to dump look for starters you you can follow PAC our pack you can follow me and I love this talk more about this this is something that I would love to talk thank you very much you and you might be better than the my
Softwarewartung
Mapping <Computergraphik>
Weg <Topologie>
Bit
Twitter <Softwareplattform>
App <Programm>
Program Slicing
Äußere Algebra eines Moduls
Gebäude <Mathematik>
Projektive Ebene
Echtzeitsystem
Framework <Informatik>
Computeranimation
Benutzerbeteiligung
Subtraktion
Framework <Informatik>
Gebäude <Mathematik>
Kartesische Koordinaten
Framework <Informatik>
Quick-Sort
Computeranimation
Server
Umsetzung <Informatik>
Bit
Total <Mathematik>
Web log
App <Programm>
Browser
Mathematisierung
Zahlenbereich
Kartesische Koordinaten
Framework <Informatik>
Synchronisierung
Computeranimation
Homepage
Client
Rendering
Endogene Variable
Softwareentwickler
Demo <Programm>
Inklusion <Mathematik>
Softwareentwickler
Wald <Graphentheorie>
Sichtenkonzept
Synchronisierung
Datenhaltung
Mailing-Liste
Software
Rechter Winkel
Server
Dateiformat
Bildschirmsymbol
Computerarchitektur
Message-Passing
Softwaretest
Softwareentwickler
Bit
Statistik
Sichtenkonzept
Klasse <Mathematik>
Mathematisierung
Systemaufruf
Fokalpunkt
Code
Computeranimation
Software
Client
Echtzeitsystem
Rendering
Prozess <Informatik>
Endogene Variable
Zusammenhängender Graph
Gerade
Aggregatzustand
Touchscreen
Einfach zusammenhängender Raum
Softwareentwickler
Statistik
Browser
Mathematisierung
Klasse <Mathematik>
Systemaufruf
Synchronisierung
Framework <Informatik>
Computeranimation
Homepage
Software
Client
Prozess <Informatik>
Endogene Variable
Skript <Programm>
Programmierumgebung
Touchscreen
Bit
Prozess <Physik>
Zahlenbereich
Schreiben <Datenverarbeitung>
EDV-Beratung
Implementierung
Kartesische Koordinaten
Transformation <Mathematik>
Code
Computeranimation
Knotenmenge
Client
Prozess <Informatik>
Volumenvisualisierung
Skript <Programm>
Softwareentwickler
Phasenumwandlung
Bildgebendes Verfahren
App <Programm>
Kontextbezogenes System
Quick-Sort
Konfiguration <Informatik>
Texteditor
Mereologie
Server
Aggregatzustand
Soundverarbeitung
Nichtlinearer Operator
Sichtenkonzept
Prozess <Physik>
Benutzeroberfläche
Punkt
Gebäude <Mathematik>
Kartesische Koordinaten
Benutzerfreundlichkeit
Kontextbezogenes System
Sichtenkonzept
Framework <Informatik>
Quick-Sort
Computeranimation
Rohdaten
Rechter Winkel
Mereologie
Projektive Ebene
Softwareentwickler
Prototyping
Prototyping
Resultante
Versicherungsmathematiker
Impuls
Bit
Punkt
Web log
Browser
Web-Applikation
Kartesische Koordinaten
Computeranimation
Formale Semantik
Client
Code
Mustersprache
Minimum
Volumenvisualisierung
Prototyping
Sichtenkonzept
Template
Gebäude <Mathematik>
Volumenvisualisierung
Strömungsrichtung
Wiederkehrender Zustand
Kontextbezogenes System
Rendering
Arithmetisches Mittel
Menge
Datenstruktur
Rechter Winkel
Server
Aggregatzustand
Mathematische Logik
Mathematisierung
Transformation <Mathematik>
Kombinatorische Gruppentheorie
Mathematische Logik
Code
Framework <Informatik>
Knotenmenge
Benutzerbeteiligung
Rendering
Hash-Algorithmus
Datentyp
Datenstruktur
Attributierte Grammatik
Matching <Graphentheorie>
Einfache Genauigkeit
Physikalisches System
Sichtenkonzept
Quick-Sort
Objekt <Kategorie>
Mereologie
Wort <Informatik>
Server
Punkt
Web log
Browser
Gruppenoperation
Klasse <Mathematik>
Iteration
Implementierung
Diskrete Gruppe
Transformation <Mathematik>
Kombinatorische Gruppentheorie
Mathematische Logik
Framework <Informatik>
Code
Computeranimation
Client
Negative Zahl
Unterring
Rendering
Front-End <Software>
Mustersprache
Endogene Variable
Programmbibliothek
Zusammenhängender Graph
Integraloperator
Hybridrechner
Datenstruktur
Bildgebendes Verfahren
Phasenumwandlung
Lineares Funktional
Sichtenkonzept
Transformation <Mathematik>
Template
Sichtenkonzept
Quick-Sort
Objekt <Kategorie>
Echtzeitsystem
Framework <Informatik>
Menge
Twitter <Softwareplattform>
Rechter Winkel
Mereologie
Client
Server
Kantenfärbung
Instantiierung
Aggregatzustand
Demo <Programm>
Punkt
Prozess <Physik>
Web log
Browser
Applet
Formale Sprache
Kartesische Koordinaten
Echtzeitsystem
Komplex <Algebra>
Computeranimation
Homepage
Skeleton <Programmierung>
Client
Prozess <Informatik>
Mustersprache
Stützpunkt <Mathematik>
Skript <Programm>
Phasenumwandlung
App <Programm>
Befehl <Informatik>
Vervollständigung <Mathematik>
Sichtenkonzept
Güte der Anpassung
Reihe
Kontextbezogenes System
Bitrate
Konfiguration <Informatik>
Arithmetisches Mittel
Hyperlink
Rechter Winkel
Server
Projektive Ebene
Aggregatzustand
App <Programm>
Mathematisierung
Unrundheit
Framework <Informatik>
Hydrostatik
Informationsmodellierung
Benutzerbeteiligung
Flächentheorie
Migration <Informatik>
Endogene Variable
Softwareentwickler
Einfache Genauigkeit
Elektronische Publikation
Quick-Sort
Echtzeitsystem
Web Site
Browser
Gebäude <Mathematik>
Kartesische Koordinaten
Kontextbezogenes System
Biprodukt
Fokalpunkt
Computeranimation
Client
Bereichsschätzung
Grundsätze ordnungsmäßiger Datenverarbeitung
Server
Projektive Ebene
Speicherabzug
Wort <Informatik>
Elektronischer Programmführer
Softwareentwickler
Maschinelles Sehen
Hilfesystem

Metadaten

Formale Metadaten

Titel Build Realtime Apps with Ruby & Pakyow
Serientitel RailsConf 2016
Teil 23
Anzahl der Teile 89
Autor Powell, Bryan
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/31499
Herausgeber Confreaks, LLC
Erscheinungsjahr 2016
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Client-side frameworks dominate the conversation about the future of web apps. Where does that leave us Ruby developers? Let's explore a way to build realtime apps driven by a traditional backend, without writing a single line of JavaScript! You’ll walk away with a new way to build modern, realtime apps employing client-side patterns.

Ähnliche Filme

Loading...