RoR Debugbar | Hacker News Reader

RoR Debugbar

debugbar.dev

298 pointspuuush77 comments

Hi I’m the maker of the debugbar. If you have any feedback or question, just let me know.

Thanks puuush for posting it.

Hey Julien, very nifty!

Can you comment on the inspiration/ similarity with the Laravel Debugbar [1]? I noticed your GH says "Laravel by Night" :)

[1] https://github.com/barryvdh/laravel-debugbar

If you click learn-more on the linked page the first section ends with this:

".... I was able to explore my application in ways I didn't think was possible. Yet, I always missed what I was used to in PHP with the Laravel Debugbar."

I’m a big fan of the Laravel debugbar. I even added the Jobs collection when I started working on this https://github.com/barryvdh/laravel-debugbar/pull/1470

Symfony’s dev toolbar has got to be one of the best.

https://symfony.com/doc/current/profiler.html

Always miss this in my RoR projects.

Yeah it does SO MUCH!

There's peek[1], albeit not exactly the same thing

[1] - https://github.com/peek/peek

I didn’t see a demo, only the closed bar with some timing stuff. Does it open to do more?

Last commit was 5 years ago. I feel like this is 80% of the rails ecosystem nowadays.

I definitely get that feeling as well. 80% ghost town

Yet almost all of it still works.

All of it almost works.

I'm moving from Phoenix back to Rails for a new project. Is it true Rails is dead? I thought it's community was at least 10x the size of Elixir's.

Rails isn't dead. In fact Hotwire and Stimulus have breathed some new life back into the community. With Rails 7 there's new and interesting changes happening like the normalize method for normalizing data before it's persisted to the database, the new testing coverage, and the new encrypted credentials, which can replace devise as it's easier to extend. STI is still awesome and concerns help DRY up the code. I know it's not the new kid on the block anymore, but if you code into a Rails way of doing things it's still crazy fast for rapid development.

I dont know

People who use Rails really seem to love it.

But in 2024 things like react and typescript exists.

Python is there for data science stuff

Typescript is there for the web.

I don't understand why you would pick Ruby instead

It’s a good choice for building a full stack web application. You know… the stuff that it is designed for.

Ruby is a very beautiful language both in logic and consistency. Rails is a mature framework. The ecosystem is very much alive albeit not “exciting” anymore and at the end of the day people use what they know. The 2010s have produced a large number of Rails developers. For the majority of CRUD apps Rails (or Laravel or Django) are just fine thus there’s no need to really make a switch. Finally, React can power a lot of things but in my experience it is far from offering the right integration and rapid development speed that something like Rails or Laravel come with.

> react and typescript

These are nonstarters for me. It seems like vercel has corrupted react beyond recognition, and other full-stack frameworks like Remix just do a lot of `rigamarole` to mimic a fraction of what an older fullstack framework like rails/django/phoenix can do.

frontend is desperately trying to catch up to backend.

backend is trying to capture frontend to seduce people back, and they're getting there with freakishly good UX like phoenix liveview and rails 8's morph.

This. So much this.

> But in 2024 things like react and typescript exists.

Avoiding this stuff is one point on the list. I know I'm being a little snarky, but it's true. If you're building a fullstack app with fullstack devs you can avoid a lot of complexity that stuff brings.

Rails is practically unusable for anything that requires concurrency inside of serving one request. If you have all your data in the database that your rails app connects to everything is great. If you need to call out over the network to 12 different services to serve your request or want to do computationally intensive things, etc, another language with support for concurrency is a better choice imho.

You could say the same for PHP. But for 99.9% of applications, that doesn't apply.

Yeah, right. Because all the interesting things nowadays happen on the same server that renders your html and nobody calls into other SaaS APIs or interacts with external systems much.

Rails is great for a world where an app was running on one server, but that world just isn't there anymore as much as it used to.

> Rails is great for a world where an app was running on one server, but that world just isn't there anymore as much as it used to.

