Lambda + API Gateway + Dynamodb
Ask HN: What stack would you use to build a CRUD web app in 2018?
161–170 of 184 posts
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#162If the application is going to be around longer than 5 years, roll your own MVC or ROA pattern in Java. Write your own DAO and database calls (stay away from ORMs). Keep 3rd party library use down to a minimum, limiting your vulnerability exposure and rewrites due to upgrades.
Home-grown means every other developer that ever has to touch it is going to have huge additional overhead getting started with the codebase (because your documentation is going to be nonexistent), and you're going to spend a ton of time unnecessarily reinventing the basics. These days it's never worth it to home roll in the CRUD world. There's way too much good tooling out there.
While it is true that there is additional overhead, they did say "if the application is going to be around for more than 5 years".
After 5 years there is a better chance you can make changes to a pure language coded app, than try and get what ever stack was common at that time working.
Basically, it could be the difference between throwing away your app and rewriting it.
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#163If you're using Postgres and want to get something done today, use PostgREST: https://postgrest.com/en/v4.4/ It is the fastest, leanest, and most powerful way to interface to postgres with an API. I've been using Python for 25 years an can tell you with certainty that Django is a slow, leaky, autocommit-infested, memory hogging pile of crap with a degenerate half-ORM that cannot model even the simplest aggregates. ht…
upvoting for Django being djunky
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#164Earlier quoted context omitted.
>> .. and vanilla JS with some jQuery If I could I'd buy you a beer and cheers you for relieving my JS anxiety a bit. I love jQuery, and I'm tired of feeling ashamed of it, damnit!
jQuery is no better ( these days ) than Vanilla JS, which you will love as well especially if you choose to use ES6 syntax.
`document.querySelectorAll` is amazing. It's a unification of the css syntax and javascript. No more filtering it your self, and your standard javascript stuff still works. It's wonderful.
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#165Twenty years ago, a simple CRUD app would have been written in Visual Basic or Delphi. It would have needed one programming language, and one framework. The tool support would be good: everything would talk to everything else. Heck, you'd even have an IDE with autocomplete! Today, a typical web app requires no fewer than five different languages (JS, HTML, CSS, Python/Ruby/whatever on the server, SQL). And that's bef…
I'd really like to use a tool like Anvil, but my experience with one-click magic solution tools is that it oftens greatly limits the customization options or doing something outside what it's built for.
Well, all I can say is that this is a known design trap that we have strained every sinew to avoid.
Anvil provides a toolbox of help you can take or leave, all driven by a real industrial-strength programming language (Python). And if all else fails, you can always drop down to the HTML and Javascript, and/or a REST API.
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#166Elm + Parse
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#167If you're using Postgres and want to get something done today, use PostgREST: https://postgrest.com/en/v4.4/ It is the fastest, leanest, and most powerful way to interface to postgres with an API. I've been using Python for 25 years an can tell you with certainty that Django is a slow, leaky, autocommit-infested, memory hogging pile of crap with a degenerate half-ORM that cannot model even the simplest aggregates. ht…
Is there any resource that you suggest to get good at learning sql? I am a django developer and have relied on the orm up until now. I know the basics of SQL and databases but I still won't feel too comfortable doing without ORM. Thanks
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#168I had to build an in house CRUD app that serviced millions of records and multiple users. It's a pain. The same technologies that existed years ago still work best today. I'm always open to rebuilding it and connecting the database to something _new_ but everything is cumbersome. I'd really like to move away from certain CRMs system but there is a lot to consider and it's always been a long battle. That's why older more mature systems have solutions ready to go.
Waiting for the day where something is smart enough to look at a SQL db and understand it then build out a quick web app that integrates with it.
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#169Earlier quoted context omitted.
Home-grown means every other developer that ever has to touch it is going to have huge additional overhead getting started with the codebase (because your documentation is going to be nonexistent), and you're going to spend a ton of time unnecessarily reinventing the basics. These days it's never worth it to home roll in the CRUD world. There's way too much good tooling out there.
While it is true that there is additional overhead, they did say "if the application is going to be around for more than 5 years". After 5 years there is a better chance you can make changes to a pure language coded app, than try and get what ever stack was common at that time working. Basically, it could be the difference between throwing away your app and rewriting it.
> than try and get what ever stack was common at that time working
Doesn't seem like a problem for languages with sane package management solutions, of which there are plenty. A Java app on Maven is going to work just fine in 5 years, and on the latest version of java to boot.
Re: Ask HN: What stack would you use to build a CRUD web app in 2018?
#170If you're using Postgres and want to get something done today, use PostgREST: https://postgrest.com/en/v4.4/ It is the fastest, leanest, and most powerful way to interface to postgres with an API. I've been using Python for 25 years an can tell you with certainty that Django is a slow, leaky, autocommit-infested, memory hogging pile of crap with a degenerate half-ORM that cannot model even the simplest aggregates. ht…
This is the exact thing everybody seems to be looking for. Create the DB, get an API out of it, polish it off with a frontend framework.
Why hasn't this taken over the world by storm? What's the catch?