I'm planning to write a web app using either Backbone or Angular. We want to push "widgets" from the server to the client (i.e. semi-complicated, dynamic but largely autonomous UI elements... something maybe like the popular TodoMVC app). So we'll need to send over a template, some javascript (controllers etc.), probably CSS, and JSON data (models).
We're debating how to send over all the information. How much can be, and what should be encapsulated in the JSON?
Is it possible to create files out of data passed over? i.e. could we pull out CSS and apply the rules to our document? I believe it would be easier to run javascript passed over this way.
I'm under the impression that being able to cache the template is important... does that require loading it as a (separate) resource rather than as part of some huge JSON object?
As for CSS, it needs to be loaded before inserting into the DOM (so we don't want just a promise). Would it make sense - or even be possible - to pass our CSS rules in the JSON and extract them somehow?
EDIT: to more fully describe what I'm working with, I'm focusing only on the front-end. The back-end can be customized to send over resources however we want - they'll optimize that depending on what the front-end needs. Our backend stack includes MongoDB, Tapestry, ActiveMQ.
The payload that needs to get sent over will be all the resources necessary to push something like a Mac Dashboard Widget or Windows Gadget into the browser. So HTML, CSS, Javascript, data will all get sent over. We want things to be snappy and minimize server requests as much as possible, as some of these payloads may get to be somewhat large.
Your questions are rather vague and the answers can change by coding on a different build platform. Your chosen application design can also impact the best practices to follow for implementing X type of application to X device(s). There's more than one way to skin a cat ya know.
What information are you sending over? Is it a lot of raw data arrays? Is it more document based where XML could be more beneficial? You'll need to work with your DBA if the data is stored in a repository and you'll be querying it. Will you need to write code to format your data or will the DBMS output it in the format you need?
What do you mean the CSS needs to be loaded before being inserted? Everything loads in the order you specify so making sure your CSS loads at the proper time shouldn't be an issue. If you're using ASP.NET, you can also use a SSM (style-sheet manager) to serve your CSS and only load whats required. SSM's are great if you have a lot of style-sheets to serve.
A lot of the questions you asked will be answered as you get further into the design phase. In order to get some solid answers and not just speculation on what is the best method, you will need to publish a lot more details than this. Any answers at this point shouldn't carry much weight in your decisions. They certainly wouldn't mine.
Related
I am working on an old enterprise solution with these properties:
The solution has a MVC web application
The solution has a WCF service layer
The solution has javascript in the database, in the form of functions in a database column
The web application retrieves said javascript through the service layer and plugs it into certain pages
My team cannot modify the web application, nor the service layer
My team must write javascript by inserting functions into said database columns
This architecture leads to:
A very inefficient development loop
Very poor source control
I'd like to propose a solution for them, how to upgrade this, but here's where I fall a bit short on experience. My suggestion would be:
Migrate the javascript from the database to javascript files
Make some sort of hook in the web application for other teams' javascript files
My questions are:
Has anyone had this kind of problem and how did they solve it?
Is there an effective way to do this kind of javascript migration into files? My idea would be to write a small console program to do the migration
How would they make a hook to import our javascript files? My idea is to make a script bundle with some naming convention, so we can add scripts without them needing to change their code. Are there problems with this approach?
Any kind of input would be invaluable.
Edit:
Additional explanation:
The mechanism maps the javascript function names to a certain DOM elements' event attributes and inlines the code right after the element
The functions are standalone functions, depending only on libraries already in the web application
The functions are grouped by a common form
So I suppose it would be better to group them into files bearing the form names.
If these are just simple, static function definitions being inlined into the web page, then I suppose it might be possible to serialize/aggregate them all into a giant file and run something like prettier on it to make it readable.
That wouldn't be ideal to gain traction in your proposed migration, though. If the code has any volume to it at all, it would be nice to give some structure and order to maintain it.
It's already kind of a huge assumption that this javascript is just pure functions without any complex dependencies on each other, but it's possible that these pieces of Javascript work in isolation already if they are being pulled out of a database. It's hard to know without knowing more context. It seems unlikely that your life will be that easy.
If you managed to extract this monolithic Javascript file, the easiest thing to do would be include it in a script tag for the entire site and be done with it. This could be a bad idea if the file is getting to the ~MB size and slows your initial page load time.
Then again, the point at which you have a bunch of functions in one file, you could probably do a lot there to optimize and reduce duplication of code.
This is still all conjecture because I don't know the mechanism by which your web application imports the javascript once it retrieves it from the database.
My PHP template looks like this:
$html=file_get_contents("/path/to/file.html");
$replace=array(
"{title}"=>"Title of my webpage",
"{other}"=>"Other information",
...
);
foreach(replace AS $search=>$replace){
$html=str_replace($search,$replace,$html);
}
echo $html;
I am considering switching to a javascript/ajax template system. The AJAX will fetch the $replace array in JSON format and then I'll use javascript to replace the HTML.
The page would then be a plain .html file and a loading screen would be shown until the ajax was complete.
Is there any real advantages to this or is the transition a waste of time?
A few of the reasons I think this will be beneficial:
Page will still load even if the Mysql or PHP services are down. If the ajax fails I can handle it with an error message.
Bot traffic (and anything else that doesnt run JS) will cause very little load to my server since the ajax will never be sent.
Please let me know what your thoughts are.
My 2cents is it is better to do the logic on the template side (javascript). If you have a high traffic site you can off load some of the processing to each computer calling the site. Maybe less servers.
With Javascript frameworks like AngularJs the template stuff is pretty simple and efficient. And the framework will do caching for you.
Yes, SEO can be an issue with certain sites. There at proxy tools you can put in place that will render the site and return the static html to the bot. Plus I think some bots render javascript these days.
Lastly, I like to template on the front-end because I like the backend to be a generic data provider (RESTful API). This way I can build a generic backend that drives web / mobile and other platforms in a generic way. The UI logic can be its separate thing in javascript.
But it comes down to the design needs of your application. I build lots of Software as a service applications so a single page application works well for me.
I've worked with similar design pattern in other projects. There are several ways to do this and the task would involve managing multiple project or application modules. I am assume you are working with a team of developers and not using either PHP or JavaScript MVC framework.
PHP Template
For many reasons, I'm against using “search and replace” method especially using server-side scripting language to parse HTML documents as a templating kit.
Why?
As you maintain business rules and project becomes larger, you will
find yourself reading through a long list of regular expressions,
parse HTML into DOM, and/or complicated algorithms for searching
nodes to replace with correct text(s).
If you had a placeholder, such as {title}, that would help the
script to have fewer search and replace expressions but the design
pattern could lead to messy sharing with multiple developers.
It is ok to parse one or two HTML files to manage the output but not
the entire template. The network response could be slower with
multiple and repetitive trips to server and that's just only for
template. There could be other scripts that is also making trips to
the server for different reason unrelated to template.
AJAX/JavaScript
Initially, AJAX with JavaScript might sound like a neat idea but I'm still not convinced.
Why?
You can't assume web browser is JavaScript-enabled in every mobile
or desktop. You might need to structure the HTML template in few
ways to manage the output for non-JavaScript browsers. You might
need to include <noscript> and/or <iframe> tags on every page. And,
managing alternative template for non-JavaScript browser can be
tedious.
Every web browser interpret JavaScript differently. Most developers
should know few differences between IE, FireFox, Chrome, Safari, and
to name few. You might need to create multiple JavaScript files to
detect then load JavaScript for that specific web browser. You
update one feature, you have to update script for all web browsers.
JavaScript is visible in page source. I wouldn't want to display
confidential JavaScript functions that might include credentials,
leak sensitive data about web services, and/or SQL queries. The idea
is to secure your page as much as possible.
I'm not saying both are impossible. You could still do either PHP or JavaScript for templating.
However, my “ideal” web structure should consist of a reliable MVC like Zend, Spring, or Magnolia. Those MVC framework include many useful features such as web services, data mapping, and templating kits. Granted, it's difficult for beginners with configuration requirements to integrate MVC into your project. But in the end, you could delegate tasks in configurations, MVC concepts, custom SQL queries, and test cases to developers. That's my two cents.
I think the most important aspects you forgot are:
SEO : What about search engine bots ? They wont be able to index your content if it is set by javascript only.
Execution and Network Latency : When your service is working, the browser will wait until the page is loaded (let's say 800ms) before making the extra Ajax calls to get your values. This might add an extra 500ms to get it (depending on network speed and geographic location...). If you have sent all the generated data by your server, you would have spent only ~1ms more to prepare the complete response. You would have a lot of waiting on a blank page.
Caching : You could cache the generated pages on your web app. That way your load will be minimized as well. And also, if you still want to deliver content while your backend services (MySQL/PHP..) are down you could even use Apache or Nginx caching.
But I guess it really depends on what you want to do.
For fast and simple pages, which seems to be your case, stick with backend enhancements.
For a dynamic/interactive app which can afford loading times, and doesn't care about SEO, you can delegate most things to the front-end. But then use an advanced framework like Angular, to handle templating, caching, etc...
I want to implement markdown to my forums.
I research many possible approaches how I would do that and this is what I thought:
A simple approach would involve pagedown on client side and php-markdown on the server.
My approach is to save pure markdown to database and when displaying convert to HTML (with pagedown). Since I already have security layer for my server side (HTML elements whitelist) and all the necessary staff I don't see anything to lose here.
What I win in this case? well I have to modify pagedown to use custom buttons and patterns. That would be hard for me to maintain both php and JavaScript.
My question is: is this good aproach?
To break this question:
Is there any serious overhead on client side loading about 30
posts and converting it to HTML (performance)
With the Idea that I check elements whitelist, is there any
security issue I need to know about? (Security)
I wouldn't use client side markdown engines. From a few quick googles its of the opinion it's very CPU intensive. Loading 30 posts would add quite a bit of overhead.
If you stored MD in the DB, rendered to HTML on the fly, then employed some caching (memcached or redis) that could work quite well.
In regards to security theres a good read here, it would require some extra sanitising removing scripts/links/redirects etc.
Further reading
http://functionn.in/resource/remarked-js
How to use Markdown & MySQL?
Converting markdown from client side is not recommended as #Lex has stated. Instead, you can use some online services to convert the markdown top html for you.
Have a look at http://daringfireball.net/projects/markdown/dingus. You can use curl or something to post markdown to the site and then scrap the website to take the html part.
You can also have a look at here http://parsedown.org/
You have two options to suggest:
Strapdown - allows to create markdown documents without server-side processing, as you can see on there page, even without code, just by using static files
markdown-js - allows to create markdown document with client-side processing (javascript)
Here is how I do it:
Save markdown code in db and at rendering I'm caching the result in a file (file, Memcached or any cache storage engine you want). This way I keep the original in database and I`m not wasting resources to compile markdown at each page visit, instead I serve the cache file until it has expired or deleted because of a change.
I'm wondering if a server exists to translate the JSON (or other format) feeds from existing web services into what the frontend expects.
For example, currently my backend team sends us JSON feeds and they doesn't always meet what we need. We could file requests for them to change the feed, however, this might not be compatible with other teams and if nothing else would take time. It would be ideal for them to make all the data available and have a layer that would translate it into what is most convenient for our frontend code.
Does something like this exist?
Clearly I could roll my own or build code for each service, but I'm hoping a system like this already exists.
Not exactly an answer to your question, but I was genuinely delighted to see how easily Angular binds data. We (our small company) have also been developing a framework that generates forms from JSON based on XML configurations, but the project's still pretty much an infant.
I've been looking at the API for Flattr, http://flattr.com/support/integrate/js , which has a cool way of accepting query variables for their JavaScript to load.
My question is, do most APIs use something other than JavaScript to accept these different variables for their services? EG:
Ruby on Rails
PHP
Python
Then these are parsed by the respective language and returned as outputted JavaScript to the requesting website?
Cheers
Javascript itself is totally capable of reading how it's embedded to the HTML it belongs to, by reading document.getElementsByTagName("script") and further parse/match their src attributes. Therefore, it's not a problem at all for it to further parse the query variables attached at the end, and dynamically (all in javascript, client side) load components within.
Any javascript libraries that allow you to pack the whole thing and deploy to your own web server should take this approach, since there's no server to handle the request anyways.
On the other hand, javascript libraries that are hosted on other sites that allow you to use (like YUI) MAY take the server approach like you mentioned.
In my personal experience, projects that I have worked on have used server side languages to deal with get params.
So a request might be /myjavascript.js?id=123123 The server side language would create the correct javascript for that request.
Keeping everything on the server side has the advantage of not allowing the user to see what is going on. If this isn't a problem for you, javascript is more than capable of handling different params.
In my experience it's fairly common that widgets embedded into others' sites gets their parameters by parsing them from their script tags. It makes the widget script static and self-contained and thus easier to distribute through eg. a fast CDN. Performance is important when you're going to convince someone else to add your javascript to their site as poor performance from the widget can make the entire site appear sluggish.
A better place to specify the parameters than query parameters would however be to specify them in the URL:s hash-part as that part isn't included when caches are checked and thus the script would have to be downloaded fewer times - which of course is good for performance, especially if the parameters might shift a lot.