No, that’s still a choice you can make. It’s still possible to make your app run on one server with Rails/Django/PHP and to scale it horizontally and vertically very easily. The requirements of a web app / web site barely changed in 10-15 years, the only things that changed is that new ways to do the same things appeared regularly : some were real improvements, most are just hype-driven.

If you need to call external APIs you can still do it on the client if that’s what you want or on the server with task queues / messages queues which are still a good practice anyway and which can be handled by how many servers you want.

How would you move ChatGPT 4 inside your rails app?

Can you explain why concurrency within processing a request makes things difficult for Rails?

The currently prevailing model in Rails is that a worker is a process that has an instance of your application running (ie the code loaded, global variables initialized etc). Let's say your service makes a request out to OpenAI and waits 5s for a model inference response. During that time, that particular worker that is servicing your request will sit around, needs to keep the 300MB or however big your heap is in memory and effectively does nothing while waiting for OpenAPI to respond. If you have 30GB of RAM to play this game, you'd be able to have 100 workers like this running and you'd be able to service a whooping 100/(5s per request) = 20 requests per second.

Contrast that to other architectures like NodeJS where there's an event loop driving execution that would suspend execution and work on the next request while waiting for OpenAPI to respond. This enables you to service thousands or tens or hundreds of thousands of the same kind of request with the same amount of RAM.

There are approaches to improve this in Ruby/Rails like Fibers, however lots of libraries in the ecosystem use global mutable state and assume it's request local. If you have multiple requests served concurrently by the same worker, they'll overwrite this state and bugs will happen. Also baking this onto the language is not very ergonomical (beautiful in Ruby speech) if you compare it to languages where concurrency has been a primary design concern in the beginning.

The global state trap ... I wonder why people still do these things, especially in web context. Basically whenever one uses mutable global state and actually mutates it, one puts off issues to the future, until one day some poor soul has to deal with this or rewrite.

It's ubiquitously used in the ruby community to this day.

Couldn’t you solve this problem with something like this:

https://ruby-concurrency.github.io/concurrent-ruby/master/Co...

Theoretically yes, but

