Year is 2025 and coming from enterprise background, what is the go to method to build full stack application nowadays?

Hi all,

I have this inner monologue for the longest time and want to share it with you guys to get an answer.

I am not sure where I read it, maybe it was a coworker of mine who said (contractor who has left long time ago), "no one writes all this SQL to build DTOs’. My background is enterprise thus far and I can’t fathom where large enterprise project can be built without any kind of SQL and its DTO mapping. When it comes to ORM, I remember a video on Hibernate ORM where the presenter explained by using ORM is not always the best option.

With this said, what is the current, true strategy or stack or mental model used to build full stack application? Is the design pattern still the same, MVC or MVVM? Or like, React + Spring/Flask/ASP.NET … what about the data persistent layer?

I made a toy app not too long ago where the persistent layer is MongoDB and I used Mongoose. I did not have to write any type of SQL since I’m working with NoSQL, but is it really possible to build a full scale app without ever writing any type of data mapping by hand? Yes, Java has Lombok, but it is not widely used in my company. We use raw DTOs mapping by hand…

To give you an idea for my perspective, we use SQL Server internally and that database has close to a thousand tables and size of the database is almost 200 gigabytes. There are thousand of SQL queries that are very complex with multiple of joins and sub-queries to get result which is eventually mapped to a DTOs. Now, for me imagine that none of this SQL is required because an ORM can do it all and better, is hard to believe.

Is this really the case? Can ORM really build objects that span multiple tables? Where is my misunderstanding and confusion here?

Just to add, I am aware there are ORM for ASP.NET (entity framework), Java is Hibernate, Mongoose for Node.js, Python…

I guess, what I am getting at, can we reliably build a large scale application without every writing a single line of SQL query? Imagine there are a million of rows in a given table, won’t an ORM attempt to load the entire table into memory and filtering is done there? Isn’t it better to perform the filtering at the database layer that returns filtered result set?

It’s a completely reasonable question with no great answers. Or, perhaps, it has too many answers but they’re all mediocre.

To answer the core of your question, mature ORMs can handle most reasonable scenarios without imposing too much of a processing cost, but there is a cost. When you start hitting edge cases, performance may take an enormous hit.

I’m an old school developer and find that ORMs cost me more productivity than they save for most applications, but that’s me. No matter what stack you choose, you’re trading potential productivity gains for increased dependencies, complexity behind the scenes, and risks that you’ll run into something that doesn’t work as advertised. It really comes down to your skills and what you’re most comfortable with.

I chose React for an application three years ago, and now so much has changed that I regret my choice. I inherited an older Angular app and had to run it through six major versions, and that was easier than keeping my React app up to date. I’m sure that someone who is neck-deep in React every day would find my complaints ridiculous.

@Finnick
Thank you for this and clearing up my doubts. This makes sense.

In conclusion, building full stack applications these days, it is completely OK to leave SQL to a later stage of the application lifecycle. In the event where performance issues point to slowness of ORM, writing SQL at that stage makes sense. Maybe SQL isn’t even required at that point and instead, indexing on a new column might do the trick. This is interesting.

Funny on the Angular to React migration. Upper management has told us to shift to React from Angular. I guess we will soon experience the pain of using React company-wide.

@Remy

Upper management has told us to shift to React from Angular

Did they give any reasons as to why?

Wynn said:
@Remy
Upper management has told us to shift to React from Angular

Did they give any reasons as to why?

The lead who enforced the use of Angular left the company. His replacement said we should use React instead.

Is it possible? Yes. That being said, for some cases, you will have to write raw SQL. It is not common but there are times where the query is just too complex to let the ORM handle it.

When the query gets that complicated however, I generally stop and re-think the process to try to let the ORM handle it so I don’t have to write the SQL.

@Zion

When the query gets that complicated however, I generally stop and re-think the process to try to let the ORM handle it so I don’t have to write the SQL.

This is where I am stuck. Does this mean, when designing an application’s data object, does it mean the object needs to be thought in a way that is ‘ORM friendly’? Turns out, it is possible to inject raw SQL in the Spring framework.

But, part of me says, “oh, but in startup and modern tech, people don’t use Spring, Python or Node.js is used.” Now, do people write SQL in Python or Node.js projects? What about those stacks that use Firebase or Supabase? Do people write SQL when building apps on top of those?

@Remy
You can communicate with a SQL database from any programming language. My default is to use SQL unless I’m inheriting someone else’s application that already has an ORM, and I’ve never had an issue. In the old days we had to read and write directly via sockets, and while that requires some degree of extra work it also eliminates a whole lot of sources of complexity or error.

NoSQL databases are obviously a little different, but I always prefer to be as close to the database as possible.

@Remy
Spring Boot is still quite used today. Almost every current framework is used to some degree today. Same with ORMs.

People do still write in SQL but today it’s mostly when the ORM isn’t fast enough or the query is so complicated the ORM can’t handle it.

Does this mean, when designing an application’s data object, does it mean the object needs to be thought in a way that is ‘ORM friendly’?

No. It means thinking about the queries you need and designing around that. When querying records, do you need all records pulled in a single query and translated or can you do several smaller queries when you need the data?

And this is the same for any language/ORM. I try to design my queries in such a way that the ORM can handle it.

A normal customer - I do my own way. So each time you want to bypass, you will create odd fields and try to join in an odd way. If your database text is only 200GB, you need to do something kind of wrong or separate the database more. If your database is full of images - S3 or something related to it. To be honest, with those large sizes, there’s no choice but to maintain.