Chris Oliver

Let us know how the implementation goes!

Ah perfect! :D

And yeah I think that'd make consuming the API a lot easier. I think the only trick then will be making sure you get all your field names right when you submit make over. There is some documentation about how that works but I can't remember where I saw it. Mostly it's just sending over an array for your observations_attributes[] and that should do the trick.

You could optionally also support the id and _destroy fields for the nested observations in case you ever wanted to be able to edit/remove observations from updating a post. That seems probably less likely to be necessary though from an API standpoint though.

I think you should be able to simply do the following instead:

@projects = current_user.projects.find(params[:id])

The trick here is that Rails knows how to do the join and where automatically because the relationship is defined as "has_many through". The has_many means it knows it must join, and through means that it needs to join twice.

Your query should work, but you're basically redefining exactly what Rails is doing internally so you can get rid of the join and where and it should produce the same output. :)

Hey Sean!

What you might consider doing here is accepting nested attibutes on the create Post action in your API. That way they can submit a post and include some preliminary records for observations all together. Those are often super convenient things so that your API users don't have to make two API requests first to posts and then to observations afterwards.

The other thing is I would suggest using nested routes for this as well. Think of these two routes:

resources :posts do
  resources :observations
end

resources :observations

In the top section that's nested, you can get observations attached to a specific post really easily by asking for the /api/v1/posts/1/observations url. As someone using your API, I know at a glance that it would give me only observations for that specific post.

You might also want to offer the ability to operate across ALL observations, not necessarily ones for a specific post. In that case, the second resources route that isn't nested can be very useful. This might be for doing more bulk requests, updates, etc that could apply to all posts. It provides advantages for different use cases and it's totally fine to include both of those routes/controllers for the some model (and often encouraged) so you can provide an elegant set of URLs that encapsulate the intent in the design of the url itself.

Hey Josh, looks like I forgot to put the video in the series. You can find the episode here: https://gorails.com/episode...

Primarily because if you're already using a frontend framework you'll want to keep all the Javascript contained within the component. If you use the JS responses from UJS requests, you're not splitting your JS across two things (the component code and the rails response) and it's no longer self contained. The component should be the one changing state to keep it organized.

You can still do that if you want to, I just wouldn't recommend it because you might as well just use UJS only and no frontend framework then.

Logout is as simple as deleting the token from localStorage and the Vue state. Ideally, you'll want expirations on your tokens ideally so that they can be invalidated after a time. This is the same thing that Rails session cookies do for logout as well so it's nice and similar.

They serve similar but different purposes, but I did talk a little bit about that here: https://gorails.com/episode...

The way I embed youtube videos on GoRails is that I have an Episode model with a column for youtube_id and when you click on an episode I embed it like the following (no need to use their API which is great):

<iframe src='https://www.youtube.com/embed/<%= @episode.youtube_id %>?rel=0&autoplay=<%= params[:autoplay] || 0 %>' frameborder='0' allowfullscreen></iframe>

Check out this week's episode where I talk a little bit about this for authentication. For the individual role authorization, you'll encode the roles of the user into the JWT payload and send that over to the client when they auth. Then you can simply base64 decode the payload of the JWT in Javascript. (See https://developer.mozilla.o... This will give you the roles on the client that you can pass to your JS to hide/show certain links. This way you can know the roles client side to determine what to display and server side you can use cancan/pundit to do the real authorization for the actions the user would take.

Anything client side is just going to be for displaying the UI and therefore should never be trusted so the server will still need to implement authorization as you normally would.

Yeah, like Szilard said that's basically be their way of doing the multi-tenancy. They just namespace the routes with an /:account_id or something at the beginning and have all their resources inside of that so that your account id is included in every single request. Effectively the exact same thing as doing a subdomain for multitenancy but they're already using the subdomains for the various versions of Basecamp.

What I usually do is I run "rbenv install 2.4.0" and it will say hey, this version is missing so update your ruby-build version and give you instructions on how to do that. Then running the install command should succeed then.

One step at a time. ;-)

Couple things I notice off the bat:

1. You can't look up the project until it's actually been created so there is a database ID.
2. You can't create the subscription just yet either since the project hasn't been saved yet.

Here's what I would do:

 def create
    @project = Project.new(project_params)
        @project.subscriptions.new(user: current_user)

    respond_to do |format|
      if @project.save
        format.html { redirect_to @project, notice: 'Project was successfully created.' }
        format.json { render :show, status: :created, location: @project }
      else
        format.html { render :new }
        format.json { render json: @project.errors, status: :unprocessable_entity }
      end
    end
  end

This is going to build the project in memory first. Then it creates an associated Subscription record in memory as well, but inside the project. Since the two are associated in memory, this will make sure that when you save the @project the subscription also gets saved and both will get inserted into the database as long as the validations pass.

You use Imgur at all? It's pretty similar to a movie rating app since it has ratings and stuff. I was kinda thinking something like their collapsible comments and/or navigation which are a pretty good showcase for like the usefulness of a JS framework. You can't do that easily without a good amount of JS for sure.

Hmm, I'm not sure Yelp would be a great one to showcase React because really the site doesn't have that much interactivity so you wouldn't really need any frontend frameworks for it.

Something like Facebook on the otherhand has a lot of interactive widgets where it would make sense. Each post has its own dropdown menus, every chat box is independent, all kinds of various little pieces of state for each section of the site. Facebook may be too overused as an example, but I'm trying to think of something in line with that.

I guess now that I'm writing this, of course Facebook is the obvious choice because they invented it. Hah.

Absolutely. I think the main thing I need to figure out is what's a good, somewhat small real world app I can do as an example. It's always hard to come up with something that isn't contrived feeling.

Hit me with your ideas!

Computers eh? :)

First, I'd check to make sure your cable.yml defines using redis in development so that it can be shared between processes. Second, if you run redis-cli you can say subscribe notifications:4 to have the redis cli show you the messages coming across there as well.

If you send a message on the channel, then it should show up in the redis cli. If it doesn't, you've narrowed it down to probably a configuration problem there and can debug why the message doesn't make it to redis. If it does, then you'll want to debug the client side to figure out why things aren't getting relayed to the websocket as you're expecting.

It would probably be helpful to watch those because they setup the foundation for this which is kind of like a chatroom restricted to just two people. Lots of different ways you can go about it, but this is just one approach that works nicely to reuse the features of group chat.