1. there are lots of problems preventing this working in practice currently (see my sister comment here: https://news.ycombinator.com/item?id=39433274).

2. the result of doing this is not the beautiful ruby code you are used to, compared to languages that have been designed for concurrency from the beginning.

I don't think this is quite right. I've done a survey a few months ago when deciding what to use for a new project (primarily comparing Ruby and Go). What I saw was many people rallying around the top useful libs out there. I also saw numerous brand new libs showing up, fixing mistakes of their predecessors. And each time I compared a popular Ruby project with a popular Go one, I'd find consistent activity from multiple maintainers in the former. And a lot of initial activity that completely dies down in the latter.

The overall feeling I got is that Ruby on Rails has gotten a lot more "getting shit done", "don't waste time" mode, — many businesses depend on it. Libs became higher quality compared to the early playful years.

Author of peek here. Honestly, I got burnt out. We stopped using this internally at GitHub for our secondary Rails applications which made it difficult to continue working on. Rails was going through its identity crisis with asset pipelines and I didn't feel like trying to support every available option for people like Sprockets, Importmaps, NPM, Bower, etc. It was nice when there was the paved path and users could generally follow the README and be up and running quickly.

https://github.com/MiniProfiler/rack-mini-profiler gets you most of the way there and comes by default in the Gemfile for new Rails applications.

Hey there, sorry if this came across as critique on the project itself or you personally. I get it, priorities change and projects get abandoned by the original maintainers.

My comment was more aiming at the ecosystem at large. Lots of the (RoR) stack in my current day job depends on long abandoned libraries with unmerged fix PRs from years ago and I see this all the time in the Rails ecosystem. Interest in the ecosystem is shrinking and this is one symptom.

It's a fair critique! I still keep kicking the can down the road about revisiting the project and modernizing it. The ecosystem has moved along so much since I last revisited it I'll need to take a fresh look at it, accepting the PRs that are currently open is likely out of the question.

> Interest in the ecosystem is shrinking and this is one symptom.

I think the interest in the ecosystem is still very strong, there is just more publicity and marketing around the newest frameworks and capturing peoples attention. Rails is more than ever the best place to go zero to one, and still scaling past 100M at GitHub.

There are so many libraries that are largely feature complete. For example, Devise doesn't need anymore features. There is some traction of going the more lazaronixon/authentication-zero route which is a generator for owning the code rather than having everything live in a gem. This is just one specific example. Rails is moving more and more third party things in house showing it matured in the ecosystem and can move into core Rails.

I find myself reaching to a gem as a last resort if at all possible these days.

This looks excellent. I love the cross-pollination of good ideas that seems to be frequently happening between the Laravel, Phoenix, and Rails frameworks.

> cross-pollination

That's a great analogy!

Very cool project. Similar to the Ruby on Rails debugger that I wrote, which allows you to see all of the methods that are called for a given request (and param values, return values, etc).

https://callstacking.com/

If anyone is interested in this sort of thing I started a proposal with a list of ideas and features around a Rails debug toolbar at: https://discuss.rubyonrails.org/t/proposal-a-fully-featured-...

NOTE: I'm not the author of this tool but they did end up replying in that thread. I didn't even know their tool existed until I happened to stumble upon it on Twitter well after my post.

It would be neat if something like this were built out and included in Rails at some point. Especially with Rails 8 focusing on tool integrations and overall developer happiness.

Django Debug Toolbar > Panels > Default built-in panels, Third-party panels, API for third-party panels: https://django-debug-toolbar.readthedocs.io/en/latest/panels...

Firelogger.py//middleware.py: https://github.com/binaryage/firelogger.py/blob/master/firep...

Distributed tracing w/ OpenTelemetry, Jaeger; Metrics with ~JMX

W3C Trace Context v1: https://www.w3.org/TR/trace-context-1/#overview

First time encountering the term 'debugbar', I see:

> This project is inspired by what you get in the PHP world, with the Laravel debugbar for instance.

Curious to know what a debugbar does? From a read of the docs (and a play around) it looks like it lets you navigate your site as usual, but it displays which controller/action got you to the page, any callbacks, and database queries. Anything else? What's a typical use case for this, or is it more like turn it on and it's just handy to have that extra info in your dev environment?

It's for having in your dev environment and/or sometimes as a toggle for "Special Requests" -- if your session is authenticated and you're marked as blessed, you get extra information about what the application is doing under the hood so you can see what's going on in production as well.

Some let you add whatever information you want into the panel.

It's a convenience feature to make it easier to wade through information rather than having to dredge everything out of logs by hand, which a lot of people still do.

We recently installed something similar (https://miniprofiler.com) into a legacy ASP.NET MVC app. It is setup to only be visible in local development environments.

In areas of the code where ORMs obscure the actual SQL that runs, it's shortened the amount of time and effort it takes to discover a slow route and optimize it.

"Handy to have that extra info in your dev environment" is pretty spot on.

The last two places I've worked I added a custom "debug bar" of sorts. We typically use in dev and lower QA environments, and they quickly become indespensible to help answer questions like "which version of service X is deployed", something that may be easy for a dev to answer as they can look at what is deployed on the server, but harder for a tester who can only access the frontend.

Other useful environmental information we find useful includes "which DB is being used", which OpenShift namespace (with a link to the console), traceability for the deployed artifact (e.g. links to the GitHub release tag, CI pipeline which built the artifact, docker registry with the correctly tagged image). Especially useful if you have downstream or upstream services, is to have colour coded status info about whether the services are up.

For the few days investment getting this up and running, it pays itself back in terms of time gained answering questions such as "Why doesn't this feature work? Oh, after investigation, this service was down during testing".

Also handy (regardless of framework, language, etc) is if you use feature flags, if you're using actual valid credentials against a service or a local testing service (eg S3 vs minio, etc).

Enabling this for non-technical users really helped also report any issues they would see, it was great for testing environments.

Plus you would probably end up needing all this information anyway if you do any error tracking, so it probably exists somewhere already :-).

Hey Julien!

Great to see that you finally released this ;)

