I'm just learning about SproutCore now, seems great. But I can't find a good answer on deployment options.
I'm starting small. Just implementing a single page of a complex site with SproutCore. Right now, that page is dynamically generated and served from my django based server. I serve all of my static files (.js, .css, images, etc) off of a CDN.
The page represents one customer.
So, on that dynamic page, it knows:
What customer we should be looking at, the ID, name, etc.
Where my media should be loaded from (absolute HTTP path)
How do I get a SproutCore based app to deploy and run in an environment like this?
I imagine I can upload the built sproutcore app to my CDN. Then in my html page, somehow reference it. But how does that SproutCore app know what server to request backend data from (I'd rather not hard code it)? It can't be installed in the root of the CDN, so how does it know how to load things relative to itself? I could tell it an absolute URL to load from at run time. With some pain, I could even tell it an absolute URL to load from at build time.
No answers on this one, here's what I did...
Ended up moving to Ember.js (aka SproutCore 2). That follows a completely normal "add .js to a page and serve it normally" model and doesn't have any interesting deployment worries, so it's a no-brainer.
Related
My goal is to embed a full Ruby on Rails app in a Wordpress site. Ideally, the staff should be able to edit the non-Rails parts of the site just like any Wordpress site, including content, theme, menus, etc. When the user clicks a link to a certain page, it should show the Rails content within the Wordpress template—headers, menus, sidebars, etc.—all of which should look the same as the rest of the site. I'd much prefer to do the presentation of the Rails content within Rails, where I can use Slim, CoffeeScript, SASS, and all of the other built in presentational magic, rather than setting Rails up as just a JSON server and having to muck around with PHP to retrieve and format the data.
I've tried a few techniques so far, but each has its downsides:
First, I tried embedding the Rails app in an iframe, but iframes are clunky, and I couldn't get it to expand or contract to the height of the content.
Second, I tried creating a special Wordpress template file that loads the Rails content using PHP's file_get_contents function. That worked okay, but required a lot of jankiness to get URLs to transfer over, including having to add a question mark into the URL for a certain subpage to get Wordpress to ignore it and pass it through. It's also a little slow because it's loading content from two different dynamic systems. And I never could figure out how to get cookies to pass through to Rails, which is essential for this app.
My third solution was to create a blank page on Wordpress (not linked to anywhere) and write a method in Rails that pulls that page, creates a layout file, and then uses that as the layout for the content. So the whole page is actually being served by Rails, but to the user it looks just like Wordpress, and because Wordpress doesn't use relative URLs in links, they all work just fine. The trouble there is that changes to the Wordpress template (including menus, template files, theme options) don't take effect on the Rails pages until that method is run. I set up a cron job to run it every 15 minutes, but that's not ideal, and something tells me there must be a better way.
This seems like something that would be pretty common, but I haven't been able to find any solutions online. Has anyone else made this work?
So, my cohorts and I have been doing some development with Phonegap +jQueryMobile for an application we've been planning to rollout. We switched off doing this natively for iOS and Android, since its mostly html anyway, and phone gap seemed like a great way to do this without having to write a whole bunch of platform specific code (although we're more or less newbs when it comes to this type of development.)
Previously, all the html, javascript, etc, was going to be housed in the app itself. For the most part, this seemed to work for us, and we advanced our design/testing/etc accordingly. However, things have changed in our approach. For each of our customers (once they go through a log-in/authentication) has a 'starting' html file (essentially 'their' index.html) that is specific to said customer. This was different from before where everyone had the same files.
Now I've played around with storing certain scripts on the web server to try and off-set opening the html running on the server, but it's not really that useful when trying to integrate some of the functionality like the camera or some of the other plugins we're trying to use. It's essentially a form-based application, so this is the ONLY file that will change from customer to customer. Also, this will not be something that changes frequently. For the most part, it will be setup for a customer ONCE AND ONLY ONCE, and it truly is unlikely to change.
Is there a way to more or less pull down this html file from a web server to replace the one that is stored internally in the app, and then load that version? Would doing something like that (if its even possible) violate Apple's or Google's App guidelines? Or is what I'm describing not even possible in the framework?
The only other thing I can think of would be to change the stored 'index.html' file to not load any of the form itself, but rather make ajax (or equivalent) calls to do so, but I've been told by our developer working the web design side of things that it would be a huge pain.
Any insight/knowledge would be appreciated.
If you really need to do this (I don't quite understand why), I think your best bet is to go the AJAX route. At least Apple does not look kindly on applications that update themselves without going through the App Store submission process.
You can do the same index.html for all and a script config.js that be the responsible of load/unload resources/html of each user at app start.
All you need to do then is save that config JSON values in localstorage and go.
I have been reading about caching and all the resources available out there, but I am just not sure if I need to use 3rd party add-ons like Memcachier in my app. Other than the front pages (Static Pages like Homepage, About, Contact Us, Terms, Privacy) all other pages require authentication and are all dynamically created. It's a small social networking app so the show page, index page, edit page are all dynamically created. The index action is constantly going to be updated.
I want to know if Rails will automatically cache my static pages and assets such as css, javascript, images? What kind of caching should I be using?
If what you call static page are HTML files located in your public folder, they are directly served by your web server (ex: Apache), and the request don't even go through Rails
If they are files located in your app/views controller, the request goes through Rails, and it could be a good idea to implement page or fragment caching. Know that you can cache just parts of the pages, this is called fragment caching, and it's useful for dynamic pages that have static parts.
Also, you can link a cache to a record, so first time the view related to this record is displayed, the cache is generated and used for the next requests. Then when you modify this record the cache is invalidated and the process start over.
You don't need cache for your assets, they are compiles and not interpreted by Rails anymore in your production environment.
There is so many things about caching, and you can do a lot of good to your application with it (or a lot of bad is used incorrectly) and I cannot cover it all, let me give you some pointers that will teach you a lot:
http://railscasts.com/episodes/387-cache-digests
http://railscasts.com/episodes/169-dynamic-page-caching
http://railscasts.com/episodes/93-action-caching
http://railscasts.com/episodes/90-fragment-caching
http://railscasts.com/episodes/89-page-caching
I am taking over development on a rails 3.2 application and am looking for the best way to improve page loading time. The site itself is more of a large dynamic website than an actual web application (the site is http://korduroy.tv/, a surf lifestyle community site), and while there is a couple of small pieces that differ from user to user, most of the site is the same experience for everyone.
Page loading time is fairly slow, and from looking at the server logs, it seems to be because each page is loading so much dynamic content (for example, most pages are loading resources from 10+ models). While I hope to go through and refactor what I can, I am looking for some basic performance wins. Knowing that most of the site is the same for every user, is their a way to aggressively cache the content on the server or even serve static content that has been generated through some kind of background job?
My initial thought was to create a job that uses a static site generator, maybe something like Jekyl, and basically creates a static copy of the site, which could then be served on a cdn. My gut is telling me this is probably not the way to do it, plus there are some pages (such as the user profile page), that need to be served dynamically.
Any recommendations would be great. Disclaimer, I come from front end land and have very little knowledge of best practices when it comes to server side optimizations. Thanks!
From what you write, I believe your biggest gain will be in implementing a fragment cache using a memcache store. See http://guides.rubyonrails.org/caching_with_rails.html as the definitive guide on rails caching.
You might be able to get away with a page cache or action caches for some of the content that doesn't depend on the user (like the homepage), but unless you're serving up millions of requests a day, I'm not sure this is necessary.
I notice that while the javascript and css seems to be compiled according to the rails asset pipeline, the images are missing the sha1 hashes that allow aggressive browser caching of the resources (since you don't have to worry about the contents changing, as they get new hashes when you change the images). The key here is enabling the asset pipeline, making sure you compile your assets as part of deployment (rake assets:precompile) and using the image_tag and asset_path helpers (or image-url sass helper). Also make sure that nginx is responding with code 304 (not modified) to your browser when you're refreshing a page. This won't affect the load on the rails server (unless you have both nginx and rails running on the same server), but will reduce the average page load time.
You can look into more advanced techniques like caching your sql queries, or optimizing these, but this can lead to increased complexity making it harder to maintain your codebase. Try the view caching first, and see if that gets the load time to an acceptable level.
I'm wondering if there's a way to store CSS asset paths, like background images, in the database so that they're customizable without accessing or rewriting the code. I've looked at some template engines, like liquid, but think they're a overkill for what I want to do. I only want a tiny bit of customization in my views between various deployments of the same app codebase, not anything for various users.
I've not looked much at Rails 3.1, but from what I understand the CSS assets are compiled and aren't static any longer, so -- does that mean I can write something like that into my CSS in rails 3.1 that pulls from the database? I usually deploy to Heroku and aren't sure if they're supporting 3.1 yet.
Anyone have any better strategies or ideas?
Storing binary files like images in the database can quickly become cumbersome. There was a time when we were storing user uploads like PDF's and such in the DB but it became unmanageable. We quickly moved it all over to S3 and made Paperclip store and retrieve the files there (encrypting the files before saving them to S3, and sending them over SSL since the files were potentially sensitive) and it made things much saner.
I'd say best bet for you is to use S3. Since
On heroku you have a limited
database size (depending on your
plan) and could quickly run out if
you're storing binaries there.
You can't dynamically save new files
to the filesystem on heroku, and
S3 is cheap as hell (and free for
most casual use) to store and
retrieve files.
EDIT based on your comment:
Ok I mis-understood the question. Either store the image path in the database or have the image stored with such a path & naming convention that the code itself can figure out where to get the image (which is what paperclip does). Both ways are acceptable. NOTE that SASS is not truly dynamic, you can't pull paths from the database and make the sass change on-the-fly. I've run into a similar situation and the solution was to make the CSS point to a background-image that was in fact a route in the application. In our instance we were able to change the image displayed based on the subdomain or domain of the incoming user, but you could just as easily display that image based on a session cookie that gets set before the views are rendered.
While SASS is compiled, after it's been generated it is static. The syntax, and 'dynamic' nature of it are just to make writing CSS easier.
What about using something like S3(Paperclip) + a "css assets" table/model?
That way in an "admin" page you can pull all of the possible CSS assets, allow someone to select a new one or even upload a new image to s3. This means you wouldn't have to actually rewrite any code just have an admin portal where they can select possible images.