Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Rails

jmduke.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Use Rails

#51

Post by dv35z »

mariocesar wrote: post #43
dv35z wrote: post #15

Earlier quoted context omitted.

What is your ideal Django stack (from front-end, to backend, APIs, database, hosting, etc), using well-supported, solid tech?

One ideal setup I have is: Django + htmx + templates with jinja2 (to use macros) and styling with tailwindcss The good part is that if you start early with a good design, it's fairly clear how to move from views to a REST API (DRF or Django-ninja) later and split the front end if you need to.

That's interesting - I'll have to explore HTMX and TailWindCSS further - one thing that has held me back is just looking at the HTML source, with all the odd tags, looks messy. I know that's an emotional reaction and not a technical one, but I do appreciate looking at code which just looks clean and neat to me...

I've been learning React / Django / Bootstrap (open to ideas on that, but it's just been "there" for me) / SQLite, Postgres / Stripe for payment, Docker, and hosting on AWS and exploring Fly.IO for hosting. I haven't dug into APIs, but curious your thoughts DRF / FastAPI / Django-ninja).

I know this is a Rails thread, so there might be a better place to have a discussion about it...

Thanks for your insights!

Re: Use Rails

#52

Post by spudlyo »

_heimdall wrote: post #40
samlambert wrote: post #35

Earlier quoted context omitted.

what limitations? PlanetScale has public companies running on top of it. If a startup found limitations then its a skill issue.

This was when foreign keys still weren't supported by Planetscale. The specific data model was heavily relational and queries were very inefficient without foreign key support. Distributed writes were also important, and if I remember right those weren't supported either though that's a really common limitation. Assuming a particular tool works for all situations because it works for some is a mistake though. Plenty…

> The specific data model was heavily relational and queries were very inefficient without foreign key support.

I can't help but wonder if you're conflating the notion foreign keys (and the usefulness of having them be indexed) and foreign key constraints, which ensure data integrity at the expense of write performance.

I have a narrow view of the performance of MySQL foreign key constraints and would be interested in learning of cases where they might actually improve certain queries.

Re: Use Rails

#53

Post by alex_lav »

Geee wrote: post #46

For web apps maybe. What's the "boring" / productive stack for desktop apps? There's this weird paradox with programming languages which causes unproductive stacks to become more popular because programmers like "difficult" stuff and they also generate more online activity.

> What's the "boring" / productive stack for desktop apps?

I've been trying to find it for years. I've started maybe 5ish desktop apps over the last decade and each time did the dance of "QT can't possibly be it...can it?" And then googled and tried everything I could find. In my experience it's all pretty bad. Unironically the best solutions I've found are either Unity/Godot or Electron.

Re: Use Rails

#54

Post by mariocesar »

dv35z wrote: post #51
mariocesar wrote: post #43

Earlier quoted context omitted.

One ideal setup I have is: Django + htmx + templates with jinja2 (to use macros) and styling with tailwindcss The good part is that if you start early with a good design, it's fairly clear how to move from views to a REST API (DRF or Django-ninja) later and split the front end if you need to.