Yep! Thank you

You probably want to post it on this thread as well - https://www.reddit.com/r/rails/comments/ekmtgu/anything_simi...

This seems pretty similar to https://github.com/dejan/rails_panel. Was that your inspiration?

Laravel's debugbar is the inspiration.

Cool project, but I hate the use of the RoR acronym

For anyone else who was confused by what ROR means, it's ruby on rails.

Y tho?

Because undefined acronyms suck. Plenty of space in the title for the full "Ruby on Rails Debugbar".

As someone who has used the Laravel version of this I gotta say it has been pretty damn helpful.

Very, very, very cool Idea. I'll try it tomorrow

Very cool, I'll add this to my next project!

Good idea but it seems that every developer of a project is going to have to use it, because it's a gem and it must be included in a layout. It's possible to do that conditionally based on an environment variable, but we're still adding some code to the Rails app. A better way would be to turn it into an extension to developer tools, like the ones for React and Vue. I've got them into my Firefox.

How would you be able to implement this functionality only from the frontend without ever adding backend code? You'll always need to expose this info from the backend somehow. Of course with react and vue the data is available since it's already in the frontend.

Yeah you always need a backend part as part of your dev dependencies but currently you also need to add a little snippet in your production view code.

It could be a browser extension like Rails panel + meta_request but I think it’s also good that anybody working on the codebase always get the debugbar, regardless of their browser or setup.

The downside is that if the project decides not to have that in the code, nobody gets it. Example: I suggest to a customer to use it. They decide they don't want it, I can't use it too.

There’s no reason you couldn’t just leave it in your own branch of git and not merge it. It’s not that hard.

That’s a good point, I didn’t consider it this way.

One thing to check out: ruby-lsp gets around this by using a custom gemfile, which enhances the project with the lsp's dependencies. That means you can use the gem, with bundler, without adding anything to the "official" project gemfile.

You could probably accomplish something similar, and possibly inject some rack middleware to add the view, or even mount it as a rails engine.

Some details from https://github.com/Shopify/ruby-lsp

> NOTE: starting with v0.7.0, it is no longer recommended to add the ruby-lsp to the bundle. The gem will generate a custom bundle in .ruby-lsp/Gemfile which is used to identify the versions of dependencies that should be used for the application (e.g.: the correct RuboCop version).

Without some kind of perf api baked into rails, this will require some server side code at the very least. An extension won't work without _something_ on the server.

But, there's also nothing stopping you from adding this during development and not committing it.

Couldn't you only have the snippet in the layout in dev environment? That's fairly common

Perhaps a future improvement is like how rack-mini-profiler does it, and just injects itself

Just curious... how come noone else in the ruby scene seems to use an actual debugger? IDEA has a front-end for ruby-debug-ide and it is divine, it puts pry to shame. Does VSCode or others not have this or something?

Some of the other stuff mentioned in the blog post... why tail development.log if you can tail stdout and get all that nice console coloration and such?

> I hate switching constantly between the browser, and the terminal where I tail the logs. I want to see the debugging information in the same window.

Get yourself multiple screens my dude.

That said, this looks like an interesting project.

Most devs I've worked in across multiple languages don't use debuggers. They can't be bothered to spend a couple hours figuring it how to configure one. Meh, to each their own. I always spend the time configuring one and it always pays off.

I hate multiple screens more than I hate switching windows :P

Why?

This is amazing. Great work.

Wish there would be one for Go.

After monitoring my portfolio performance, CASSANDRA_ E_ OAKLEY blew me away $70k in the last two quarters alone, I learned why these experienced traders make huge profits from the seemingly unknown market.. Also on Facebook CASSANDRA _E_ OAKLEY

Thought this was going to be about debugging Rigs of Rods bars (joints). Meh

Thought this was about visualizing the 6502 rotate right instruction problem.

Reply on news.ycombinator.com