Frameworks to the rescue Normally if faced with these problems people say: don't reinvent the wheel, let's look what's already out there, let's use some framework (or some libraries), or if you have a bad case of the not-invented-here syndrom in your company, you are going to develop your own
webserver HTML browser JS so the normal flow of a web application is that some server code serves some html (and maybe some apis) to the browser, in the browser there is some (or a lot of) javascript that manipulates the DOM
webserver HTML browser JS Ajax and either links to other pages served by the server or does ajax requests back to the server. this concept is mostly true for either traditional apps as well as single page applications
duplication de duplication ode duplication code duplication code duplication code duplication code duplication code duplication code duplication code duplication code duplication code duplication code duplication code duplication code duplicatio code duplicat code duplic code dup code du code cod co co which leads to lot of code duplication in templates, validation logic, models and lots of boiler plate code for communication between server and client, marshalling data
ResearchGate gives science back to the people who make it happen. We help researchers build reputation and accelerate scientific progress. On their terms. ‟ the goal is to give...
Meteor http://www.meteor.com or meteor, that try to bridge the gap between server and client. but they are still very alpha, good for prototyping, writing small apps, trying things out, but personally I wouldn't create a big million lines of code web application with 40+ developers yet
Incremental Refactoring the way to make the architecture of your existing application better and connect your backend with your frontend code is incremental refactoring, since you hopefully can't afford to sit down, stop development for 6 months and rewrite everything
http://www.youtube.com/watch?v=fqULJBBEVQE what's interesting about all these approaches and with all these totally different applications and totally different use cases and totally different technologies, that the underlying concepts people come up with are strikingly similar. basically it's thinking about your app in small components, that are as independent as possible. this may even make it directly into browsers: if you haven't heard about it yet, check out the proposed web components standard.
on the frontend yui3, but every page was built with custom modules, not much reuse of existing modules but very basic ones (also some legacy pages with yui2, prototype.js and scriptaculous)
Server JS Browser JSON HTML HTML so it should have it's own url, and for seo reasons can just be included in a page rendered to a browser by the server or can be fetched separately or nested within other components by the apps javascript, where we only wanted to transport the data to the client and render it into html there
Share code between server and client and we wanted to share as much code between server and client as possible (considering our heterogeneous architectur, js client, php server)
PHP Controller Mustache Template JavaScript view class Widget Providing data Handling browser events Displaying data so to sum it up an widget contains
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu we see, that it's actually kind of a tree structure, for the sake of this presentation i simplified it slightly, actually our profile consists of over 200 components
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu Server Request Response i said earlier, that all these components have their own URL. So they can be requested and rendered by the client seperately. For better user experience on the first load or SEO reasons these components can also be bundled together and rendered in a single page load on the backend.
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu that means the profile widget requires: publications, aboutMe, leftColumn and institution
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu and Publications requires several publicationItem widgets and leftColumn the Image and the Menu widget
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu Account Account Account Account Account Publication1 Publication2 Publication3 if we take our simplified example, a lot of components need the account of the user that's displayed, while that could be solved with in memory caching, a list of publications each need the publication entity, if we display 20 publications, that would mean 20 database queries, doing it in one query would be much faster though, and you have lot's of stuff like this
Require stuff so instead of fetching stuff directly, it's way better to require stuff (that's also why building up the widget tree was done with widget "requirements"
http://www.infoq.com/presentations/Evolution-of-Code- Design-at-Facebook/ this concept is actually not that new, one small company who is doing this very much is for example facebook, who also did a very good talk about this a few years back
Widget Widget Widget Widget Preparer Fetch Requirements Resolver Resolver Services Connector Interfaces Connector Implementations the preparer iterates over all components and fetches their requirments
Widget Widget Widget Widget Preparer Resolver Resolver Services Connector Interfaces Connector Implementations Batch requirements and pass them to resolvers it batches them together as intelligently as possible, passes the requirements to resolvers
Widget Widget Widget Widget Preparer Resolver Resolver Services Connector Interfaces Connector Implementations Call Services as effective as possible (Multi-GET,...) which call the services/storages/etc as effective as possible, or just execute some service class methods
Widget Widget Widget Widget Preparer Resolver Resolver Services Connector Interfaces Connector Implementations Attach fetched data to Requirements and pass them back to the preparer the fetched data is attached to the requirements, passed back to the preparer
Widget Widget Widget Widget Preparer Resolver Resolver Services Connector Interfaces Connector Implementations Distribute fetched data to the widgets that required it who in turn distributes the fetched data to the components
Required / Optional requirements can be required or optional, meaning either it's ok if a call fails or not (important for error handling). if it's not ok we just deactivate the whole component
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu CALLBACK CALLBACK CALLBACK so in the first iteration the profile widget returns its requirements as well as a callback function that should be executed once all the requirements have been fullfilled
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu CALLBACK CALLBACK CALLBACK after the first iteration this callback is then executed while collecting all the requirements of the new subwidgets. the callback can then return further requirments as well as also further callbacks
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu CALLBACK CALLBACK CALLBACK and so on, this iterative process is done as long as there are components or callbacks available that return new requirements
public function collect() { yield array( new EntityRequirement( 'account', Account::class, array('accountId' => $this->requestContext->getAccountId()) ), ); yield array( new ServiceRequirement( 'scienceDisciplines', AccountService::class, 'getScienceDisciplines', array('account' => $this->account) ) ); } because then you can write it like this:
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu e.g. for a list of publications that you got from a solr search, you may not want to go to the database again to fetch each publication in each list item, but since a list item is supposed to be renderable separately as well, it needs this logic in there
that means if the subwidget has a requirment like this, the preparer would directly put the prefilled data in there instead of passing it on to the resolvers
Whoa, this looks awfully complicated to debug you're right, it takes a bit of time to get used to program this way, but everyone who joined our company in the last few months since we are doing it says after a week or so, that they actually can't imagine working any other way again (i'll talk more about the benefits later)
but still it's complex, so a good thing is taking a bit of effort to make it as transparent as possible to see what happens in your application (which is a very good thing anyways). we have a debug toolbar that shows all the component on the page
Helper Methods there is also a php implementation of mustache, but it's not the fastest and one thing is, that mustache oftentimes relies on small helper functions
•nl2br •truncate •pluralize •wordwrap •highlight •... like ... if you now use a php implementation on the server and a js implementation on the client, we have to develop these functions twice ... not a good idea
http://pecl.php.net/package/v8js V8js that why we actually execute javascript through a php extension that makes the v8 js library available on the server. so we are executing the same code on the server and on the client to render the same templates. suprise: it's acutally really really fast
JavaScript so we handled templates and rendering, the backend controllers that provide the data, on the javascript side in the client each component can have a view object to bind on DOM events
http://www.youtube.com/watch?v=fqULJBBEVQE .. this is exactly what web components is about. they have their own html, css, js and are even more sandboxed through a shadow dom to limit interactions between different components. an example for webcomponents are the browser controls for videos or forms by the way.
Easier Refactoring even if the implementation of one component is very ugly and crude, at least it's encapsulated (hopefully tested) and you can either leave it or revisit this component later on
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu EXCEPTION if an exception occurs in one of our components while fulfilling a requirement that is not optional
Profile Publications Publication Publication Publication LeftColumn Image Instiution Menu we just deactivate this component and the rest of the page is still functional
we are doing this excessively, and have over 90 or so experiments with sometimes over 20 variants running. the way we can do this quickly and easily is by just switching components for the different variants
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu
because every component has it's own url you can just render out a esi placeholder instead of the widget to tell varnish to fetch it separately and provided it has caching headers, get it out of the cache
Profile Publications Publication Publication Publication AboutMe LeftColumn Image Instiution Menu
loadWidget('/aboutMe', function(w) {<br/>w.render({ replace : '#placeholder' });<br/>}) so instead of rendering the widget you render a placeholder dom element and a script tag that loads the widget with an ajax request and then renders it on the client side
so our http request looks like this, first you compute and render the important parts of the page, like the top menu and the profile header as well as the rest of the layout, for the left column and right column which are expensive to compute you just render placeholders and then flush the content to the client so that the browser already renders this
still in the same http request you render out the javascript needed to make the already rendered components work, so people can use the menu for example
still in the same http request you then compute the data for the left column and render out some javascript that takes this data and renders it into the components template client side and then replaces the placeholder with the rendered template
still in the same request you then can do this with the right column -> flush content as early as possible, don't wait for the whole site to be computed
pushState and if you are at that, when you switch pages, you can also just load the differences between and use pushState to change the url (if supported) to make your app faster
http://twitter.com/BastianHofmann http://lanyrd.com/people/BastianHofmann http://speakerdeck.com/u/bastianhofmann [email protected] thanks, you can contact me on any of these platforms or via mail.
bastianhofmann
mackee
yutootsuka
ruyadorno
m_seki
fendo181
y0gi
77web
en2zo
haman29
mitchan
takahirom
usualoma
nonsquared
sugarenia
zakiyama
holman
vanstee
andyhume
chriscoyier
eileencodes
maltzj
iamctodd
cromwellryan