If applicable, instead of a full-blown app, could try a self-hosted forms solution, like https://github.com/ohmyform/ohmyform
Ask HN: Easiest way to build a CRUD app?
31–40 of 239 posts
Re: Ask HN: Easiest way to build a CRUD app?
#32I know, use WordPress!
(...I'll show myself out)
Re: Ask HN: Easiest way to build a CRUD app?
#33I've been working on a tool that generates the basic scaffolding for a CRUD API/GraphQL app in Node/Mongo/Express. Basically you write descriptions of your database models and it produces a very simple standalone app - you just go into the new folder, do npm install and run it, and it works out the gate. It's made to save you all the dull parts of creating a simple CRUD tool to get up and running, which you can then go ahead and add on to as you need.
I'd link to it but it's not really ready for prime time. But there's probably a billion other similar tools like it already. For me, it was built out of the desire to create, not a framework, but a static code generator - it literally generates the .js files for you, you only run it once to generate those files, and the tool itself isn't part of the finished app at all.
Re: Ask HN: Easiest way to build a CRUD app?
#34I would recommend Rails.
You can just do:
bin/rails generate scaffold Car title:string amount:integer
I can also be deployed without any K8s, Docker ... (but I recommend at least an Ansible set up so you can migrate the hosting easy between providers)
You can directly deploy it simply to a machine with Nginx and PostgreSQL.
Re: Ask HN: Easiest way to build a CRUD app?
#35I would go for Ruby on Rails, or a more modern Phoenix Framework (Elixir). With Phoenix you can also use Phoenix LiveView to avoid writing JavaScript. Very stable, scalable and low-hassle once you deploy.
I can second this. I am using Elixir/Phoenix/LiveView for a new web app I am launching soon, and I have not written a single line of javascript so far.
Re: Ask HN: Easiest way to build a CRUD app?
#36I'd go with Perl Dancer, SQLite and plain HTML.
Perl rocks.
Re: Ask HN: Easiest way to build a CRUD app?
#37I would go for Ruby on Rails, or a more modern Phoenix Framework (Elixir). With Phoenix you can also use Phoenix LiveView to avoid writing JavaScript. Very stable, scalable and low-hassle once you deploy.
LiveView is amazingly productive, and it allows you to make highly interactive webapps much faster than if you make a REST/front-end split, just using regular Elixir.
Re: Ask HN: Easiest way to build a CRUD app?
#38Almost all the answers I can see at time of replying are assuming a web application. Web applications will require at a minimum HTML, CSS a server side language and probably Javascript.
To meet your criteria for:
no: >multiple programming/scripting languages to learn
You could look at building a Java FX or Java Swing desktop application with a Java server (SOAP or RPC).
Quite a few exploits (CORS, XSS) are not possible in a desktop app or are less likely to cause problems as your users aren't loading web pages.
The Java ecosystem is large and there are many stable libraries and frameworks out there that can help with CRUD application development.
The difficulty with desktop apps is updating the client on users machines. If you can get a Long Term Support (LTS) version of OpenJDK installed on your users machines, updates could be as simple as getting the users to copy paste a JAR file from a network share. There are probably nifty ways to get the client to ask the server for any updates, download the new JAR then tell the user to restart.
Re: Ask HN: Easiest way to build a CRUD app?
#39rails
agreed. rails.
Re: Ask HN: Easiest way to build a CRUD app?
#40I find it a little disappointing that everyone (including the OP) assumes a CRUD app must be a web-application.
In a web-application you are NECESSARILY breaking, in all but the most exotic cases, the "multiple programming/scripting languages to learn" AND "external dependencies" requirement. Almost always, the "simple and resilient, can last for a long time" requirement goes out the window as well.
If the requirements given by the OP are intended to be strict, then they need to go desktop. A few things come to mind...
* java swing -- OK, it's not simple, but it is "one language" and quite self-contained, ORM is extensive. Many teams still work on 20 year old codebases in this stuff.
* .net desktop UI's -- .net, especially lately, is a great choice if you want to remain in a "large-enough" walled-garden. For UI, there's a lot to choose from, winforms would keep the OP very strictly in the "one language" zone. If they're willing to go XAML based, then options open up a lot with the trade off that there's a lot more complexity/learning-curve to deal with.
Both of these options have the ability to "launch" from a website (java webstart and .net clickonce), and both could talk through native remote procedure calls, use a REST API or even through gRPC to a service written by the OP in the same language. So it's not like they're inflexible.