Ask HN: What stack would you use to build a CRUD web app in 2018? - xstartup
======
theli0nheart
I work with startups, so I make this decision every 2-3 weeks or so.

Language: Python. Python is easy to learn for those that don't know it, and
all-around liked. It's not hard to find engineers with existing experience if
you need to grow.

Framework: Django. Django does everything you might want in a framework. It
scales with larger teams, and the admin is still one of its killer features.

Frontend: SCSS/SASS, and vanilla JS with some jQuery sprinkled in. When (if)
the team/product grows, figure out which frontend framework fits best.

Database: PostgreSQL. Well-maintained, reliable, and great documentation.

In-memory cache: Redis.

Infrastructure: AWS. EC2 for hosting, S3 for file uploads and static file
storage, CloudFront for content delivery.

Web server: nginx. Let's Encrypt for SSL cert generation.

App server: gunicorn. It works.

There are probably a few other things I'm missing but these are the big ones!
All of my clients from years back (a few who now have 20+ people on their
engineering teams) are still using this entire stack, so it scales both
technically and as the number of team members grow. Happy to answer any
questions!

~~~
golergka
I always had a question I wanted to ask an experienced Django dev. After
trying this framework for a couple of hobby projects (I'm a client game
developer primarily and never worked on "serious" web project), I kinda got
the impression that it's architecture is created for two main user roles:
admins who create most of the content and have marvelous admin forms in front
of them to input all the data, and users, who mostly consume the content and
only occasionally input some data. When I tried to create complex input forms
with a lot of complicated, relational data that users would be able to input
and modify, it felt so much harder than exposing the data models in the admin
panel — it really felt that this wasn't the use case this framework was
designed for.

Did I get the right impression, or may be I just didn't learn to use Django
correctly?

~~~
ioddly
From the Django tutorial:

> Generating admin sites for your staff or clients to add, change, and delete
> content is tedious work that doesn’t require much creativity. For that
> reason, Django entirely automates creation of admin interfaces for models.

> Django was written in a newsroom environment, with a very clear separation
> between “content publishers” and the “public” site. Site managers use the
> system to add news stories, events, sports scores, etc., and that content is
> displayed on the public site. Django solves the problem of creating a
> unified interface for site administrators to edit content.

> The admin isn’t intended to be used by site visitors. It’s for site
> managers.

