9 thoughts on “What would you consider advanced topics in Rails?”

  1. I’ve only got a couple years experience w Rails but something I’ve always wondered is the benefits of doing thing the “Rails way”. Like scaffolds for example? Do i get extra security, speed, or compatibility benefits using rails infrastructure as opposed to doing things my own custom way? What about overhead?

    Another one – How to speed up Rails? JIT, TruffleRuby, etc.

    I’ve also been messing around with popular frameworks and libraries. I got react working just fine but when I tried adding tailwind it created a dependency hell that was almost impossible to solve thanks to webpack. Maybe add a section on webpacker? It’s a huge bridge between rails and the rest of the web ecosystem and is not talked about enough. I for one didnt even understand the technology until I went and learned about it, its something rails does so effortlessly out of the box which is nice, but makes it a pain to debug when the time comes that something breaks.

    Also, is your course revolving around Rails 6 or Rails 7? I know rails 7 has some pretty huge changes (including the outright removal of webpacker). I elected not to use it for my new projects because it’s still immature.

    Just some ideas! Would love to see your course when it’s finished.

    Reply
  2. These are some things that I deal with regularly after 15+ years of experience.

    – Deep understanding of background workers, how to scale them, intelligently retry them, and log errors
    – Web sockets and async operations at scale. Can your controller handle hundreds of simultaneous requests? If not, how to address that situation.
    – Working with multiple databases within one codebase
    – Managing your dependencies by keeping them up to date and understanding the api changes when changing versions. Also deciding if I really need that gem or can I replace it with a really simple class?
    – api authentication, rate limiting, and access control
    – Facilitating data transfer between multiple apps (micro services) that share one database
    – module prepending, which I have only seen 3-4 good implementations over the years and so many bad implementations. More broadly, deciding when to use or not to use ruby’s dynamic language features.

    Reply
  3. * goodies in ActiveSupport (e.g. ActiveSupport::Duration)
    * Arel
    * following the “Law of Demeter” with Ruby’s delegate and ActiveRecord’s query merge

    Reply
  4. – Rails engine and Rack applications
    – ActiveRecord for complex queries and their manipulation (when a query is triggered and when not)
    – how to quickly benchmark different query approaches. I find this very handy when tables billions records

    Reply
  5. – Custom Rack configuration (maybe a bit much for a course)
    – Separation of logic dealing with database transactions
    – Modularity, namespacing
    – Testing best practices
    – Complex “Rails flavored” querying
    – Caching (Dalli, etc)

    Reply
  6. IMO most of the actually advanced stuff doesn’t have that much to do with Rails itself, they’re just things you have to understand in order to build certain large-scale scale applications. The advanced stuff comes in once you’re starting to exit the help Rails provides for you. For example:

    * multi-tennancy
    * database sharding
    * advanced caching strategies (nesting doll, pre-caching, cache busting strategies, dedicated cache servers, etc)
    * metaprogramming
    * advanced performance techniques (loop unrolling, highly optimizing key code, dropping down into C, etc)
    * anything that you might realistically label as “high volume”
    * database scalability (indexing, ratios, hand-writing SQL for performance, reading stats tables to identify bottlenecks, etc)
    * authoring and hosting gems/engines to share business logic across codebases in a platform
    * decoupled but interconnected services/microserves or platform apps

    edited in some examples

    Reply
  7. An important point – that has nothing to do with Rails – might involve teaching how to:

    * Cut down the scope which encompasses a further question: are we solving the right problem? Both involve questions of judgment, priorities, and weighing things up. Resources are not infinite.

    * Seeing where problems exist in the Rails eco-system, and fixing them via PRs. I suppose you’d learn a lot from these excercises.

    Reply

Leave a Comment