Speaker 1: Have you ever paused, you know, to really think about
Speaker 1: what it takes to build the software as a service
Speaker 1: a sauce app from the ground up.
Speaker 2: Yeah, it's It's definitely more than just.
Speaker 1: Coding, right exactly, It's about architecting something wow.
Speaker 2: Robust, scalable, user friendly, the whole package.
Speaker 1: So today we're doing a deep dive. We've got this
Speaker 1: fantastic source, a really comprehensive guide on building sauce with
Speaker 1: Ruby on Rails seven.
Speaker 2: And our mission really is to cut through all the complexity.
Speaker 2: We want to pull out those key nuggets of knowledge,
Speaker 2: look at the modern tools, the best practices, you know,
Speaker 2: what makes Rails such a powerhouse for this kind of development.
Speaker 1: Right, and show you how to navigate it all without
Speaker 1: feeling well completely overwhelmed.
Speaker 2: Get ready for some aha moments, because we're going to
Speaker 2: demystify what goes into a production ready sauce app.
Speaker 1: Okay, let's start right at the beginning. Then laying the foundation.
Speaker 1: Rails has this famous philosophy convention over configuration. For folks
Speaker 1: listening who may be no development, what's the real like
Speaker 1: strategic edge you get from that when you're kicking off a.
Speaker 2: Sauce It's all about speed initial velocity. Rails is well,
Speaker 2: it's opinionated about speed. It hands you this pre defined
Speaker 2: logical structure right away. Your app canfig dB test folders,
Speaker 2: so you get productive almost instantly.
Speaker 1: Ah, so you're not stuck debating file structures for days exactly.
Speaker 2: You run Rails new and you've basically got a working
Speaker 2: app skeleton ready for a Hello World pretty much out
Speaker 2: of the box. It lets you focus on your business problem,
Speaker 2: not the framework.
Speaker 1: Setup that makes sense moves a lot of that initial churn.
Speaker 1: And when you are spinning up that new app, what
Speaker 1: are some of those first big setup choices, the ones
Speaker 1: that really mark the difference between a quick demo and
Speaker 1: something you'd actually deploy.
Speaker 2: Okay, first up database, This trips people up. Sometimes Rails
Speaker 2: defaults to skoy three, which is fine, super simple for
Speaker 2: getting started.
Speaker 1: But not for production.
Speaker 2: Generally, No, for real sauce, you'll almost certainly want Postgres School.
Speaker 2: It's just more robust handles, concurrent users, better advanced features
Speaker 2: like Jason in b stuff.
Speaker 1: You'll need later, so you'd specify that right at the start.
Speaker 1: YEP Rails New year app database postcrescool tells Rails what
Speaker 1: you intend to use from day one.
Speaker 2: Okay, database sorted. What about managing the code itself, especially
Speaker 2: if you have a team.
Speaker 1: Well, get is absolutely fundamental. That's probably obvious to most devs,
Speaker 1: but for Sauce. Its role in smooth team workflows, feature branching,
Speaker 1: quick rollbacks when things go wrong. It's crucial for maintaining speed.
Speaker 2: Insanity, and you'd host that somewhere like GitHub right.
Speaker 1: GitHub, bitbucket. Essential for collaboration and especially for keeping your
Speaker 1: code private.
Speaker 2: Got it? Now? Inside that new Reils app, there's the
Speaker 2: gem file. What are the sort of must have gems
Speaker 2: included right away? What problems are they solving?
Speaker 1: The gem file is like your recipe. You'll see pg
Speaker 1: in there if you chose postcres school. That's the connector.
Speaker 1: Puma is your web server handles the actual requests. It's fast,
Speaker 1: concurrent and a really important one now is import mafrails.
Speaker 2: What's the deal with that?
Speaker 1: One?
Speaker 2: Sounds modern?
Speaker 1: It is? It lets you use modern JavaScript yes modules
Speaker 1: directly in the browser without needing a complex build step
Speaker 1: like webpack or as build. It really simplifies front end
Speaker 1: asset management. Big win for developer experience and styling. That's
Speaker 1: gotten simpler too, hasn't it.
Speaker 2: Oh yeah, tailwind CSS is basically built in now with
Speaker 2: Rail seven. It's a utility first CSS framework makes styling
Speaker 2: fast and consistent without writing tons of custom CSS. You
Speaker 2: build styles writing your HTML.
Speaker 1: Okay, so you've run Rails new, configured a few things.
Speaker 1: The source really stresses how fast you get something working.
Speaker 1: Can you walk us through that?
Speaker 2: Yeah, it's pretty neat. You run Rails new, then Rail Server,
Speaker 2: and boom you've got a default Rails welcome page in
Speaker 2: your browser. Minutes tops just like that. Then the guide
Speaker 2: usually shows you making a tiny change at a route,
Speaker 2: a super simple controller action to display your own custom
Speaker 2: Hello World. It just hammers home how quick that feedback
Speaker 2: loop is with rails rapid iteration.
Speaker 1: Okay, let's talk. Testing often feels like a chore, But
Speaker 1: why is it so critical, especially for size right from
Speaker 1: the get go right.
Speaker 2: It's not just about finding bugs today, it's about building confidence.
Speaker 2: It's a safety net so when you refactor later or
Speaker 2: add new features, you can deploy without constantly worrying you
Speaker 2: broke something else. It actually speeds up long term development
Speaker 2: because you move faster when you're not afraid to change things.
Speaker 1: That's a great way to put it in. There are
Speaker 1: different kinds of tests.
Speaker 2: Right, Absolutely, you've got your model tests or unit tests,
Speaker 2: so they check small pieces in isolation, make sure a
Speaker 2: specific calculation is right for example. Then view tests and
Speaker 2: the big ones system tests.
Speaker 1: What does system tests do?
Speaker 2: They use tools like Capybara to actually simulate a user
Speaker 2: interacting with your app in a browser, clicking buttons, filling forms,
Speaker 2: the whole flow.
Speaker 1: Ah, so they test the whole stack together exactly.
Speaker 2: They're powerful, but they're also slow.
Speaker 1: To run, okay, so there's a trade off.
Speaker 2: Definitely, you use system tests for your most critical user paths,
Speaker 2: sign up, core feature usage, for edge cases or specific
Speaker 2: controller logic, you rely on faster controller or unit tests
Speaker 2: to get quick feedback makes sense.
Speaker 1: Any specific testing tools that are really indispensable here.
Speaker 2: I definitely mentioned simple cough. It shows your test coverage
Speaker 2: literally highlights which lines of code your tests are.
Speaker 1: Hitting, so you know what's not being tested precisely.
Speaker 2: And the other big one is VCR.
Speaker 1: VCR like the old video takes hah.
Speaker 2: Yeah, the name's a bit retro, but it records external
Speaker 2: API calls like to stripe or get hub the first
Speaker 2: time your test runs them. Then on subsequent runs, it
Speaker 2: just plays back that recorded response.
Speaker 1: Ah, so your tests don't actually hit the live API.
Speaker 2: Every time exactly makes tests way faster, more reliable, and
Speaker 2: you can even run them offline. Huge time saver, especially
Speaker 2: for APIs that change or have right limits brilliant.
Speaker 1: And to run all these tests automatically, that's continuous integration,
Speaker 1: right yeap.
Speaker 2: CI services think Circle Ci, Travis CI, Semaphore, GitHub actions.
Speaker 2: They run your full test suite automatically. Every time you
Speaker 2: push code, you get immediate feedback did your change break anything?
Speaker 2: Crucial for team velocity and keeping the codebase healthy.
Speaker 1: Okay, shifting gears a bit. Users can't have a songs
Speaker 1: without them. How do you start setting up a solid
Speaker 1: user system in rails?
Speaker 2: Users are everything? Yeah, it starts with a user model.
Speaker 2: You add attributes you need, name, time zone, maybe rules later.
Speaker 2: A really important detail, often overlooked early on, is adding
Speaker 2: a hasheet or UUID.
Speaker 1: Why is that important?
Speaker 2: It's mainly for security and cleaner URLs. Instead of seeing
Speaker 2: users one users two in the URL, which someone could
Speaker 2: guess or iterate.
Speaker 1: Through trying to find other users data.
Speaker 2: Right, a UID gives you something like user say three
Speaker 2: B seven C it's nonsequential, unpredictable, much safer, and Rail's
Speaker 2: database migrations handle adding these columns and changing your database
Speaker 2: schema really smoothly. That's a core strength.
Speaker 1: Okay, And for actually logging users in authentication is building
Speaker 1: your own login system still a thing people do.
Speaker 2: Please please don't. Rolling your own off is notoriously hard
Speaker 2: to get right. Security is complex, So what's the standard approach?
Speaker 2: Devise It's a gem, It's been around forever, it's battle tested.
Speaker 2: It handles sessions, cookies, password resets, confirmations, the works, and
Speaker 2: it gives you basic views you can customize using device,
Speaker 2: saves you a massive amount of time and prevents countless
Speaker 2: security headaches.
Speaker 1: Good advice. So users can log in. Yeah, but then
Speaker 1: you often need roles right, like admins versus regular users.
Speaker 1: How's that handled right?
Speaker 2: So first you need the basic flows sign in, sign out,
Speaker 2: sign up, make sure you have clear feedback using rails
Speaker 2: flash messages. User invites are also common, especially for team
Speaker 2: based apps. For roles themselves, a gem called rollifies really popular.
Speaker 2: It lets you associate roles you define them like dot
Speaker 2: admin or dot member with your users.
Speaker 1: Okay, so user has a role.
Speaker 2: Yep, and then you need to connect that role to
Speaker 2: what they're allowed to do.
Speaker 1: That's authorization and how do you manage that? Is there
Speaker 1: standard way?
Speaker 2: Can can can is the go to gem here. It's
Speaker 2: incredibly powerful because it lets you define all your authorization
Speaker 2: roles in one central place, usually a file called ability dot.
Speaker 1: RB one file for all permissions.
Speaker 2: Yeah, pretty much. It keeps things really organized.
Speaker 1: How fine grained can you get with those rules?
Speaker 2: Very you define can or cannot rules, you combine actions
Speaker 2: like read dot create, dot update, dot manage, which is
Speaker 2: like a wild card with specific models. So you could
Speaker 2: say a user can manage their own projects, but they
Speaker 2: can read projects belonging to their team.
Speaker 1: Ah okay, very specific exactly.
Speaker 2: And if someone tries to do something they're not allowed
Speaker 2: to can can can helps you catch that and redirect them,
Speaker 2: maybe show an access denied message.
Speaker 1: And obviously you need to test all of this thoroughly.
Speaker 1: The log ins, the roles, the permissions absolutely critical.
Speaker 2: You'd use a mix of tests here. Controller specs are
Speaker 2: good for checking the logic does this role get redirected correctly?
Speaker 2: And system specs are essential for testing the full user experience.
Speaker 2: Can a user actually sign up, log in and access
Speaker 2: the things they should be able to access.
Speaker 1: Right makes sense. Okay, let's dive into the core business logic,
Speaker 1: the real meat of the application. The source mentioned scaffold
Speaker 1: quite a bit. Rails G scaffold. What is that and
Speaker 1: why is it highlighted? Ugh scaffolding. This is where rails
Speaker 1: can feel like magic sometimes, especially when you're starting. It's
Speaker 1: a generator command. You run rails G scaffold stand up,
Speaker 1: for example, and it instantly creates the model, the database, migration,
Speaker 1: the controller with all the basic actions index, show, new, create, edit, update,
Speaker 1: destroy the views for each action and basic tests.
Speaker 2: Wow. Okay, the whole cru setup in one command.
Speaker 1: Exactly, crud, create, read, update, delete. It gives you a
Speaker 1: fully working interface for managing that stand up object in minutes.
Speaker 1: Huge shortcut for getting basic features up.
Speaker 2: But it's not the final code, right. You don't just
Speaker 2: deploy the scaffold output.
Speaker 1: Oh definitely not. Think of it as a starting point,
Speaker 1: a really, really good starting point. You almost always need
Speaker 1: to customize the generator code, change the forms, tweak the
Speaker 1: controller logic, adjust the views. But it saves you from
Speaker 1: writing all that boilerplate yourself. It's you maybe eighty percent there.
Speaker 2: Or fast okay, so you scaffold then customize using our
Speaker 2: stand up tracker example. What are some key business models
Speaker 2: or patterns you'd build on top of that. Well, one
Speaker 2: neat concept the source mentions is tracking the current date
Speaker 2: using RAILS sessions and maybe a dedicated controller. The app
Speaker 2: can remember which date the user is looking at.
Speaker 1: So if I navigate away and come back, I'm still
Speaker 1: looking at yesterday's stand ups exactly.
Speaker 2: It provides context across the application, very useful for something
Speaker 2: like a daily stand up tracker.
Speaker 1: And what about relationships like users belonging to teams?
Speaker 2: That's a classic RAILS pattern has many through You'd have
Speaker 2: user model, a team model, and a team membership model.
Speaker 1: In between that links them the join table.
Speaker 2: Right, it makes it easy to ask what teams does
Speaker 2: this user belong to user dot teams? Or who are
Speaker 2: the members of this team team dot users? Very clean.
Speaker 2: You could also use similar patterns for things like static lookups,
Speaker 2: maybe using enom for days of the week or something.
Speaker 1: Got it and I saw something interesting about tasks single
Speaker 1: table in Harrodan's STI. What's that about?
Speaker 2: Ah STI? It's a clever database pattern. Imagine in our
Speaker 2: stand up app you have different types of tasks, things
Speaker 2: you did, things you plan, Toto, and maybe blockers.
Speaker 1: Okay, three distinct types.
Speaker 2: Instead of creating three separate database tables DIDs Toto's blockers,
Speaker 2: you use one tasks table and you add a special
Speaker 2: type column to that table. Rails uses this column to
Speaker 2: know which class each row represents, did Toto or blocker?
Speaker 1: So they all live in one table, but your code
Speaker 1: treats them as different classes exactly.
Speaker 2: It's great for models that share a lot of common
Speaker 2: attributes but have some distinct behaviors. Keeps your schema simpler.
Speaker 1: Very cool now, making all this feel dynamic and interactive.
Speaker 1: Hot Wire seems to be a big deal in Rails seven.
Speaker 1: What is it?
Speaker 2: Hot Wire is huge. It's basically a collection of technologies
Speaker 2: Turbo stimulus, JS and strata for mobile designed to give
Speaker 2: you that fast interactive SPA.
Speaker 1: Like field SBA being single page application. Right.
Speaker 2: But here's the kicker. You get that feel without writing
Speaker 2: much custom JavaScript. That's the revolutionary part for many Rails devs.
Speaker 1: How does that work? No JavaScript framework needed largely. No.
Speaker 2: Hot wire sends HTML over the wire, not Jason. It
Speaker 2: leverages the server to render HTML fragments and then uses
Speaker 2: clever techniques to update the page.
Speaker 1: Okay, break that down. What does turbo do.
Speaker 2: Turbo has a few parts. Turbo drive intercepts, link clicks
Speaker 2: and form submissions. Instead of a full page reload, it
Speaker 2: fetches the new page in the background and cleverly swaps
Speaker 2: out just the body or specific parts. Makes navigation feel instant.
Speaker 1: Okay, faster page changes. What about real time updates like
Speaker 1: seeing a teammate stand up appear without refreshing.
Speaker 2: That's turbo streams. It uses web sockets to push small
Speaker 2: HTML changes directly from the server to all connected clients.
Speaker 2: Someone saves the stand up, a turbostream message goes out
Speaker 2: and bam, it appears on everyone else's screen.
Speaker 1: And Turbo frames.
Speaker 2: Turbo frames let you designate specific sections of your page.
Speaker 2: Turbo frame tags as independent updatable Click a link inside
Speaker 2: a frame and only that frame's content gets replaced. Great
Speaker 2: for things like editing a single item in a list
Speaker 2: without reloading the whole list.
Speaker 1: And you can still use JavaScript if you need to
Speaker 1: for things like date pickers.
Speaker 2: Absolutely, that's where stimulus js comes in. It's a modest
Speaker 2: JavaScript framework that connects JavaScript controllers to HTML elements using
Speaker 2: data attributes the source shows integrating a JavaScript date picker
Speaker 2: like flat picker stimulus handles the interaction and then maybe
Speaker 2: triggers a turbo request to update the page content based
Speaker 2: on the selected date. They work together beautifully.
Speaker 1: So putting it all together, the stand up app can
Speaker 1: show stand ups based on different filters.
Speaker 2: Yeah, you can easily build views that show your stand
Speaker 2: ups or all stand ups for a specific team, or
Speaker 2: all stand ups from a particular user on their profile page. Rails,
Speaker 2: routing and controllers handle the data fetching, and hot wire
Speaker 2: makes the presentation dynamic and fast.
Speaker 1: Okay, moving beyond the core UI in models, let's talk
Speaker 1: robustness and integrations objects. You call them the secret sauce.
Speaker 1: Why are they so important?
Speaker 2: AI? Yeah, secret sauce might be a bit much, but
Speaker 2: they are really helpful for keeping your code clean as
Speaker 2: the app grows. The core idea is to prevent fat
Speaker 2: controllers or fat models where you cram way too much
Speaker 2: business logic into those default rails classes.
Speaker 1: So you pull logic out exactly.
Speaker 2: You create dedicated Ruby classes service objects that handle one
Speaker 2: specific business process or action like create user process payment.
Speaker 2: Since stand up reminder, it makes the code much easier
Speaker 2: to understand, test and maintain. You know exactly where to
Speaker 2: look for the logic related to creating a user.
Speaker 1: Are their best practices for writing them? Yeah?
Speaker 2: Definitely. A common one is to have just one public
Speaker 2: method often called dot call, makes its purpose clear, keep
Speaker 2: dependencies internal or pass them in, and crucially return something meaningful,
Speaker 2: not just true or false.
Speaker 1: What kind of meaningful object?
Speaker 2: Maybe a simple struct or an immutable struck that indicates
Speaker 2: success and carries the results object like the newly created
Speaker 2: user or any errors that occurred. Gives you much more
Speaker 2: context than a boolean.
Speaker 1: Can you give a concrete example?
Speaker 2: Sure, the source uses a new registration service. When the
Speaker 2: user signs up, this one service might coordinate several steps.
Speaker 2: Create the hat record, create a user, maybe create a
Speaker 2: striped customer record, queue up a welcome email, send a
Speaker 2: Slack notification.
Speaker 1: Okay, lots of steps right.
Speaker 2: Putting all that logic directly in your user's controller would
Speaker 2: be a mess. The service object orchestrates it cleanly. You
Speaker 2: can even use namespaces like notification services, dot, Slack, webooks,
Speaker 2: dot new account to organize related services.
Speaker 1: Okay, that makes sense. Now, Some of those steps like
Speaker 1: sending emails or talking to stripe might take a second
Speaker 1: or two. How do you prevent that from slowing down
Speaker 1: the user's request?
Speaker 2: Background jobs absolutely essential for a responsive web apps. You
Speaker 2: identify tasks that don't need to happen immediately within the
Speaker 2: web request cycle, sending emails, processing images, calling slow external APIs,
Speaker 2: and you push them onto a background queue so.
Speaker 1: The web request finishes quickly and the job runs later exactly.
Speaker 2: The user gets a fast response and a separate process
Speaker 2: picks up the job from the queue and executes it
Speaker 2: in the background. Keeps your app feeling snappy.
Speaker 1: How does Rails handle that?
Speaker 2: Rails has a built in framework called active job. It
Speaker 2: provides a standard way to define your jobs. Then you
Speaker 2: choose a back end adapter to actually run the jobs.
Speaker 2: Sidekick is probably the most popular for Rails. It uses rttus.
Speaker 2: It's very fast and reliable.
Speaker 1: Could use schedule jobs too, like send a daily email yep.
Speaker 2: You can use extensions like Sidekick, dot cron or similar
Speaker 2: tools to schedule jobs to run at specific times or intervals.
Speaker 2: Perfect for daily reminders, weekly reports, nightly cleanups, et cetera.
Speaker 1: Speaking of emails, how does Rails actually send.
Speaker 2: Them through action mailer? It's another built in framework. You
Speaker 2: define mailer classes similar to controllers, with methods for each
Speaker 2: type of email you want to send. You can create
Speaker 2: both HTML and plaintext versions easily.
Speaker 1: And you mentioned deliver later for background jobs right.
Speaker 2: You can call deliver now to send it immediate lee
Speaker 2: usually only for testing or very specific cases, or deliver
Speaker 2: later to queue it up via active job. Always use
Speaker 2: deliver later for real world emails.
Speaker 1: What else do you need for emails and production just
Speaker 1: action mailer?
Speaker 2: No, you'll need an actual email delivery service like send grid, Postmark,
Speaker 2: or mail gun. Your server itself usually isn't configured for
Speaker 2: reliable mass email delivery. You also need to configure DNS
Speaker 2: records SBF, DKM for your domain to ensure your emails
Speaker 2: don't end up in spam folders.
Speaker 1: And apikeys for those services, How do you store those? Securely?
Speaker 2: Rails credentials It's a built in way to manage secrets.
Speaker 2: It creates an encrypted file canfig credentials, dot email, dot
Speaker 2: enc where you store apikeys and other sensitive stuff. This
Speaker 2: file can be checked in to get but you need
Speaker 2: the master key canfig master dot key which you never
Speaker 2: check in to decrypt it. Very secure way to handle secrets.
Speaker 1: Okay, that's sending email. What about receiving email? Can rails
Speaker 1: handle replies? Yes?
Speaker 2: This is super powerful. Action Mailbox is the framework for this.
Speaker 2: That's your Rails application receive incoming emails. You can figure
Speaker 2: specific email addresses like replies at your wapp dot com
Speaker 2: to route emails into your application.
Speaker 1: What could you do with them?
Speaker 2: Then you define mailboxes that process incoming emails. Based on
Speaker 2: routing rules, you can parse the email content, extract data,
Speaker 2: and trigger actions in your app. Imagine replying to a
Speaker 2: stand up reminder email with your updates and action Mailbox
Speaker 2: automatically parses it and saves your stand up Very cool stuff.
Speaker 1: Wow, Okay, that opens up possibilities. Let's talk money. Stripe
Speaker 1: integration for payments and subscriptions. How does that typically work?
Speaker 2: In rail SaaS Stripe is pretty much the de facto standard.
Speaker 2: It's very developer friendly. First, you define your products and
Speaker 2: prices in the Stripe dashboard, your different subscription tiers, free, pro,
Speaker 2: enterprise and how much they.
Speaker 1: Cost, and link those to your app.
Speaker 2: Yeah. You often map those Stripe product price IDs to
Speaker 2: something in your application, maybe a configuration file, products dot
Speaker 2: AML or a simple product model. This lets your app
Speaker 2: know the limits associated with each plan like max users,
Speaker 2: features available, etc.
Speaker 1: How does the sign up flow work with Stripe?
Speaker 2: Typically, when a user signs up or upgrades, your application
Speaker 2: interacts with stripes API. You create a Stripe customer object
Speaker 2: for the user count. Then you create a subscription linking
Speaker 2: that customer to a specific price. Stripe handles the actual
Speaker 2: payment processing. Your app just needs to store the Stripe
Speaker 2: customer ID and subscription ID on your account or user model,
Speaker 2: and then.
Speaker 1: You check that subscription status to enforce limits exactly.
Speaker 2: You'll have logic, maybe a before reaction in your controllers
Speaker 2: or checks within specific features that looks at the account's
Speaker 2: subscription status. Is the subscription active, what plan are they on?
Speaker 2: Based on that, you allow or deny actions, or maybe
Speaker 2: redirect them to a billing page if they hit a limit.
Speaker 2: Stripe provides a pre built billing portal you can easily
Speaker 2: link users to for managing their subscription.
Speaker 1: And testing this. You don't want to actually charge credit
Speaker 1: cards during.
Speaker 2: Tests, absolutely not. This is where mocking comes in again.
Speaker 2: You use libra is like webmoc or VCR again to
Speaker 2: intercept any calls to the Stripe API during your tests,
Speaker 2: you provide fake successful or failed responses. This ensures your
Speaker 2: tests run quickly and reliably without hitting striped servers or
Speaker 2: needing real card details. Crucial.
Speaker 1: Okay, beyond payments, what about integrating with other APIs like GitHub?
Speaker 2: The pattern is often similar, usually involving o off for authorization.
Speaker 2: For GitHub, you'd register an oof app. When a user
Speaker 2: wants to connect their account, you redirect them to Gethub
Speaker 2: to authorize your application.
Speaker 1: Big grant permission right.
Speaker 2: GitHub redirects them back to your app with a temporary code.
Speaker 2: Your app then exchanges that code securely with GitHub's API
Speaker 2: to get an access token. You store that token securely,
Speaker 2: maybe using Rails credentials or database encryption, and then you
Speaker 2: can use it to make API calls on the user's
Speaker 2: behalf like listing their repositories.
Speaker 1: And getting real time updates from GitHub like new code pushes.
Speaker 2: That's webhooks. You'd use the GitHub API using the user's
Speaker 2: token to tell GitHub, Hey, whenever there's a push event
Speaker 2: on this repo, send a notification to this URL on
Speaker 2: my application.
Speaker 1: So getthub calls your app exactly.
Speaker 2: Your app needs an endpoint ready to receive that webhook data.
Speaker 2: You'd probably store these incoming events in your database, maybe
Speaker 2: in an event table. STI could be useful here too.
Speaker 2: For different types of events push event, pull request event,
Speaker 2: you might store the raw event, payload and adjson B
Speaker 2: column for flexibility.
Speaker 1: And finally, tracking what users are doing in the app.
Speaker 2: Analytics Yeah, super important for understanding usage and making decisions.
Speaker 2: Tools like mixed Panel or segment or common you integrate
Speaker 2: their stks and send events from your rails app back
Speaker 2: end or potentially the front end. JavaScript you identify users
Speaker 2: and track key actions users sign up, page viewed, feature used,
Speaker 2: stand up, created, plan, upgraded gives you valuable insights into
Speaker 2: user behavior.
Speaker 1: Okay, we've built a lot, now making it fast and
Speaker 1: getting it deployed. Optimizations First, what are the low hanging fruit,
Speaker 1: the real bang for your buck performance improvements?
Speaker 2: Good question? First, know where the slownesses. Tools like Rackmini
Speaker 2: Profiler show you database query times and rendering times right
Speaker 2: in your browser during development. Essential first step.
Speaker 1: Okay, diagnose first, Then what.
Speaker 2: N plus one queries? Huge performance killer. This is when
Speaker 2: you load a list of things like teams and then
Speaker 2: loop through them, making a separate database query inside the
Speaker 2: loop to get related data like the users for each team.
Speaker 1: One query for the list, then end queries inside.
Speaker 2: The loop exactly. You fix it with eager loading. In Rails,
Speaker 2: you use dot includes or references on your initial query
Speaker 2: team dot includes, dot users, dot all that tells Rails
Speaker 2: to fetch all the teams and their associated users in
Speaker 2: just one or two efficient queries.
Speaker 1: Are there tools to fined N plus ones?
Speaker 2: Yes? The bullet gem is fantastic for detecting N plus
Speaker 2: one queries and other database issues automatically during development. It'll
Speaker 2: pop up warnings telling you where to add eager loading.
Speaker 1: What else slows down database access.
Speaker 2: Missing database indices. If you're freequently looking up records by
Speaker 2: a column that doesn't have an index, like finding a
Speaker 2: user by email, the database has to scan the hotal
Speaker 2: terribly slow on large tables.
Speaker 1: How do you find missing indices?
Speaker 2: Tools like luld blog can scan your models and usage
Speaker 2: patterns and suggest indices you should add. Adding the right
Speaker 2: indices can make lookups orders of magnitude faster.
Speaker 1: What about just displaying lots of data like a huge
Speaker 1: list of stand ups pagination.
Speaker 2: Don't try to load and render thousands of records on
Speaker 2: one page. It kills memory and browser performance. Use a
Speaker 2: gem like pagy, which is very fast and memory efficient
Speaker 2: to break results into pages, show twenty or fifty items
Speaker 2: at a time. Huge improvement for user experience and serverload.
Speaker 1: Any quick server side wins Gzip compression.
Speaker 2: Rails has middleware called rack deflator that can automatically compress
Speaker 2: responses htmail json before sending them to the browser. Smaller
Speaker 2: response size means faster downloads. It's usually just a one
Speaker 2: line configuration change.
Speaker 1: Easy win, okay, and the big one casing How does that?
Speaker 2: Cashing is probably the single most impactful performance technique. The
Speaker 2: basic idea is don't recalculate or rerender something if it
Speaker 2: hasn't changed, store the result and reuse it.
Speaker 1: Where do you store the cash stuff?
Speaker 2: You can figure a cash store. Rettis is very common
Speaker 2: and versatile for cashing in Rails. Memcash is another option.
Speaker 2: You can even use the filesystem or memory for development.
Speaker 1: What kinds of things can you cash?
Speaker 2: Several levels. There's low level caching, where you cash raw
Speaker 2: data like the result of a complex query. Then there's
Speaker 2: fragment caching, which is really powerful in RAILS views. You
Speaker 2: wrap a piece of HTML, maybe a complex partial in
Speaker 2: a cash block. Rails renders at once, stores the HPML fragment,
Speaker 2: and reuses it on subsequent requests until the underlying data changes.
Speaker 1: How does it know when the data changes?
Speaker 2: Typically through cash keys based on the objects being rendered.
Speaker 2: If you cash a block based on a at product object,
Speaker 2: Rails uses the products it and update at timestamp and
Speaker 2: the key. When the product updates, the key changes and
Speaker 2: the cash is invalid.
Speaker 1: In Russian doll caching sounds complex.
Speaker 2: It builds on fragment caching. Imagine you cash a list
Speaker 2: of products, and each product in the list is also
Speaker 2: cashed individually, like nested Russian dolls. The magic is that
Speaker 2: if you update one product, Rails can automatically invalidate just
Speaker 2: that product's fragment and the outerless cash that contained it.
Speaker 2: It often involves using touch true on model associations or
Speaker 2: after commit hooks to ensure parent objects updated timestamps change
Speaker 2: when children change, automatically busting the cash. Very efficient. How
Speaker 2: you set up cashing, You can figure your cash store
Speaker 2: in your environment files example fund environments, production, dot RP
Speaker 2: tell Rails to use reddis You can easily toggle cashing
Speaker 2: on off and development with binrailsdev dot cash.
Speaker 1: Okay apps optimized time to deploy. Heroku is mentioned as popular.
Speaker 1: How do you prep for that?
Speaker 2: Heroku is great for getting started. Before deploying. You need
Speaker 2: to configure production specific settings your domain name, mailer settings
Speaker 2: using those SND grid keys, maybe forcing SSL.
Speaker 1: And the deployment process itself.
Speaker 2: It's pretty standard Heroku workflow. Install the Heroku Cli two belt,
Speaker 2: run Heroku create to create your app. Add necessary add
Speaker 2: ons like postgrass, Heroku add ons dot create, Heroku postgress
Speaker 2: call and rettis Heroku add ons dot create, Heroku rettis.
Speaker 2: Set your environment variables securely using Heroku configu do set,
Speaker 2: especially the Rails master key needed to decrypt your credentials.
Speaker 2: You might need to adjust your profile to specify how
Speaker 2: many web workers and background job sidecack workers to run.
Speaker 2: Then it's just get push Heroku Maine to deploy your code,
Speaker 2: followed by Heroku run rails dB dot migrate to update
Speaker 2: the production database.
Speaker 1: STEMA seems straightforward enough for basic deployment. Any other cool
Speaker 1: modern rails tools worth mentioning for sauce.
Speaker 2: Oh yeah, Rail seven brought lotuing for active record queries.
Speaker 2: If you have a page that needs to run say
Speaker 2: three independent database queries to gather data for different sections
Speaker 2: look at dashboard exactly. Instead of running them one after another,
Speaker 2: lotusink lets them run concurrently, potentially speeding up data loading significantly.
Speaker 2: And another big one is active record encryption.
Speaker 1: Encrypting data in the database YEP.
Speaker 2: Rail seven has built in support using the encrypts declaration
Speaker 2: in your model. You can mark attributes like user dotcrypts
Speaker 2: dot email or task dotcrypts dot title. Rails handles the
Speaker 2: encryption and decryption automatically and transparently for your application. The
Speaker 2: data is stored encrypted at rest in the database, but
Speaker 2: your app code just reads and writes it normally. Adds
Speaker 2: a great layer of security for sensitive data.
Speaker 1: Wow, that's built right in. Very nice. Okay, so we've
Speaker 1: covered a kind of ground here. What does this all
Speaker 1: mean for someone listening trying to learn or build their
Speaker 1: own saws.
Speaker 2: I think the big takeaway is seeing the whole journey
Speaker 2: mapped out from that initial Rails new and setting up
Speaker 2: users with solid off through building core features, handling payments,
Speaker 2: integrating APIs, using background jobs all the way to optimizing
Speaker 2: and deploying. Rails provides tools and conventions for almost every step.
Speaker 2: It's amazing how this one framework guides you through such complexity,
Speaker 2: often quite elegantly.
Speaker 1: It really paints picture of how all these pieces connect.
Speaker 1: The database, the back end logic, the frontend reactivity with
Speaker 1: hot wire, the external services.
Speaker 2: Absolutely, building a sauce is a deep dive. It's not
Speaker 2: just one thing, it's this whole ecosystem of interconnected parts
Speaker 2: working together.
Speaker 1: So as you, the listener, reflect on everything we've unpacked
Speaker 1: from this guide, here's something to think about. How might
Speaker 1: understanding this deep interplay between that server driven frontend reactivity
Speaker 1: like hot wire and the back end efficiency techniques like
Speaker 1: background jobs and sophisticated caching. How might that fundamentally change
Speaker 1: the way you approach building your next major software project,
Speaker 1: even if you're not using rails