[https://docs.djangoproject.com/en/2.0/intro/tutorial02/](https://docs.djangoproject.com/en/2.0/intro/tutorial02/)

------
meredydd
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 before you
even start on the frameworks:

    
    
      - Something to make JS bearable (eg React)
      - Something to make CSS bearable (eg Bootstrap)
      - Possibly another JS framework (eg Redux)
      - A framework to make web serving bearable (eg Flask)
      - Something to make database access easier (eg SQLAlchemy)
    
      - Did I mention Webpack, Docker, AWS, CI/CD...?
    

Now, I'm sure we're going to have a big lively thread, debating which
technology we should choose for each of these slots (and whether the answer
has changed since last week). But the ecosystem which requires so many
components, for a simple CRUD app, is _utterly insane_.

We designed Anvil ([https://anvil.works](https://anvil.works)) to be the
complete opposite of this. It's a development environment that lets you build
and deploy full-stack web apps, from your browser, with nothing but Python.
There's a visual designer, client code, server code, and a built-in database.
Unsurprisingly, when we did the head-to-head tests, a typical CRUD app is
about seven times faster to build with Anvil than with traditional tools.
Looking at the list above, are you surprised?

~~~
elorant
You need neither JS nor CSS to build a simple CRUD app. Just use the server
technology of your liking and a database. Sure, it will look ugly but so did
apps 20 years ago.

The landscape got complicated because now we build beautiful and elaborate
things. We have apps that serve hundreds if not thousands of users
simultaneously. Modern databases get hammered with requests every single
second. What was the average case scenario for a CRUD app 20 years ago? Some
godforsaken company that had a couple hundred employees at best and no more
than 10 at time were accessing the data. And lets not forget the endless hours
we used to spend trying to get reports printed properly. With web apps
whatever you see on the screen you get on the paper.

~~~
candiodari
> The landscape got complicated because now we build beautiful and elaborate
> things

As someone who works at a large company which has TONS of crud web apps, let
me just say ...

No.

We don't.

We build ugly disasters, badly, with loads of bugs and unusable interfaces.

And of course, only very rarely are 2 crud apps built using the same stack. We
have everything from Oracle WebForms to Ruby on Rails, to AngularJS on NodeJS.

And may I add, the "beautiful" ones are the worst in terms of usability. Can
we place take all the frameworks that don't have a very good and built-in data
grid and shoot them ?

~~~
elorant
As someone who builds SaaS sites the shit I build now are miles more elegant
and functional than the apps I used to build back in the Visual Basic days, or
even earlier when I was writing software for DOS. We may bitch and moan all we
like but the fact is that the average web app of today is way more usable than
the average windows app some twenty years ago.

I won't argue that the situation with web development is ludicrous, we have a
bazillion of js frameworks that last no more than two to three years until the
next shinny thing pops-up not to mention changes in pretty much every aspect
of the stack, from devops to server-side languages and whatnot.

As a testament, take a look at the available dashboard templates in the major
template sites. Some of them are so beautiful they make me droll. We never had
so gorgeous interfaces in recent history.

Of course as always YMMV.

~~~
candiodari
Well, perhaps it's that I used Delphi back in the days, but I have a different
experience. Delphi apps the equivalent of tiny webapps were orders of
magnitude simpler.

------
jgoodhcg
Clojure(script) with re-frame, using the luminus template.

[https://github.com/Day8/re-frame](https://github.com/Day8/re-frame)
[http://www.luminusweb.net/](http://www.luminusweb.net/)

edit: Should probably say why...

\- Clojure and clojurescript give nearly identical experiences on the front
and back end, with the ability to actually share some code between the two.

\- Clojure is dynamic and spec gives some really awesome validation and
generative test capabilities

\- There is a lot of fuss around javascript frameworks and dealing with html /
css build tools and their arbitrary syntax. Clojure front end frameworks
provide tools that make templating html look just like regular data structures
in clojure, styles too. With stylefy you can also keep all styles inline while
supporting media queries. It really is a low cognitive load setup once you get
going. I love it.

[https://github.com/Jarzka/stylefy](https://github.com/Jarzka/stylefy)

edit-2: More whys...

\- re-frame is basically redux but easier and with less boilerplate. I use it
for small and large projects.

\- Pure immutable functions are such a game changer. Even poorly written
projects with tons of features can be reasoned about and broken down for long
term maintenance if the language supports immutability and pure functions. Re-
frame really plays to this strength for managing state and I can't say enough
good things about it. Been working with it for 2+ years and I can't imagine
switching for anything else I've seen out there.

~~~
WalterGR
How healthy is the Clojure web development ecosystem - especially library
availability - compared to Ruby on Rails and Django?

~~~
jgoodhcg
I haven't tried to find something and not found it.

The back end is way more mature than front end SPA stuff so I'll just list
some things I'm really glad to have in that space

\- re-frame : like redux but better

\- re-learn : lets you create tutorials for application with no changes to dom

\- cljsjs/filesaverjs : cross browser file download dialog

\- cljs-react-material-ui : material ui react library port

\- camel-snake-kebab :useful for changing casing

\- com.rpl/specter : easy way to deal with large nested data structures

\- stylefy : inline styles with support for media queries and animations (all
with clojure data structures!)

------
nickjj
The same as 4 years ago.

Server side rendered templates with Rails or Flask using Postgres + Redis +
background worker of choice.

I'm starting to build some apps with Phoenix now, but it's not because I feel
the above 2 are poor choices. I just like learning new things, especially when
I see big wins of potentially using it. It's another tool in my tool belt, not
an all-in replacement of the previous thing.

~~~
wastedhours
100% agree - unless you're doing anything especially novel, or know you're
getting 10's of millions of connections from day 1, with the ecosystem around
it, I wouldn't hesitate choosing Rails + Postgres + Redis + Sidekiq.

~~~
ericb
Even then. Are you going to be bigger than Shopify on day one?

~~~
swat535
Or.. github.. or gitlab..

~~~
stuxnet79
Amazing ... are Shopify, Github and Gitlab using a similar stack at their
scale? I feel less bad about not using an exotic stack now.

~~~
nickjj
They are all built with Rails.

------
michelpp
If you're using Postgres and want to get something done today, use PostgREST:

[https://postgrest.com/en/v4.4/](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.

[https://www.youtube.com/watch?v=GxL9MnWlCwo](https://www.youtube.com/watch?v=GxL9MnWlCwo)

Learn SQL and do it right.

~~~
copperx
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?

~~~
purerandomness
The coaching gap:
[https://www.youtube.com/watch?v=ecIWPzGEbFc](https://www.youtube.com/watch?v=ecIWPzGEbFc)

People early in their career thinking SQL is something UNIX greybeards did in
ancient times, and which is not necessary anymore.

------
arnorhs
Great question. The funny thing is, 6 years ago, if you'd ask the same
question (and I'm guess that's what you're coming from) the go-to answer on HN
would've been Rails / Django something. Where both will allow you to build a
basic crud app in 20 minutes.

Since then, everybody has gone heavily into various javascript stacks, and the
norm has become to deal with 20 different packages to build (somewhat) the
same thing. And the first hour will easily be spent researching different
dependencies, trying to get them all to work how you'd want etc.

It's easy to see this as a horrible backwards progression, but the reality
might be a bit nuanced.

The easiest way to get a basic crud app up and running these days is probably
still some sort of rails/django stack. But today's requirements in terms of UX
/ dynamism (is that a word?) require you to end up building things
differently, so even if you get up and running fast with a rails app, you'd
end up having to build up a pretty hefty JS stack in the end, so you'd
basically be delaying the inevitable.

So the answer really depends on what level of "good enough" you're going for.

~~~
mercer
> But today's requirements in terms of UX / dynamism (is that a word?) require
> you to end up building things differently, so even if you get up and running
> fast with a rails app, you'd end up having to build up a pretty hefty JS
> stack in the end, so you'd basically be delaying the inevitable.

I'm starting to wonder to what degree this is actually true.

Most people I know, all along the spectrum of 'computer literacy', complain
about the slowness and brokenness of many sites and web apps. On the other
hand I've never heard anyone complain about a lack of 'dynamism'.

To be clear, _some_ degree of interactivity is often useful. But I can't help
but feel that it's quite often not at all necessary to move things like
routing, validation, and (almost) complete page changes to the client side, at
least not as long as it increases complexity to such a degree.

~~~
nerdwaller
I came to say something similar, it’s easy in tech to see something could be
“better” but from the outside most people just want something that works and
is easy to use (pretty is bonus).

Secondly I’d argue that if “dynamicism” matters, choosing rails or Django
doesn’t hinder that ability as a lot of that is simply presentation layer
concerns.

------
sudders
Start with what you know, don't spend months figuring out a certain database
tech for example when MySQL/mariaDB is just as good for 99% of the use cases.

I know there's a lot of bias out there against PHP. But I would still use it
over the alternatives, there's a large community. With excellent frameworks
who do the heavy lifting for you. (Symfony, Laravel). Great support and
tooling, a large recruiting base and easy to pick up.

I personally love using Drupal 8 (which is built with Symfony), it has an
excellent database abstraction layer, you can easily swap MySQL out for
Postgres for example. There's a lot of functionality built in, and very
developer minded (compared to WP) with many extra 3rd party addons. It also
has a proven track record with deployments from small SMB to large enterprise
users. It can also easily be extended with any Symfony packages.

For front end, I swear by Ember.js it is a framework which makes a lot of
important decisions for you. You don't loose time setting up your tooling,
deployments, state management, ... A great community, many excellent add-ons.
A proven track record (LinkedIn, Twitch, Apple Music, ...) And on top of that,
it has been around for 6 years, and is still actively developed with regular
releases, with a excellent deprecation support so you can easily upgrade to
new versions.

~~~
tabacitu
"_Start with what you know_" \- amin to that. I also found this is the most
important consideration for this decision. I've made the mistake of applying
the "_if it fails, at least I used and learnt a new system_" logic, but every
time I did that, I still preferred my old stack. So I ended up taking 2x as
much time to build, to re-use nothing of the learning (on the development
front). I'm now a big believer in the "_build fast, fail fast_" mantra.

My favorite stack: nginx, PostgreSQL/MySQL, PHP 7.1/7.2, Laravel,
BackpackForLaravel for admin panels, jQuery/Vue.js

That being said, I'm the creator of BackpackForLaravel. So my productivity is
off-the-charts with it, and I'm probably biased towards PHP. I think PHP is
underrated, especially in the US & Silicon Valley. It's "cool" to hate on PHP
for its past mistakes, and I agreed on many of them, but nowadays, with
Laravel... \- it's a joy to work in it (I now like it better than Ruby) \- you
get _so much_ done, so fast \- I've been able to easily scale it for millions
of users (I've built a social network, a video-on-demand app, an e-learning
app - for clients, not myself) \- PHP/Laravel developers are easy to find, all
across the world, when you need it \- there's a plethora of good agencies that
use it, if you ever want to outsource the entire development team

IMHO, Laravel is here to stay. And with BackpackForLaravel for admin apnels, I
hope it'll soon be on par with Django.

------
songshu
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

~~~
sharpercoder
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.

~~~
bpicolo
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.

------
gingerlime
As a developer working with Rails (and previously Django), I'd love to try
Phoenix/Elixir now. I'd probably find lots of great reasons why it's the best
choice. And I won't be wrong.

As an entrepreneur however, I would opt for Wordpress unless there's a clear,
strong reason not to. I know it's a bit heretic here on HN, and I dislike PHP
and working with Wordpress isn't fun at all. But they take the concept of
"Batteries included" to the next level. It's like "Nuclear power included".

You want a simple and powerful admin backend? got it. Caching? check. Image
optimization? Yup. Logins? of course. Payment/Shopping Cart/Even subscriptions
- just get woocommerce. 5 minutes later you're charging credit cards or
paypal. Not to mention how easy it is to create content pages, landing pages,
blog posts... You know, the stuff that actually convinces people to even
consider your shiny new app.

~~~
sparkzilla
I often meet people who want to use <insert tech here> for their generic MVP
or website, and seem quite eager to spend thousands on programmers replicating
what you can easily find on WordPress. But even though I tell them they should
buy a WordPress template closest to the result they want, and hire a
programmer if they need to customize it (saving thousands of dollars and a
while load of grief), quite a few simply don't believe it's possible and still
spend the money.

~~~
gingerlime
couldn't agree more. This was from the perspective of a developer-
entrepreneur. If I was talking to non-technical entrepreneur the arguments in
favour of Wordpress are probably stronger. So much easier to find developers
and agencies who are familiar with it. Without spending a fortune. It's easier
to pass from one agency to another even. Not to mention easier to sell your
business later on... To quote Patrick McKenzie[0]:

 _" Practically speaking, this means that the market wants your website to be
on WordPress and your technology stack to be something very, very mainstream,
like Rails or PHP. That ensures that, when they want to hire someone to work
with it, that person will exist in quantity and be inexpensive. The market
highly dislikes software which is written in something more esoteric (the new
Javascript hotness, Golang, Erlang, etc) because that adds substantial risk
and cost to operating the business."_

[0]
[https://training.kalzumeus.com/newsletters/archive/selling_s...](https://training.kalzumeus.com/newsletters/archive/selling_software_business)

------
red0point
I build lots of CRUD apps very fast with JHipster, which is designed to handle
the initial bootstrapping of traditional CRUD apps very well, while also
allowing you to choose your tech stack (in some ways). Because it's giving you
a nice boilerplate, you can customize it as you go.

The stack ist mostly Java with Spring and AngularJS on the frontend.

[http://www.jhipster.tech/](http://www.jhipster.tech/)

------
withinboredom
Honestly, I would probably build it out on WordPress with a slick theme from
somewhere, and the app built out as a plugin using jQuery or Backbone on the
frontend. See if works and people give me money.

If I get money, refactor frontend to use react/redux.

On the back, if PHP/WordPress weren't a good fit, I'd rewrite in another
language and have WordPress proxy the requests and cache the responses smartly
(POST/DELETE/etc would invalidate the cache for GET) or something.

I don't understand why you'd want to start out with a complex stack. It locks
you into a set of solutions when you don't even know the whole problem set
yet. See what people give you money for and figure it out from there.

~~~
mooreds
What is the default crud solution on WordPress? Do you create new objects? Are
there API generation plugins?

I like WordPress for a CMS (wouldn't recommend anything else for a small to
midsize CMS solution) but wouldn't think of it for a crud app.

That said, haven't researched it much lately, so wondering what I am missing.

~~~
mooreds
Never mind, someone answered my questions:
[https://news.ycombinator.com/item?id=16509513](https://news.ycombinator.com/item?id=16509513)

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

~~~
pas
NodeJS + TypeScript works wonderfully. Nunchuck templates (Jinja2 inspired).

And we use Angular on the front end.

And I'd recommend GraphQL, takes a lot of worry about API design and wiring
off your shoulders.

------
arenaninja
Funny, I was writing something to manage orders for a side business that looks
promising and I started building it with Node+Express. It took some hours
(3-4) but then I realized I haven't deployed a Node application to production
and I'm not even sure how to keep the process alive forever, how updates would
work, etc.

I re-wrote it last night in the LAMP stack in about 30 minutes. So I would
write a CRUD app in PHP in 2018, I would suggest you do too tbh; PHP7 is a joy
to work with. For backend framework I'm using
[https://www.slimframework.com/](https://www.slimframework.com/)

~~~
shmooth
i've been an occasional defender of php, but darn...those backslashes.

and, symfony is the worst garbage in the history of the planet. worst mistake
ever.

~~~
arenaninja
I agree, backslashes are annoying. Unfortunately that ship has sailed :|

I've never used the full-fledged Symfony framework but I have used individual
components from time to time. Surely it can't be worse than Zend 1?

------
nzoschke
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](https://github.com/nzoschke/gofaas)

I use it with this excellent admin interface framework for CRUD tools:

[https://github.com/marmelab/admin-on-rest](https://github.com/marmelab/admin-
on-rest)

~~~
candiodari
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
dependencies. JSON for other pieces of configuration. There is even some XML
stuff in there". Even just limiting to Go you're using something like 10 large
external libraries.

When I read this, I'm like ... _sigh_ not AGAIN.

Oh and after starting it, may I just point out, that despite all that work,
it's nowhere near as good as a Laravel, Drupal or Ruby-on-rails app, in terms
of functionality (speficially, using this, you'll constantly need to write
extra tools for basic operations on the database that your tool doesn't
support, whereas each of those frameworks have something like Drupal's
"admin"). And I might add, more expensive to host than either of those options
too.

~~~
nzoschke
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](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.

------
perlgeek
One you are familiar with, if possible. Django, Rails, or maybe Elixir+Phoenix
if you absolutely need something modern.

~~~
daryllxd
I completely agree with this. Whatever's most familiar for you, but hopefully,
it should be familiar for other people too. Try to write it in a way that you
can switch out parts if you really needed to. For example, I'm still a Rails
programmer but I've been structuring my apps differently from traditional
Rails (oftentimes just doing the API backend).

However, that's only because I still have the luxury of time. If I had a gun
to my head and a finite number of hours to code an app, then I'd go with
vanilla Rails. If I was given a few weeks to study a new framework, I'd go
with Elixir/Phoenix, but only because I spent a few days trying it around and
while I'm not particularly fluent with it yet, I like its design and speed a
lot more than Rails.

I think this is why we perfect our craft. We have to be able to code fast or
code pretty, depending on the circumstances.

------
iambateman
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?

~~~
astockwell
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...

~~~
mooreds
If you want your custom posts using the ACF to be accessible via a json API,
you might want to check out this SO post:

[https://stackoverflow.com/questions/10132685/json-api-to-
sho...](https://stackoverflow.com/questions/10132685/json-api-to-show-
advanced-custom-fields-wordpress)

------
daigoba66
Use what you know. In my case, probably ASP.NET Core and either SQL Server or
PostreSQL.

------
Clobbersmith
Rails. Rails was basically designed to write CRUD apps. You will 99% never get
big enough where rails' downsides become a problem.

------
oblib
I've been using:

Server side: Apache Web Server CouchDB Perl or Python

Client side: Pouchdb jQuery Bootstrap Moustache/Handlebars

On client side that toolset provides an almost seamless API that gets you
authorization, authentication, offline/mobile first, and data sync among all
connected devices. And it's a very fast app because it runs almost entirely on
the client side and transfers very little data between the client and server.

There's not a lot to do on the server side with this setup. PouchDB/CouchDB
work together to handle the CRUD routines for both the client and server side
and to sync data automatically and/or on-demand when the client is online.

You can also setup a 2nd CouchDB on a remote server to replicate your data to
for automated backups. And it's fairly easy to configure a cluster of CouchDB
servers with load balancing.

Productivity is what we're really looking for in a framework. To achieve that
you want a very low learning curve and a very rich feature set. You want to
leverage what you already know, as opposed to "learning a new way" to do
things.

For me, this "stack" provided that.

------
sideproject
PHP with Laravel :)

For JS, Vue.js probably. Though I'm still using Backbone + Marionette.

~~~
icc97
[https://vuejsdevelopers.com/2018/02/05/vue-laravel-
crud/](https://vuejsdevelopers.com/2018/02/05/vue-laravel-crud/)

------
laci27
I would go with PHP+mySQL/PostgreSQL maybe some Redis for good measure. What
PHP framework to use in 2018? Fat-Free Framework, of course.

------
wheresvic1
I've also worked with quite a few startups and usually recommend the
following:

\- Python / Node.js for the backend

\- React.js (with Redux) / Angular for the front-end

\- MySQL / Postgresql as the db

\- Host on a digitalocean or linode VM

\- ReactNative (if using React.js) for mobile apps, prefer to write native
apps otherwise.

All of the above are proven technologies with Node.js giving an edge when it
comes to real-time applications.

The hardest part I've found is in having a consistent design, marketing and
branding strategy. Usually the inhouse designers are swamped and it gets
really tricky for frontend developers to make the beautiful looking widgets
that were designed in Adobe InDesign or whatever...

------
fefb
For the APP I 'd use ReactJS

For the compute back-end I'd use Serverless Lambda or Google Functions,
nodejs.

For the database I' d use Firestore or datastore

For the communication between client and back, I'd use GraphQL.

------
jftuga
Has anyone here used DataTables, specifically the Editor?

[https://www.datatables.net/](https://www.datatables.net/)

[https://editor.datatables.net/](https://editor.datatables.net/)

[https://github.com/DataTables](https://github.com/DataTables)

I have a license for the Editor and have to say it works very well. They have
an online Generator that makes it easy to get started very quickly.

~~~
leavy_pine
It works pretty well and is fairly straightforward to use. It can be really
frustrating if you have more advanced requirements for your editable tables,
but it works great and is documented pretty well for its intended use cases.

------
senthilnayagam
Design crud API in swagger generate code api server / April in your favourite
language/framework with swagger codegen

Design frontend in web or mobile with poison of your choice

------
kyriakos
PHP and CRUD is match made in heaven.

Use a framework like symphony or laravel and you only need to worry about
business logic. The rest is taken care of by the framework.

------
olfactory
\- Any of the Sinatra-derived frameworks (flask, express, etc. Language isn't
a major factor as the API is small).

\- Neo4j graph db instead of a relational db. Simple crud stuff is easy, and
you can encode most business logic (if there is a need for anything beyond
basic crud) as simple graph operations, avoiding the need for a bunch of other
boilerplate that is found in frameworks that leverage ORMs.

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

------
artpar
Its surprising that I don't see any of the new headless cms stacks here.
Checkout [https://headlesscms.org/](https://headlesscms.org/)

I am working on
[https://github.com/daptin/daptin](https://github.com/daptin/daptin)

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

~~~
bpicolo
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.

~~~
acutesoftware
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.

~~~
bpicolo
> 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.

~~~
skavanagh
Maven is a build tool and can help manage dependencies. It doesn't ensure your
code base is compatible with the latest version of the dependency or ensure
the dependency is still supported.

------
SnowingXIV
I 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.

------
rayalez
Node/Express, or maybe Django, depending on a project (Django for simpler,
standard ones, Node if I want a REST API).

Although recently I'm mostly using Node/Express for almost everything, and I'm
really happy with them.

------
iisbum
If it's a simple CRUD app, whatever stack you already know.

For a simple CRUD app the stack is irrelevant. You'll want to get to market as
quickly as you can and that will be with the stuff you already know.

------
blattimwind
Django Admin. Or even Drupal, for all its brokenness, bloat, slowness and
security problems, you can build fairly decent data entry and retrieval apps
with it without writing a single line of code.

------
buremba
Don't look too far, Django is still the most flexible and stable solution (If
you're familiar with Python) for CRUD unless you need a single page
application (SPA).

------
dochtman
This is probably more hopeful/an ambitious end goal than anything sane people
would really do today, but I would try to write a functional reactive
isomorphic Rust app.

------
fuego
.NET (C#) for the back end and Mithril.js for the front end.

------
mooreds
I'd use Rails today. But I can see the value in Django or Express or ASP.Net
or Spring Boot.

Criteria I'd think about:

What is going to be easy for my organization to support (both operationally
and with future code changes).

What do I know/want to learn? If the CRUD app is complicated, then I want a
tech I know well. If the CRUD app is simple, then I may want to experiment
with a different technology (again, within the organizational support
guardrails).

------
looperhacks
Whatever you're experienced with. I know it's nice to write a backend in js
and easy to learn Python, but if all you ever did is writing C#, then there's
nothing wrong with using it. You only know jQuery? Don't worry, you're
probably being paid for the result and not for using React. (This is obviously
not true if you want to learn new technologies)

------
dustingetz
[http://www.hyperfiddle.net/](http://www.hyperfiddle.net/) (Karl and I made
this)

------
mstijak
Regarding front-end, CxJS is a JavaScript framework specifically designed for
large CRUD apps. It offers powerful data-binding, form widgets + validation,
advanced grid (data-tables) and much more. CxJS is free for small teams and
startups.

[https://cxjs.io/](https://cxjs.io/)

------
Edmond
Developer of Solvent (codesolvent.com)...We are still finding the right angle
for the product but it has been my goto platform for web development for the
past 3 yrs.

Combines custom middle-ware+appserver+IDE to give you a one-stop web app
solution. You then use whatever else you want on the front-end or backend (jvm
libraries).

------
superasn
Development: Definitely Laravel (PHP7 + Mysql) for backend with Vue 2 +
Webpack (or mix) for frontend. It's the best combo to get shit done.

Deployment: EC2 or DO both work great.

P.S. Most important thing. Do not worry about optimization before you ship
your first version.

------
raman162
I would use rails for the API and react on the front end. Rails 5.1 makes it
super easy to do this and Rails 5.2 which is coming out soon (5.2.rc1 I'd
already available) also adds some neat features. Database I usually pick is
postgres.

------
candiodari
PHP, Drupal, Ruby on Rails, or GWT.

In increasing level of complexity. PHP is very fast to write, but gets
unmanageable relatively quickly. GWT can handle anything you could possibly
want to do, but it'll be quite a while before your app starts working.

------
al2o3cr
Whichever one you're familiar with - that requirement doesn't provide any
meaningful information to decide among the many choices. It's like asking
"which path should I take to cross the street".

------
graycrow
Well, of course it's personal choice, but I ended with Aurelia JS + Typescript
on the client side and .net core with SQL server for the backend.

------
Gys
Its like asking economists about the economy: so many people, so many
different answers ;-)

Interesting enough, it probably means the market is still growing.

------
FahadUddin92
I would use WordPress if its a simple site. For a more complex site, I would
choose PHP/MySQL with CodeIgniter or Laravel framework.

------
madrafi
Golang + VueJS will do a great Job , otherwise you can get up and running
within an hour with Express,Mongo and Handlebars or EJS .

~~~
spicyusername
Came here to say this. Go is such a nice language to develop with and once you
understand the ELM architecture, VueJS with ElementUI makes throwing a webapp
together a breeze.

------
cweagans
2018 is not special, so the same answer as any other year: the stack that you
know inside and out and are most productive in.

------
nkristoffersen
Building a lot of SaaS products for startups these days.

Frontend: ReactJS

Backend: NodeJS

Database: Postgres

Hosting: AWS

CI/CD: Gitlab

Simple for me. Easy to deploy changes quickly. Fast iteration.

------
jonathan-kosgei
Lambda + API Gateway + Dynamodb

------
tgdn
Golang for api, React front-end

~~~
rrjanbiah
Any Golang framework?

------
Rapzid
This is a big question and hard to answer IMHO without more context and
constraint. I'll take a stab at laying out some thoughts on the matter.

So many apps can fit into the CRUD tent. I mean, Jira and Confluence are
basically CRUD apps, right? But so is an ad-hoc internal company app. I'll
focus more on apps that are meant to be externally facing as I typically work
on larger efforts, and then mostly on backend services and infrastructure
automation.

I would personally stay away from Python. Not only do I prefer typed
languages, but I also appreciate languages with fantastic tooling and language
services, mature concurrency primitives, and an active/energetic community. I
find Python seriously lacking in those regards, and falling further behind
other language choices every year. I personally have no issues with writing
prototype/production ready code in less dynamic languages at the same speed;
faster usually is my sense for anything more than a few dozen lines.

If elixir had focused more on a type system and better language
services/tooling(like the F# team) I'd probably be more interested in Phoenix.
Ignoring the erlang VM, I find F# much more compelling as a language and am
hoping one of the new crop of frameworks will shape into a viable Phoenix
alternative. That being said, I could still see myself pushing Phoenix
depending on the experience and leanings of the rest of the team.

In no particular order:

TypeScript+React+ASP.NET:

I really like C#; it's not for everyone, but coupled with the CLR it has
completely acceptable performance, concurrency primitives, and language
services(intellisense, refactor support, etc). Entity framework and linq are a
super compelling combo; using this ORM will ruin most other ORMs for many
people. Dotnet core has resulted in a lot of extra activity in the OSS
community, and the dot.net ecosystem is full of very well engineered,
comprehensive projects.

F#+React+ASP.NET:

For some extra spice try F# full-stack. There are some great backend
frameworks shaping up, and Fable makes F# possible for the client. Great
language and great concurrency support. F# is my crush language. Fable's
creator has been doing excellent work including making it possible to consume
TypeScript type definitions; going so far as to reach out to the F# team to
include features necessary to support the flexibility of TS. Ability to
execute on this would really depend on the starting team as well as
current/future hiring practices.

TypeScript+React+Node.js(TypeScript):

This is one of my favorite "easy-ish-to-sell" stacks. Nodejs has come a long
ways, and offers a sufficient concurrency experience with async/await. Node-
Chakra-Core has some clutch time-travel debugging abilities.. Javascript
programmers at least keeping up with ES6 shouldn't have TOO much trouble
adjusting to TS, and as a bonus they can be more effective working full-stack
on the backend. This should provide for a very large potentially hiring pool.
There are some super compelling TypeScript-first projects cropping up as well
like MobX, NestJS, TypeORM, etc. My sense is that TypeScript is attracting
more of the "engineery" types to the JS/Node ecosystem. If C# is any
indication, this is a welcome addition IMHO.

Dart:

Dart appears on the surface to be a more first class TypeScript. It looks
super compelling, has some great tooling(including a sweet looking profiler),
has a great looking VM for server side execution, and a small but very
passionate and motivated community.. A few highly visible companies adopted it
and swear by it. This is probably the most experimental stack I would consider
and can't really explain it... I'm dart-curious. I feel they should ditch the
custom eclipse based IDE and focus on the language server protocol and plugins
for the popular IDEs with the 2.0 initiative.

TypeScript+React+Golang:

Sure, why not? I think I'd need a good reason for going golang... Like some
serious server-side performance requirements and/or lots of backend services.
In the context of a "CRUD" app, I'd be more likely to swap services written in
other languages out with golang as the performance requirements became clear.

Mini-rant:

React is pretty great but I wouldn't mind a TypeScript-first implementation to
it's interfaces. DefinitelyTyped group has done an excellent job but keeping
everything typed can be a bit gnarly and gross.

I'm a huge proponent of MobX over redux until you know you need redux. I
haven't personally missed redux since extricated myself from it, however I can
imagine circumstances where I'd "see the light" and want it. Take the redux
creators advice; you probably don't need it.

------
Raed667
Sails.js for the backend react/Redux for the front

------
moltar
AdonisJS (like Laravel but in JS), PostgreSQL, Vue.

------
twovi
Flask and SQLite3

------
pknerd
Laravel or Flask.

------
Randgalt
Dropwizard on the server. Vue on the browser.

------
nik736
Rails + Postgres

------
chkte
Java (Spring) + vanilla JavaScript.

------
gglitch
Tcl/Tk/SQLite, obv

~~~
Something1234
Tcl/Tk supports doing web stuff?! There's gui frameworks that can produce a
web interface and a native gui now?

~~~
gglitch
As a Tcl fan, I was just clowning around; but as a matter of curiosity, there
do happen to be a number of possibly-credible Tcl web frameworks. I haven’t
done any homework on any of them.
[https://wiki.tcl.tk/40649](https://wiki.tcl.tk/40649)

------
hmoghnie
backend : ratpack + java + kotlin + ebean (sql orm) + postgresql

frontend : VueJS

------
stillbourne
ASP.NET/angular5

------
pvsukale3
Rails + jQuery

------
quickthrower2
Elm + Parse

------
tribby
nuxt and mysql.

------
sureaboutthis
At my company, we still use the same thing to create high performance web
sites. HTML, CSS, JavaScript, SQL and our favorite programming language which
I won't go into. We don't even consider anything else because we've been there
and done that (whatever one needs) years ago. The only time we give any
thought to any framework or library is when the client requires it for some
existing interface and we can't get around it. But we will make an effort to
scrape off such things wherever possible cause that's our job: high
performance at low cost.

------
alt_f4
For CRUD, I like CakePHP + Bootstrap

------
Numberwang
Full stack Dart.

~~~
jaxondu
What Dart library/framework do you use for the backend? The recent DartConf
has only 5 mins of talk of Dart server end. The emphasis seems to switch to
use Dart for front end clients.

------
matte_black
Postgres database, an express server and React front end.

------
kapauldo
Rails. It's minutes to build a functioning CRUD.

------
Ruud-v-A
You should not write a CRUD app in 2018. Update and delete are remnants from
the times where memory and disk were expensive, and update in place was a
necessity. This is no longer the case. Apart from a few very specialised use
cases, there is no need any more for update or delete. Record new facts and
don’t destroy the older ones.

~~~
cgdub
What should I use to write a CR app?

~~~
hodl
Probably Object Oriented

------
DougWebb
Disclaimer: I'm about to promote my own company, Surround Technologies[1]

Reading through all of the comments so far, I'm seeing solutions that give you
a CRUD web app... and nothing else. If that's all you really need, then that's
fine. For the past seven years I've been working with large companies who need
Enterprise-class CRUD apps, with Enterprise-class requirements that go far
beyond what you get out of the box with most of the cobble-it-together-
yourself solutions being mentioned here.

Surround Accelerator is a CRUD Application Generator and Framework. To use it,
you first develop an optional plugin that customizes the generator, then you
run the generator and point it at your database. It loads the schema, does a
bunch of analysis, and asks you a bunch of questions. Your plugin is used to
govern the analysis and provide standard answers to the questions, so that you
can customize the result consistently. Finally, a set of C# web services and
applications are created. We're currently producing both a WPF desktop
application and a fully-responsive ASP.Net MVC SPAs. Both GUIs are highly
customizable; our framework is very flexible and all of the code you need to
change to customize the application is part of the generation rather than
locked up in the framework.

Generation isn't a one-time thing though; if your schema changes we've got
tools that you can use to re-generate just the parts you've changed, or to add
generation for the parts that are new. Typically, the way we've structured our
code to allow for customization, it's easy to merge your customizations back
into the generated code.

If any of this interests you, please visit our website. We've got a number of
videos showing the process, a bunch of demos, and many case studies and
testimonials from actual customers.

[1] [http://surroundtech.com/](http://surroundtech.com/)

