Bestand wählen
Merken

The Future of Data in Ember

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and in due the to the fact that this happened this
is the fact that the fact that you
know that the morning everyone
I'm really really excited about the conference so far I'm excited to see so many of you here after having said such an obviously good time yesterday in last night so thanks for coming out or try to make it worth your while not as you go said I've been working in the data realm for quite a while and I have also been a member of the Amber Corps for a couple years now and I'm particularly thrilled to be working more closely with the ambit dated team to help answers some of the questions about the Future of data in amber what a nebulous topic let's try to fill in this blank this is the future of data in amber web standards or perhaps is a step ahead of Web standards is a real time restful graph-based operational offline the truth is the future of data in number is what you needed to be a we as a framework need to meet you where you are and help you get where you want to be as you can see on amber observer ecosystem already contains a number of solutions that answer 1 or more of these needs independently and this morning to
make sure we're all the way started off with a little demo in build Baristas and neither my PM has made the requirement that this must fetch and display data about seeing a favorite embarassed it's sounds pretty straightforward on the server side will need a couple endpoints also very straightforward Let's start with the most straightforward client-side solution but used pure fetch J. signed and work with Kojo's on a client side so
in our context around or Baristas rout perhaps the model the model hook it performs a fetch at the V-1 endpoint forgetting the and then returns that responses as a the 1st case of so let's see what we've
built here just very straightforward master-detail read only application time so far only web standards of the news proconsul we kept it
is simple and uncomplicated as possible so a new requirement is come that's gonna put us to the text breezes must now work offline was just double check that it
doesn't we know switch off a network and yet there's a downer source so yet we're out of luck we have some work to do the answer it is
also a web standard service workers we are on the
cusp of day that many of us have waited for a long time for in which service workers are supported across all the Evergreen browsers desktop and mobile and were
lucky tried to have good folks like Martin Châu from dockyard whose FIL some add-ons focused on a implementing Service Workers as easily as possible so we're going to
install those add-ons in our emperor going to do a little minimal
configuration I am we need to specify the static assets that will be cashed in the service worker layer service worker acts as a proxy between the application and the network layer and it can do caching the it can do it can do cash cash-first some cash fulfillment of requests or it can attempt to perform a fetching then and then only fall back to the cash if if needed if that fails so here were pointing Our fullback to watch the requests that go out to the API the 1 and points and to Cashel so now with that minimal
configuration we are back on line go back we go offline we refresh data is still there despite the network not so we got in all this way with pure Web standards with know formal data like of course were not done next is
a requirement to Ad advantageous to edit embarassed doesn't need to work offline this is the admin area but it seems like it might be used mostly on the desktop so we are going to need some new server points so we're creating of the 2 API with some new points to do basic CRUD and were going to upgrade hard data layer from pure Web standards to use amber data we're going to
introduce a model and in outs were going to access this EMBA data store that's the injected into over rats and we're going to in this case we're going to find all that the context all the instances of the model so
does a lot more than that but it's pretty basic pride and follows the same guidelines you see on the it in the ambit guide so I I won't go in in depth into the implementation but basically we now can you in the art pleased as we can edit them we can we can do any cried operation we can delete them I felt only right deleting myself and I and we can even welcome on the newest member of our family Melanie some and there she has the story doesn't end there
it turns out on the our project manager is seeing a real call for using our app which is of course looming in in popularity of cereal or a real an increase in their request to to users on the train and people networks are a little flaky and so those advantageous at work required work offline now now she wants us to work off on so we can use the same RESTful endpoints that we implemented already and now we're going to introduce a new a data layer were and which is accessible
from I fought for the Amber world to the amber add-on amber orbit so let's just take a look at the end result so we're going to you can see the the orbit lost in the consul were now offline we're adding a couple more of our favorite memories this by the time Mr. and you see the network requests failing in the log because it's offline but orbit is keeping them queued up and retrying at that network this network requests until you go back we go back online and they get 1st through the cues get emptied and we refresh and zillion times still there so we were able to seamlessly right through that network outage I mean even if we opened our eyes are Apple when it was off line so that's that's another level of working offline no need none of these
steps that we've gone through has come cheaply take a firm me the guy who feels that cost very viscerally when he decides to put together not just 1 but 3 demos UNL on the day before his talk so and every upgrade I felt like a rewrite of of the whole data light look at the additions required to implement or better an amber orbit in our application we needed to add data buckets to catch application state we needed add data sources to to store our data in index dB when i in case the in case of browser gets closed and we reopen it we don't wanna lose data that's in flight or chewed up really we also need strategies implemented I'm going to go into some of these details about about orbit later in this but the point is that we've
in in the reasonable costs of developing a single Member application we build 3 pretty independent data like there's no each 1 of them worked but the upgrade cost were pretty high because they're pretty independent how do we allow access to evolve with less friction do we want to blur the boundaries between Our data layers our our data solutions or maybe the shape of a solution is less of a Venn diagram and more linear in which we add capabilities and accept a proportional complexity cost there should be an easy on-ramp heavily based in standards where possible as an application it needs more complexity it can incrementally augmented capabilities and applications only needed to accept the cost of the complexity that they truly need every augmentation should require little to no additional configuration and what's
more important functional layer should be delineated well enough to allow it to be replaced by compatible layers know this sounds pretty abstract
so let's make it more real with a case study has started 5 years ago Tm 2013 meant a lot to me it was the very 1st time I give a conference talk and it was also the very 1st time I met in person a lot of the for the the people who have become my friends working working in the early days of Amber it was it was pretty fun to watch you who dead channel Johnny I this like keynote and at the same time others says channel they're up there in years spice girl and
I mustard my courage to give this talk OptimaX an API for amber data it was very much about convention over configuration a quarter value of the rails and number the talk focused on a
backhanded will library active model serializes fulfilling the data needs of a front end member data with the rest adapter what it turned out to be was actually not just 1 contractor but a bunch of micro contracts know is OK because those contracts were evolving they we'd we'd say OK well this is how we're going to post records OK well we can tweak the server-side world or word this is you know this is the represent the record the document structure were going to use OK well we can tweak amber data's rested well obviously that was but a bit little fragile in in in the long run and not not very not a long-term solution but it was a necessary step because it allowed us to to actually let a good solution comes through and pit took quite a while from that beginning solution to you who does the 1st draft of the j sunny API in 2013 2 versions whining of J son API in 2015
API provided a single contract between the back end in the front and it defines the document structure the protocol usage at the API layer it unlocked flexibility he didn't to use AMS on the back and maybe you your a job a shop or maybe you had a preferred rails lived sign API resources the new adapter showed up in number data Jason API adaptive which was tailored to J. sign API which was different from the original rested after similarly orbit can work with J. Sinai P. with the adjacent API source that's what were but calls Our data sources netflix just put out fast son API of serialized that could also work basically both ends swappable there are now over 50 server libraries and 50 client libraries written in 14 languages on each and implementing J. son API I don't guarantee that the all as as good as 1 at 1 or the other but obviously they were all written by people who had particular needs had particular itches to scratch and they're all based around a single spec and you can review them and use an API that word and you can choose your particular client and the language and framework conserver language and framework can pick 1 that's right for you so what's the secret sauce It's composable well-defined interfaces the sun API defines a document structure protocol usage complying with its http we went
from the AMS ember dataset monolithic full-stack solution in which at the back end in front end were tightly bound with all those micro contracts to a single point of connection the do sunny guessed and that provided a new degree of freedom which are not interchangeable components so how is G sunday PID 1 hour incremental adoption scale at its most basic following only the must back to sign API specifies a very simple itchy compliant RESTful API with a slightly opinionated document structure you can start with the most basic credit implementation but as you move up a level you may adopt advanced concerns such as compound documents hypermedia links filtering sparse fields that some more there's another layer were building on top of that version 1 comma decimal 1 should come out this year and will include concepts of operations which allow multiple single requests in the base factor to be serialized together and performed together transactional only which unlocks creating multiple related resources together local identities local to the document can bind those Resources together so you'll be able to create a graph of data in a single request and it will succeed or fail I'm pretty excited about this it's been it's been a long time coming so let's talk about every
data how can we have a lot of sense from the sun API to somebody 1st of all what it
wanted somebody to I think a good goal as for it to serve their needs of over 80 per cent of member applications and as needs shipped amber data should the ball to align with those needs this is because the evergreen relationship goal here and and how can it do that it can use the same secret sauce that do son API doses compose ability extensibility unlocked by well-defined interfaces in fact it already has some well-defined interfaces and degrees of freedom the store can be connected to an adapter and serialize here
and just like the sun API has of the breath of implementations and its ecosystem if you look at amber observer you can see that Member data also of has many implementations that serve many different needs at the adapter insulated layer 1 issue that the team is actively addressing is the tight coupling that currently exist between the store and the model there's a lot of internal private code which unfortunately for out of necessity has become semi-private CoA in intimate code and the add-ons add-ons relying on us and no and so we've got a bit of so we've got a bit of a bind there because a lot of add-ons need that functionality that can only be accessed by you through those intimidate the eyes that exist between the store and the model of and we need to give we provide a way for those add-ons to evolve so that's where the gauze record data RFC comes in the record data interface formalize the interface between the store in the mall in allow add-ons to deal with that that well-defined interface and by defining that new interface we can unlock experimentation perhaps member
data models are a little heavyweight for your application maybe there's a of memory cost and you want me to be fined using Kojo's Joe's maybe a mutable data structures could add some real benefits tear at Lake allowing for cheap store for working we can implement static analysis at the model layer to generate a schema we or go the other way with schema was models there's a lot of experimentation that work we can unlock that we can unlock in a forward-looking way that can be maintained and advanced deprecated in the same way were all used so let's look at Brigade is
incremental adoption of capabilities scale right now the very core of amber data still relies on a store models basic crowd we're looking at potentially shrinking that even further perhaps there is in between path between our web standards example which relied on fetch in a full-blown number date example where we recognize the value of an identity map of sharing a single canonical record across an application it's especially important when you're using when you mutating data so so if we at least provided a store to those applications it might provide a little a better on-ramp to go from strength fetch with Kojo's to the using of full-blown member data with adapters and serializes and everything that comes along with it so that's that's a bit of a of a question mark exactly where those lines will be drawn with this is all about the future and experimentation so at the next layer of our capabilities it's with somebody it it's typically of the domain of Adams partial records embedded records change that's that's a lot of interesting experimentation going on already in the amber data ecosystem and perhaps just
like the sun API has an next level perhaps ember data also has an act of war and that's really what I'd been exploring for the last few years with my work on orbit or it was the 3rd example in our Brees's of app is a data access
and synchronization library it aims to be the universal data layer it's seeing adoption across of a number of frameworks in back back and but mostly front-end It's written in TypeScript but of course chips the plane a job description is fully compatible with than flavor JavaScript so why why did I work on or what what were the use cases of were driving by a wide and I tried it unlocking those use cases directly in number data while they they were it was it's a real challenge and some of them involve some new primitives so let's take a look at what those use cases are what we've
seen already is just 1 the offline case in an increasingly connected mobile world offline is critical 4 web applications pw ways to compete with native on the other end orbit on allows for very a very simple the model where you have a single source and can work without a back you can also connect multiple sources that shared the same interface and swap one out for another for example if you're using a in that needs to store application state in the browser storage you're and you're you're you're not sure at the browser supports look of index the you could provide a fallback to local storage and you could swap them out at runtime 1 of the main challenges it's been so hard to get right is data synchronization increasingly applications are not just 1 or the other type they're not just dealing with 1 1 type of real so real time were RESTful or you know from multiple services that they needed make sense of that data synchronizer and presented to the user and that you be a really hard problem also I found that creating forms and editing structures that you can reason about easily it has been a challenge and just providing strict isolation between and that's between the canonical data in the store and an edited data seeing critical so what I wanted to be a bold to allow for complex and it's that could be committed in a single transaction were thrown away and a forgetting that deterministic about tracking are changes then that unlocks things like undue and redo and really optimistic view I is just another another term for offline it's another way of thinking about offline you can provide some benefits when you're online by not waiting for the request response cycle the show that actions of happened and so this doesn't apply for all types of data if you're going to process an invoices something you probably wanna wait for that request response cycle but there are times when when you can be optimistic like say you're making and to retirement tree or something like that that doesn't need to wait it's probably just going to exist in in in your browser until until you of loaded I won't get to in depth with were a bit but the basics are that it considers all
sources of data with with with a a base class a single interface with with specialized interfaces implemented on top of that it synchronizes normalize data between sources and provides flow control so that you can have the actions of block that depend upon other actions completing and this is all enabled through events an event handlers listening and and returning promises if they wanna block and the orbit store
uses a cash that's modeled on the that that tracks changes like get it tracks inverse changes and can be of basically rollback any changes or reset can for work fork stores create branches throw away those those branches and this is unlocked through the use of immutable data structures under the hood so
let's take take a look at hi you might incrementally access orbits capabilities it start very simply with a single source in the schema some their minimum then you could then like a memory memory sources store that you could query next level you might wanna connect multiple sources with coordination strategies state buckets stay pockets are important to maintain each source can I can use a state bucket to maintain everything that is in in memory application state that it should be persisted to I you know so that if the brown if your browser goes down unexpectedly all those cues all those logs state will be about revived rehydrated when it comes back and then
at like the last frontier part of people who are using orbit to create custom sources in particular to their own types of data on you can create new query ops visage generalized query and update language which are which could be adapted to support any type of operation like we're like orbit could eventually support our graph ql well for instance as as an operation tight in it in queries were graph all mutation so it's pretty general purpose it's certainly not specific to do sunny PI C orbit fitting
in with samba data was as we've as we've already seen with somebody This incremental scale there's a big
question mark I think a lot of question marks at that operate you know what where does it go what's next I C X a lot of issues opened in the member data are of season and the repo about you know pushing advanced capabilities and I'm hopeful that those advanced capabilities that we all need as a community line up with a lot of what were but provides so I
think you could consider this analogy that were written December data as glamor is to Amber and this makes a whole lot more sense when you look at the locus so this works in a couple ways and the data can provide orbits capabilities in a convention driven packed remember all those configuration files I had to add to that were being asked to make it all work were a convention here over configuration community we can apply the same strategies that at the data layer and unlocked advanced features for all of us without a lot of sweat in another way that orbit is like a glimmer were glimmer JSC might say is that orbit and its ecosystem can provide a laboratory for experimentation in the same way that we sanded down a lot of the rough spots on glimmer components before they landed in number so we have now reached the part of this talk that all regret every prediction so far has been a carefully extrapolated hedge that I feel quite confident about but to give a talk with the future in the title without going out on a limb might be deeply unsatisfying like but pushing out a major release to a framework without any new features it at all all of this anyway here goes nothing and put to get my crystal ball and saying that yes graph QL is under something graph kill usage will continue to grow and Apollo will continue to innovate and there's a lot of interesting things happening there rest plus solutions like J. sunny API at 1 point 1 will also grow they also provide graph about Us graphical structures of abuse into data they also provide with 2 operations in alternative to graph your mutations and that operations primitive will be adopted across the stack not just on the client side flowing through to the server and static analysis will be key in all of our work not just the at the data layer but also in in the broader framework to prove runtime efficiency and from my experience with a mutable data structures we can get most of the power of most of the positives from them with our the pain points by keeping their usage internal and fairly isolated from the application layer so that they're used under the hood so that you can fork a store with 10 thousand records and it's like copying a reference were too that that there's a lot of power they're but we don't wanna use custom accessories to access every single every so single piece of data in in a in this directly in the structures I I strongly believe with the with the advent of service workers in all our Evergreen browsers demand for offline pw ways will really grow and web apps will truly compete with native apps on so many fronts and this is the be wishful thinking but since I have a crystal ball out I really I really have seeing a lot of excitement from different communities about orbits so it's clearly meeting in the that others others are not providing so again I will go out on a limb and and and put hope that that and continues but put the crystal ball away though and provides an guarantees of all say that we need to make it a goal that you should yield incrementally adopt new capabilities in your application as you need them should build a start primitives with the with standards as as little as possible add capabilities except complexity costs only as needed and only venture into the red zone when you really need to know and you're doing something really advanced but
hopefully each step of the web is unlocked by little the no configuration and strong
boundaries between these functional layers which allows for swapping a new solutions can be generated
so in closing I'm not only partially excited about what's going on in data I'm the I'm thrilled to see what's going on across the ecosystem I think that he note yesterday this laid it out so well and if feel like this year is a great year for all of us to reach out and share what's going on in the embryo ecosystem with the broader JavaScript community as were as applications as our framework has modernized and is 2nd to none our performance stands toe-to-toe with free act our conventions are as well thought out as any I'd love to see where folks sharing their experiences with each other at Ember meetups at conferences like this but also have broader JavaScript conferences because I think there's a lot of good stuff to share and I think it goes both ways and we can we can all learn and learn from each other it's a it's a great Amber's part of a larger ecosystem and it's it's really great so so please please get out there and and spread the good word and let's build great things together thanks but the
this and so the fact
that and this is the fact
that in fact the
the new the the fact
and the and the
and that the fact
Videokonferenz
Nichtlinearer Operator
Benutzerbeteiligung
Echtzeitsystem
Standardabweichung
Güte der Anpassung
Binder <Informatik>
Luenberger-Beobachter
Zahlenbereich
Framework <Informatik>
Standardabweichung
Informationsmodellierung
Client
Demo <Programm>
Einheit <Mathematik>
Hook <Programmierung>
Endogene Variable
Gebäude <Mathematik>
Server
Routing
Kontextbezogenes System
Endogene Variable
Datensichtgerät
Benutzerbeteiligung
Kartesische Koordinaten
Standardabweichung
Dienst <Informatik>
Benutzerbeteiligung
Datennetz
Browser
Mobiles Internet
Browser
Bootstrap-Aggregation
Dienst <Informatik>
Quellcode
Lie-Gruppe
Benutzerführung
Standardabweichung
Caching
Proxy Server
Punkt
Datennetz
Installation <Informatik>
Default
Güte der Anpassung
Indexberechnung
Kartesische Koordinaten
Dienst <Informatik>
Mustersprache
Dienst <Informatik>
Faser <Mathematik>
Versionsverwaltung
Konfigurationsraum
NP-hartes Problem
Benutzerbeteiligung
Punkt
Flächeninhalt
Datennetz
Server
Formale Grammatik
Patch <Software>
Konfigurationsraum
Gerade
Homepage
Standardabweichung
Nichtlinearer Operator
Stellenring
Informationsmodellierung
Datenmodell
Familie <Mathematik>
Implementierung
Elektronischer Programmführer
E-Mail
Speicher <Informatik>
Kontextbezogenes System
Instantiierung
Resultante
App <Programm>
Datenmanagement
Wellenpaket
Datennetz
Festspeicher
Orbit <Mathematik>
Systemaufruf
Projektive Ebene
Patch <Software>
Gerade
Übergang
Retrievalsprache
Addition
Shape <Informatik>
Demo <Programm>
Punkt
Stochastische Abhängigkeit
Browser
Reibungskraft
Orbit <Mathematik>
Einfache Genauigkeit
Kartesische Koordinaten
Euler-Diagramm
Quellcode
Datensicherung
Komplex <Algebra>
Quellcode
Randwert
Erweiterte Realität <Informatik>
Orbit <Mathematik>
Automatische Indexierung
Strategisches Spiel
Modelltheorie
Ereignishorizont
Konfigurationsraum
Standardabweichung
Aggregatzustand
Beobachtungsstudie
Konfigurationsraum
Datenmodell
Versionsverwaltung
Zahlenbereich
Design by Contract
Informationsmodellierung
Datensatz
RFID
Debugging
Programmbibliothek
Wort <Informatik>
Datenstruktur
Konfigurationsraum
Punkt
Formale Sprache
Versionsverwaltung
HIP <Kommunikationsprotokoll>
Übergang
Client
Prozess <Informatik>
Vorzeichen <Mathematik>
Nichtunterscheidbarkeit
Protokoll <Datenverarbeitungssystem>
Schnittstelle
Schnelltaste
Nichtlinearer Operator
Zentrische Streckung
REST <Informatik>
Digitalfilter
Quellcode
Marketinginformationssystem
Teilbarkeit
Datenfeld
Orbit <Mathematik>
Datenstruktur
Verschlingung
Server
Client
Schnittstelle
Server
Zahlenbereich
Implementierung
Identitätsverwaltung
Framework <Informatik>
Hypermedia
Freiheitsgrad
Hauptidealring
Front-End <Software>
Programmbibliothek
Zusammenhängender Graph
Operations Research
Datenstruktur
Inklusion <Mathematik>
American Mathematical Society
Implementierung
Einfach zusammenhängender Raum
Protokoll <Datenverarbeitungssystem>
Graph
Orbit <Mathematik>
Datenmodell
Einfache Genauigkeit
Binder <Informatik>
Menge
Design by Contract
Hypermedia
Debugging
Wort <Informatik>
Energieerhaltung
Freiheitsgrad
Kartesische Koordinaten
Maßerweiterung
Speicher <Informatik>
Schnittstelle
Hydrostatik
Schnittstelle
Lineares Funktional
Schnelltaste
Bit
Datenmodell
Implementierung
Kartesische Koordinaten
Analysis
Code
Datensatz
Modallogik
Informationsmodellierung
Datensatz
Datenfeld
Datenstruktur
Festspeicher
Luenberger-Beobachter
Modelltheorie
Datenstruktur
Speicher <Informatik>
Analysis
Schnittstelle
App <Programm>
Zentrische Streckung
Bit
Mathematisierung
Orbit <Mathematik>
Zahlenbereich
Kartesische Koordinaten
Partielle Differentiation
Menge
Übergang
Mapping <Computergraphik>
Informationsmodellierung
Domain-Name
Benutzerbeteiligung
Datensatz
Anpassung <Mathematik>
Nichtunterscheidbarkeit
Speicherabzug
Serielle Schnittstelle
Modelltheorie
Speicher <Informatik>
Gerade
Standardabweichung
Ebene
Bit
Browser
Mathematisierung
Gruppenoperation
Web-Applikation
Zahlenbereich
Kartesische Koordinaten
Term
Synchronisierung
Framework <Informatik>
Netzwerktopologie
Quellcode
Deskriptive Statistik
Informationsmodellierung
Bildschirmmaske
Prozess <Informatik>
Datentyp
Endogene Variable
Programmbibliothek
Primitive <Informatik>
Datenstruktur
Speicher <Informatik>
Grundraum
Schnittstelle
Einfach zusammenhängender Raum
Sichtenkonzept
Synchronisierung
Mobiles Internet
Orbit <Mathematik>
Rechenzeit
Quellcode
Transaktionsverwaltung
Dienst <Informatik>
Echtzeitsystem
Automatische Indexierung
Dreiecksfreier Graph
Client
Aggregatzustand
Objektverfolgung
Kontrollstruktur
Zurücksetzung <Transaktion>
Mathematisierung
Gruppenoperation
Orbit <Mathematik>
Verzweigendes Programm
Mathematisierung
Quellcode
p-Block
Datenfluss
Ereignishorizont
Quellcode
Vererbungshierarchie
Gamecontroller
Datenfluss
Datenstruktur
Speicher <Informatik>
Normalvektor
Schnittstelle
Einfach zusammenhängender Raum
Retrievalsprache
Nichtlinearer Operator
Graph
Extrempunkt
Browser
Formale Sprache
Orbit <Mathematik>
Abfrage
Kartesische Koordinaten
Quellcode
Login
Übergang
Quellcode
Open Source
Multiplikation
Festspeicher
Mereologie
Datentyp
Strategisches Spiel
Koordinaten
Fitnessfunktion
Aggregatzustand
Zentrische Streckung
Orbit <Mathematik>
Datenfeld
Modelltheorie
Repository <Informatik>
Gerade
Hydrostatik
Subtraktion
Punkt
Ortsoperator
App <Programm>
Browser
Web-Applikation
Primitive <Informatik>
Zahlenbereich
Kartesische Koordinaten
Komplex <Algebra>
Analysis
Service provider
Framework <Informatik>
Hydrostatik
Benutzerbeteiligung
Client
Datensatz
Prognoseverfahren
Äußere Algebra eines Moduls
Zusammenhängender Graph
Primitive <Informatik>
Speicher <Informatik>
Datenstruktur
Konfigurationsraum
Analogieschluss
Leistung <Physik>
Analysis
App <Programm>
Nichtlinearer Operator
Graph
Rechenzeit
Orbit <Mathematik>
Einfache Genauigkeit
Ausnahmebehandlung
Zeitzone
Dienst <Informatik>
Orbit <Mathematik>
Datenstruktur
Mereologie
Strategisches Spiel
Server
Standardabweichung
Randwert
Freeware
Gemeinsamer Speicher
Güte der Anpassung
Mereologie
Kartesische Koordinaten
Wort <Informatik>
Framework <Informatik>
Mittelwert
Datensatz
Datentyp
COM
Binder <Informatik>
Quadratzahl
p-Block
RSA-Verschlüsselung
Sommerzeit

Metadaten

Formale Metadaten

Titel The Future of Data in Ember
Serientitel EmberConf 2018
Autor Gebhardt, Dan
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/35701
Herausgeber Confreaks, LLC
Erscheinungsjahr 2018
Sprache Englisch
Produzent Confreaks, LLC
Produktionsjahr 2018

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract This talk will provide an overview of the latest developments in the realm of managing data in Ember applications. The focus will be the past, present, and future of Ember Data, which is becoming faster, lighter-weight, and more modular. The JSON:API specification, which provides the conventions that underpin Ember Data, is evolving through “operations” and other extensions. And new interfaces are being explored in Ember Data to allow interop with Orbit.js, which will unlock capabilities such as offline operation, store forking / merging, and more. This talk will also touch upon some popular data management solutions in the wider JavaScript ecosystem, both to show how they can be used in Ember applications and to compare and contrast them with Ember’s conventional data stack.

Ähnliche Filme

Loading...
Feedback