Chris Oliver

So many little nuances to everything, it can be really tough to explain and understand it all!

That's correct, I'm using regular interval polling rather than long polling. Long polling is used more as a replacement for something like WebSockets so that you can get realtime communication happening rather than periodically checking for updates.

If you're using long polling, that's a request that will sit open each time, potentially clogging up resources server side because what you're really trying to do there is keep a persistent connection going. ActionCable is a better solution for something like that instead.

Regarding #2, if you're doing regular interval polling, there will be no slowdown. Generating a request once every 5 seconds, when your app can handle say 30 requests per second means that you have consumed 1 request out of the 150 requests (30 requests/sec * 5 sec) which puts very little extra load on the server. Obviously if you've got tons and tons of users, you'll have to scale up accordingly. The notification requests returning JSON are also lighter weight than your average request by a lot because they're not generating a full HTML template. Caching can also speed that up meaning you can squeeze more than 30 requests per second out if some are regular HTML requests and others are the lightweight notification requests.

There will be a lot more requests happening, that's true. Better errors won't be affected by that, but what you're likely seeing is that better_errors really only works best with Webrick, not Puma. The trouble is that when you get into the multi-process and multi-threaded webservers, keeping track of the stack after the request gets very hard and Puma doesn't really allow you to use better_errors like it's intended because of that.

Twitter does simple polling on an interval every few seconds just like what I showed in the episode. If you open up your Webkit console and click on the network tab, you'll see periodic requests to /timeline and /toast_poll every handful of seconds. This is how they send notifications out, so it's definitely a solution that scales nicely for large sites.

The trouble with websocket connections is you can run out of resources quickly because one user is fully consuming a connection to the server. With polling you only use a connection to the server for a few milliseconds and close it afterwards freeing up the resource for someone else. Websockets are persistent so once that user opened the connection, nobody else can use that resource which makes for much harder scaling.

I definitely would imagine that using ActionCable for this would make the most sense. The trouble you're going to run into is the amount of data you need to stream and how often would conflict with polling in any sense. It'll be best in a situation like this to have open connections that you can just push data over to instantly whenever necessary. If you did JS fetching, you'd have to wait for the connection to open each time which would be too much overhead for fast performance on updates in a situation like this.

Awesome, glad you got it working! Turbolinks can definitely be tricky to wrap your head around what's going on.

Also for reference, this is a pretty great list of solutions to convert JS from popular libraries to Turbolinks compatible stuff: http://reed.github.io/turbolinks-compatibility/twitter.html

Whoo! :)

Give their readme a look on the new iOS adapter. It might help wrap your head around it a bit. https://github.com/turbolin...

Basically your mobile app just ends up primarily being a WebView (webkit browser full screen) and it let's you set the website. This is similar to things like PhoneGap in the past, except that the code is all just your public website meaning you can update your mobile app at any time by deploying your website again. Pretty slick! I'm not sure if React Native lets you do things like that.

With Turbolinks on mobile, you get a web view that embeds the Rails site just like you would have in your browser, but you can override link clicks with native code. So all the stuff you see on mobile is just as if you were viewing it in the browser. It's a hybrid app because of the webview, but easily intercepts those things to do native Swift or whatever. Turbolinks would only need the server to return HTML and so you don't really need to build an API.

React Native is somewhat similar in that you're still sharing the same app code with the main website, but you will have to build an API to make React work, and you'll need to do some extra work to serve up the HTML as well.

Mostly because I'd rather spend most of my time doing the heavy lifting in Rails rather than JS. If you built your Rails frontend in React already, React native is the way to go. Since I'm using Turbolinks already and because I don't have any complex JS widgets on the frontend to need React, the Turbolinks adapters are the best solution for me. React could just as easily fill the same gaps, just fits well for me.

Super nice that it's included in the library isn't it? :D

Also if you're using Turbolinks 5 (I've yet to upgrade) then I think it also has the same progress bar.

