Ask HN: Easiest way to build a CRUD app?

Yup. That's how we think about it. Avo is for Rails what Rails is for web development. It should increase your speed a few times (3x-10x).

Also Avo is so much more than just CRUD. You can easily break out of CRUD and create your own pages and dynamic content in it; dashboards is incoming in the next month; authorization; multi-tenancy; multi-resource search; and much more.

We're trying to figure out a way so we distance ourselver from being just "a prettier activeadmin", but a full on rocket of a developer platform.

Thank you for your compliment!

The absolute simplest setup that i've ever seen would be along the lines of the following:

  - PHP on the server, regular .php files that process the requests
  - Apache2/httpd as your web server
  - SQLite as your database (just a file), through PHP's PDO
  - just regular JS/CSS files for additional functionality that you need (e.g. add jQuery/Bootstrap)
  - no Composer or reliance on external dependencies or package management whatsoever

That said, every application that i've seen that has been written this way has been pretty bad - eventually you develop your own badly tested and badly documented abstractions that will slow you down towards the end of the project development and will cripple most of the developers that will need to take over your mess. Furthermore, security is generally an issue, since you should almost never write your own security code under most circumstances, but you probably will do just that with this approach. Also, managing the installation will eventually be a bit problematic, as your current PHP version will be deprecated.

For those reasons (and some others), i'd generally advise people to go with one of the other popular web frameworks with server side rendering:

  - PHP with Laravel/Lumen/Slim
  - Ruby with Rails
  - Python with Django

Now, some might prefer having a separate front end application (Angular, React, Vue, Svelte) from the back end (probably REST for its simplicity), but that's just introducing more complexity into the mix than necessary in this case, even though it has other benefits in regards to eventually scaling and/or swapping out bits of functionality for other technologies down the road.

Personally, i'd look in the direction of using something like MariaDB for the simpler apps that might need to eventually have a separate DB instance, as well as containers for managing the runtimes of everything as well as networking (Docker, Docker Compose, Docker Swarm, rather than something complicated like Kubernetes), but none of that is also strictly necessary.

As for the actual servers, just get an Ubuntu LTS VPS on whatever provider is affordable to you. It has a long life cycle, is generally pretty well documented and pretty boring. That way you can also migrate elsewhere if need be.

We are currently thinking about how to break that barrier.

When talking about configuring Avo, it's not really about having the best ruby developer. Instead, you just need a crafty developer.

If you bring in any PHP/JS/Python/INSERT_PROGRAMMING_LANG_HERE developer, they will know how to write that one-liner that adds that new field to a resource.

The alternatives are to use "general purpose" low-code tools (like re-tool) or mash it all together yourself using packages like AG Grid, both having the burden of a steep learning curve and continuous maintenance. With Avo, you need to know a bit of ruby and let it help you get the job done.

Avo is designed to be a bit boring like Rails. You build it; it works, and then you forget about it.

I am really liking nextjs but with the caveat of only if you already are on the NPM hamster wheel (braking changes are too regular in that ecosystem) and already love React

I use Grails, which is Spring Boot with sane defaults already configured. Grails is very similar to Rails, while Spring Boot still involves some configuration.