That's interesting - I'll have to explore HTMX and TailWindCSS further - one thing that has held me back is just looking at the HTML source, with all the odd tags, looks messy. I know that's an emotional reaction and not a technical one, but I do appreciate looking at code which just looks clean and neat to me... I've been learning React / Django / Bootstrap (open to ideas on that, but it's just been "there" for me)…

For templating, that is why I prefer Jinja2 with macros instead of Django templates.

  {% macro IssueCard(issue, type) -%}
     ... lot of HTML
  {% endmacro -%}
  {% for issue in myissues %}
    {% macro IssueCard(issue, 'myissue') %}
  {% endfor %}
The alternative is creating template tags, which can be a lot of work, and it gets you out of the templates.

I have a folder called macros/ where I put all the macros I need, and then I use the import call from Jinja2.

I agree with you; having long and deeply nested HTML templates creates too much noise when developing. Jinja2 Macros help with that.

Re: Use Rails

#55

Post by alex_lav »

samlambert wrote: post #35
_heimdall wrote: post #34

Earlier quoted context omitted.

I've seen a really interesting pattern play out a few times now. A startup needs to raise money and hitches onto the latest tech stack that grabs investors' attention. The startup raises on a valuation inflated based partly on the tech stack itself, meaning enough attention isn't given to the actual product or business model. Ultimately the startup runs into money problems when they can't live up to the tech stack hy…

what limitations? PlanetScale has public companies running on top of it. If a startup found limitations then its a skill issue.

> If a startup found limitations then its a skill issue.

"If it didn't work, you must have done it wrong" is maybe the most toxic sentiment in tech and in life. The Agile Coach's mindset.

Re: Use Rails

#56

Post by hakunin »

jupp0r wrote: post #39
hakunin wrote: post #32

Earlier quoted context omitted.

Just out of curiosity, what are you doing with a great concurrency story in a company you start in 2024?

Make HTTP calls to OpenAI? Pusher? DynamoDB? KMS? SQS? Make a datababse query? Anything that you cannot or do not want to run in your monolith service. You make it sound like it's sufficient to have concurrency support in 2024. My point is that it's necessary.

Http clients have pipelining for parallel requests that doesn't require threads. Database calls in Rails 7 now have `load_async`. You can still have other services, outside of Rails. Would that cover it?

P.S. I'm a huge fan of Elixir/Phoenix, but didn't find the big need for concurrency in practice that Rails doesn't address somehow.

Re: Use Rails

#57

Post by _heimdall »

spudlyo wrote: post #52
_heimdall wrote: post #40

Earlier quoted context omitted.

This was when foreign keys still weren't supported by Planetscale. The specific data model was heavily relational and queries were very inefficient without foreign key support. Distributed writes were also important, and if I remember right those weren't supported either though that's a really common limitation. Assuming a particular tool works for all situations because it works for some is a mistake though. Plenty…

> The specific data model was heavily relational and queries were very inefficient without foreign key support. I can't help but wonder if you're conflating the notion foreign keys (and the usefulness of having them be indexed) and foreign key constraints, which ensure data integrity at the expense of write performance. I have a narrow view of the performance of MySQL foreign key constraints and would be interested i…

I'm actually curious what the distinction is in your view. I've never really considered a column to be a foreign key when the constraint isn't used.

Having a column that we give business logic context to is useful, and indexing a column that should contain values for another table is helpful for query speed, but at least in my opinion they really aren't foreign keys unless that constraint lives directly in the database layer itself. I'd say the same for columns that are used as unique identifiers without actually adding unique constraints to the column.

There are good performance reasons to do either one if you're willing to take on the data integrity responsibility in the application code, but the column itself really is just a typed column if the constraints live elsewhere (again in my opinion, I think the technical definitions may ignore this functional argument).

Where I find foreign key constraints helpful for queries is when I need to be absolutely sure of the data integrity. Say I need to make a complex query that joins across three different tables based on foreign keys. If the table constraints exist I know that (a) any value in a foreign key column is valid and the referenced key exists and (b) if no rows are found I can trust that its just because none exist.

Without foreign key constraints, I may not know why the query didn't find any results. It could be because there just aren't any matching rows, it could also be that one of the keys is no longer valid (or never was). If I don't care about that second error state my query may not change much, but if I need to know why the query failed to match and handle any invalid data accordingly I couldn't do it.

When writing, I also much prefer having a single insert that I know will fail if the foreign key isn't valid. This could be done with a more complex query, or a transaction, but then I'd be taking on that responsibility when it could live directly in the db. Beyond the complexity there, I have to assume the database authors would be able to write a more efficient foreign key validation check them I could from my end.

That said, what's been your experience handling foreign keys when the constraint is either unsupported or unused? Do you avoid it mainly for the bump in query performance, and if so how do you avoid that performance hit elsewhere in your code?

Re: Use Rails

#58

Post by quest88 »

alex_lav wrote: post #50
quest88 wrote: post #29

Earlier quoted context omitted.

I suspect you'd find the same thing if you were a python or php consultant diving into python or php projects.

This is correct, but doesn't really change the discussion at all does it?

It does. The parent was making an argument that rails is not great past 1 or 2 developers and more than X lines of code. I was pointing out this argument is not a strong one, since the this is not exclusive to rails, instead hoping to focus on what is exclusive to rails, so we can have a discussion about "Use Rails".

Re: Use Rails

#59

Post by jupp0r »

hakunin wrote: post #56
jupp0r wrote: post #39

Earlier quoted context omitted.

Make HTTP calls to OpenAI? Pusher? DynamoDB? KMS? SQS? Make a datababse query? Anything that you cannot or do not want to run in your monolith service. You make it sound like it's sufficient to have concurrency support in 2024. My point is that it's necessary.

Http clients have pipelining for parallel requests that doesn't require threads. Database calls in Rails 7 now have `load_async`. You can still have other services, outside of Rails. Would that cover it? P.S. I'm a huge fan of Elixir/Phoenix, but didn't find the big need for concurrency in practice that Rails doesn't address somehow.

Yeah, there are small, niche solutions for solving concurrency for very specific use cases vs general support for this in the language. This doesn't help you when you are using the AWS SDK to make HTTP requests or when you want to hide latency of making a DB query and and HTTP request concurrently.

I'm currently working on a large Rails App in my day job and lack of concurrency support is a major limiting factor for the growth of the whole company (~$10B market cap).

Re: Use Rails

#60

Post by axelthegerman »

ekidd wrote: post #33
axelthegerman wrote: post #23

Earlier quoted context omitted.

Static typing vs not has clear pros and cons. I do appreciate that JS/TS offers you a choice but I personally prefer Ruby the way it is. Your other comments are basically: - ruby/rails has a great 3P package system - oh and yes you can choose "bad" ones - ruby/rails let's you quickly write great code - oh and yes you can just as quickly write "bad" code

I have worked on a decent number of dynamically-typed Ruby and Python systems in the 50,000 to 250,000 line range, written and maintained by teams. This has never felt like a strong use case for dynamic typing. You end up losing: - A lot of IDE support. The loss of documentation tooltips, in particular, can be painful in a team environment. - The ability to change an API and immediately see all the affected code. Thi…

Well I don't mind to agree to disagree :)

Similar points between your comment and the other reply. Still I worked with Java in the past and Ruby has been a liberation for me. It allows me to simpler, cleaner and less complex to write my code.

I work on one of the largest Rails apps and the added typing is usually more of a burden than anything - sure could be the implementation of typing which is harder for Ruby than let's say JS (to your point)

Still I don't mind others wanting to write typed code and finding more positives to it than I do - I just still am not convinced that statically typed is ever objectively better than dynamic and it stays of subjective nature.

TLDR: imho the quality problem of most large code bases is not due to dynamic typing but due to many other factors that lead to low quality code

Post reply on HN