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

Ask HN: What stack would you use to build a CRUD web app in 2018?

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 184 posts

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#81

Post by scarface74 »

drinchev wrote: post #4

Depends on how complicated the app is. Most of the times a good old non-SPA with NodeJS / Express / Some ORM with vanilla JS / Handlebars and SASS will do the job without having a huge technical debt. If on the other hand the requirements are to have a more complicated SPA, I would go with React / Redux and a NodeJS / Express / ORM for the API. Hosting the front-end on an S3 and the backend on a Digital Ocean Droplet…

Let me second Handlebars. There is nothing simpler than a plain old REST Api on the back end + Bootstrap + Handlebars + JQuery mostly for Ajax calls

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#82

Post by astockwell »

iambateman wrote: post #71

For those of you saying WordPress...could you elaborate a bit more? I'm willing to shelve my pride in favor of speed, but it seems like there are very few guides to building a web app in WP. HelloBar from 2012 seems to still be one of the top results. Could you elaborate on your approach to setting up a WP CRUD app? What are your go-to tools?

There’s a couple ways to do it, depending on how much you do/don’t want it to look like WordPress. In both scenarios you have to mentally translate what you want to do into WP architecture (e.g. you want a new model? In WP that’s a custom post type, etc.).

The “easier” way is to create custom post types for each model you want, and use Advanced Custom Fields (plugin) for the data fields. Users log into the WP backend and can CRUD the custom post types. With ACF, pretty amazing things are possible (inter-model relationships, uploads, etc, and all done with amazing UIs for each type of field).

The “harder” way (if you are trying to make your app appear less like WP) is to get a plug-in that hijacks the user login process and admin, then customize the front-end to display the CRUD fields/controls (again using custom post types and ACF) when users are logged in, so your users never see the WP admin.

Both ways (and more, now that WP also has a new-ish full-featured rest API) are possible, however the standard WP caveats apply: the more plugin-spaghettini you introduce, the more unexpected issues you will face. I’ve been meaning to write up a guide, need to do that one of these days...

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#83

Post by meredydd »

candiodari wrote: post #76
meredydd wrote: post #17

Twenty 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…

Is anvil a hosted service ? Can I host my own apps, preferably by just dropping them into some folder and giving them a database ?

Yep, it's a hosted service - you can publish your app with one click! Self-hosting requires an on-site Anvil installation. This is because many of the things we do to make things easy (eg returning live database rows from server to client in a function call, then manipulating them directly there) require server-side report.

We think it's worth it - for example, it saves you building a new REST API each time you blow your nose - but the trade-off is that we can't just provide a "download as Flask app" button.

If you want to run server code on your own machine, though, check out the Uplink. It's a library you 'pip install', connect to your app, and then you can drive your code from the web. Here's an example driving a Raspberry Pi: https://anvil.works/blog/uplink

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#85

Post by nzoschke »

candiodari wrote: post #78
nzoschke wrote: post #59

Golang for the API, running on Lambda. React or Vue for the UI. FaaS isn’t a fad, new systems built on an event based architecture are simpler, more cost effective, and scalable than the traditional application server approach. And the reactive programming pattern is easy and powerful and maps extremely well to modern UI needs. I have a boilerplate Go / Lambda app here: https://github.com/nzoschke/gofaas I use it wit…

Half the source files read like J2EE stuff. An example: // KMS is an xray instrumented KMS client func KMS() *kms.KMS { c := kms.New(session.Must(session.NewSession())) xray.AWS(c.Client) return c } > Golang for the API, running on Lambda. React or Vue for the UI. You forgot "YAML for configuration. Python for ... I'm not even sure what for (linting the configurations ?), but you use lots of it. TOML for golang depen…

Yes static YAML for config.

It may be more verbose but it's simpler than Rail's ERB in YAML that requires a the Ruby VM plus application config to interpret.

Yes external libraries. 80% of those are for testing (as is the Python stuff). In Go land you should effectively ignore the vendor folder, I check it in for developer convenience and system stability.

Compare to Rails which has a massive dependency graph. And one that has to follow your app around for every build and deploy.

I will absolutely grant that for SQL CRUD apps, you still can't beat the Rails tooling. Migrations, rake tasks, ActiveRecord, Scaffolding and the Ruby REPL to poke at your models and data are very useful.

But decoupled tooling is getting really good.

The https://github.com/marmelab/admin-on-rest project is better than Django Admin. The basic CRUD stuff is just as easy, then it's infinitely more configurable with a bit of custom React programming. And it's not coupled to any language, framework or database.

Finally cost is effectively zero for all of these options to start. AWS and Heroku offer a generous free tier. Developer time is the real cost to watch.

But in terms of raw resource consumption, static Go binaries talking to DynamoDB plus a static React page are obviously less "expensive" than Ruby VMs talking to a dedicated Postgres server and rendering HTML pages.

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#86

Post by bpicolo »

skavanagh wrote: post #25

If 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.

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#87

Post by qpiox »

It always depends on the use-cases. JS frameworks are good for interactive content, but if the content is write once read many times, they might not be the best solution. So I wont even mention any of them.

From server oriented stacks I would suggest and personally use for many years:

Open-source:

OpenXava - because it will generate the whole CRUD app automatically based on the database relations, and this will be sufficient for generic use-cases (it is based on Java Server Pages, Hibernate)

or

Tapestry - if I need something which is very component oriented, flexible and capable of extreme customization of the rendering process.

or Commercial:

Oracle APEX (Application Express) - it is extremely easy to create CRUD apps and general table/grid/master-detail type UI. Even if you are not a programmer you will be able to create a nice app. There are free options and there are cheaper options for smaller websites. If you get a hosted version it's easeir, if you host it yourself you would need a Oracle DBA knowledge to install it.

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#88

Post by mulrian »

songshu wrote: post #7

The boring Java enterprise way, 2018 edition. Back end: Java 9 JVM, Spring Boot web service, Kotlin, plain SQL via JdbcTemplate working with Kotlin data classes, Liquibase for DDL and migrations, Spring caching with redis if need be, Postgres, deployment via docker to AWS Fargate Front end: Angular... but I’d like to try Vue. Nginx and docker to Fargate

This. Might not be hip and trendy, but we've been using this stack (just with React on the frontend) and it's probably the best that I've ever worked with.

Anyone who knows Java/Kotlin will have experience with Spring Boot so it's easy to find good people. The whole platform is as mature as it gets at this point and the docs/questions cover pretty much everything.

It's really easy to get started when working on smaller projects, but you can also easily scale and integrate loads of other technologies if/when you need to. You might not need a complex caching layer, monitoring, metrics etc when you're starting out, but you know you can add it in if needed.

Re: Ask HN: What stack would you use to build a CRUD web app in 2018?

#89

Post by bpicolo »

sharpercoder wrote: post #32
songshu wrote: post #7

The boring Java enterprise way, 2018 edition. Back end: Java 9 JVM, Spring Boot web service, Kotlin, plain SQL via JdbcTemplate working with Kotlin data classes, Liquibase for DDL and migrations, Spring caching with redis if need be, Postgres, deployment via docker to AWS Fargate Front end: Angular... but I’d like to try Vue. Nginx and docker to Fargate

I tried Vue a few months back and I could not be happier. The single-file components (html/css/js) make development a breeze. I now need to make changes in relatively complex components I created 2 months ago, and my learning curve is small. Most things in Vue are expressed as expected and just work. I cannot wait for full ES6 support in vue - it will get massively better by then.

I'm really in love with just having v-if available. Ternary operators in React are ugly and the alternative of hoisting control flow makes things much more complicated to read through.
Post reply on HN