Hey Enrique! I'm actually just using the stock Turbolinks progress bar that's builtin. I think the only thing you have to do is add a little CSS to make sure that it displays.

https://github.com/turbolinks/turbolinks-classic#progress-bar

Awesome! Also if things get out of sync for some reason and you've got the customer ID, you can generally hit their API and ask for the customer's subscriptions and sync them to your database. That way you won't have to clear your DB or anything. It's that keeping-in-sync process that really would be nice if it was easily automated.

I think Matt's answer is correct. Basically just need to reverse your way back to the code that creates the Subscription object (in your database) and attaches that to the user. Maybe it's not saving?

1. You'll definitely want to do some parsing and validation. For example, leaving out the protocol happens all the time where someone might type in just gorails.com into the field. The protocol is important, otherwise you can print out a link that ends up being relative on accident like https://gorails.com/example.com. You see this stuff all the time when validations haven't been written properly.

2. You can use the url input field type to have the browser do a little verification. This will help with the frontend validation since it should require users to type in a protocol like http:// at the beginning. Here's how to use that url field: http://apidock.com/rails/ActionView/Helpers/FormHelper/url_field

3. Server side, you could simply require all the urls to have http:// or https:// at the beginning. That's nice and simple, can do that with regex or just plain Ruby. Easy to maintain. The Coderwall link Enrique posted is a great example of an implementation like that (although it looks like it has a couple small issues). It basically uses Ruby to parse the URL and verify the protocol. That's important because simple regex checks can't verify the TLD at the end of the domains easily. There are infinite number of TLDs now, and it's going to be best to rely on the Ruby standard library for this because it will always get updated behind the scenes and you have no external dependencies.

4. Now all these methods: regex, URI, gems, etc are all going to be approximations. If you truly want to make sure the URL is 100% valid, the best way is just to simply make a request server side anytime the URL changes to request the status code for it.

require 'open-uri'
open("https://gorails.com").status
=> ["200", "OK"]

As long as you get a 200 status, then you know the URL is truly valid. You can't do anything more accurate than that, but it's also going to slow down your server response somewhat to request the page. Worth considering how important it is to have 100% correct because you're trading off server time vs correcting a number of errors on user input. It probably depends on how often you see mistyped URLs. You could also make an AJAX endpoint that does this to improve validations client side when the user is typing so it doesn't have to significantly delay server side validations.

I definitely will. I also need to learn some around Swift and Android so that I can make some example apps using the Turbolinks adapters. That might mean we'll have a GoRails mobile app at some point. :)

I've found that using Segment.io for managing those external libraries helps a lot. It makes that management a lot easier, but I also intentionally use very few third-party Javascript libraries because they can quickly slow down the frontend performance of a site. You might check out Segment and see how it goes.

https://segment.com/docs/li...

Hey Pete, this usually happens from one of two things:

1. You're using a third party library (like Segment.io for example) that isn't compatible with Turbolinks events by default. These usually require some tweaking in order to make compatible. It all depends on the library but there are usually ways to do it. You can google for that library + turbolinks and see if anyone else has made it work, or if you can tweak it yourself.

2. Sometimes it can just be a simple setup issue if your JS is running incorrectly. Maybe you need the jQuery.turbolinks adapter, or just to modify your code slightly to allow running on multiple pages.

It all kinda depends on your code and the issues you're experiencing. They can be kinda hard to track down so the easy solution is to turn off turbolinks for those links in the meantime if you can figure it out. I don't think there's anything wrong with that so you can figure it out later.

Heck yeah man! :D

It took me a little while, but I did it! https://gorails.com/episodes/gorails-performance?autoplay=1

Good news! Heroku is actually really easy now.

Just tested it this morning and it's super easy to setup: https://github.com/excid3/a...

The trick is that you _must_ use the route mounted version because Heroku apps only expose one port. Just make sure you have a Redis connection added, and you should be all set.

You can try out my example app here: http://actioncable-gorails.... (just make sure you're on http, not https.